From nobody Wed Jan 1 14:58: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 CF6C9120058 for ; Wed, 1 Jan 2020 14:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 TrQa1sb30Pix for ; Wed, 1 Jan 2020 14:58:00 -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 C8EE212000F for ; Wed, 1 Jan 2020 14:57:59 -0800 (PST) Received: from [192.168.1.16] (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 001Mvqo8027936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 Jan 2020 17:57:53 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0F48C972-51F4-4961-9C02-6CEF438DE5E1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 1 Jan 2020 17:57:52 -0500 In-Reply-To: Cc: Eve Maler , "rdd@cert.org" , txauth@ietf.org, Benjamin Kaduk To: Dick Hardt References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <07AEE8DB-A0EE-4780-9CE7-B578F69948F9@mit.edu> <68CA5C79-10AB-42E6-B4A9-06A594CA436C@mit.edu> <3066B58F-47D5-48C6-B705-A9F3F58EB496@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed 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: Wed, 01 Jan 2020 22:58:04 -0000 --Apple-Mail=_0F48C972-51F4-4961-9C02-6CEF438DE5E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 31, 2019, at 3:40 PM, Dick Hardt wrote: >=20 > On Tue, Dec 31, 2019 at 11:01 AM Justin Richer > wrote: >>=20 >>>=20 >>>>=20 >>>> 2. Why do you restrict this to HTTP? >>>=20 >>> Because I want us to use all of the features and benefits of HTTP = instead of having to invent within-protocol functions to replicate them. = I don=E2=80=99t want SOAP, which pretends to be transport agnostic much = to its detriment. If someone wants to do OAuth 3 on not-HTTP, they can = define what that looks like. This is what happened with the COAP/CORE = stuff and OAuth 2. >>>=20 >>> I agree SOAP was complicated. Which features and benefits of HTTP = are you wanting to use?=20 >>>=20 >>=20 >> Well so far we=E2=80=99ve got headers, URLs, methods, data payload = types, and the whole array of technologies that we can rely on working = together along with HTTP. >>=20 >> But which ones do you want to use? >> =20 >=20 > Those things that I already listed are what I want to use. I want to = use the headers for sending key proofs and probably content negotiation. = I want to have content negotiation so that we can have an option to use = JOSE (or COSE) as the body format instead of JSON, but that function = switch should come from the transport protocol (HTTP) and not something = internal to our protocol. I want to be able to use redirects to get the = user to interact, and get back from the interaction. I want to = (eventually) do things like token revocation using a DELETE verb instead = of a separate endpoint. I want to use HTTP Message Signatures (once they = exist) as a key presentation mechanism. And I want our security = considerations to be able to take into account the particulars of HTTP, = TLS, and the like when we write them. >=20 > Thanks for clarifying. I agree that using the http content-type = header, and http verbs is preferable to inventing new mechanisms. Thanks, and those are just some examples. I want us to have all of = HTTP=E2=80=99s features as options that we can use without reinventing = them, even things I can=E2=80=99t think of right now. > =20 >=20 >>=20 >>=20 >>> If it was simple to support COAP, why would we not do that? >>=20 >> Because it=E2=80=99s not just COAP =E2=80=94 you=E2=80=99ve got a = different set of assumptions for the lower layer protocols, and you=E2=80=99= ve got lots of considerations about how the different components can = talk to each other in the embedded space.=20 >>=20 >> You are suggesting we rule out it working with COAP in the charter, = before we have even had a chance to work on it. >>=20 >> Perhaps it will be trivial to support COAP. We won't know if the = charter forbids it. >=20 > If it turns out to be trivial and people want to include it and do the = work here, then we could always update the charter to include it. I = would rather see that than us trying to enumerate all of the target = carrier mechanisms. Because if we do COAP, why not MQTT? Or BluetoothLE?=20= >=20 > If we include COAP, then to my mind that necessitates one of two = things, if not both: >=20 > 1) We have a document that says =E2=80=9CIF you=E2=80=99re doing HTTP = do (A) if you=E2=80=99re doing COAP do (B)=E2=80=9D > 2) We have an =E2=80=9Cabstract=E2=80=9D document that says = =E2=80=9Chere=E2=80=99s this thing but for details on how to do it go = read the HTTP document and/or the COAP document=E2=80=9D, but when you = read the HTTP or COAP documents, they don=E2=80=99t have any information = about what the thing is because it=E2=80=99s in the abstract.=20 >=20 > =46rom a developer=E2=80=99s perspective, I would rather have an HTTP = document be self-contained, and a COAP document be self-contained. And = if the two describe the same process, or one inherits from the other but = says =E2=80=9Cinstead of doing HTTP thing X do COAP equivalent Y=E2=80=9D,= then that=E2=80=99s good.=20 >=20 > I agree completely. > =20 >=20 > But overly abstracting a system is both tempting and potentially = disastrous.=20 >=20 > I agree.=20 >=20 > I align with the design tenet: >=20 > "Easy things should be easy, hard things should be possible" -- Larry = Wall >=20 > If the WG has a choice between A and B, and they all other things are = equal for an HTTP implementation, but B is much better for COAP, then I = would suggest we choose B. >=20 > I'm not saying COAP support should be a priority, I'm saying we should = not completely ignore it.=20 I am in full agreement with these principles, since it would make = alignment for any present or future COAP version of this protocol to be = built. I think we can manage that while still focusing on an HTTP-bound = process, without getting into the over-abstraction problem. > =20 >=20 >> =20 >>=20 >> In my experience, it=E2=80=99s much more successful to have a = protocol strongly integrated with its transport mechanism and then = translated out to other mechanisms, instead of trying to come up with = one universal interlingua of a protocol that just get shunted along. >>=20 >> Would you provide an example besides SOAP for this? >=20 > It=E2=80=99s the most egregious example that comes to mind for me, so = that=E2=80=99s why I keep coming back to it. I also have in mind a dozen = projects that never went anywhere, and nobody=E2=80=99s heard of, = because of an outmoded effort being put into defining abstractions ahead = of time in order to allow transport-agnostic messaging.=20 >=20 > A similar level of overly-eager abstraction went into JOSE, with the = JWA document. It makes it so that JWS, JWE, and JWK make no sense = without JWA, and JWA is just a collection of content that really should = have been included inline with the other documents.=20 >=20 > I want to avoid that kind of thing. >=20 > Agreed > =20 >=20 >> =20 >> This is why SOAP can=E2=80=99t use HTTP verbs to communicate things, = and why the only signatures it can use are internal. When you do that = kind of system, you almost always end up having people just use it with = one transport anyway, like SOAP over HTTP. >>=20 >>> =20 >>>=20 >>>>=20 >>>> 3. Why is authentication not in scope? >>>=20 >>> It felt, to me, like that might be a bridge too far. >>>=20 >>> I disagree. But I also think that authentication is the wrong term. = Identity* may be a term that maps better, as the Client is wanting to = get "identity" data from the AS.=20 >>>=20 >>> * The identity term is super confusing, but authentication implies = just knowing it is the same user, where OpenID Connect also provides = claims about the user. >>=20 >> I=E2=80=99m coming around to this view, but I would still like it to = be separate. >>=20 >> What does separate mean? >=20 > It means that the bits that say =E2=80=9Cthis is how you talk about = identity information in the response=E2=80=9D are controlled by a = separate spec that not everyone needs to understand. I think there are = too many use cases of wanting to get API access and NOT user information = for it to be a core piece.=20 >=20 > Some developers only care about identity. Some only care about API = access. It should be easy for both. Perhaps, but that gets us into an important question of what the result = of the transaction should be. In my view, it=E2=80=99s delegation for = access to something =E2=80=94 some bit of information. In the OIDC = model, that includes information about who the current user is. OAuth 2 = always returns an access token, no matter what you do. Is this still the = right model? Right now in XYZ that=E2=80=99s how it works, but in the = pure-identity case and in Annabelle=E2=80=99s extended use case, that = isn=E2=80=99t true.=20 The hard question there, to me, is how do we switch that kind of = behavior. I=E2=80=99m not fond of something like = =E2=80=9Creturn_type=3Didentity=E2=80=9D or = =E2=80=9Creturn_type=3Daccess_token=E2=80=9D, since these tend to be = both limiting and overbuilt at the same time. But I=E2=80=99ve struggled = with how to manage this, and if we=E2=80=99re going to include identity = and other use cases in the charter explicitly, then it=E2=80=99s = something we=E2=80=99ll need to have a good solution for.=20 > =20 >=20 > However, this is arguably getting into the details of how to slice up = different documents, which is really a decision to be made once the WG = is running and not during the charter.=20 >=20 > Currently, identity is not in scope of the charter, which is why I am = bringing it up. I=E2=80=99m currently thinking something like this for the charter text = to set the right scope: resulting in information about the request (such as a user=E2=80=99= s identity or current status) and/or an artifact that will allow the = client to undertake the delegated action. In other words, our focus is on the delegation protocol, not what it=E2=80= =99s delegating to. But the ability to include information in that = protocol directly is a potentially powerful pattern and we should = probably include some of that in our scope. I think the identity portion = can be fairly minimal, at least as a starting point. > =20 >=20 >> =20 >>=20 >>> =20 >>> If we do decide it=E2=80=99s in scope, then I think it should be = clearly layered on top of the authorization layer.=20 >>>=20 >>> Being layered on top is confusing. An OpenID Connect flow where the = Client receives an ID token, has not authorization, unless you are = counting the UX as authorization -- but that does not seem like a layer. = Would you elaborate? >>> =20 >>=20 >> What you=E2=80=99re doing in OIDC is authorizing the application to = know who you are =E2=80=94 to get your identity information. That key = insight is what makes the combination of OAuth and OIDC work as well as = it does. And, importantly, once you authorize identity access, you can = authorize other stuff as well. >>=20 >>=20 >> As I stated, there is the UX of authorizing knowing who the user is, = but there is no artifact representing that authorization as there is in = OAuth -- ie there is no access token to access a resource. (yes, an = access token may be used to read the user info endpoint, but that is all = it can do.=20 >> =20 >> And it=E2=80=99s the =E2=80=9Cand other stuff=E2=80=9D that people = really, really, really like about OIDC. Nobody ever wants just = authorization, in practice.=20 >>=20 >> Did you mean to say "authentication"? >>=20 >> If so, then I would posit that there are more OIDC user interactions = than plain OAuth 2.0 user interactions, and that almost all of those = OIDC user interactions are just logging in with Google or Facebook -- = and that there is no "and other stuff". >>=20 >=20 > Yes, I meant authentication, thank you.=20 >=20 > I=E2=80=99m not sure it=E2=80=99s true, but I=E2=80=99ll agree that = it=E2=80=99s more public-facing. But even if what you posit is actually = true by raw numbers, it=E2=80=99s not universal. In particular, there = are a large number of system-to-system cases that OAuth 2 covers, which = have nothing to do with identity, that we don=E2=80=99t want to throw = out. >=20 > I'm not suggesting that those use cases should be thrown out, nor = second class. Good, because it=E2=80=99s important that we do think of this as more = than just a pure authentication system.=20 > =20 >=20 >>=20 >> =20 >> =20 >>=20 >>>=20 >>>>=20 >>>> 4. When you say "not backwards compatible with OAuth 2.0 and its = extensions", do you expect to define a new standard to replace RFC 6750? = Developers will have to have a new method to call APIs? >>>=20 >>> Kinda. First, it=E2=80=99s more 6749 that I want to step away from. = But even then, I think keeping just the header version of 6750 is OK = enough if someone wants to keep using that. The thing is, won=E2=80=99t = someone seeing an OAuth 2 header assume the rest of OAuth 2 = infrastructure? In some cases this won=E2=80=99t matter, but in many = that could be really confusing.=20 >>>=20 >>> One of the problems, though, is that 6750 has already been clouded = by things like the MTLS binding, where they use =E2=80=9Cbearer=E2=80=9D = tokens that have to be bound to the client=E2=80=99s certificate. So =E2=80= =A6 not much of a bearer token anymore. >>>=20 >>> So, are you are you proposing that Tx have a new mechanism for API = calls? >>=20 >> Yes, I think there will be new mechanisms for different kinds of = key-bound tokens. >>=20 >> So are you proposing that OAuth 3.0 will not support bearer tokens? >=20 > That is not correct and I=E2=80=99m not sure where you got that. = Bearer tokens are still useful. But they should look and behave as = distinct from sender-constrained tokens. But ultimately we can tell the = client how the token gets used, as below. >=20 > It was not clear from your response, as a new mechanism could mean = that the old one is not used anymore. >=20 > To clarify, you expect there will be additional mechanisms. Correct. I would expect us to either redefine or re-use bearer tokens a = la 6750 in some capacity but also have other presentation mechanism, = like using HTTP Signatures (once Annabelle and my draft is real) and = MTLS binding (like the OAuth MTLS binding).=20 Thanks again for the great discussion! It=E2=80=99s important to get = these details out where they=E2=80=99re readable. =E2=80=94 Justin= --Apple-Mail=_0F48C972-51F4-4961-9C02-6CEF438DE5E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Dec 31, 2019, at 3:40 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

On Tue, Dec 31, 2019 at = 11:01 AM Justin Richer <jricher@mit.edu> wrote:



2. Why = do you restrict this to HTTP?

Because I want us to use = all of the features and benefits of HTTP instead of having to invent = within-protocol functions to replicate them. I don=E2=80=99t want SOAP, = which pretends to be transport agnostic much to its detriment. If = someone wants to do OAuth 3 on not-HTTP, they can define what that looks = like. This is what happened with the COAP/CORE stuff and OAuth = 2.

I agree SOAP was complicated. Which features and benefits of = HTTP are you wanting to use? 


Well so far we=E2=80=99ve got headers, = URLs, methods, data payload types, and the whole array of technologies = that we can rely on working together along with = HTTP.

But which ones do you want to = use?
 

Those things that I = already listed are what I want to use. I want to use the headers for = sending key proofs and probably content negotiation. I want to have = content negotiation so that we can have an option to use JOSE (or COSE) = as the body format instead of JSON, but that function switch should come = from the transport protocol (HTTP) and not something internal to our = protocol. I want to be able to use redirects to get the user to = interact, and get back from the interaction. I want to (eventually) do = things like token revocation using a DELETE verb instead of a separate = endpoint. I want to use HTTP Message Signatures (once they exist) as a = key presentation mechanism. And I want our security considerations to be = able to take into account the particulars of HTTP, TLS, and the like = when we write them.

Thanks for clarifying. I agree that = using the http content-type header, and http verbs is preferable to = inventing new mechanisms.

Thanks, and those are just some examples. I want = us to have all of HTTP=E2=80=99s features as options that we can use = without reinventing them, even things I can=E2=80=99t think of right = now.

 



If it = was simple to support COAP, why would we not do = that?

Because it=E2=80=99s not just COAP =E2=80= =94 you=E2=80=99ve got a different set of assumptions for the lower = layer protocols, and you=E2=80=99ve got lots of considerations about how = the different components can talk to each other in the embedded = space. 

You are suggesting we rule out it = working with COAP in the charter, before we have even had a chance to = work on it.

Perhaps it will be trivial to support COAP. We won't know if = the charter forbids it.

If it turns out to be trivial and = people want to include it and do the work here, then we could always = update the charter to include it. I would rather see that than us trying = to enumerate all of the target carrier mechanisms. Because if we do = COAP, why not MQTT? Or BluetoothLE? 

If we include COAP, then to my mind = that necessitates one of two things, if not both:
1) We have a document that says =E2=80=9C= IF you=E2=80=99re doing HTTP do (A) if you=E2=80=99re doing COAP do = (B)=E2=80=9D
2) We have an =E2=80=9Cabstract=E2=80=9D= document that says =E2=80=9Chere=E2=80=99s this thing but for details = on how to do it go read the HTTP document and/or the COAP document=E2=80=9D= , but when you read the HTTP or COAP documents, they don=E2=80=99t have = any information about what the thing is because it=E2=80=99s in the = abstract. 

=46rom a developer=E2=80=99s perspective, I would rather have = an HTTP document be self-contained, and a COAP document be = self-contained. And if the two describe the same process, or one = inherits from the other but says =E2=80=9Cinstead of doing HTTP thing X = do COAP equivalent Y=E2=80=9D, then that=E2=80=99s = good. 

I agree completely.
 

But overly abstracting a = system is both tempting and potentially = disastrous. 

I agree. 

I align with the design = tenet:

"Easy = things should be easy, hard things should be possible" -- Larry = Wall

If the WG = has a choice between A and B, and they all other things are equal for an = HTTP implementation, but B is much better for COAP, then I would suggest = we choose B.

I'm= not saying COAP support should be a priority, I'm saying we should not = completely ignore it. 

I am in full agreement with these principles, = since it would make alignment for any present or future COAP version of = this protocol to be built. I think we can manage that while still = focusing on an HTTP-bound process, without getting into the = over-abstraction problem.

 

 

In my = experience, it=E2=80=99s much more successful to have a protocol = strongly integrated with its transport mechanism and then translated out = to other mechanisms, instead of trying to come up with one universal = interlingua of a protocol that just get shunted = along.

Would you provide an example besides = SOAP for this?

It=E2=80=99s the most egregious example = that comes to mind for me, so that=E2=80=99s why I keep coming back to = it. I also have in mind a dozen projects that never went anywhere, and = nobody=E2=80=99s heard of, because of an outmoded effort being put into = defining abstractions ahead of time in order to allow transport-agnostic = messaging. 

A similar level of overly-eager abstraction went into JOSE, = with the JWA document. It makes it so that JWS, JWE, and JWK make no = sense without JWA, and JWA is just a collection of content that really = should have been included inline with the other = documents. 

I want to avoid that kind of = thing.

Agreed
 

 
This is why SOAP can=E2=80=99t use HTTP verbs = to communicate things, and why the only signatures it can use are = internal. When you do that kind of system, you almost always end up = having people just use it with one transport anyway, like SOAP over = HTTP.

 


3. Why = is authentication not in scope?

It felt, to me, like = that might be a bridge too far.

I disagree. But I also = think that authentication is the wrong term. Identity* may be a term = that maps better, as the Client is wanting to get "identity" data from = the AS. 

* = The identity term is super confusing, but authentication implies just = knowing it is the same user, where OpenID Connect also provides claims = about the user.

I=E2=80=99m coming around to this view, = but I would still like it to be = separate.

What does separate = mean?

It means that the bits that say =E2=80=9C= this is how you talk about identity information in the response=E2=80=9D = are controlled by a separate spec that not everyone needs to understand. = I think there are too many use cases of wanting to get API access and = NOT user information for it to be a core = piece. 

Some developers only care about = identity. Some only care about API access. It should be easy for = both.

Perhaps, but that gets us into an important = question of what the result of the transaction should be. In my view, = it=E2=80=99s delegation for access to something =E2=80=94 some bit of = information. In the OIDC model, that includes information about who the = current user is. OAuth 2 always returns an access token, no matter what = you do. Is this still the right model? Right now in XYZ that=E2=80=99s = how it works, but in the pure-identity case and in Annabelle=E2=80=99s = extended use case, that isn=E2=80=99t true. 

The hard question there, to me, is how do we = switch that kind of behavior. I=E2=80=99m not fond of something like = =E2=80=9Creturn_type=3Didentity=E2=80=9D or = =E2=80=9Creturn_type=3Daccess_token=E2=80=9D, since these tend to be = both limiting and overbuilt at the same time. But I=E2=80=99ve struggled = with how to manage this, and if we=E2=80=99re going to include identity = and other use cases in the charter explicitly, then it=E2=80=99s = something we=E2=80=99ll need to have a good solution for. 

 

However, this is arguably getting into the details of how to = slice up different documents, which is really a decision to be made once = the WG is running and not during the = charter. 

Currently, identity is not in scope of = the charter, which is why I am bringing it = up.

I=E2=80=99= m currently thinking something like this for the charter text to set the = right scope:

resulting = in information about the request (such as a user=E2=80=99s identity or = current status) and/or an artifact that will allow the client to = undertake the delegated action.

In = other words, our focus is on the delegation protocol, not what it=E2=80=99= s delegating to. But the ability to include information in that protocol = directly is a potentially powerful pattern and we should probably = include some of that in our scope. I think the identity portion can be = fairly minimal, at least as a starting point.

 

 

 
If we do decide it=E2=80=99s in scope, then I = think it should be clearly layered on top of the authorization = layer. 

Being layered on top is confusing. An = OpenID Connect flow where the Client receives an ID token, has not = authorization, unless you are counting the UX as authorization -- but = that does not seem like a layer. Would you elaborate?
 

What you=E2=80=99re doing in OIDC is = authorizing the application to know who you are =E2=80=94 to get your = identity information. That key insight is what makes the combination of = OAuth and OIDC work as well as it does. And, importantly, once you = authorize identity access, you can authorize other stuff as = well.


As = I stated, there is the UX of authorizing knowing who the user is, but = there is no artifact representing that authorization as there is in = OAuth -- ie there is no access token to access a resource. (yes, an = access token may be used to read the user info endpoint, but that is all = it can do. 
 
And it=E2=80=99s the =E2=80=9Cand other = stuff=E2=80=9D that people really, really, really like about OIDC. = Nobody ever wants just authorization, in = practice. 

Did you mean to say = "authentication"?

If so, then I would posit that there are more OIDC user = interactions than plain OAuth 2.0 user interactions, and that almost all = of those OIDC user interactions are just logging in with Google or = Facebook -- and that there is no "and other stuff".


Yes, I meant = authentication, thank you. 

I=E2=80=99m not sure it=E2=80=99s true, = but I=E2=80=99ll agree that it=E2=80=99s more public-facing. But even if = what you posit is actually true by raw numbers, it=E2=80=99s not = universal. In particular, there are a large number of system-to-system = cases that OAuth 2 covers, which have nothing to do with identity, that = we don=E2=80=99t want to throw out.

I'm not suggesting that = those use cases should be thrown out, nor second = class.

Good, = because it=E2=80=99s important that we do think of this as more than = just a pure authentication system. 

 


 
 



4. When = you say "not backwards compatible with OAuth 2.0 and its extensions", do = you expect to define a new standard to replace RFC 6750? Developers will = have to have a new method to call = APIs?

Kinda. First, it=E2=80=99s more 6749 = that I want to step away from. But even then, I think keeping just the = header version of 6750 is OK enough if someone wants to keep using that. = The thing is, won=E2=80=99t someone seeing an OAuth 2 header assume the = rest of OAuth 2 infrastructure? In some cases this won=E2=80=99t matter, = but in many that could be really confusing. 
One of the problems, though, is that = 6750 has already been clouded by things like the MTLS binding, where = they use =E2=80=9Cbearer=E2=80=9D tokens that have to be bound to the = client=E2=80=99s certificate. So =E2=80=A6 not much of a bearer token = anymore.

So, are you are you proposing that Tx = have a new mechanism for API = calls?

Yes, I think there will be new = mechanisms for different kinds of key-bound = tokens.

So are you proposing that OAuth 3.0 = will not support bearer tokens?

That is not correct and = I=E2=80=99m not sure where you got that. Bearer tokens are still useful. = But they should look and behave as distinct from sender-constrained = tokens. But ultimately we can tell the client how the token gets used, = as below.

It was not clear from your response, as = a new mechanism could mean that the old one is not used = anymore.

To = clarify, you expect there will be additional = mechanisms.

Correct. I would expect us to either redefine or = re-use bearer tokens a la 6750 in some capacity but also have other = presentation mechanism, like using HTTP Signatures (once Annabelle and = my draft is real) and MTLS binding (like the OAuth MTLS = binding). 

Thanks again for the = great discussion! It=E2=80=99s important to get these details out where = they=E2=80=99re readable.

 =E2=80= =94 Justin
= --Apple-Mail=_0F48C972-51F4-4961-9C02-6CEF438DE5E1-- From nobody Thu Jan 2 16:18: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 1D2B212018D for ; Thu, 2 Jan 2020 16:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.497 X-Spam-Level: X-Spam-Status: No, score=-14.497 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 nLOTA9P_AEKW for ; Thu, 2 Jan 2020 16:18:37 -0800 (PST) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.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 15BCA120817 for ; Thu, 2 Jan 2020 16:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578010717; x=1609546717; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IBAkL80ccRa8hSGWKymuSMD135qzmufKlZYzTG9uceI=; b=HRQouOCQFzfxVp3X3wAWcGPKGWeoQH2HfI7ftxqSO2If9BHK6vEk22CH fjY7nL+jYh/6Uz4s38kKvOmKb9lQTUUoe3c5zFiq1WnXTef4BdG+YF18a moJDslNWa6QHGRRCJpcIJDbkXeE2NXZV7O9eOmY8+3yn55IAx4KgrbJTc 8=; IronPort-SDR: aDDlbNqVoPBlXQCX40XU31E8fYCIvw3A5Crt+/VXVHUtid9Z0ZIvWkwrni9JSWhb+38tvJ4uhs 8iT3v/qbRfIA== X-IronPort-AV: E=Sophos; i="5.69,388,1571702400"; d="scan'208,217"; a="10824822" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-2b-4ff6265a.us-west-2.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 03 Jan 2020 00:18:35 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2b-4ff6265a.us-west-2.amazon.com (Postfix) with ESMTPS id BCABDA23DF; Fri, 3 Jan 2020 00:18:33 +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, 3 Jan 2020 00:18:32 +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.1367.3; Fri, 3 Jan 2020 00:18:32 +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.1367.000; Fri, 3 Jan 2020 00:18:32 +0000 From: "Richard Backman, Annabelle" To: Justin Richer , Dick Hardt CC: "txauth@ietf.org" Thread-Topic: [Txauth] Framework vs Protocol Thread-Index: AQHVv3BLjLjPvzgVakaionCxh87rBKfUN1kAgABiyoCAAAObgIAC8+4A Date: Fri, 3 Jan 2020 00:18:32 +0000 Message-ID: <6DFD1CA6-D334-4FCA-9881-834571A5DE7C@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.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.118] Content-Type: multipart/alternative; boundary="_000_6DFD1CA6D3344FCA9881834571A5DE7Camazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Framework vs Protocol 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, 03 Jan 2020 00:18:39 -0000 --_000_6DFD1CA6D3344FCA9881834571A5DE7Camazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T0F1dGggMi4w4oCZcyBkZXNpZ24gcmVzdWx0ZWQgaW4gd2lsZGx5IGRpZmZlcmVudCBwcm90b2Nv bCBtZXNzYWdlcyBhbmQgY29tbXVuaWNhdGlvbiBzZXF1ZW5jZXMgZm9yIGRpZmZlcmVudCB1c2Ug Y2FzZXMuIEkgc3Ryb25nbHkgYWdyZWUgdGhhdCB0aGlzIGlzIHNvbWV0aGluZyB3ZSBzaG91bGQg YXZvaWQgd2l0aCBUeEF1dGguIEkgbGlrZSB0aGUgaWRlYSBvZiBpbmNsdWRpbmcgdGhpcyBhcyBh IHRlbmV0IHdpdGhpbiB0aGUgY2hhcnRlci4gKCsxIGZvciBtb3JlIHRlbmV0cyBhbmQgbGVzcyBt ZWNoYW5pY3MvbWV0aG9kb2xvZ3kgaW4gdGhlIGNoYXJ0ZXIgaW4gZ2VuZXJhbCkNCg0KVGhlIGN1 cnJlbnQgZG9jdW1lbnQgc2VlbXMgdG8gZG8gYSBiZXR0ZXIgam9iIG9mIGxheWluZyBvdXQgYSBj b3JlIG1lc3NhZ2UgYW5kIGNvbW11bmljYXRpb24gcGF0dGVybiwgYnV0IGl0IGRvZXNu4oCZdCBh bGlnbiB3ZWxsIHdpdGggdGhlIGltcGxpY2l0IGdyYW50LiBXZSB3aWxsIHdhbnQgdG8gZGlnIGlu dG8gcGVyc2lzdGVudCB1c2UgY2FzZXMgZm9yIGltcGxpY2l0IChlLmcuLCBCcmlhbiBDYW1wYmVs bOKAmXMgdXNlIGNhc2UgaW4gdGhpcyBPQXV0aCBtYWlsaW5nIGxpc3QgdGhyZWFkPGh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvUnVjWkhLdVJmNkhDc1dVeUpESzBY Und1YjN3PikgdG8gc2VlIGlmIHRoZSBUeEF1dGggcGF0dGVybiBjYW4gc2VydmUgdGhlbSwgb3Ig aWYgdGhlcmUgYXJlIGdhcHMgdGhhdCBuZWVkIHRvIGJlIGZpbGxlZC4NCg0K4oCTDQpBbm5hYmVs bGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBUeGF1dGggPHR4YXV0 aC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSnVzdGluIFJpY2hlciA8anJpY2hlckBt aXQuZWR1Pg0KRGF0ZTogVHVlc2RheSwgRGVjZW1iZXIgMzEsIDIwMTkgYXQgMTE6MTMgQU0NClRv OiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT4NCkNjOiAidHhhdXRoQGlldGYub3Jn IiA8dHhhdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUeGF1dGhdIEZyYW1ld29yayB2cyBQ cm90b2NvbA0KDQpBbnN3ZXJzIGlubGluZS4NCg0KDQpPbiBEZWMgMzEsIDIwMTksIGF0IDI6MDAg UE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdt YWlsLmNvbT4+IHdyb3RlOg0KDQpBIGNvdXBsZSBxdWVzdGlvbnMgaW5zZXJ0ZWQgdG8gdW5kZXJz dGFuZCB3aGF0IHlvdSBhcmUgc3VnZ2VzdGluZyAuLi4uDQoNCk9uIFR1ZSwgRGVjIDMxLCAyMDE5 IGF0IDU6MDYgQU0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVy QG1pdC5lZHU+PiB3cm90ZToNCkkgYWdyZWUgd2l0aCB0aGlzLiBJIHRoaW5rIHRoYXQgd2l0aCBP QXV0aDIgdGhlIGV4dGVuc2lvbiBtZWNoYW5pc20gb2YgZ3JhbnQgdHlwZXMgd2FzIGEgZGVjZW50 IGlkZWEsIGFuZCBJ4oCZdmUgYXJndWVkIHRoYXQgaXQgbGVhZHMgdG8gc2lnbmlmaWNhbnQgYW1v dW50cyBvZiBjb2RlLXJldXNlIGZyb20gdmVyeSBkaWZmZXJlbnQgc3lzdGVtcyB0aGF0IGZ1bmN0 aW9uIGluIHZlcnkgZGlmZmVyZW50IHdheXMuDQoNCkJ1dCBJIGFsc28gdGhpbmsgdGhhdCB3aGF0 IEnigJlkIGxpa2UgdG8gc2VlIGhlcmUsIGFuZCB3aGF0IEnigJl2ZSB0cmllZCB0byBkbyB3aXRo IFhZWiwgaXMgdG8gaGF2ZSBvbmUgcHJvdG9jb2wgdGhhdCBsZXRzIHlvdSBicmFuY2ggb2ZmIGZv ciBkaWZmZXJlbnQgdXNlIGNhc2VzIHdoZXJlIG5lY2Vzc2FyeSBidXQgc3RpbGwgYnJpbmdzIHlv dSBiYWNrIHRvIHRoZSBzYW1lIHByb2Nlc3MgaW4gdGhlIGVuZC4NCg0KIi4uLiBicmluZ3MgeW91 IGJhY2sgdG8gdGhlIHNhbWUgcHJvY2VzcyBpbiB0aGUgZW5kLiIgLS0gaW1wbGllcyBzb21ldGhp bmcgZGlmZmVyZW50IHRoYW4gYmVsb3cgd2hlcmUgdGhlIHByb2Nlc3MgbWF5IGJyYW5jaCBvZmYg YW5kIGVuZCB1cCBpbiBhIGRpZmZlcmVudCBwbGFjZS4gV291bGQgeW91IGNsYXJpZnkgd2hhdCB5 b3UgbWVhbj8NCg0KSSBkaWRu4oCZdCBtZWFuIHRvIGltcGx5IHRoYXQgeW914oCZZCBlbmQgdXAg c29tZXdoZXJlIGVsc2UsIGJ1dCByYXRoZXIgdGhhdCB5b3XigJlkIHBvdGVudGlhbGx5IHRha2Ug YSBkZXRvdXIgdGhyb3VnaCBzb21lIG90aGVyIG1lY2hhbmlzbSBhbmQgY29tZSBiYWNrIHRvIHRo ZSBzYW1lIHRoaW5nIHRoYXQgeW91IHN0YXJ0ZWQuIFNvIEkgc3RhcnQgYnkgbWFraW5nIGFuIEhU VFAgY2FsbCwgYW5kIHRoZW4gbWF5YmUgSSBibGlwIG91dCBhIG51bWJlciBvdmVyIG15IHNwZWFr ZXIsIG9yIEkgc2VuZCBhIERJRENvbW0gbWVzc2FnZSB0byBhbiBhZ2VudCBvbiBteSBkZXZpY2Us IG9yIEkgcmVkaXJlY3QgdGhlIHVzZXIgb2ZmIGluIHNvbWUgYnJvd3NlciB0aGluZyDigJQgYnV0 IHRoZW4gZXZlbnR1YWxseSBJIGdvIGJhY2sgdG8gbWFraW5nIGFuIEhUVFAgY2FsbC4gVGhlIHZh cmlhYmlsaXR5IGlzIGluIHRoZSBtaWRkbGUgcGFydCwgd2hlcmUgdGhlIHVzZXIgaW50ZXJhY3Rp b24gaXMgaW52b2x2ZWQuIFRoZSB2YXJpYWJpbGl0eSBzaG91bGQgbm90IGJlIGluIGhvdyB0aGUg Y2xpZW50cyB0YWxrIHRvIG90aGVyIHN5c3RlbXMuDQoNCg0KDQpUaGlzIGlzIG9uZSBvZiB0aGUg dGhpbmdzIEkgbGlrZSBhYm91dCBoYXZpbmcgdGhlIEFTIGRlZmluZWQgYXMgdGhlIHRyYW5zYWN0 aW9uIGVuZHBvaW50IOKAlCBldmVyeW9uZSBnb2VzIHRvIG9uZSBwbGFjZSBhbmQgc2VuZHMgb25l IGtpbmQgb2YgbWVzc2FnZSB0byBzdGFydCB0aGluZ3Mgb2ZmLCBhbmQgdGhlbiB5b3UgaGF2ZSBl dmVyeXRoaW5nIHlvdSBuZWVkIHRvIGZpZ3VyZSBvdXQgd2hlcmUgdG8gZ28gZnJvbSB0aGVyZSwg ZXZlbiBpZiBpdOKAmXMgb2ZmLUhUVFAgYW5kIG91dC1vZi1iYW5kLg0KDQpBIHdheSB0byBzdGFy dCB0aGUgdHJhbnNhY3Rpb24gaW4gQ09BUCB3b3VsZCBsaWtlbHkgYmUgaW50ZXJlc3RpbmcgdG8g dGhlIGNvbnN0cmFpbmVkIGVudmlyb25tZW50IHBlb3BsZS4gV291bGQgeW91IG5vdCBhZ3JlZT8N Cg0KSSB0b3RhbGx5IGFncmVlLiBBbmQgdGhleeKAmWQgYWxzbyB3YW50IHRvIGNvbnRpbnVlIGFu ZCBmaW5pc2ggdGhlIHRyYW5zYWN0aW9uIGluIENPQVAuIEFuZCBiZSBhYmxlIHRvIGRvIHJlZGly ZWN0cyB1c2luZyBDT0FQIHByaW5jaXBsZXMgaW5zdGVhZCBvZiBIVFRQIHByaW5jaXBsZXMuIEFu ZCBnZW5lcmFsbHkgZG8gdGhpbmdzIHRoYXQgYXJlIHNpbWlsYXIgYnV0IG5vdCB0aGUgc2FtZS4g U28gaXQgdHVybnMgaW50byBhIGRpZmZlcmVudCBwcm90b2NvbCB3aXRoIHRoZSBzYW1lIGlkZWFz LCBhbmQgSeKAmW0gYWxsIGZvciB0aGF0IGhhcHBlbmluZyDigJQgYnV0IEkgZG9u4oCZdCB0aGlu ayBpdOKAmXMgYSBnb29kIGlkZWEgdG8gcHV0IGl0IGFsbCBpbiB0aGUgc2FtZSBkb2N1bWVudCwg b3IgdG8gaGF2ZSBhbiBhYnN0cmFjdCBkb2N1bWVudCB0aGF0IGV2ZXJ5b25lIHRyaWVzIHRvIGlu aGVyaXQgZnJvbS4NCg0KV2Uga25vdyB3ZSBuZWVkIGFuZCB3YW50IEhUVFAsIHNvIHRvIG1lIHRo YXTigJlzIGZpcm1seSBpbi1zY29wZS4gT3RoZXIgcHJvdG9jb2xzIGFyZSDigJx3b3VsZG7igJl0 IGl0IGJlIG5pY2UgaWYgaXQgZGlkIHRoaXPigJ0gcmlnaHQgbm93LCBhbmQgYWJzdHJhY3Rpbmcg Zm9yIHNvbWV0aGluZyB0aGF0IOKAnHdvdWxkIGJlIG5pY2XigJ0gbGVhZHMgdG8gYmFkIHN5c3Rl bSBkZXNpZ24uDQoNCknigJltIG5vdCBhZ2FpbnN0IENPQVAsIGJ1dCBsaWtlIHdpdGggT0F1dGgg YW5kIEFDRSwgSSBkb27igJl0IHRoaW5rIGl04oCZcyBnb29kIHRvIHRyeSBhbmQgY3JhbSB0aGVt IHRvZ2V0aGVyIHRoaXMgZWFybHkuDQoNCg0KDQoNCiDigJQgSnVzdGluDQoNCj4gT24gRGVjIDMw LCAyMDE5LCBhdCA3OjIwIFBNLCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWls dG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4gSSB3b3VsZCBwcm9wb3NlIHRo YXQgdGhlIHJlc3VsdGluZyB3b3JrIGlzIGEgcHJvdG9jb2wsIGFuZCBub3QgYSBmcmFtZXdvcmsu DQo+DQo+IFdoYXQgaXMgdGhlIGRpZmZlcmVuY2U/IEhlcmUgYXJlIG15IHRob3VnaHRzOg0KPg0K PiBBIGZyYW1ld29yayBkZWZpbmVzIGEgdmFyaWV0eSBvZiB3YXlzIHRvIGRvIGVhY2ggY2FwYWJp bGl0eS4gQSBmcmFtZXdvcmsgdXN1YWxseSBuZWVkcyBhIHByb2ZpbGUgZm9yIHR3byBzeXN0ZW1z IHRvIGludGVyb3BlcmF0ZS4gRm9yIGV4YW1wbGUsIE9JREMgcHJvdmlkZXMgYSBudW1iZXIgb2Yg d2F5cyB0byBnZXQgaWRlbnRpdHkgZGF0YSBmcm9tIGFuIE9QLCBhbmQgT0F1dGggMiBncmFudCB0 eXBlcyBoYXZlIG92ZXJsYXAuIEEgZnJhbWV3b3JrIGlzIGxpa2UgUGVybC4gTG90cyBvZiB3YXlz IHRvIGRvIHRoZSBzYW1lIHRoaW5nLCBtYW55IG9mIHdoaWNoIGFyZSB1bnJlYWRhYmxlLg0KPg0K PiBBIHByb3RvY29sIHByb3ZpZGVzIG9uZSB3YXkgdG8gZG8gZWFjaCBjYXBhYmlsaXR5LiAgQSBw cm90b2NvbCBpcyBsaWtlIFB5dGhvbiwgdGhlcmUgaXMgYSByaWdodCB3YXkgdG8gZG8gc29tZXRo aW5nLg0KPg0KPiBBdCB0aW1lcyBhIHN0YW5kYXJkcyBncm91cCB3aWxsIGdldCAiY29uc2Vuc3Vz IiBieSBub3QgYmVpbmcgZGVjaXNpdmUsIGFuZCBpbmNsdWRpbmcgZXZlcnlvbmUncyBmYXZvcmVk IG1lY2hhbmlzbS4gSW4gbXkgb3BpbmlvbiwgdGhpcyBtYWtlcyBkZXBsb3ltZW50cyBtb3JlIGNv bXBsaWNhdGVkIGZvciBhdmVyYWdlIGRldmVsb3BlcnMsIGFuZCBpbmNyZWFzZXMgdGhlIHN1cmZh Y2UgYXJlYSB0byBzZWN1cmUuDQo+DQo+IERvIG90aGVycyBhZ3JlZSB3aXRoIGFkZGluZyB0aGlz IGFzIGEgdGVuZXQgdG8gdGhlIGNoYXJ0ZXI/DQo+DQo+IC9EaWNrDQo+DQo+IE5vdGU6IEknbSBh IGZhbiBvZiBib3RoIFBlcmwgYW5kIFB5dGhvbi4gPSkNCj4NCj4gLS0NCj4gVHhhdXRoIG1haWxp bmcgbGlzdA0KPiBUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCg0KDQo= --_000_6DFD1CA6D3344FCA9881834571A5DE7Camazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <8D25DE65C5425C488B9819FC96DDE5AF@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PQXV0aCAyLjDigJlz IGRlc2lnbiByZXN1bHRlZCBpbiB3aWxkbHkgZGlmZmVyZW50IHByb3RvY29sIG1lc3NhZ2VzIGFu ZCBjb21tdW5pY2F0aW9uIHNlcXVlbmNlcyBmb3IgZGlmZmVyZW50IHVzZSBjYXNlcy4gSSBzdHJv bmdseSBhZ3JlZSB0aGF0IHRoaXMgaXMgc29tZXRoaW5nIHdlIHNob3VsZCBhdm9pZCB3aXRoIFR4 QXV0aC4gSSBsaWtlIHRoZSBpZGVhIG9mIGluY2x1ZGluZyB0aGlzIGFzIGEgdGVuZXQgd2l0aGlu DQogdGhlIGNoYXJ0ZXIuICgmIzQzOzEgZm9yIG1vcmUgdGVuZXRzIGFuZCBsZXNzIG1lY2hhbmlj cy9tZXRob2RvbG9neSBpbiB0aGUgY2hhcnRlciBpbiBnZW5lcmFsKTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgY3VycmVudCBkb2N1bWVudCBzZWVtcyB0byBkbyBhIGJldHRlciBqb2Igb2Yg bGF5aW5nIG91dCBhIGNvcmUgbWVzc2FnZSBhbmQgY29tbXVuaWNhdGlvbiBwYXR0ZXJuLCBidXQg aXQgZG9lc27igJl0IGFsaWduIHdlbGwgd2l0aCB0aGUgaW1wbGljaXQgZ3JhbnQuIFdlIHdpbGwg d2FudCB0byBkaWcgaW50byBwZXJzaXN0ZW50IHVzZSBjYXNlcyBmb3IgaW1wbGljaXQgKGUuZy4s IEJyaWFuIENhbXBiZWxs4oCZcw0KIHVzZSBjYXNlIGluIDxhIGhyZWY9Imh0dHBzOi8vbWFpbGFy Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvUnVjWkhLdVJmNkhDc1dVeUpESzBYUnd1YjN3 Ij4NCnRoaXMgT0F1dGggbWFpbGluZyBsaXN0IHRocmVhZDwvYT4pIHRvIHNlZSBpZiB0aGUgVHhB dXRoIHBhdHRlcm4gY2FuIHNlcnZlIHRoZW0sIG9yIGlmIHRoZXJlIGFyZSBnYXBzIHRoYXQgbmVl ZCB0byBiZSBmaWxsZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxs ZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlR4YXV0aCAmbHQ7dHhhdXRoLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVy QG1pdC5lZHUmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIERlY2VtYmVyIDMxLCAyMDE5 IGF0IDExOjEzIEFNPGJyPg0KPGI+VG86IDwvYj5EaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdt YWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3R4YXV0aEBpZXRmLm9yZyZxdW90OyAm bHQ7dHhhdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1R4YXV0aF0g RnJhbWV3b3JrIHZzIFByb3RvY29sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFuc3dlcnMgaW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRGVjIDMxLCAyMDE5LCBhdCAyOjAwIFBNLCBEaWNr IEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iPmRpY2suaGFy ZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBjb3VwbGUgcXVlc3Rpb25zIGluc2VydGVkIHRvIHVu ZGVyc3RhbmQgd2hhdCB5b3UgYXJlJm5ic3A7c3VnZ2VzdGluZyAuLi4uJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIERlYyAzMSwgMjAx OSBhdCA1OjA2IEFNIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1p dC5lZHUiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRoIHRoaXMu IEkgdGhpbmsgdGhhdCB3aXRoIE9BdXRoMiB0aGUgZXh0ZW5zaW9uIG1lY2hhbmlzbSBvZiBncmFu dCB0eXBlcyB3YXMgYSBkZWNlbnQgaWRlYSwgYW5kIEnigJl2ZSBhcmd1ZWQgdGhhdCBpdCBsZWFk cyB0byBzaWduaWZpY2FudCBhbW91bnRzIG9mIGNvZGUtcmV1c2UgZnJvbSB2ZXJ5IGRpZmZlcmVu dCBzeXN0ZW1zIHRoYXQgZnVuY3Rpb24gaW4gdmVyeSBkaWZmZXJlbnQgd2F5cy4NCjxicj4NCjxi cj4NCkJ1dCBJIGFsc28gdGhpbmsgdGhhdCB3aGF0IEnigJlkIGxpa2UgdG8gc2VlIGhlcmUsIGFu ZCB3aGF0IEnigJl2ZSB0cmllZCB0byBkbyB3aXRoIFhZWiwgaXMgdG8gaGF2ZSBvbmUgcHJvdG9j b2wgdGhhdCBsZXRzIHlvdSBicmFuY2ggb2ZmIGZvciBkaWZmZXJlbnQgdXNlIGNhc2VzIHdoZXJl IG5lY2Vzc2FyeSBidXQgc3RpbGwgYnJpbmdzIHlvdSBiYWNrIHRvIHRoZSBzYW1lIHByb2Nlc3Mg aW4gdGhlIGVuZC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7Li4uIGJyaW5ncyB5b3UgYmFjayB0byB0aGUgc2FtZSBw cm9jZXNzIGluIHRoZSBlbmQuJnF1b3Q7IC0tIGltcGxpZXMgc29tZXRoaW5nIGRpZmZlcmVudCB0 aGFuIGJlbG93IHdoZXJlIHRoZSBwcm9jZXNzIG1heSBicmFuY2ggb2ZmIGFuZCBlbmQgdXAgaW4g YSBkaWZmZXJlbnQgcGxhY2UuIFdvdWxkIHlvdSBjbGFyaWZ5IHdoYXQgeW91IG1lYW4/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZGlkbuKAmXQgbWVhbiB0byBpbXBseSB0 aGF0IHlvdeKAmWQgZW5kIHVwIHNvbWV3aGVyZSBlbHNlLCBidXQgcmF0aGVyIHRoYXQgeW914oCZ ZCBwb3RlbnRpYWxseSB0YWtlIGEgZGV0b3VyIHRocm91Z2ggc29tZSBvdGhlciBtZWNoYW5pc20g YW5kIGNvbWUgYmFjayB0byB0aGUgc2FtZSB0aGluZyB0aGF0IHlvdSBzdGFydGVkLiBTbyBJIHN0 YXJ0IGJ5IG1ha2luZyBhbiBIVFRQIGNhbGwsIGFuZCB0aGVuIG1heWJlIEkNCiBibGlwIG91dCBh IG51bWJlciBvdmVyIG15IHNwZWFrZXIsIG9yIEkgc2VuZCBhIERJRENvbW0gbWVzc2FnZSB0byBh biBhZ2VudCBvbiBteSBkZXZpY2UsIG9yIEkgcmVkaXJlY3QgdGhlIHVzZXIgb2ZmIGluIHNvbWUg YnJvd3NlciB0aGluZyDigJQgYnV0IHRoZW4gZXZlbnR1YWxseSBJIGdvIGJhY2sgdG8gbWFraW5n IGFuIEhUVFAgY2FsbC4gVGhlIHZhcmlhYmlsaXR5IGlzIGluIHRoZSBtaWRkbGUgcGFydCwgd2hl cmUgdGhlIHVzZXIgaW50ZXJhY3Rpb24NCiBpcyBpbnZvbHZlZC4gVGhlIHZhcmlhYmlsaXR5IHNo b3VsZCBub3QgYmUgaW4gaG93IHRoZSBjbGllbnRzIHRhbGsgdG8gb3RoZXIgc3lzdGVtcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgb25lIG9mIHRoZSB0aGluZ3MgSSBsaWtlIGFib3V0IGhh dmluZyB0aGUgQVMgZGVmaW5lZCBhcyB0aGUgdHJhbnNhY3Rpb24gZW5kcG9pbnQg4oCUIGV2ZXJ5 b25lIGdvZXMgdG8gb25lIHBsYWNlIGFuZCBzZW5kcyBvbmUga2luZCBvZiBtZXNzYWdlIHRvIHN0 YXJ0IHRoaW5ncyBvZmYsIGFuZCB0aGVuIHlvdSBoYXZlIGV2ZXJ5dGhpbmcgeW91IG5lZWQgdG8g ZmlndXJlIG91dCB3aGVyZSB0byBnbyBmcm9tDQogdGhlcmUsIGV2ZW4gaWYgaXTigJlzIG9mZi1I VFRQIGFuZCBvdXQtb2YtYmFuZC4gPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHdheSB0byBzdGFydCB0aGUgdHJhbnNhY3Rpb24g aW4gQ09BUCB3b3VsZCBsaWtlbHkgYmUgaW50ZXJlc3RpbmcgdG8gdGhlIGNvbnN0cmFpbmVkIGVu dmlyb25tZW50IHBlb3BsZS4gV291bGQgeW91IG5vdCBhZ3JlZT88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB0b3RhbGx5IGFncmVlLiBBbmQgdGhleeKAmWQgYWxzbyB3YW50 IHRvIGNvbnRpbnVlIGFuZCBmaW5pc2ggdGhlIHRyYW5zYWN0aW9uIGluIENPQVAuIEFuZCBiZSBh YmxlIHRvIGRvIHJlZGlyZWN0cyB1c2luZyBDT0FQIHByaW5jaXBsZXMgaW5zdGVhZCBvZiBIVFRQ IHByaW5jaXBsZXMuIEFuZCBnZW5lcmFsbHkgZG8gdGhpbmdzIHRoYXQgYXJlIHNpbWlsYXIgYnV0 IG5vdCB0aGUgc2FtZS4gU28gaXQgdHVybnMgaW50bw0KIGEgZGlmZmVyZW50IHByb3RvY29sIHdp dGggdGhlIHNhbWUgaWRlYXMsIGFuZCBJ4oCZbSBhbGwgZm9yIHRoYXQgaGFwcGVuaW5nIOKAlCBi dXQgSSBkb27igJl0IHRoaW5rIGl04oCZcyBhIGdvb2QgaWRlYSB0byBwdXQgaXQgYWxsIGluIHRo ZSBzYW1lIGRvY3VtZW50LCBvciB0byBoYXZlIGFuIGFic3RyYWN0IGRvY3VtZW50IHRoYXQgZXZl cnlvbmUgdHJpZXMgdG8gaW5oZXJpdCBmcm9tLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBrbm93IHdlIG5lZWQgYW5kIHdhbnQgSFRUUCwg c28gdG8gbWUgdGhhdOKAmXMgZmlybWx5IGluLXNjb3BlLiBPdGhlciBwcm90b2NvbHMgYXJlIOKA nHdvdWxkbuKAmXQgaXQgYmUgbmljZSBpZiBpdCBkaWQgdGhpc+KAnSByaWdodCBub3csIGFuZCBh YnN0cmFjdGluZyBmb3Igc29tZXRoaW5nIHRoYXQg4oCcd291bGQgYmUgbmljZeKAnSBsZWFkcyB0 byBiYWQgc3lzdGVtIGRlc2lnbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gbm90IGFnYWluc3QgQ09BUCwgYnV0IGxpa2Ugd2l0aCBP QXV0aCBhbmQgQUNFLCBJIGRvbuKAmXQgdGhpbmsgaXTigJlzIGdvb2QgdG8gdHJ5IGFuZCBjcmFt IHRoZW0gdG9nZXRoZXIgdGhpcyBlYXJseS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KJm5ic3A74oCUIEp1c3Rpbjxicj4NCjxicj4N CiZndDsgT24gRGVjIDMwLCAyMDE5LCBhdCA3OjIwIFBNLCBEaWNrIEhhcmR0ICZsdDs8YSBocmVm PSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0 QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHdvdWxkIHBy b3Bvc2UgdGhhdCB0aGUgcmVzdWx0aW5nIHdvcmsgaXMgYSBwcm90b2NvbCwgYW5kIG5vdCBhIGZy YW1ld29yay48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2hhdCBpcyB0aGUgZGlmZmVyZW5jZT8gSGVy ZSBhcmUgbXkgdGhvdWdodHM6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEEgZnJhbWV3b3JrIGRlZmlu ZXMgYSB2YXJpZXR5IG9mIHdheXMgdG8gZG8gZWFjaCBjYXBhYmlsaXR5LiBBIGZyYW1ld29yayB1 c3VhbGx5IG5lZWRzIGEgcHJvZmlsZSBmb3IgdHdvIHN5c3RlbXMgdG8gaW50ZXJvcGVyYXRlLiBG b3IgZXhhbXBsZSwgT0lEQyBwcm92aWRlcyBhIG51bWJlciBvZiB3YXlzIHRvIGdldCBpZGVudGl0 eSBkYXRhIGZyb20gYW4gT1AsIGFuZCBPQXV0aCAyIGdyYW50IHR5cGVzIGhhdmUgb3ZlcmxhcC4g QSBmcmFtZXdvcmsNCiBpcyBsaWtlIFBlcmwuIExvdHMgb2Ygd2F5cyB0byBkbyB0aGUgc2FtZSB0 aGluZywgbWFueSBvZiB3aGljaCBhcmUgdW5yZWFkYWJsZS48YnI+DQomZ3Q7IDxicj4NCiZndDsg QSBwcm90b2NvbCBwcm92aWRlcyBvbmUgd2F5IHRvIGRvIGVhY2ggY2FwYWJpbGl0eS4mbmJzcDsg QSBwcm90b2NvbCBpcyBsaWtlIFB5dGhvbiwgdGhlcmUgaXMgYSByaWdodCB3YXkgdG8gZG8gc29t ZXRoaW5nLjxicj4NCiZndDsgPGJyPg0KJmd0OyBBdCB0aW1lcyBhIHN0YW5kYXJkcyBncm91cCB3 aWxsIGdldCAmcXVvdDtjb25zZW5zdXMmcXVvdDsgYnkgbm90IGJlaW5nIGRlY2lzaXZlLCBhbmQg aW5jbHVkaW5nIGV2ZXJ5b25lJ3MgZmF2b3JlZCBtZWNoYW5pc20uIEluIG15IG9waW5pb24sIHRo aXMgbWFrZXMgZGVwbG95bWVudHMgbW9yZSBjb21wbGljYXRlZCBmb3IgYXZlcmFnZSBkZXZlbG9w ZXJzLCBhbmQgaW5jcmVhc2VzIHRoZSBzdXJmYWNlIGFyZWEgdG8gc2VjdXJlLjxicj4NCiZndDsg PGJyPg0KJmd0OyBEbyBvdGhlcnMgYWdyZWUgd2l0aCBhZGRpbmcgdGhpcyBhcyBhIHRlbmV0IHRv IHRoZSBjaGFydGVyPzxicj4NCiZndDsgPGJyPg0KJmd0OyAvRGljazxicj4NCiZndDsgPGJyPg0K Jmd0OyBOb3RlOiBJJ20gYSBmYW4gb2YgYm90aCBQZXJsIGFuZCBQeXRob24uID0pPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IC0tIDxicj4NCiZndDsgVHhhdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsg PGEgaHJlZj0ibWFpbHRvOlR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlR4YXV0aEBp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHhhdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_6DFD1CA6D3344FCA9881834571A5DE7Camazoncom_-- From nobody Thu Jan 2 16:46: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 882D41200C3 for ; Thu, 2 Jan 2020 16:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.699 X-Spam-Level: X-Spam-Status: No, score=-11.699 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 uNci-xKF3dzd for ; Thu, 2 Jan 2020 16:46:00 -0800 (PST) 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 B777512006B for ; Thu, 2 Jan 2020 16:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578012361; x=1609548361; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+f4OF5OG1vLGAK4ePPtEaAtChQiKMdVhmy1qQEjyR84=; b=oEKUs30zOW/E9PpJUtuFmlz6CzCDcD3/SqPHpl6D07yzwlzj4LzMkrZM yV7zKWE7i/jwkOjYzwKiTDXTQNmNp6e2xoFdiUvTa5/N0WDqRAWUuC+ZT l7ZIFqLqZRpp+ZPqddxeg8sIGEx2LJN59W+6/5VHdwIW5kZtt7NSvAzLB E=; IronPort-SDR: 0fXP2j32p4QD5fVWMyuZF9ZpG7RghbM9wyTO8I+PCr2y7oH6sHEXuKw4kcthmkhM03Z1Cmjo+8 5gVs0SAOINoA== X-IronPort-AV: E=Sophos; i="5.69,388,1571702400"; d="scan'208,217"; a="17922386" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1d-9ec21598.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 03 Jan 2020 00:45:50 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1d-9ec21598.us-east-1.amazon.com (Postfix) with ESMTPS id 4DABBA2010; Fri, 3 Jan 2020 00:45:46 +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; Fri, 3 Jan 2020 00:45:46 +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.1367.3; Fri, 3 Jan 2020 00:45: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.1367.000; Fri, 3 Jan 2020 00:45:46 +0000 From: "Richard Backman, Annabelle" To: Justin Richer CC: Dick Hardt , Eve Maler , "rdd@cert.org" , "txauth@ietf.org" , "Benjamin Kaduk" Thread-Topic: [Txauth] TxAuth Proposed Charter Thread-Index: AQHVt4W+Cd5+sniY+0u9RUqE6+8fD6fDqwuAgAAMvQD//4lSAIAAjYeAgABdgjyAAFyWAIABI/3hgAFGlACAADdN4YABHkoA//+RsQCAAiXqgIANqKCA Date: Fri, 3 Jan 2020 00:45:46 +0000 Message-ID: References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com> <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> <949341AE-C72B-4645-8F20-699F14529FFB@mit.edu> <78FA3EB7-C72F-4543-95A8-03123F4E40A1@amazon.com> <1FD41975-3CB5-48B6-88D5-6DB7511742CA@mit.edu> <684F4469-031B-4AB9-8B53-A87597AE012E@amazon.com> <7CA2CAA2-231D-40B4-BC0E-9CECCB16AE90@mit.edu> In-Reply-To: <7CA2CAA2-231D-40B4-BC0E-9CECCB16AE90@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.118] Content-Type: multipart/alternative; boundary="_000_FD7172F9ADFF49E1ABCADBCFB8FC8639amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] TxAuth Proposed 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, 03 Jan 2020 00:46:05 -0000 --_000_FD7172F9ADFF49E1ABCADBCFB8FC8639amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgZmVlbGluZyBpcyB0aGF0IHRoZSBjaGFydGVyIHNob3VsZCByZWFkIG1vcmUgbGlrZSBhIHBy b2JsZW0gc3RhdGVtZW50IHRoYW4gYSBzb2x1dGlvbiBwcm9wb3NhbC4gSSB0aGluayB3ZeKAmXJl IG9uIHRoZSBzYW1lIHBhZ2UgdGhlcmUuIEhvd2V2ZXIsIHRoZSBjdXJyZW50IHRleHQgZG9lc27i gJl0IGFkaGVyZSB0byB0aGlzOg0KDQogICogICBJdCBtYW5kYXRlcyBhIHRyYW5zYWN0aW9uYWwg cHJvdG9jb2wuIFdoaWxlIHRoaXMgaXMgdGhlIGFwcHJvYWNoIHdl4oCZcmUgc3RhcnRpbmcgZnJv bSwgdGhlcmUgaXMgbm8gZ3VhcmFudGVlIHRoYXQgaXQgaXMgdGhlIGNvcnJlY3Qgb25lLCBhbmQg d2Ugc2hvdWxkbuKAmXQgYm94IG91cnNlbHZlcyBpbnRvIGl0Lg0KICAqICAgSXQgcmVmZXJzIHRv IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gV2hpbGUgdGhpcyByb2xlIHRlbmRzIHRvIGJlIGNl bnRyYWwgdG8gb3VyIHNvbHV0aW9ucywgaXTigJlzIG5vdCBjbGVhciB0byBtZSB0aGF0IGl0IGlz IGFuIGluaGVyZW50IHBhcnQgb2YgdGhlIHByb2JsZW0gc3RhdGVtZW50Lg0KDQrigJMNCkFubmFi ZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IEp1c3RpbiBSaWNo ZXIgPGpyaWNoZXJAbWl0LmVkdT4NCkRhdGU6IFR1ZXNkYXksIERlY2VtYmVyIDI0LCAyMDE5IGF0 IDQ6MTEgUE0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6 b24uY29tPg0KQ2M6IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPiwgRXZlIE1hbGVy IDxldmVAeG1sZ3JybC5jb20+LCAicmRkQGNlcnQub3JnIiA8cmRkQGNlcnQub3JnPiwgInR4YXV0 aEBpZXRmLm9yZyIgPHR4YXV0aEBpZXRmLm9yZz4sIEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQu ZWR1Pg0KU3ViamVjdDogUmU6IFtUeGF1dGhdIFR4QXV0aCBQcm9wb3NlZCBDaGFydGVyDQoNCkkg ZG9u4oCZdCB0aGluayB3ZSBzaG91bGQgd3JpdGUgdGhlIGNoYXJ0ZXIgd2l0aCBhIHNwZWNpZmlj IHNvbHV0aW9uIGluIG1pbmQsIGJ1dCBpbnN0ZWFkIGRlc2NyaWJpbmcgdGhlIHByb2JsZW1zIHRo YXQgd2Ugd2FudCB0byBzb2x2ZSB3aXRoIGEgc3RhbmRhcmQuIFRoZSDigJx3aXRoIGEgc3RhbmRh cmTigJ0gaXMgaW1wb3J0YW50IGhlcmUgYXMgbm90IGV2ZXJ5IGFzcGVjdCBpcyBnb2luZyB0byBu ZWVkIGEgc3RhbmRhcmQgc3BlY2lmaWNhdGlvbiwgb25seSB0aGUgcGFydHMgd2hlcmUgd2UgZXhw ZWN0IGNvbW11bmljYXRpb24gYW5kIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBpbXBsZW1lbnRh dGlvbnMsIHJpZ2h0Pw0KDQpJIHdvdWxkIHNheSB0aGF0IHJhdGhlciB0aGUgY2hhcnRlciBzaG91 bGQgYmUgbW9yZSBnZW5lcmFsIGluIGRlc2NyaWJpbmcgdGhlIHB1cnBvc2UgYW5kIG5vdCBwdXR0 aW5nIHRoaW5ncyA6b3V0OiBvZiBzY29wZS4gSXQgbWlnaHQgdmVyeSB3ZWxsIGJlIHRoYXQgdGhl IGRlcGxveW1lbnQgeW914oCZcmUgZGVzY3JpYmluZyBpcyBhbiBvcHRpbWl6YXRpb24sIGJ1dCBp ZiBpdCBtYWtlcyBzZW5zZSB3aXRoaW4gdGhlIGJvdW5kcyBvZiB0aGUgd29yaywgZXZlbiBpZiB0 aGUgZGV0YWlscyBhcmUgZGVzY3JpYmVkIGluIHRoZWlyIG93biBzcGVjIChvciBub3QgaW4gYSBz cGVjIGF0IGFsbCwgaWYgd2UgZGVjaWRlIHRoYXTigJlzIG9uZSBvZiB0aGUg4oCcdW5kZXIgdGhl IGhvb2TigJ0gYXNwZWN0cyksIHRoZW4gdGhhdOKAmXMgT0suIEkgZG8gYWdyZWUgdGhhdCB3aGF0 4oCZcyByZWFsbHkgaW1wb3J0YW50IGhlcmUgaXMgaGF2aW5nIGFuIGlkZWEgb2Ygd2hhdCB0aGUg ZGlmZmVyZW50IG1vdmluZyBwYXJ0cyBhcmUsIGF0IGxlYXN0IHRvIHN0YXJ0LiBBbnkgcHJvcG9z ZWQgaWRlYXMgb24gaG93IHRvIGRlc2NyaWJlIHRoaXMgd2l0aG91dCBnZXR0aW5nIGludG8gcHJl c2NyaXB0aXZlIGRlcGxveW1lbnQgZGV0YWlscz8NCg0KIOKAlCBKdXN0aW4NCg0KDQpPbiBEZWMg MjMsIDIwMTksIGF0IDY6MjIgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5u YUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4gd3JvdGU6DQoNClRoZSBw b2ludCBpcywgSSBtaWdodCB3YW50IG15IHRva2VucyB0byBiZSBzaWduZWQgdXNpbmcga2V5cyB0 aGF0IG15IFRYIEVuZHBvaW50IGRvZXMgbm90IGhhdmUgYWNjZXNzIHRvLiBFLmcuLCBteSB0b2tl biBpc3N1ZXIgc2lnbnMgdG9rZW5zIHdpdGgga2V5IEEgYW5kIG15IFRYIEVuZHBvaW50IHNpZ25z IEhUVFAgcmVzcG9uc2UgbWVzc2FnZXMgd2l0aCBrZXkgQiwgbmVpdGhlciBzeXN0ZW0gaGFzIGFj Y2VzcyB0byB0aGUgb3RoZXIga2V5LCBhbmQgdG9rZW5zIHNpZ25lZCBieSBrZXkgQiBhcmUgcmVq ZWN0ZWQgYnkgUlNlcy4gVGhpcyByZXF1aXJlcyB0aGUgd29ya2luZyBncm91cCB0byB1bmRlcnN0 YW5kIHRoYXQgdHJ1c3QgYm91bmRhcmllcyBtYXkgZXhpc3QgYmV0d2VlbiB0aGUgZGlmZmVyZW50 IGNvbXBvbmVudHMgaW1wbGVtZW50aW5nIHBvcnRpb25zIG9mIOKAnEFT4oCdIGJlaGF2aW9yLiBJ ZiB0aGlzIGlzbuKAmXQgdW5kZXJzdG9vZCwgdGhlbiBpZi93aGVuIEkgYnJpbmcgdXAgdGhpcyB1 c2UgY2FzZSwgSeKAmW0gZ29pbmcgdG8gYmUgdG9sZCDigJx0aGVyZSBhcmUgbm8gdHJ1c3QgYm91 bmRhcmllcyB3aXRoaW4gYW4gQVMsIHNvIHdoYXQgeW914oCZcmUgZGVzY3JpYmluZyBpc27igJl0 IGFuIEFTIGFueW1vcmUsIGFuZCBub3QgaW4gc2NvcGUgcGVyIHRoZSBjaGFydGVyLuKAnQ0KDQpJ 4oCZbSBzZW5zaXRpdmUgdG8gdGhlIGRlc2lyZSB0byBub3Qgb3ZlcmNvbXBsaWNhdGUgdGhpbmdz LiBUaGUgc2NlbmFyaW8gSeKAmW0gZGVzY3JpYmluZyBpcyB1bnVzdWFsLCBhbmQgcHJvYmFibHkg bm90IHdoYXQgd2Ugc2hvdWxkIG9wdGltaXplIHRoZSBwcm90b2NvbCBmb3IgKHRob3VnaCB0aGF0 IGNvdWxkIGFsd2F5cyBjaGFuZ2UpLiBCdXQgd2XigJlyZSB0YWxraW5nIGFib3V0IGNoYXJ0ZXIs IG5vdCBwcm90b2NvbC4gVGhlIGNoYXJ0ZXIgY2FuIGJlIGFzIGRldGFpbGVkIGFuZCBudWFuY2Vk IGFzIGl0IG5lZWRzIHRvIGJlIHRvIHByb3Blcmx5IGRlc2NyaWJlIHdoYXQgd2UgYXJlIHNldHRp bmcgb3V0IHRvIGFjY29tcGxpc2guDQoNCuKAkw0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0K QVdTIElkZW50aXR5DQoNCg0KRnJvbTogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1h aWx0bzpqcmljaGVyQG1pdC5lZHU+Pg0KRGF0ZTogTW9uZGF5LCBEZWNlbWJlciAyMywgMjAxOSBh dCAxOjU3IFBNDQpUbzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1h em9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+DQpDYzogRGljayBIYXJkdCA8ZGlj ay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4sIEV2ZSBNYWxl ciA8ZXZlQHhtbGdycmwuY29tPG1haWx0bzpldmVAeG1sZ3JybC5jb20+PiwgInJkZEBjZXJ0Lm9y ZzxtYWlsdG86cmRkQGNlcnQub3JnPiIgPHJkZEBjZXJ0Lm9yZzxtYWlsdG86cmRkQGNlcnQub3Jn Pj4sICJ0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBpZXRmLm9yZz4iIDx0eGF1dGhAaWV0 Zi5vcmc8bWFpbHRvOnR4YXV0aEBpZXRmLm9yZz4+LCBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0 LmVkdTxtYWlsdG86a2FkdWtAbWl0LmVkdT4+DQpTdWJqZWN0OiBSZTogW1R4YXV0aF0gVHhBdXRo IFByb3Bvc2VkIENoYXJ0ZXINCg0KU28gdGhlIHRoaW5nIGlzLCBJIGRvbuKAmXQgdGhpbmsgeW91 IG5lZWQgYSBzaW5nbGUgSldLUyBVUkkgYW55bW9yZSBhbnl3YXkuIFlvdeKAmWQgaGF2ZSBvbmUg YXNzb2NpYXRlZCB3aXRoIHRoZSBUeEVuZHBvaW50LCBpZiB5b3XigJl2ZSBnb3Qgc2lnbmVkIHRv a2VucyB0aGF0IHlvdSBuZWVkIHRvIHZhbGlkYXRlIHNlcGFyYXRlbHkuIEFuZCBpZiB5b3XigJly ZSBkb2luZyBzaWduZWQgdXNlciBhc3NlcnRpb25zLCB5b3XigJlkIGhhdmUgYSBkaWZmZXJlbnQg b25lIGlkZW50aWZpZWQgaW4gdGhlIGFzc2VydGlvbiAoZWl0aGVyIGRpcmVjdGx5IG9yIHZpYSBh biBpc3N1ZXItZGlzY292ZXJ5IG1lY2hhbmlzbSkuIFVsdGltYXRlbHkgdGhlIGNsaWVudCBpcyBn b2luZyB0byBjYXJlIGFib3V0IG9uZSBhbmQgdGhlIFJTIGFib3V0IGFub3RoZXIgc28gaXTigJlz IGZpbmUgdGhhdCB0aGV54oCZcmUgZGlmZmVyZW50LiBXZSBnZXQgdG8gZGVmaW5lIHdoYXQgdGhh dCBsb29rcyBsaWtlLg0KDQpPbiB0aGUgc3VyZmFjZSBJ4oCZbSBPSyB3aXRoIGEgZGVjb21wb3Nl ZCBBUywgdG8gc29tZSBleHRlbnQsIGJ1dCBvbmx5IGlmIHRoZXJlIGFyZSB2ZXJ5LCB2ZXJ5IGNs ZWFyIGJvdW5kYXJpZXMgYWJvdXQgd2hhdCB0aGUgaW5kaXZpZHVhbCByb2xlcyBhcmUuIEFuZCB0 aGUgbW9yZSByb2xlcyB3ZSBtYWtlLCB0aGUgbW9yZSB3ZSBoYXZlIHRvIGRlZmluZSB3aGF0IHRo ZSBjb21tdW5pY2F0aW9uIHBvaW50cyBhcmUgaW4gYmV0d2VlbiB0aGVtLiBNYXliZSDigJxBU+KA nSBpcyB0b28gYWxsLWVuY29tcGFzc2luZyBvZiBhIHJvbGUgbm93LCBidXQgSeKAmW0gbm90IHll dCBjb252aW5jZWQgdGhhdOKAmXMgdHJ1ZSBpbiBwcmFjdGljZSwgYW5kIEkgZG8gd2FudCBzb21l b25lIHRvIGJlIGFibGUgdG8gZGVwbG95IHRoaXMgYnkgaGF2aW5nIGFsbCB0aGUg4oCcc2VydmVy 4oCdIHNpZGUgZnVuY3Rpb25hbGl0aWVzIHJ1bm5pbmcgb3V0IG9mIGEgc2luZ2xlLCBzaW1wbGUg Ym94LiBUaGF0IG1pZ2h0IGJlIGEgY2FzZSBvZiB0aGF0IHNpbmdsZSBib3ggbmVlZGluZyB0byBw bGF5IG11bHRpcGxlIHJvbGVzLCBhbmQgdGhhdOKAmXMgT0ssIGJ1dCB3ZSBuZWVkIHRvIGJlIGNs ZWFyIG9uIHdoYXQga2luZHMgb2Ygb3B0aW1pemF0aW9ucyBhcmUgYWxsb3dhYmxlIGluIGNhc2Vz IGxpa2UgdGhhdC4NCg0KSSBkbyB0aGluayB0aGVyZeKAmXMgcHJlY2VkZW50IGluIGFza2luZyB0 aGlzIHF1ZXN0aW9uIHRob3VnaCwgc2luY2UgYmV0d2VlbiBPQXV0aCAxIGFuZCAyIHdlIHNwbGl0 IHRoZSDigJxzZXJ2ZXLigJ0gaW50byDigJxBUyBhbmQgUlPigJ0uIE9BdXRoIDIgZmFtb3VzbHkg ZGlkbuKAmXQgZGVmaW5lIGEgY29ubmVjdGlvbiBwb2ludCBiZXR3ZWVuIHRoZW0gdW50aWwgbXVj aCBsYXRlciAoSldUIGFuZCBJbnRyb3NwZWN0aW9uKSwgYnV0IHRoYXQgcGF0dGVybiBzZWVtcyB0 byBoYXZlIG1vc3RseSB3b3JrZWQuDQoNCiDigJQgSnVzdGluDQoNCg0KDQpPbiBEZWMgMjIsIDIw MTksIGF0IDExOjUyIFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1h em9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KDQpNeSBleGFtcGxl IGRlbW9uc3RyYXRlcyBhbiBhcmNoaXRlY3R1cmUgd2hlcmUgdGhlIFRYIEVuZHBvaW50LCBhdXRo ZW50aWNhdGlvbiBzeXN0ZW0sIGFuZCB0b2tlbiBpc3N1ZXIgYXJlbuKAmXQgc2ltcGx5IGRpZmZl cmVudCBtaWNybyBzZXJ2aWNlcywgdGhleeKAmXJlIGNvbXBsZXRlbHkgaW5kZXBlbmRlbnQgc3lz dGVtcyBpbiBkaWZmZXJlbnQgdHJ1c3QgYm91bmRhcmllcywgcG9zc2libHkgaGF2ZSBkaWZmZXJl bnQgZG9tYWlucyBhbmQgZGlmZmVyZW50IGtleXMuIFRoaXMgaGFzIGltcGxpY2F0aW9ucyBmb3Ig cHJvdG9jb2wgZGVzaWduLiBGb3IgZXhhbXBsZSwgaXQgd291bGQgbm8gbG9uZ2VyIGJlIHN1ZmZp Y2llbnQgdG8gaGF2ZSBhIHNpbmdsZSBqd2tzX3VyaSwgYXMgT0F1dGggMi4wIGhhcy4NCg0KDQoN CklmIHdlIHdhbnQgdG8gc3VwcG9ydCB0aGlzIGtpbmQgb2Yg4oCcZGVjb21wb3NlZCBBU+KAnSBt b2RlbCwgdGhlbiB3ZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF04oCZcyBzdXBwb3J0ZWQgYnkgdGhl IGNoYXJ0ZXIgYW5kIGtlZXAgaXQgaW4gbWluZCBhcyB3ZSBkZXNpZ24gdGhlIHByb3RvY29sLiBX ZSBjYW4gYWxzbyBkZWNpZGUgaXQgaXMgb3V0IG9mIHNjb3BlLCBidXQgd2Ugc2hvdWxkIGJlIGlu dGVudGlvbmFsIGFib3V0IHRoYXQgZGVjaXNpb24uDQoNCg0KDQpUbyBteSBtaW5kLCB0aGlzIHJv bGUgZGVjb21wb3NpdGlvbiBpcyB0aGUgbmV4dCBsb2dpY2FsIHN0ZXAgYWZ0ZXIgdGhlIGNoYW5u ZWwgZGVjb21wb3NpdGlvbiB0aGF0IFR4QXV0aCBhbHJlYWR5IGRvZXMuIEkgc2VlIGEgbG90IG9m IHBvdGVudGlhbCBpbiBpdCBhbmQgdGhpbmsgd2Ugc2hvdWxkIGF0IG1pbmltdW0gYXZvaWQgY2xv c2luZyB0aGUgZG9vciBvbiBpdC4NCg0KDQoNCk9uIERlYyAyMiwgMjAxOSwgYXQgNTozNSBQTSwg SnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3 cm90ZToNCkkgdGhpbmsgeW914oCZcmUgY29uZmxhdGluZyB0aGUgcm9sZXMgdGhhdCBkaWZmZXJl bnQgY29tcG9uZW50cyBwbGF5LCBpbiByZWdhcmQgdG8gdGhlIG90aGVyIGNvbXBvbmVudHMsIHdp dGggdGhlIHBvdGVudGlhbCBkZXBsb3ltZW50IG9mIHRob3NlIGNvbXBvbmVudHMuIFRoZSBzcGVj IG5lZWRzIHRvIGJlIHdyaXR0ZW4gaW4gdGVybXMgb2YgdGhlIHJvbGVzLiBXaGlsZSB0aGUgcm9s ZXMgZG8gbmVlZCB0byBjb25zaWRlciB3aGF0IHBvdGVudGlhbCBkZXBsb3ltZW50cyBtaWdodCBi ZSwgaXTigJlzIGltcG9ydGFudCB0aGF0IHdlIHdyaXRlIHRoaW5ncyBpbiBpbiB0ZXJtcyBvZiBo b3cgdGhleSBpbnRlcmFjdCB3aXRoIGVhY2ggb3RoZXIgYW5kIG5vdCBpbiB0ZXJtcyBvZiBob3cg dGhleSBtaWdodCBsb29rIHVuZGVyIHRoZSBjb3ZlcnMuDQoNClNvIGZyb20gdGhlIGNsaWVudHMg cGVyc3BlY3RpdmUsIHRoZSBUWCBFbmRwb2ludCA6aXM6IHRoZSBBUy4gVGhlIGNsaWVudCBkb2Vz buKAmXQgY2FyZSB0aGF0IGl04oCZcyBhIOKAnGdsb3JpZmllZCBtZXNzYWdlIHF1ZXVl4oCdIG9y IGlmIGl04oCZcyBhIG1hc3NpdmUgc2VydmVyIGZhcm0uIFRoZSBjbGllbnQgZG9lc27igJl0IGNh cmUgaWYgdGhlcmXigJlzIGEgVExTIHJldmVyc2UgcHJveHkgb3IgaWYgaXTigJlzIHRhbGtpbmcg ZGlyZWN0bHkgdG8gdGhlIGFwcGxpY2F0aW9uIGxheWVyLiBUaGUgb25seSB0aGluZyB0aGUgY2xp ZW50IGNhcmVzIGFib3V0IGlzIGlmIHRoZSBUWCBFbmRwb2ludCBkb2VzIHRoZSB0aGluZ3MgdGhh dCBhIFRYIEVuZHBvaW50IGlzIHN1cHBvc2VkIHRvIGRvLCBhbmQgd2UgZGVmaW5lIHRoYXQgdG8g YmUgdGhlIGZ1bmN0aW9uIG9mIHRoZSBBUy4NCg0KV2hhdOKAmXMgaW1wb3J0YW50IGluIHlvdXIg c2NlbmFyaW8gYmVsb3cgaXMgdGhhdCB0aGUgY2xpZW50IHdvdWxkIGhhdmUgdG8gdGFsayB0byB0 aGUgUlMgZmlyc3QgZXZlcnkgdGltZS4gVGhhdOKAmXMgb25lIG9mIHRoZSBwcm9ibGVtcyB0aGF0 IFVNQSBoYXMsIGFuZCBJIHRoaW5rIHNvbWV0aGluZyB3ZSBzaG91bGQgYXZvaWQuIEkgdGhpbmsg UlMtZmlyc3QgaXMgYW4gaW50ZXJlc3RpbmcgcGF0dGVybiBidXQgQVMtZmlyc3Qgb3VnaHQgdG8g ZHJpdmUgdGhpcy4NCg0KV2l0aCB5b3VyIGh5cG90aGV0aWNhbCBsYXlvdXQgYmVsb3csIGl0IHJl YWxseSBzb3VuZHMgbGlrZSB0aGUgVFggRW5kcG9pbnQgaXMgYSBmdW5jdGlvbiBvZiB0aGUgSURQ LCB3aGljaCBpcyBmaW5lLiBUaGUgY2xpZW50IGRvZXNu4oCZdCBjYXJlIHRoYXQgaXTigJlzIGRl cGxveWVkIHVzaW5nIHNvbWUgZXh0ZXJuYWxpemVkIGNsb3VkIHNlcnZpY2UuIFRoZSBvbmx5IHdl aXJkIHRoaW5nIGdvaW5nIG9uIGlzIHRoZSBwdXNoIGZyb20gdGhlIEFTIGJhY2sgdG8gdGhlIGNs aWVudC4gVGhlIGNsaWVudCB3b3VsZCBuZWVkIHRvIHJlZ2lzdGVyIHRoYXQgd2l0aCB0aGUgQVMg KG9yIHRocm91Z2ggdGhlIEFTIG1vcmUgc3BlY2lmaWNhbGx5KSBhcyBwYXJ0IG9mIGl0cyB0cmFu c2FjdGlvbiByZXF1ZXN0LiBUaGlzIHdvdWxkIGJlIHBhcnQgb2YgaXRzIGludGVyYWN0aW9uIG1l Y2hhbmlzbSwgYmVjYXVzZSDigJxob3cgeW91IGdldCBtZXNzYWdlcyBhbmQgdXBkYXRlcyBiYWNr IHRvIHRoZSBjbGllbnTigJ0gaXMgcGFydCBvZiB0aGUgaW50ZXJhY3Rpb24gbW9kZWwuDQoNClNv IGZvciBhbiBSUy1maXJzdCB0cmFuc2FjdGlvbiwgdGhlIGNsaWVudCBjYWxscyB0aGUgUlM6DQoN CkdFVCAvZm9vDQoNClRoZSBSUyByZXR1cm5zIGEgcmVzb3VyY2UgaGFuZGxlLCBidXQgdGhlIGNs aWVudCBkb2VzbuKAmXQgY2FyZSB3aGVyZSB0aGF0IGNhbWUgZnJvbS4gVGhlIFJTIGNvdWxkIHRh bGsgdG8gdGhlIEFTIHRvIGdldCBpdC4gUHJvYmFibHkgYSBuZXcgZW5kcG9pbnQgb2Ygc29tZSBr aW5kLCBjYW4gcHJvYmFibHkgdXNlIHRoZSBzYW1lIGtpbmRzIG9mIGtleSBiaW5kaW5nIHRoYXQg dGhlIFRYIEVuZHBvaW50IGhhcy4gT3IgdGhlIFJTIGNhbiBtYWtlIG9uZSB1cCB0aGF0IHRoZSBU WCBFbmRwb2ludCBjYW4gcmVjb2duaXplLiBPciBpdCBjYWxscyB0aGUgSWRQIHRvIGdldCBvbmUu IFRoZSBjbGllbnQgZG9lc27igJl0IGNhcmUsIGFuZCB0aGF04oCZcyB0aGUga2V5IHBvaW50Lg0K DQpXV1ctQXV0aGVudGljYXRlIHR4X2VuZHBvaW50PeKAnGh0dHA6Ly9zZXJ2ZXIvL3R4PGh0dHA6 Ly9zZXJ2ZXIlRUYlQkYlQkQvdHg+4oCdIHJlc291cmNlOiDigJxhc2RmMTIzNOKAnQ0KDQpUaGUg Y2xpZW50IGNhbGxzIHRoZSBUWCBlbmRwb2ludCBsaWtlIGEgbm9ybWFsIHRyYW5zYWN0aW9uOg0K DQpQT1NUIC90eA0KDQp7DQogIHJlc291cmNlczogWyDigJxhc2RmMTIzNOKAnSBdLA0KICBpbnRl cmFjdDogew0KICAgIHJlZGlyZWN0OiB0cnVlLA0KICAgIHB1c2g6IOKAnGh0dHA6Ly9jbGllbnQv cHVzaC85ODc24oCdDQogIH0NCn0NCg0KVGhlIEFTICh3aGljaCBpcyB0byBzYXkgdGhlIFRYIEVu ZHBvaW50KSB0ZWxscyB0aGUgY2xpZW50IHRvIHNlbmQgdGhlIHVzZXIgYWdlbnQgdG8gdGhlIElk UA0KDQp7DQogIGludGVyYWN0X3VybDog4oCcaHR0cDovL2lkcC9sb2dpbuKAnSwNCiAgaGFuZGxl OiB7IHZhbHVlOiDigJxoamts4oCdLCB0eXBlOiBiZWFyZXIgfQ0KfQ0KDQpOb3cgdGhlIGNsaWVu dCBjb3VsZCBwb2xsIHRoZSBUWCBFbmRwb2ludCBidXQgaXQgY291bGQgYWxzbyBqdXN0IHNpdCBh bmQgd2FpdCBmb3IgYW4gdXBkYXRlIHRvIGJlIHB1c2hlZCBpbi4NCg0KVGhlcmUgYXJlIHByb2Jh Ymx5IHRoaW5ncyB0aGF0IG5lZWQgdG8gYmUgdGllZCB0b2dldGhlciBmb3IgdGhpcyB0byBiZSBz ZWN1cmUsIGJ1dCBJIHRoaW5rIHRoZSBiYXNpYyBwYXR0ZXJuIHN0aWxsIGZpdHMuIEltcG9ydGFu dGx5LCB0aGUgY2xpZW50IGRvZXNu4oCZdCBjYXJlIHdoZXJlYnkgb2YgdGhhdCBzdHVmZiBjYW1l IGZyb20g4oCUIGFzIGZhciBhcyBpdOKAmXMgY29uY2VybmVkLCBpdOKAmXMgdGFsa2luZyB0byB0 aGUgQVMuDQoNClJlbWVtYmVyLCB0aGUg4oCcQVPigJ0gaXMgYSBsb2dpY2FsIGNvbnN0cnVjdCwg bm90IGEgcGh5c2ljYWwgb25lLiBKdXN0IGxpa2UgdGhlIOKAnGNsaWVudOKAnSBjb3VsZCBiZSBh IGNsdXN0ZXIgb2YgYXBwbGljYXRpb25zIGFuZCB0aGUg4oCcUlPigJ0gY291bGQgYmUgYSBzdWl0 ZSBvZiBBUElzIHRpZWQgYmVoaW5kIGEgZ2F0ZXdheS4NCg0KIOKAlCBKdXN0aW4NCg0KDQoNCg0K T24gRGVjIDIyLCAyMDE5LCBhdCAxOjA1IEFNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8 cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0K DQoNCk9uIERlYyAyMSwgMjAxOSwgYXQgNDo0MiBBTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBt aXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCg0KRXZlbiBpZiB0aGUgY2xp ZW50IHN0YXJ0cyBhdCB0aGUgUlMsIHRoZSBjbGllbnQgc3RpbGwgaGFzIHRvIGdvIHRhbGsgdG8g dGhlIEFTLiBJIGhhdmVu4oCZdCBidWlsdCB0aGlzIG91dCwgYnV0IEkgc2VlIGl0IHdvcmtpbmcg c29tZXdoYXQgbGlrZSBVTUEuIEluIFhZWuKAmXMgdGVybXM6DQoNCg0KMS4gQ2xpZW50IGNhbGxz IHRoZSBSUyB0cnlpbmcgdG8gRG8gQSBUaGluZw0KMi4gUlMgY2FsbHMgdGhlIEFTIHJlcXVlc3Rp bmcgYSBSZXNvdXJjZSBIYW5kbGUgKGJlY2F1c2UgdGhhdOKAmXMgd2hhdCB0aGUgUlMgcmVwcmVz ZW50cywgcmVzb3VyY2VzKSDigJQgYXQgbGVhc3QgZ29vZCBlbm91Z2ggdG8gY292ZXIgd2hhdCB0 aGUgY2xpZW50IHRyaWVkIHRvIGRvLCBjb3VsZCBiZSBtb3JlDQozLiBSUyBnaXZlcyB0aGUgUmVz b3VyY2UgSGFuZGxlIGFuZCBBUyBUcmFuc2FjdGlvbiBFbmRwb2ludCBiYWNrIHRvIHRoZSBjbGll bnQNCjQuIENsaWVudCBjYWxscyB0aGUgQVMgVHJhbnNhY3Rpb24gRW5kcG9pbnQgdG8gc3RhcnQg YSB0cmFuc2FjdGlvbiwgaW5jbHVkZXMgdGhlIFJlc291cmNlIEhhbmRsZSBhcyBwYXJ0IG9mIGl0 cyByZXF1ZXN0IChub3RlOiBkb2VzbuKAmXQgaGF2ZSB0byBiZSB0aGUgd2hvbGUgcmVzb3VyY2Ug c2VjdGlvbiwgY2xpZW50IGNhbiBhZGQgc3R1ZmYpDQo1LiBQcm9jZXNzIGNvbnRpbnVlcyBhcyBu b3JtYWwNCg0KSXQgZGVwZW5kcyBvbiB3aGF0IHlvdSBjb25zaWRlciB0aGUg4oCcQVPigJ0uIENv bnNpZGVyIHRoZSBmb2xsb3dpbmcgaHlwb3RoZXRpY2FsIGFyY2hpdGVjdHVyZToNCg0K4oCiIFRo ZSBSUywgY2xpZW50LCBhbmQgdHggZW5kcG9pbnQgYXJlIG9uIHRoZSBwdWJsaWMgSW50ZXJuZXQu DQrigKIgVGhlIHR4IGVuZHBvaW50IHJldHVybnMgaW50ZXJhY3Rpb24gdXJscyB0aGF0IHBvaW50 IHRvIGFuIElkUCB0aGF0IGlzIGluYWNjZXNzaWJsZSBmcm9tIHRoZSBwdWJsaWMgSW50ZXJuZXQu DQrigKIgVGhlIHVzZXIgYWdlbnQgY2FuIHJlYWNoIHRoZSBJZFAsIGJ1dCBub25lIG9mIHRoZSBv dGhlciBzeXN0ZW1zIGNhbi4NCuKAoiBXaGVuIHRoZSBVQSBpcyByZWRpcmVjdGVkIHRvIHRoZSBJ ZFAsIHRoZSBJZFAgY2FsbHMgdGhlIHR4IGVuZHBvaW50IHN5c3RlbSB0byByZXRyaWV2ZSB0cmFu c2FjdGlvbiBkZXRhaWxzLg0K4oCiIFdoZW4gYXV0aG9yaXphdGlvbiBpcyBncmFudGVkLCB0aGUg SWRQIHB1c2hlcyBhcnRpZmFjdHMgZGlyZWN0bHkgdG8gYW4gZW5kcG9pbnQgcHJvdmlkZWQgYnkg dGhlIGNsaWVudC4NCg0KSW4gdGhpcyBleGFtcGxlLCB0aGUgY2xpZW50IG9ubHkgaW50ZXJhY3Rz IHdpdGggdGhlIFJTIGFuZCB0aGUgdHggZW5kcG9pbnQuIEl0IHNlZW1zIG9kZCB0byBtZSB0byBj b25zaWRlciB0aGUgc3lzdGVtIGhvc3RpbmcgdGhlIHR4IGVuZHBvaW50IHRvIGJlIHRoZSBBUyAo b3IgYXQgbGVhc3QgcGFydCBvZiB0aGUgQVMpLCBhcyBpdHMgYSBnbG9yaWZpZWQgbWVzc2FnZSBx dWV1ZSB3aXRoIGVzc2VudGlhbGx5IG5vIGF1dGhvcml0eSBpbiB0aGlzIGFyY2hpdGVjdHVyZS4N Cg0KV2UgY291bGQgZ28gYSBzdGVwIGZ1cnRoZXIgYW5kIHJlbW92ZSB0aGUgY2xpZW504oCZcyBp bnRlcmFjdGlvbiB3aXRoIHRoZSB0eCBlbmRwb2ludCBieSBoYXZpbmcgdGhlIFJTIHJldHVybiB0 aGUgaW50ZXJhY3Rpb24gdXJsIGRpcmVjdGx5ICh5b3XigJlkIG5lZWQgdG8gc2VjdXJlIHRoZSBj bGllbnQgbm9uY2UgaWYgeW91IHdhbnQgdG8gaGlkZSBpdCBmcm9tIHRoZSBSUywgYnV0IHRoYXTi gJlzIG5vdCB0aGF0IGhhcmQpLg0KDQpJcyB0aGUgbWVhbmluZyBvZiDigJxhdXRob3JpemF0aW9u IHNlcnZlcuKAnSAob3IgdGhlIHBocmFzZSDigJx0aHJvdWdoIGFuIGF1dGhvcml6YXRpb24gc2Vy dmVy4oCdKSBmbGV4aWJsZSBlbm91Z2ggdG8gYWNjb21tb2RhdGUgdGhlc2UgY2FzZXM/IE9yIGFy ZSB0aGV5IGNvbnNpZGVyZWQgb3V0IG9mIHNjb3BlIGZvciBUeEF1dGg/DQoNCiDigJQgSnVzdGlu DQoNCg0KDQoNCkFzIEkgc2FpZCwgbWF5YmUgSeKAmW0gYmVpbmcgdG9vIGxpdGVyYWwuDQoNCg0K DQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtk RUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlkPTgxMTI3YTlkLTA2NDEtNDIz Yy1iZTc3LTgxMjA3MDI0MTEwM13hkKcNCk9uIEZyaSwgRGVjIDIwLCAyMDE5IGF0IDU6MDggUE0g UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJp Y2hhbm5hQGFtYXpvbi5jb20+PiB3cm90ZToNCknigJltIG5vdCBzdXJlIGlmIHRoaXMgaXMgd2hh dCBFdmUgaGFkIGluIG1pbmQsIGJ1dCBjb25zaWRlciBhbiBhdXRvbWF0ZWQgc3lzdGVtIGluIGFu IGVudGVycHJpc2UgY29udGV4dCB0aGF0IGhhcyBiZWVuIGF1dGhvcml6ZWQgYnkgYW4gYWRtaW5p c3RyYXRvci4gVGhlIGF1dG9tYXRlZCBzeXN0ZW0gaXNu4oCZdCBhY3RpbmcgYXMgb3Igb24gYmVo YWxmIG9mIHRoZSBhZG1pbmlzdHJhdG9yLCBhbmQgdGhlIGFkbWluaXN0cmF0b3IgaGFzbuKAmXQg 4oCcZGVsZWdhdGVkIGFjY2Vzc+KAnTsgdGhleeKAmXZlIGdyYW50ZWQgYWNjZXNzLCBqdXN0IGFz IHRoZXkgZG8gd2hlbiB0aGV5IGFzc2lnbiBwZXJtaXNzaW9ucyB0byB1c2Vycy9ncm91cHMvcm9s ZXMvZXRjLg0KTWF5YmUgSeKAmW0gYmVpbmcgdG9vIGxpdGVyYWwsIGJ1dCDigJx0aHJvdWdoIGFu IGF1dGhvcml6YXRpb24gc2VydmVy4oCdIGluIHBhcmFncmFwaCAxIGltcGxpZXMgYSBzcGVjaWZp YyBjb250ZXh0L2luZm9ybWF0aW9uL3JlcXVlc3QgZmxvdyB0byBtZS4gR2l2ZW4gdGhhdCBvbmUg b2YgVHhBdXRo4oCZcyBmZWF0dXJlcyBpcyBkZWNvdXBsaW5nIHRoZSBkaWZmZXJlbnQgY29tbXVu aWNhdGlvbiBjaGFubmVscywgd2Ugc2hvdWxkIG5vdCBzdWdnZXN0IHRoYXQgdGhlIGNsaWVudCBv ciBhdXRob3JpemluZyBwYXJ0eSBpcyBkaXJlY3RseSBpbnRlcmFjdGluZyB3aXRoIHRoZSBBUy4N Cg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9t OiBUeGF1dGggPHR4YXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0eGF1dGgtYm91bmNlc0Bp ZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxt YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0KRGF0ZTogRnJpZGF5LCBEZWNlbWJlciAyMCwg MjAxOSBhdCA0OjE0IFBNDQpUbzogRXZlIE1hbGVyIDxldmVAeG1sZ3JybC5jb208bWFpbHRvOmV2 ZUB4bWxncnJsLmNvbT4+DQpDYzogInJkZEBjZXJ0Lm9yZzxtYWlsdG86cmRkQGNlcnQub3JnPiIg PHJkZEBjZXJ0Lm9yZzxtYWlsdG86cmRkQGNlcnQub3JnPj4sICJ0eGF1dGhAaWV0Zi5vcmc8bWFp bHRvOnR4YXV0aEBpZXRmLm9yZz4iIDx0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBpZXRm Lm9yZz4+LCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0 LmVkdT4+LCBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdTxtYWlsdG86a2FkdWtAbWl0LmVk dT4+DQpTdWJqZWN0OiBSZTogW1R4YXV0aF0gVHhBdXRoIFByb3Bvc2VkIENoYXJ0ZXINCg0KRXZl OiBkbyB5b3Ugbm90IHRoaW5rIHRoZSBzb2Z0d2FyZSBjbGllbnQgaXMgYWN0aW5nIG9uIGJlaGFs ZiBvZiBzb21lIHBhcnR5PyBPciBkbyB5b3UgdGhpbmsgdGhhdCBzb2Z0d2FyZSBhbHdheXMgaXMg YWN0aW5nIG9uIGJlaGFsZiBvZiBzb21lIHBhcnR5LCBhbmQgdGhlIG1lbnRpb25lZCBwaHJhc2Ug aXMgcmVkdW5kYW50Pw0KDQpKdXN0aW46IGEgY291cGxlIHF1ZXN0aW9ucw0KDQoxLiBXaGF0IGlz IG1lYW50IGJ5ICJEZWxlZ2F0aW9uIGJldHdlZW4gbXVsdGlwbGUgdXNlcnMiID8NCg0KMi4gV2h5 IGRvIHlvdSByZXN0cmljdCB0aGlzIHRvIEhUVFA/DQoNCjMuIFdoeSBpcyBhdXRoZW50aWNhdGlv biBub3QgaW4gc2NvcGU/DQoNCjQuIFdoZW4geW91IHNheSAibm90IGJhY2t3YXJkcyBjb21wYXRp YmxlIHdpdGggT0F1dGggMi4wIGFuZCBpdHMgZXh0ZW5zaW9ucyIsIGRvIHlvdSBleHBlY3QgdG8g ZGVmaW5lIGEgbmV3IHN0YW5kYXJkIHRvIHJlcGxhY2UgUkZDIDY3NTA/IERldmVsb3BlcnMgd2ls bCBoYXZlIHRvIGhhdmUgYSBuZXcgbWV0aG9kIHRvIGNhbGwgQVBJcz8NCg0KDQpPbiBGcmksIERl YyAyMCwgMjAxOSBhdCAzOjI3IFBNIEV2ZSBNYWxlciA8ZXZlQHhtbGdycmwuY29tPG1haWx0bzpl dmVAeG1sZ3JybC5jb20+PiB3cm90ZToNClJlIOKAnHRvIGEgc29mdHdhcmUgY2xpZW50IF9hY3Rp bmcgb24gYmVoYWxmIG9mIGFuIGF1dGhvcml6aW5nIHBhcnR5X+KAnTogVGhlcmUgaXMgYSB3aG9s ZSBsb3Qgb2YgcGhpbG9zb3BoeSBiZWhpbmQgd2hvbSB0aGUgZGVsZWdhdGVkIGFjY2VzcyBpcyBw ZXJmb3JtZWQgb24gYmVoYWxmIG9mLCB1bmxlc3MgdGhlIHNjZW5hcmlvIGlzIHNpbmdsZS11c2Vy IG9yIHNvbWUgImFjdCBhcyIgc2VtYW50aWMgaXMgc3BlbGxlZCBvdXQgb24gdGhlIHdpcmUuIERv ZXMgaXQgbmVlZCB0byBiZSBzdGF0ZWQgaGVyZT8gV2hhdCdzIHRoZSBjb25zZXF1ZW5jZSBpZiB0 aGUgaGlnaGxpZ2h0ZWQgcGhyYXNlIHdlcmUgcmVtb3ZlZD8NCkV2ZSBNYWxlciAoc2VudCBmcm9t IG15IGlQYWQpIHwgY2VsbCArMSA0MjUgMzQ1IDY3NTYNCg0KT24gRGVjIDIwLCAyMDE5LCBhdCA0 OjM0IFBNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0 LmVkdT4+IHdyb3RlOg0KSGkgYWxsLA0KDQpBcyBkaXNjdXNzZWQgaW4gU2luZ2Fwb3JlLCBubyBt YXR0ZXIgd2hhdCBmb3J1bSBUeEF1dGggdGFrZXMsIGl0cyB3b3JrIHdpbGwgcmVxdWlyZSBhIG5l dyBjaGFydGVyLiBXaXRoIHRoYXQgaW4gbWluZCwgSeKAmXZlIHRha2VuIGEgYml0IG9mIHRpbWUg dG8gcHV0IHRvZ2V0aGVyIGEgcHJvcG9zZWQgY2hhcnRlciB0ZXh0IGZvciB0aGUgVHhBdXRoIHdv cms6DQoNClRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBuZXh0LWdlbmVyYXRp b24gdHJhbnNhY3Rpb25hbCBhdXRob3JpemF0aW9uIGFuZCBkZWxlZ2F0aW9uIHByb3RvY29sIGZv ciBIVFRQLWJhc2VkIEFQSXMgYW5kIHRoZWlyIGNsaWVudHMuIFRoZXNlIHRyYW5zYWN0aW9ucyB3 aWxsIGFsbG93IGFuIGF1dGhvcml6aW5nIHBhcnR5IHRvIGRlbGVnYXRlIGEgcmlnaHQgb2YgYWNj ZXNzIGZvciBhbiBBUEkgb3Igc2V0IG9mIEFQSXMgdGhyb3VnaCBhbiBhdXRob3JpemF0aW9uIHNl cnZlciB0byBhIHNvZnR3YXJlIGNsaWVudCBhY3Rpbmcgb24gYmVoYWxmIG9mIGFuIGF1dGhvcml6 aW5nIHBhcnR5Lg0KDQpUaGUgZ3JvdXAgd2lsbCBkZWxpdmVyIGEgcHJvdG9jb2wgc3BlY2lmaWNh dGlvbiBkZXRhaWxpbmcgaG93IGEgY2xpZW50IGNhbiByZXF1ZXN0IGFuZCBvYnRhaW4gZGVsZWdh dGVkIGFjY2VzcywgaG93IGFuIGF1dGhvcml6YXRpb24gc2VydmVyIGNhbiBwcm92aWRlIGRlbGVn YXRlZCBhY2Nlc3MsIGhvdyBhbiBhdXRob3JpemVkIHBhcnR5IGNhbiBhdXRob3JpemUgZGVsZWdh dGVkIGFjY2VzcywgYW5kIGhvdyB0aGF0IGF1dGhvcml6ZWQgYWNjZXNzIGNhbiBiZSBjb21tdW5p Y2F0ZWQgdG8gdGhlIHJlc291cmNlcyBiZWluZyBwcm90ZWN0ZWQuIFRoZXNlIGFjdGlvbnMgd2ls bCBiZSBjb25uZWN0ZWQgdGhyb3VnaCBhbiBleHBsaWNpdCB0cmFuc2FjdGlvbiBiZXR3ZWVuIHRo ZSBjbGllbnQgYW5kIGF1dGhvcml6YXRpb24gc2VydmVyLCByZXN1bHRpbmcgaW4gYW4gYXJ0aWZh Y3QgdGhhdCB3aWxsIGFsbG93IHRoZSBjbGllbnQgdG8gdW5kZXJ0YWtlIHRoZSBkZWxlZ2F0ZWQg YWN0aW9uLg0KDQpBZGRpdGlvbmFsbHksIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mgd2lsbCBhbGxv dyBmb3I6DQotIEZpbmUtZ3JhaW5lZCBzcGVjaWZpY2F0aW9uIG9mIHJlc291cmNlIGFjY2Vzcw0K LSBEZWxlZ2F0aW9uIGJldHdlZW4gbXVsdGlwbGUgdXNlcnMNCi0gV2ViLCBtb2JpbGUsIHNpbmds ZS1wYWdlLCBhbmQgb3RoZXIgY2xpZW50IGFwcGxpY2F0aW9ucw0KDQpUaGUgZ3JvdXAgd2lsbCBk ZWZpbmUgZXh0ZW5zaW9uIHBvaW50cyBmb3IgdGhpcyBwcm90b2NvbCB0byBhbGxvdyBmb3IgZmxl eGliaWxpdHkgaW4gYXJlYXMgaW5jbHVkaW5nOg0KDQotIENyeXB0b2dyYXBoaWMgYWdpbGl0eSBm b3Iga2V5cywgbWVzc2FnZSBzaWduYXR1cmVzLCBhbmQgcHJvb2Ygb2YgcG9zc2Vzc2lvbg0KLSBV c2VyIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5jbHVkaW5nIHdlYiBhbmQgbm9uLXdlYiBtZXRo b2RzDQotIFRva2VuIHByZXNlbnRhdGlvbiBtZWNoYW5pc21zIGFuZCBrZXkgYmluZGluZ3MNCg0K VGhlIGFydGlmYWN0cyBmb3IgdGhpcyB3b3JrIGFyZSBub3QgaW50ZW5kZWQgb3IgZXhwZWN0ZWQg dG8gYmUgYmFja3dhcmRzLWNvbXBhdGlibGUgd2l0aCBPQXV0aCAyLjAgYW5kIGl0cyBleHRlbnNp b25zLg0KDQpXaGlsZSB0aGlzIHdvcmsgY291bGQgYmUgZG9uZSBpbiB3aXRoaW4gdGhlIE9BdXRo IHdvcmtpbmcgZ3JvdXAsIEkgbm93IGJlbGlldmUgdGhhdCBpdCBzaG91bGQgYmUgZG9uZSBpbiBh IG5ldyB3b3JraW5nIGdyb3VwLCBhbmQgdGhhdCB3ZSBzaG91bGQgdHJ5IHRvIGdldCB0aGF0IHdv cmtpbmcgZ3JvdXAgdXAgYW5kIHJ1bm5pbmcgcHJpb3IgdG8gdGhlIFZhbmNvdXZlciBtZWV0aW5n IGluIE1hcmNoLi4gSSB0aGluayB0aGlzIGdyb3VwIHNob3VsZCBzdGF5IGhlcmUgb24gdGhlIFR4 QXV0aCBsaXN0LCBhbmQgaXTigJlzIG15IHN1Z2dlc3Rpb24gdGhhdCB0aGUgcmVzdWx0aW5nIHdv cmsgYmUgY2FsbGVkIE9BdXRoIDMuMC4NCg0KV2h5IGEgbmV3IGdyb3VwPyBJIHRoaW5rIHRoYXQg dGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIHJlbWFpbiBmb2N1c2VkIG9uIGV4dGVuZGlu ZywgcGF0Y2hpbmcsIGFuZCBhZGFwdGluZyBPQXV0aCAyLjAgdG8gYSBjaGFuZ2luZyB3b3JsZC4g SSBwbGFuIHRvIGJlIGVuZ2FnZWQgaW4gYm90aCBncm91cHMsIGFuZCBJIGtub3cgbW9zdCBvZiB5 b3UgYXJlIGFzIHdlbGwsIGJ1dCB0aGF04oCZcyBub3QgdW5pdmVyc2FsLiBTaW5jZSBPQXV0aCAy LjAgaXMgc28gZXN0YWJsaXNoZWQgYWxyZWFkeSwgdGhlcmUgYXJlIGEgTE9UIG9mIHBlb3BsZSB3 aG8gYXJlbuKAmXQgZ29pbmcgdG8gYmUgaW50ZXJlc3RlZCBpbiBzb21ldGhpbmcgbmV3IGFueSB0 aW1lIHNvb24uIEJ1dCBvbiB0aGUgb3RoZXIgaGFuZCwgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHBl b3BsZSBmb3Igd2hvbSBPQXV0aCAyLjAgZG9lcyBub3Qgd29yaywgb3IgaXMgYXQgdGhlIHZlcnkg bGVhc3QgYSBwb29yIGZpdCwgYW5kIHdl4oCZbGwgd2FudCB0byBicmluZyB0aGVtIGluIGF0IHRo aXMgZWFybHkgc3RhZ2UuIFNvIGV2ZW4gd2l0aCBzaWduaWZpY2FudCBvdmVybGFwLCBJIHRoaW5r IHRoZXJl4oCZcyBlbm91Z2ggZGlzY29ubmVjdCBpbiB0aGUgY29tbXVuaXR5IGZyb20gYm90aCBz aWRlcyB0aGF0IHdhcnJhbnRzIGEgbmV3IGdyb3VwLiBJbiBhZGRpdGlvbiwgSSB0aGluayB0aGlz IGlzIGEgYmlnIGVub3VnaCBwaWVjZSBvZiB3b3JrIHRoYXQgaXTigJlzIHNpbXBseSB0b28gbXVj aCBmb3IgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgdG8gYmUgYWJsZSB0byBmb2N1cyBvbi4gV2Ug d291bGRu4oCZdCBiZSBhYmxlIHRvIGdldCBhZGRpdGlvbmFsIG1lZXRpbmcgdGltZSwgYW5kIE9B dXRoIGFscmVhZHkgaGFzIHRyb3VibGUgZml0dGluZyBpbnRvIGl0cyB0d28gbWVldGluZyBzbG90 cyBhcyBpdCBpcy4NCg0KSeKAmXZlIHB1Ymxpc2hlZCBhIGJsb2cgcG9zdCBkZXRhaWxpbmcgbW9y ZSBvZiBteSByYXRpb25hbGU6DQoNCmh0dHBzOi8vbWVkaXVtLmNvbS9AanVzdGluc2VjdXJpdHkv dGhlLWNhc2UtZm9yLW9hdXRoLTMtMC13aHktYS1uZXctd29ya2luZy1ncm91cC1kNjIyOWJhOGUz Nj8NCg0KUGxlYXNlIHN1Z2dlc3QgY2hhbmdlcyB0byB0aGUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0 IGFib3ZlLiBJdOKAmXMgbXkgaG9wZSB0aGF0IHdlIGNhbiBnZXQgdGhlIGNoYXJ0ZXJpbmcgcHJv Y2VzcyBzdGFydGVkLg0KDQog4oCUIEp1c3Rpbg0KLS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4 YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCi0tDQpUeGF1dGggbWFpbGluZyBsaXN0DQpUeGF1 dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQoNCg== --_000_FD7172F9ADFF49E1ABCADBCFB8FC8639amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAy IDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQg MiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3Nl LTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiRXVw aGVtaWEgVUNBUyI7DQoJcGFub3NlLTE6MiAxMSA1IDMgNCAxIDIgMiAxIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb25z b2xhcyIsc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4t bGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNv bm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQt c3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixzZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2NzI5NDk1ODY7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zNDg2Mzcw NiAxNDc3OTc2NTkwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE1ODAwMTUxMjU7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjcyMTExMTc0IDQzOTAyNTU4 NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0 OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28t ZmFyZWFzdC1mb250LWZhbWlseToiTVMgTWluY2hvIjsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgZmVl bGluZyBpcyB0aGF0IHRoZSBjaGFydGVyIHNob3VsZCByZWFkIG1vcmUgbGlrZSBhIHByb2JsZW0g c3RhdGVtZW50IHRoYW4gYSBzb2x1dGlvbiBwcm9wb3NhbC4gSSB0aGluayB3ZeKAmXJlIG9uIHRo ZSBzYW1lIHBhZ2UgdGhlcmUuIEhvd2V2ZXIsIHRoZSBjdXJyZW50IHRleHQgZG9lc27igJl0IGFk aGVyZSB0byB0aGlzOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPkl0IG1hbmRhdGVzIGEgdHJhbnNhY3Rp b25hbCBwcm90b2NvbC4gV2hpbGUgdGhpcyBpcyB0aGUgYXBwcm9hY2ggd2XigJlyZSBzdGFydGlu ZyBmcm9tLCB0aGVyZSBpcyBubyBndWFyYW50ZWUgdGhhdCBpdCBpcyB0aGUgY29ycmVjdCBvbmUs IGFuZCB3ZSBzaG91bGRu4oCZdCBib3ggb3Vyc2VsdmVzIGludG8gaXQuPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMiI+SXQgcmVmZXJzIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ci4gV2hpbGUgdGhpcyByb2xlIHRlbmRzIHRvIGJlIGNlbnRyYWwgdG8gb3VyIHNvbHV0aW9ucywg aXTigJlzIG5vdCBjbGVhciB0byBtZSB0aGF0IGl0IGlzIGFuIGluaGVyZW50IHBhcnQgb2YgdGhl IHByb2JsZW0gc3RhdGVtZW50LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKAkyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0 eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5KdXN0aW4gUmlj aGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIERl Y2VtYmVyIDI0LCAyMDE5IGF0IDQ6MTEgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O1JpY2hhcmQg QmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDtyaWNoYW5uYUBhbWF6b24uY29tJmd0Ozxicj4N CjxiPkNjOiA8L2I+RGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7LCBFdmUg TWFsZXIgJmx0O2V2ZUB4bWxncnJsLmNvbSZndDssICZxdW90O3JkZEBjZXJ0Lm9yZyZxdW90OyAm bHQ7cmRkQGNlcnQub3JnJmd0OywgJnF1b3Q7dHhhdXRoQGlldGYub3JnJnF1b3Q7ICZsdDt0eGF1 dGhAaWV0Zi5vcmcmZ3Q7LCBCZW5qYW1pbiBLYWR1ayAmbHQ7a2FkdWtAbWl0LmVkdSZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtUeGF1dGhdIFR4QXV0aCBQcm9wb3NlZCBDaGFydGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u 4oCZdCB0aGluayB3ZSBzaG91bGQgd3JpdGUgdGhlIGNoYXJ0ZXIgd2l0aCBhIHNwZWNpZmljIHNv bHV0aW9uIGluIG1pbmQsIGJ1dCBpbnN0ZWFkIGRlc2NyaWJpbmcgdGhlIHByb2JsZW1zIHRoYXQg d2Ugd2FudCB0byBzb2x2ZSB3aXRoIGEgc3RhbmRhcmQuIFRoZSDigJx3aXRoIGEgc3RhbmRhcmTi gJ0gaXMgaW1wb3J0YW50IGhlcmUgYXMgbm90IGV2ZXJ5IGFzcGVjdCBpcyBnb2luZyB0byBuZWVk IGEgc3RhbmRhcmQNCiBzcGVjaWZpY2F0aW9uLCBvbmx5IHRoZSBwYXJ0cyB3aGVyZSB3ZSBleHBl Y3QgY29tbXVuaWNhdGlvbiBhbmQgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGltcGxlbWVudGF0 aW9ucywgcmlnaHQ/DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgd291bGQgc2F5IHRoYXQgcmF0aGVyIHRoZSBjaGFydGVyIHNob3VsZCBiZSBtb3JlIGdl bmVyYWwgaW4gZGVzY3JpYmluZyB0aGUgcHVycG9zZSBhbmQgbm90IHB1dHRpbmcgdGhpbmdzIDpv dXQ6IG9mIHNjb3BlLiBJdCBtaWdodCB2ZXJ5IHdlbGwgYmUgdGhhdCB0aGUgZGVwbG95bWVudCB5 b3XigJlyZSBkZXNjcmliaW5nIGlzIGFuIG9wdGltaXphdGlvbiwgYnV0IGlmIGl0IG1ha2VzIHNl bnNlIHdpdGhpbiB0aGUNCiBib3VuZHMgb2YgdGhlIHdvcmssIGV2ZW4gaWYgdGhlIGRldGFpbHMg YXJlIGRlc2NyaWJlZCBpbiB0aGVpciBvd24gc3BlYyAob3Igbm90IGluIGEgc3BlYyBhdCBhbGws IGlmIHdlIGRlY2lkZSB0aGF04oCZcyBvbmUgb2YgdGhlIOKAnHVuZGVyIHRoZSBob29k4oCdIGFz cGVjdHMpLCB0aGVuIHRoYXTigJlzIE9LLiBJIGRvIGFncmVlIHRoYXQgd2hhdOKAmXMgcmVhbGx5 IGltcG9ydGFudCBoZXJlIGlzIGhhdmluZyBhbiBpZGVhIG9mIHdoYXQgdGhlIGRpZmZlcmVudA0K IG1vdmluZyBwYXJ0cyBhcmUsIGF0IGxlYXN0IHRvIHN0YXJ0LiBBbnkgcHJvcG9zZWQgaWRlYXMg b24gaG93IHRvIGRlc2NyaWJlIHRoaXMgd2l0aG91dCBnZXR0aW5nIGludG8gcHJlc2NyaXB0aXZl IGRlcGxveW1lbnQgZGV0YWlscz8NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gRGVjIDIzLCAyMDE5LCBhdCA2OjIyIFBNLCBSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20i PnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwb2ludCBpcywgSSBtaWdodCB3YW50IG15IHRv a2VucyB0byBiZSBzaWduZWQgdXNpbmcga2V5cyB0aGF0IG15IFRYIEVuZHBvaW50IGRvZXMgbm90 IGhhdmUgYWNjZXNzIHRvLiBFLmcuLCBteSB0b2tlbiBpc3N1ZXIgc2lnbnMgdG9rZW5zIHdpdGgg a2V5IEEgYW5kIG15IFRYIEVuZHBvaW50IHNpZ25zIEhUVFAgcmVzcG9uc2UgbWVzc2FnZXMgd2l0 aCBrZXkgQiwgbmVpdGhlciBzeXN0ZW0gaGFzIGFjY2Vzcw0KIHRvIHRoZSBvdGhlciBrZXksIGFu ZCB0b2tlbnMgc2lnbmVkIGJ5IGtleSBCIGFyZSByZWplY3RlZCBieSBSU2VzLiBUaGlzIHJlcXVp cmVzIHRoZSB3b3JraW5nIGdyb3VwIHRvIHVuZGVyc3RhbmQgdGhhdCB0cnVzdCBib3VuZGFyaWVz IG1heSBleGlzdCBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgY29tcG9uZW50cyBpbXBsZW1lbnRpbmcg cG9ydGlvbnMgb2Yg4oCcQVPigJ0gYmVoYXZpb3IuIElmIHRoaXMgaXNu4oCZdCB1bmRlcnN0b29k LCB0aGVuIGlmL3doZW4NCiBJIGJyaW5nIHVwIHRoaXMgdXNlIGNhc2UsIEnigJltIGdvaW5nIHRv IGJlIHRvbGQg4oCcdGhlcmUgYXJlIG5vIHRydXN0IGJvdW5kYXJpZXMgd2l0aGluIGFuIEFTLCBz byB3aGF0IHlvdeKAmXJlIGRlc2NyaWJpbmcgaXNu4oCZdCBhbiBBUyBhbnltb3JlLCBhbmQgbm90 IGluIHNjb3BlIHBlciB0aGUgY2hhcnRlci7igJ08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gc2Vuc2l0aXZlIHRvIHRoZSBkZXNpcmUg dG8gbm90IG92ZXJjb21wbGljYXRlIHRoaW5ncy4gVGhlIHNjZW5hcmlvIEnigJltIGRlc2NyaWJp bmcgaXMgdW51c3VhbCwgYW5kIHByb2JhYmx5IG5vdCB3aGF0IHdlIHNob3VsZCBvcHRpbWl6ZSB0 aGUgcHJvdG9jb2wgZm9yICh0aG91Z2ggdGhhdCBjb3VsZCBhbHdheXMgY2hhbmdlKS4gQnV0IHdl 4oCZcmUgdGFsa2luZyBhYm91dDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48aT5jaGFydGVyPC9pPiwNCiBub3Q8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGk+cHJvdG9jb2w8L2k+LiBUaGUgY2hhcnRlciBjYW4g YmUgYXMgZGV0YWlsZWQgYW5kIG51YW5jZWQgYXMgaXQgbmVlZHMgdG8gYmUgdG8gcHJvcGVybHkg ZGVzY3JpYmUgd2hhdCB3ZSBhcmUgc2V0dGluZyBvdXQgdG8gYWNjb21wbGlzaC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RnJvbTo8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFp bHRvOmpyaWNoZXJAbWl0LmVkdSI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs8YnI+DQo8Yj5EYXRl OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+TW9u ZGF5LCBEZWNlbWJlciAyMywgMjAxOSBhdCAxOjU3IFBNPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj4mcXVvdDtSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpv bi5jb20iPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+RGljayBIYXJkdCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNv bTwvYT4mZ3Q7LCBFdmUgTWFsZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpldmVAeG1sZ3JybC5jb20i PmV2ZUB4bWxncnJsLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86cmRkQGNlcnQu b3JnIj5yZGRAY2VydC5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmRkQGNlcnQu b3JnIj5yZGRAY2VydC5vcmc8L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86dHhhdXRo QGlldGYub3JnIj50eGF1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 dHhhdXRoQGlldGYub3JnIj50eGF1dGhAaWV0Zi5vcmc8L2E+Jmd0OywgQmVuamFtaW4gS2FkdWsg Jmx0OzxhIGhyZWY9Im1haWx0bzprYWR1a0BtaXQuZWR1Ij5rYWR1a0BtaXQuZWR1PC9hPiZndDs8 YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L2I+UmU6IFtUeGF1dGhdIFR4QXV0aCBQcm9wb3NlZCBDaGFydGVyPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNvIHRoZSB0aGluZyBpcywgSSBkb27igJl0IHRoaW5rIHlvdSBu ZWVkIGEgc2luZ2xlIEpXS1MgVVJJIGFueW1vcmUgYW55d2F5LiBZb3XigJlkIGhhdmUgb25lIGFz c29jaWF0ZWQgd2l0aCB0aGUgVHhFbmRwb2ludCwgaWYgeW914oCZdmUgZ290IHNpZ25lZCB0b2tl bnMgdGhhdCB5b3UgbmVlZCB0byB2YWxpZGF0ZSBzZXBhcmF0ZWx5LiBBbmQgaWYgeW914oCZcmUg ZG9pbmcgc2lnbmVkIHVzZXIgYXNzZXJ0aW9ucywgeW914oCZZA0KIGhhdmUgYSBkaWZmZXJlbnQg b25lIGlkZW50aWZpZWQgaW4gdGhlIGFzc2VydGlvbiAoZWl0aGVyIGRpcmVjdGx5IG9yIHZpYSBh biBpc3N1ZXItZGlzY292ZXJ5IG1lY2hhbmlzbSkuIFVsdGltYXRlbHkgdGhlIGNsaWVudCBpcyBn b2luZyB0byBjYXJlIGFib3V0IG9uZSBhbmQgdGhlIFJTIGFib3V0IGFub3RoZXIgc28gaXTigJlz IGZpbmUgdGhhdCB0aGV54oCZcmUgZGlmZmVyZW50LiBXZSBnZXQgdG8gZGVmaW5lIHdoYXQgdGhh dCBsb29rcyBsaWtlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gdGhlIHN1cmZhY2UgSeKA mW0gT0sgd2l0aCBhIGRlY29tcG9zZWQgQVMsIHRvIHNvbWUgZXh0ZW50LCBidXQgb25seSBpZiB0 aGVyZSBhcmUgdmVyeSwgdmVyeSBjbGVhciBib3VuZGFyaWVzIGFib3V0IHdoYXQgdGhlIGluZGl2 aWR1YWwgcm9sZXMgYXJlLiBBbmQgdGhlIG1vcmUgcm9sZXMgd2UgbWFrZSwgdGhlIG1vcmUgd2Ug aGF2ZSB0byBkZWZpbmUgd2hhdCB0aGUgY29tbXVuaWNhdGlvbiBwb2ludHMgYXJlDQogaW4gYmV0 d2VlbiB0aGVtLiBNYXliZSDigJxBU+KAnSBpcyB0b28gYWxsLWVuY29tcGFzc2luZyBvZiBhIHJv bGUgbm93LCBidXQgSeKAmW0gbm90IHlldCBjb252aW5jZWQgdGhhdOKAmXMgdHJ1ZSBpbiBwcmFj dGljZSwgYW5kIEkgZG8gd2FudCBzb21lb25lIHRvIGJlIGFibGUgdG8gZGVwbG95IHRoaXMgYnkg aGF2aW5nIGFsbCB0aGUg4oCcc2VydmVy4oCdIHNpZGUgZnVuY3Rpb25hbGl0aWVzIHJ1bm5pbmcg b3V0IG9mIGEgc2luZ2xlLCBzaW1wbGUgYm94LiBUaGF0DQogbWlnaHQgYmUgYSBjYXNlIG9mIHRo YXQgc2luZ2xlIGJveCBuZWVkaW5nIHRvIHBsYXkgbXVsdGlwbGUgcm9sZXMsIGFuZCB0aGF04oCZ cyBPSywgYnV0IHdlIG5lZWQgdG8gYmUgY2xlYXIgb24gd2hhdCBraW5kcyBvZiBvcHRpbWl6YXRp b25zIGFyZSBhbGxvd2FibGUgaW4gY2FzZXMgbGlrZSB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGRvIHRoaW5rIHRoZXJl4oCZcyBwcmVjZWRlbnQgaW4gYXNraW5nIHRoaXMgcXVl c3Rpb24gdGhvdWdoLCBzaW5jZSBiZXR3ZWVuIE9BdXRoIDEgYW5kIDIgd2Ugc3BsaXQgdGhlIOKA nHNlcnZlcuKAnSBpbnRvIOKAnEFTIGFuZCBSU+KAnS4gT0F1dGggMiBmYW1vdXNseSBkaWRu4oCZ dCBkZWZpbmUgYSBjb25uZWN0aW9uIHBvaW50IGJldHdlZW4gdGhlbSB1bnRpbCBtdWNoIGxhdGVy IChKV1QgYW5kIEludHJvc3BlY3Rpb24pLCBidXQNCiB0aGF0IHBhdHRlcm4gc2VlbXMgdG8gaGF2 ZSBtb3N0bHkgd29ya2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDvigJQgSnVz dGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBEZWMgMjIsIDIwMTksIGF0IDExOjUyIFBN LCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5h QGFtYXpvbi5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5j b208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBleGFtcGxlIGRl bW9uc3RyYXRlcyBhbiBhcmNoaXRlY3R1cmUgd2hlcmUgdGhlIFRYIEVuZHBvaW50LCBhdXRoZW50 aWNhdGlvbiBzeXN0ZW0sIGFuZCB0b2tlbiBpc3N1ZXIgYXJlbuKAmXQgc2ltcGx5IGRpZmZlcmVu dCBtaWNybyBzZXJ2aWNlcywgdGhleeKAmXJlIGNvbXBsZXRlbHkgaW5kZXBlbmRlbnQgc3lzdGVt cyBpbiBkaWZmZXJlbnQgdHJ1c3QgYm91bmRhcmllcywgcG9zc2libHkgaGF2ZSBkaWZmZXJlbnQN CiBkb21haW5zIGFuZCBkaWZmZXJlbnQga2V5cy4gVGhpcyBoYXMgaW1wbGljYXRpb25zIGZvciBw cm90b2NvbCBkZXNpZ24uIEZvciBleGFtcGxlLCBpdCB3b3VsZCBubyBsb25nZXIgYmUgc3VmZmlj aWVudCB0byBoYXZlIGEgc2luZ2xlIGp3a3NfdXJpLCBhcyBPQXV0aCAyLjAgaGFzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2Ugd2FudCB0byBzdXBwb3J0IHRoaXMga2luZCBv ZiDigJxkZWNvbXBvc2VkIEFT4oCdIG1vZGVsLCB0aGVuIHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRo YXTigJlzIHN1cHBvcnRlZCBieSB0aGUgY2hhcnRlciBhbmQga2VlcCBpdCBpbiBtaW5kIGFzIHdl IGRlc2lnbiB0aGUgcHJvdG9jb2wuIFdlIGNhbiBhbHNvIGRlY2lkZSBpdCBpcyBvdXQgb2Ygc2Nv cGUsIGJ1dCB3ZSBzaG91bGQgYmUgaW50ZW50aW9uYWwgYWJvdXQNCiB0aGF0IGRlY2lzaW9uLjxi cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gbXkgbWluZCwgdGhpcyByb2xl IGRlY29tcG9zaXRpb24gaXMgdGhlIG5leHQgbG9naWNhbCBzdGVwIGFmdGVyIHRoZSBjaGFubmVs IGRlY29tcG9zaXRpb24gdGhhdCBUeEF1dGggYWxyZWFkeSBkb2VzLiBJIHNlZSBhIGxvdCBvZiBw b3RlbnRpYWwgaW4gaXQgYW5kIHRoaW5rIHdlIHNob3VsZCBhdCBtaW5pbXVtIGF2b2lkIGNsb3Np bmcgdGhlIGRvb3Igb24gaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPk9uIERlYyAyMiwgMjAxOSwgYXQgNTozNSBQTSwgSnVzdGluIFJpY2hlciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+anJpY2hlckBtaXQuZWR1PC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSB0aGluayB5b3XigJlyZSBjb25mbGF0aW5nIHRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48aT5yb2xlczwvaT4mbmJzcDt0aGF0IGRpZmZlcmVu dCBjb21wb25lbnRzIHBsYXksIGluIHJlZ2FyZCB0byB0aGUgb3RoZXIgY29tcG9uZW50cywgd2l0 aCB0aGUgcG90ZW50aWFsIGRlcGxveW1lbnQgb2YgdGhvc2UgY29tcG9uZW50cy4gVGhlIHNwZWMg bmVlZHMgdG8gYmUgd3JpdHRlbiBpbg0KIHRlcm1zIG9mIHRoZSByb2xlcy4gV2hpbGUgdGhlIHJv bGVzIGRvIG5lZWQgdG8gY29uc2lkZXIgd2hhdCBwb3RlbnRpYWwgZGVwbG95bWVudHMgbWlnaHQg YmUsIGl04oCZcyBpbXBvcnRhbnQgdGhhdCB3ZSB3cml0ZSB0aGluZ3MgaW4gaW4gdGVybXMgb2Yg aG93IHRoZXkgaW50ZXJhY3Qgd2l0aCBlYWNoIG90aGVyIGFuZCBub3QgaW4gdGVybXMgb2YgaG93 IHRoZXkgbWlnaHQgbG9vayB1bmRlciB0aGUgY292ZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28g ZnJvbSB0aGUgY2xpZW50cyBwZXJzcGVjdGl2ZSwgdGhlIFRYIEVuZHBvaW50IDppczogdGhlIEFT LiBUaGUgY2xpZW50IGRvZXNu4oCZdCBjYXJlIHRoYXQgaXTigJlzIGEg4oCcZ2xvcmlmaWVkIG1l c3NhZ2UgcXVldWXigJ0gb3IgaWYgaXTigJlzIGEgbWFzc2l2ZSBzZXJ2ZXIgZmFybS4gVGhlIGNs aWVudCBkb2VzbuKAmXQgY2FyZSBpZiB0aGVyZeKAmXMgYSBUTFMgcmV2ZXJzZSBwcm94eSBvciBp ZiBpdOKAmXMgdGFsa2luZyBkaXJlY3RseQ0KIHRvIHRoZSBhcHBsaWNhdGlvbiBsYXllci4gVGhl IG9ubHkgdGhpbmcgdGhlIGNsaWVudCBjYXJlcyBhYm91dCBpcyBpZiB0aGUgVFggRW5kcG9pbnQg ZG9lcyB0aGUgdGhpbmdzIHRoYXQgYSBUWCBFbmRwb2ludCBpcyBzdXBwb3NlZCB0byBkbywgYW5k IHdlIGRlZmluZSB0aGF0IHRvIGJlIHRoZSBmdW5jdGlvbiBvZiB0aGUgQVMuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXTigJlzIGltcG9ydGFudCBpbiB5b3VyIHNjZW5hcmlv IGJlbG93IGlzIHRoYXQgdGhlIGNsaWVudCB3b3VsZCBoYXZlIHRvIHRhbGsgdG8gdGhlIFJTIGZp cnN0IGV2ZXJ5IHRpbWUuIFRoYXTigJlzIG9uZSBvZiB0aGUgcHJvYmxlbXMgdGhhdCBVTUEgaGFz LCBhbmQgSSB0aGluayBzb21ldGhpbmcgd2Ugc2hvdWxkIGF2b2lkLiBJIHRoaW5rIFJTLWZpcnN0 IGlzIGFuIGludGVyZXN0aW5nIHBhdHRlcm4gYnV0IEFTLWZpcnN0DQogb3VnaHQgdG8gZHJpdmUg dGhpcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0aCB5b3VyIGh5cG90aGV0 aWNhbCBsYXlvdXQgYmVsb3csIGl0IHJlYWxseSBzb3VuZHMgbGlrZSB0aGUgVFggRW5kcG9pbnQg aXMgYSBmdW5jdGlvbiBvZiB0aGUgSURQLCB3aGljaCBpcyBmaW5lLiBUaGUgY2xpZW50IGRvZXNu 4oCZdCBjYXJlIHRoYXQgaXTigJlzIGRlcGxveWVkIHVzaW5nIHNvbWUgZXh0ZXJuYWxpemVkIGNs b3VkIHNlcnZpY2UuIFRoZSBvbmx5IHdlaXJkIHRoaW5nIGdvaW5nIG9uIGlzIHRoZSBwdXNoDQog ZnJvbSB0aGUgQVMgYmFjayB0byB0aGUgY2xpZW50LiBUaGUgY2xpZW50IHdvdWxkIG5lZWQgdG8g cmVnaXN0ZXIgdGhhdCB3aXRoIHRoZSBBUyAob3IgdGhyb3VnaCB0aGUgQVMgbW9yZSBzcGVjaWZp Y2FsbHkpIGFzIHBhcnQgb2YgaXRzIHRyYW5zYWN0aW9uIHJlcXVlc3QuIFRoaXMgd291bGQgYmUg cGFydCBvZiBpdHMgaW50ZXJhY3Rpb24gbWVjaGFuaXNtLCBiZWNhdXNlIOKAnGhvdyB5b3UgZ2V0 IG1lc3NhZ2VzIGFuZCB1cGRhdGVzIGJhY2sgdG8NCiB0aGUgY2xpZW504oCdIGlzIHBhcnQgb2Yg dGhlIGludGVyYWN0aW9uIG1vZGVsLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T byBmb3IgYW4gUlMtZmlyc3QgdHJhbnNhY3Rpb24sIHRoZSBjbGllbnQgY2FsbHMgdGhlIFJTOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HRVQgL2ZvbzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGUgUlMgcmV0dXJucyBhIHJlc291cmNlIGhhbmRsZSwgYnV0IHRoZSBjbGllbnQgZG9l c27igJl0IGNhcmUgd2hlcmUgdGhhdCBjYW1lIGZyb20uIFRoZSBSUyBjb3VsZCB0YWxrIHRvIHRo ZSBBUyB0byBnZXQgaXQuIFByb2JhYmx5IGEgbmV3IGVuZHBvaW50IG9mIHNvbWUga2luZCwgY2Fu IHByb2JhYmx5IHVzZSB0aGUgc2FtZSBraW5kcyBvZiBrZXkgYmluZGluZyB0aGF0IHRoZSBUWCBF bmRwb2ludCBoYXMuIE9yDQogdGhlIFJTIGNhbiBtYWtlIG9uZSB1cCB0aGF0IHRoZSBUWCBFbmRw b2ludCBjYW4gcmVjb2duaXplLiBPciBpdCBjYWxscyB0aGUgSWRQIHRvIGdldCBvbmUuIFRoZSBj bGllbnQgZG9lc27igJl0IGNhcmUsIGFuZCB0aGF04oCZcyB0aGUga2V5IHBvaW50LiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XV1ctQXV0aGVudGljYXRlIHR4X2VuZHBvaW50PeKA nDxhIGhyZWY9Imh0dHA6Ly9zZXJ2ZXIlRUYlQkYlQkQvdHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHA6Ly9zZXJ2ZXIvL3R4PC9zcGFuPjwvYT7igJ0gcmVzb3VyY2U6IOKAnGFzZGYx MjM04oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjbGllbnQgY2FsbHMgdGhlIFRY IGVuZHBvaW50IGxpa2UgYSBub3JtYWwgdHJhbnNhY3Rpb246PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlBPU1QgL3R4PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPns8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyByZXNvdXJjZXM6IFsg4oCcYXNkZjEyMzTigJ0gXSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBpbnRl cmFjdDogezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyByZWRpcmVjdDogdHJ1ZSw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgcHVzaDog4oCcPGEgaHJlZj0iaHR0cDovL2NsaWVudC9wdXNoLzk4NzYi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9jbGllbnQvcHVzaC85ODc2PC9zcGFu PjwvYT7igJ08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj59PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBBUyAod2hpY2ggaXMgdG8gc2F5IHRoZSBUWCBFbmRwb2ludCkgdGVsbHMg dGhlIGNsaWVudCB0byBzZW5kIHRoZSB1c2VyIGFnZW50IHRvIHRoZSBJZFA8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+ezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IGludGVyYWN0X3VybDog4oCcPGEgaHJl Zj0iaHR0cDovL2lkcC9sb2dpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL2lk cC9sb2dpbjwvc3Bhbj48L2E+4oCdLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IGhhbmRsZTogeyB2YWx1ZTog 4oCcaGprbOKAnSwgdHlwZTogYmVhcmVyIH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPn08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Tm93IHRoZSBjbGllbnQgY291bGQgcG9sbCB0aGUgVFggRW5kcG9pbnQgYnV0IGl0 IGNvdWxkIGFsc28ganVzdCBzaXQgYW5kIHdhaXQgZm9yIGFuIHVwZGF0ZSB0byBiZSBwdXNoZWQg aW4uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSBwcm9iYWJseSB0 aGluZ3MgdGhhdCBuZWVkIHRvIGJlIHRpZWQgdG9nZXRoZXIgZm9yIHRoaXMgdG8gYmUgc2VjdXJl LCBidXQgSSB0aGluayB0aGUgYmFzaWMgcGF0dGVybiBzdGlsbCBmaXRzLiBJbXBvcnRhbnRseSwg dGhlIGNsaWVudCBkb2VzbuKAmXQgY2FyZSB3aGVyZWJ5IG9mIHRoYXQgc3R1ZmYgY2FtZSBmcm9t IOKAlCBhcyBmYXIgYXMgaXTigJlzIGNvbmNlcm5lZCwgaXTigJlzIHRhbGtpbmcgdG8gdGhlDQog QVMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlbWVtYmVyLCB0aGUg4oCcQVPi gJ0gaXMgYSBsb2dpY2FsIGNvbnN0cnVjdCwgbm90IGEgcGh5c2ljYWwgb25lLiBKdXN0IGxpa2Ug dGhlIOKAnGNsaWVudOKAnSBjb3VsZCBiZSBhIGNsdXN0ZXIgb2YgYXBwbGljYXRpb25zIGFuZCB0 aGUg4oCcUlPigJ0gY291bGQgYmUgYSBzdWl0ZSBvZiBBUElzIHRpZWQgYmVoaW5kIGEgZ2F0ZXdh eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBEZWMgMjIs IDIwMTksIGF0IDE6MDUgQU0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVm PSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ cmljaGFubmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gRGVjIDIxLCAyMDE5LCBhdCA0OjQyIEFNLCBKdXN0aW4gUmljaGVy ICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1Ij48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5qcmljaGVyQG1pdC5lZHU8L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdmVuIGlmIHRoZSBjbGllbnQgc3RhcnRz IGF0IHRoZSBSUywgdGhlIGNsaWVudCBzdGlsbCBoYXMgdG8gZ28gdGFsayB0byB0aGUgQVMuIEkg aGF2ZW7igJl0IGJ1aWx0IHRoaXMgb3V0LCBidXQgSSBzZWUgaXQgd29ya2luZyBzb21ld2hhdCBs aWtlIFVNQS4gSW4gWFla4oCZcyB0ZXJtczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4xLiBDbGllbnQgY2FsbHMgdGhlIFJTIHRyeWluZyB0byBEbyBBIFRoaW5n PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4yLiBSUyBjYWxscyB0aGUgQVMgcmVxdWVzdGluZyBhIFJlc291cmNlIEhhbmRs ZSAoYmVjYXVzZSB0aGF04oCZcyB3aGF0IHRoZSBSUyByZXByZXNlbnRzLCByZXNvdXJjZXMpIOKA lCBhdCBsZWFzdCBnb29kIGVub3VnaCB0byBjb3ZlciB3aGF0IHRoZSBjbGllbnQgdHJpZWQgdG8g ZG8sIGNvdWxkIGJlIG1vcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuIFJTIGdpdmVzIHRoZSBSZXNvdXJjZSBIYW5k bGUgYW5kIEFTIFRyYW5zYWN0aW9uIEVuZHBvaW50IGJhY2sgdG8gdGhlIGNsaWVudDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+NC4gQ2xpZW50IGNhbGxzIHRoZSBBUyBUcmFuc2FjdGlvbiBFbmRwb2ludCB0byBzdGFydCBh IHRyYW5zYWN0aW9uLCBpbmNsdWRlcyB0aGUgUmVzb3VyY2UgSGFuZGxlIGFzIHBhcnQgb2YgaXRz IHJlcXVlc3QgKG5vdGU6IGRvZXNu4oCZdCBoYXZlIHRvIGJlIHRoZSB3aG9sZSByZXNvdXJjZSBz ZWN0aW9uLCBjbGllbnQgY2FuIGFkZCBzdHVmZik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUuIFByb2Nlc3MgY29udGlu dWVzIGFzIG5vcm1hbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SXQgZGVwZW5kcyBvbiB3aGF0IHlvdSBjb25zaWRlciB0aGUg4oCcQVPi gJ0uIENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgaHlwb3RoZXRpY2FsIGFyY2hpdGVjdHVyZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCiIFRoZSBSUywgY2xpZW50LCBhbmQgdHggZW5kcG9p bnQgYXJlIG9uIHRoZSBwdWJsaWMgSW50ZXJuZXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igKIgVGhlIHR4IGVuZHBv aW50IHJldHVybnMgaW50ZXJhY3Rpb24gdXJscyB0aGF0IHBvaW50IHRvIGFuIElkUCB0aGF0IGlz IGluYWNjZXNzaWJsZSBmcm9tIHRoZSBwdWJsaWMgSW50ZXJuZXQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igKIgVGhl IHVzZXIgYWdlbnQgY2FuIHJlYWNoIHRoZSBJZFAsIGJ1dCBub25lIG9mIHRoZSBvdGhlciBzeXN0 ZW1zIGNhbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPuKAoiBXaGVuIHRoZSBVQSBpcyByZWRpcmVjdGVkIHRvIHRoZSBJ ZFAsIHRoZSBJZFAgY2FsbHMgdGhlIHR4IGVuZHBvaW50IHN5c3RlbSB0byByZXRyaWV2ZSB0cmFu c2FjdGlvbiBkZXRhaWxzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCiIFdoZW4gYXV0aG9yaXphdGlvbiBpcyBncmFu dGVkLCB0aGUgSWRQIHB1c2hlcyBhcnRpZmFjdHMgZGlyZWN0bHkgdG8gYW4gZW5kcG9pbnQgcHJv dmlkZWQgYnkgdGhlIGNsaWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhpcyBl eGFtcGxlLCB0aGUgY2xpZW50IG9ubHkgaW50ZXJhY3RzIHdpdGggdGhlIFJTIGFuZCB0aGUgdHgg ZW5kcG9pbnQuIEl0IHNlZW1zIG9kZCB0byBtZSB0byBjb25zaWRlciB0aGUgc3lzdGVtIGhvc3Rp bmcgdGhlIHR4IGVuZHBvaW50IHRvIGJlIHRoZSBBUyAob3IgYXQgbGVhc3QgcGFydCBvZiB0aGUg QVMpLCBhcyBpdHMgYSBnbG9yaWZpZWQgbWVzc2FnZSBxdWV1ZSB3aXRoIGVzc2VudGlhbGx5IG5v DQogYXV0aG9yaXR5IGluIHRoaXMgYXJjaGl0ZWN0dXJlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XZSBjb3VsZCBnbyBhIHN0ZXAgZnVydGhlciBhbmQgcmVtb3ZlIHRoZSBjbGll bnTigJlzIGludGVyYWN0aW9uIHdpdGggdGhlIHR4IGVuZHBvaW50IGJ5IGhhdmluZyB0aGUgUlMg cmV0dXJuIHRoZSBpbnRlcmFjdGlvbiB1cmwgZGlyZWN0bHkgKHlvdeKAmWQgbmVlZCB0byBzZWN1 cmUgdGhlIGNsaWVudCBub25jZSBpZiB5b3Ugd2FudCB0byBoaWRlIGl0IGZyb20gdGhlIFJTLCBi dXQgdGhhdOKAmXMgbm90IHRoYXQgaGFyZCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklz IHRoZSBtZWFuaW5nIG9mIOKAnGF1dGhvcml6YXRpb24gc2VydmVy4oCdIChvciB0aGUgcGhyYXNl IOKAnHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXLigJ0pIGZsZXhpYmxlIGVub3VnaCB0 byBhY2NvbW1vZGF0ZSB0aGVzZSBjYXNlcz8gT3IgYXJlIHRoZXkgY29uc2lkZXJlZCBvdXQgb2Yg c2NvcGUgZm9yIFR4QXV0aD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgSSBzYWlkLCBtYXliZSBJ4oCZbSBiZWluZyB0b28gbGl0 ZXJhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGltZyBib3JkZXI9IjAiIGlk PSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2Vu ZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9emVyb2NvbnRlbnQm YW1wO2d1aWQ9ODExMjdhOWQtMDY0MS00MjNjLWJlNzctODEyMDcwMjQxMTAzIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0V1cGhlbWlhIFVDQVMmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZy aSwgRGVjIDIwLCAyMDE5IGF0IDU6MDggUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0 OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5yaWNoYW5uYUBhbWF6b24uY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SeKAmW0gbm90IHN1cmUgaWYgdGhpcyBpcyB3aGF0IEV2ZSBoYWQgaW4gbWluZCwgYnV0IGNv bnNpZGVyIGFuIGF1dG9tYXRlZCBzeXN0ZW0gaW4gYW4gZW50ZXJwcmlzZSBjb250ZXh0IHRoYXQg aGFzIGJlZW4gYXV0aG9yaXplZCBieSBhbiBhZG1pbmlzdHJhdG9yLiBUaGUgYXV0b21hdGVkIHN5 c3RlbSBpc27igJl0IGFjdGluZyBhcyBvciBvbiBiZWhhbGYgb2YgdGhlIGFkbWluaXN0cmF0b3Is IGFuZCB0aGUgYWRtaW5pc3RyYXRvcg0KIGhhc27igJl0IOKAnGRlbGVnYXRlZCBhY2Nlc3PigJ07 IHRoZXnigJl2ZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48aT5ncmFudGVkPC9pPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5hY2Nlc3MsIGp1c3QgYXMgdGhleSBkbyB3aGVuIHRoZXkgYXNzaWduIHBlcm1pc3Np b25zIHRvIHVzZXJzL2dyb3Vwcy9yb2xlcy9ldGMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXliZSBJ4oCZbSBiZWluZyB0b28gbGl0ZXJhbCwg YnV0IOKAnHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXLigJ0gaW4gcGFyYWdyYXBoIDEg aW1wbGllcyBhIHNwZWNpZmljIGNvbnRleHQvaW5mb3JtYXRpb24vcmVxdWVzdCBmbG93IHRvIG1l LiBHaXZlbiB0aGF0IG9uZSBvZiBUeEF1dGjigJlzIGZlYXR1cmVzIGlzIGRlY291cGxpbmcgdGhl IGRpZmZlcmVudCBjb21tdW5pY2F0aW9uIGNoYW5uZWxzLCB3ZSBzaG91bGQNCiBub3Qgc3VnZ2Vz dCB0aGF0IHRoZSBjbGllbnQgb3IgYXV0aG9yaXppbmcgcGFydHkgaXMgZGlyZWN0bHkgaW50ZXJh Y3Rpbmcgd2l0aCB0aGUgQVMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+4oCT Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJk IEJhY2ttYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPkZyb206PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlR4 YXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dHhhdXRoLWJvdW5jZXNAaWV0Zi5v cmc8L3NwYW4+PC9hPiZndDsNCiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+ZGljay5oYXJkdEBnbWFpbC5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8 Yj5EYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L2I+RnJpZGF5LCBEZWNlbWJlciAyMCwgMjAxOSBhdCA0OjE0IFBNPGJyPg0KPGI+VG86PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5FdmUgTWFsZXIg Jmx0OzxhIGhyZWY9Im1haWx0bzpldmVAeG1sZ3JybC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5ldmVAeG1sZ3JybC5jb208L3NwYW4+PC9hPiZndDs8YnI+ DQo8Yj5DYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpyZGRAY2VydC5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yZGRAY2VydC5vcmc8L3NwYW4+PC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJkZEBjZXJ0Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnJkZEBjZXJ0Lm9yZzwvc3Bhbj48L2E+Jmd0OywgJnF1b3Q7PGEg aHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPnR4YXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+JnF1b3Q7DQogJmx0Ozxh IGhyZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj50eGF1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDssIEp1c3RpbiBS aWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5qcmljaGVyQG1pdC5lZHU8L3NwYW4+PC9hPiZn dDssIEJlbmphbWluIEthZHVrICZsdDs8YSBocmVmPSJtYWlsdG86a2FkdWtAbWl0LmVkdSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmthZHVrQG1pdC5lZHU8L3Nw YW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UmU6IFtUeGF1dGhdIFR4QXV0aCBQcm9wb3NlZCBDaGFy dGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXZlOiBkbyB5b3Ug bm90IHRoaW5rIHRoZSBzb2Z0d2FyZSBjbGllbnQgaXMgYWN0aW5nIG9uIGJlaGFsZiBvZiBzb21l IHBhcnR5PyBPciBkbyB5b3UgdGhpbmsgdGhhdCBzb2Z0d2FyZSBhbHdheXMgaXMgYWN0aW5nIG9u IGJlaGFsZiBvZiBzb21lIHBhcnR5LCBhbmQgdGhlIG1lbnRpb25lZCBwaHJhc2UgaXMgcmVkdW5k YW50PzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkp1c3RpbjogYSBjb3VwbGUgcXVlc3Rpb25zPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjEuIFdoYXQgaXMgbWVhbnQgYnkgJnF1b3Q7RGVsZWdhdGlvbiBiZXR3ZWVu IG11bHRpcGxlIHVzZXJzJnF1b3Q7ID88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gV2h5 IGRvIHlvdSByZXN0cmljdCB0aGlzIHRvIEhUVFA/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjMuIFdoeSBpcyBhdXRoZW50aWNhdGlvbiBub3QgaW4gc2NvcGU/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjQuIFdoZW4geW91IHNheSAmcXVvdDtub3QgYmFja3dhcmRzIGNvbXBhdGlibGUg d2l0aCBPQXV0aCAyLjAgYW5kIGl0cyBleHRlbnNpb25zJnF1b3Q7LCBkbyB5b3UgZXhwZWN0IHRv IGRlZmluZSBhIG5ldyBzdGFuZGFyZCB0byByZXBsYWNlIFJGQyA2NzUwPyBEZXZlbG9wZXJzIHdp bGwgaGF2ZSB0byBoYXZlIGEgbmV3IG1ldGhvZCB0byBjYWxsIEFQSXM/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBG cmksIERlYyAyMCwgMjAxOSBhdCAzOjI3IFBNIEV2ZSBNYWxlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmV2ZUB4bWxncnJsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPmV2ZUB4bWxncnJsLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPlJlIOKAnDxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRl Ij50byBhIHNvZnR3YXJlIGNsaWVudCBfYWN0aW5nIG9uIGJlaGFsZiBvZiBhbiBhdXRob3Jpemlu ZyBwYXJ0eV/igJ06IFRoZXJlIGlzIGEgd2hvbGUgbG90IG9mIHBoaWxvc29waHkgYmVoaW5kIHdo b20gdGhlIGRlbGVnYXRlZCBhY2Nlc3MgaXMgcGVyZm9ybWVkIG9uIGJlaGFsZiBvZiwNCiB1bmxl c3MgdGhlIHNjZW5hcmlvIGlzIHNpbmdsZS11c2VyIG9yIHNvbWUgJnF1b3Q7YWN0IGFzJnF1b3Q7 IHNlbWFudGljIGlzIHNwZWxsZWQgb3V0IG9uIHRoZSB3aXJlLiBEb2VzIGl0IG5lZWQgdG8gYmUg c3RhdGVkIGhlcmU/IFdoYXQncyB0aGUgY29uc2VxdWVuY2UgaWYgdGhlIGhpZ2hsaWdodGVkIHBo cmFzZSB3ZXJlIHJlbW92ZWQ/Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox My4wcHQiPkV2ZSBNYWxlciAoc2VudCBmcm9tIG15IGlQYWQpIHwmbmJzcDtjZWxsICYjNDM7MSA0 MjUgMzQ1IDY3NTY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5PbiBEZWMgMjAsIDIwMTksIGF0IDQ6MzQgUE0sIEp1c3RpbiBS aWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5qcmljaGVyQG1pdC5lZHU8L3NwYW4+PC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B cyBkaXNjdXNzZWQgaW4gU2luZ2Fwb3JlLCBubyBtYXR0ZXIgd2hhdCBmb3J1bSBUeEF1dGggdGFr ZXMsIGl0cyB3b3JrIHdpbGwgcmVxdWlyZSBhIG5ldyBjaGFydGVyLiBXaXRoIHRoYXQgaW4gbWlu ZCwgSeKAmXZlIHRha2VuIGEgYml0IG9mIHRpbWUgdG8gcHV0IHRvZ2V0aGVyIGEgcHJvcG9zZWQg Y2hhcnRlciB0ZXh0IGZvciB0aGUgVHhBdXRoIHdvcms6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzAuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBncm91cCBpcyBj aGFydGVyZWQgdG8gZGV2ZWxvcCBhIG5leHQtZ2VuZXJhdGlvbiB0cmFuc2FjdGlvbmFsIGF1dGhv cml6YXRpb24gYW5kIGRlbGVnYXRpb24gcHJvdG9jb2wgZm9yIEhUVFAtYmFzZWQgQVBJcyBhbmQg dGhlaXIgY2xpZW50cy4gVGhlc2UgdHJhbnNhY3Rpb25zIHdpbGwgYWxsb3cgYW4gYXV0aG9yaXpp bmcgcGFydHkgdG8gZGVsZWdhdGUgYSByaWdodCBvZiBhY2Nlc3MgZm9yIGFuIEFQSQ0KIG9yIHNl dCBvZiBBUElzIHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gYSBzb2Z0d2FyZSBj bGllbnQgYWN0aW5nIG9uIGJlaGFsZiBvZiBhbiBhdXRob3JpemluZyBwYXJ0eS4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGdyb3VwIHdpbGwgZGVsaXZlciBhIHByb3RvY29s IHNwZWNpZmljYXRpb24gZGV0YWlsaW5nIGhvdyBhIGNsaWVudCBjYW4gcmVxdWVzdCBhbmQgb2J0 YWluIGRlbGVnYXRlZCBhY2Nlc3MsIGhvdyBhbiBhdXRob3JpemF0aW9uIHNlcnZlciBjYW4gcHJv dmlkZSBkZWxlZ2F0ZWQgYWNjZXNzLCBob3cgYW4gYXV0aG9yaXplZCBwYXJ0eSBjYW4gYXV0aG9y aXplIGRlbGVnYXRlZCBhY2Nlc3MsIGFuZCBob3cgdGhhdA0KIGF1dGhvcml6ZWQgYWNjZXNzIGNh biBiZSBjb21tdW5pY2F0ZWQgdG8gdGhlIHJlc291cmNlcyBiZWluZyBwcm90ZWN0ZWQuIFRoZXNl IGFjdGlvbnMgd2lsbCBiZSBjb25uZWN0ZWQgdGhyb3VnaCBhbiBleHBsaWNpdCB0cmFuc2FjdGlv biBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIGF1dGhvcml6YXRpb24gc2VydmVyLCByZXN1bHRpbmcg aW4gYW4gYXJ0aWZhY3QgdGhhdCB3aWxsIGFsbG93IHRoZSBjbGllbnQgdG8gdW5kZXJ0YWtlIHRo ZSBkZWxlZ2F0ZWQNCiBhY3Rpb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFk ZGl0aW9uYWxseSwgdGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGFsbG93IGZvcjo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPi0gRmluZS1ncmFpbmVkIHNwZWNpZmljYXRpb24gb2YgcmVzb3VyY2UgYWNjZXNzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tIERlbGVnYXRpb24gYmV0d2VlbiBtdWx0aXBsZSB1c2VyczxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBXZWIs IG1vYmlsZSwgc2luZ2xlLXBhZ2UsIGFuZCBvdGhlciBjbGllbnQgYXBwbGljYXRpb25zPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBncm91cCB3aWxsIGRlZmluZSBleHRlbnNpb24gcG9p bnRzIGZvciB0aGlzIHByb3RvY29sIHRvIGFsbG93IGZvciBmbGV4aWJpbGl0eSBpbiBhcmVhcyBp bmNsdWRpbmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gQ3J5cHRvZ3JhcGhpYyBhZ2ls aXR5IGZvciBrZXlzLCBtZXNzYWdlIHNpZ25hdHVyZXMsIGFuZCBwcm9vZiBvZiBwb3NzZXNzaW9u Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tIFVzZXIgaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcg d2ViIGFuZCBub24td2ViIG1ldGhvZHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gVG9rZW4gcHJlc2VudGF0aW9uIG1l Y2hhbmlzbXMgYW5kIGtleSBiaW5kaW5nczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg YXJ0aWZhY3RzIGZvciB0aGlzIHdvcmsgYXJlIG5vdCBpbnRlbmRlZCBvciBleHBlY3RlZCB0byBi ZSBiYWNrd2FyZHMtY29tcGF0aWJsZSB3aXRoIE9BdXRoIDIuMCBhbmQgaXRzIGV4dGVuc2lvbnMu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIHRo aXMgd29yayBjb3VsZCBiZSBkb25lIGluIHdpdGhpbiB0aGUgT0F1dGggd29ya2luZyBncm91cCwg SSBub3cgYmVsaWV2ZSB0aGF0IGl0IHNob3VsZCBiZSBkb25lIGluIGEgbmV3IHdvcmtpbmcgZ3Jv dXAsIGFuZCB0aGF0IHdlIHNob3VsZCB0cnkgdG8gZ2V0IHRoYXQgd29ya2luZyBncm91cCB1cCBh bmQgcnVubmluZyBwcmlvciB0byB0aGUgVmFuY291dmVyIG1lZXRpbmcgaW4gTWFyY2guLiBJIHRo aW5rDQogdGhpcyBncm91cCBzaG91bGQgc3RheSBoZXJlIG9uIHRoZSBUeEF1dGggbGlzdCwgYW5k IGl04oCZcyBteSBzdWdnZXN0aW9uIHRoYXQgdGhlIHJlc3VsdGluZyB3b3JrIGJlIGNhbGxlZCBP QXV0aCAzLjAuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoeSBhIG5ldyBncm91 cD8gSSB0aGluayB0aGF0IHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIHNob3VsZCByZW1haW4gZm9j dXNlZCBvbiBleHRlbmRpbmcsIHBhdGNoaW5nLCBhbmQgYWRhcHRpbmcgT0F1dGggMi4wIHRvIGEg Y2hhbmdpbmcgd29ybGQuIEkgcGxhbiB0byBiZSBlbmdhZ2VkIGluIGJvdGggZ3JvdXBzLCBhbmQg SSBrbm93IG1vc3Qgb2YgeW91IGFyZSBhcyB3ZWxsLCBidXQgdGhhdOKAmXMgbm90IHVuaXZlcnNh bC4NCiBTaW5jZSBPQXV0aCAyLjAgaXMgc28gZXN0YWJsaXNoZWQgYWxyZWFkeSwgdGhlcmUgYXJl IGEgTE9UIG9mIHBlb3BsZSB3aG8gYXJlbuKAmXQgZ29pbmcgdG8gYmUgaW50ZXJlc3RlZCBpbiBz b21ldGhpbmcgbmV3IGFueSB0aW1lIHNvb24uIEJ1dCBvbiB0aGUgb3RoZXIgaGFuZCwgdGhlcmUg YXJlIGEgbnVtYmVyIG9mIHBlb3BsZSBmb3Igd2hvbSBPQXV0aCAyLjAgZG9lcyBub3Qgd29yaywg b3IgaXMgYXQgdGhlIHZlcnkgbGVhc3QgYSBwb29yIGZpdCwNCiBhbmQgd2XigJlsbCB3YW50IHRv IGJyaW5nIHRoZW0gaW4gYXQgdGhpcyBlYXJseSBzdGFnZS4gU28gZXZlbiB3aXRoIHNpZ25pZmlj YW50IG92ZXJsYXAsIEkgdGhpbmsgdGhlcmXigJlzIGVub3VnaCBkaXNjb25uZWN0IGluIHRoZSBj b21tdW5pdHkgZnJvbSBib3RoIHNpZGVzIHRoYXQgd2FycmFudHMgYSBuZXcgZ3JvdXAuIEluIGFk ZGl0aW9uLCBJIHRoaW5rIHRoaXMgaXMgYSBiaWcgZW5vdWdoIHBpZWNlIG9mIHdvcmsgdGhhdCBp dOKAmXMgc2ltcGx5IHRvbw0KIG11Y2ggZm9yIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIHRvIGJl IGFibGUgdG8gZm9jdXMgb24uIFdlIHdvdWxkbuKAmXQgYmUgYWJsZSB0byBnZXQgYWRkaXRpb25h bCBtZWV0aW5nIHRpbWUsIGFuZCBPQXV0aCBhbHJlYWR5IGhhcyB0cm91YmxlIGZpdHRpbmcgaW50 byBpdHMgdHdvIG1lZXRpbmcgc2xvdHMgYXMgaXQgaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPknigJl2ZSBwdWJsaXNoZWQgYSBibG9nIHBvc3QgZGV0YWlsaW5nIG1vcmUgb2YgbXkgcmF0 aW9uYWxlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL21lZGl1 bS5jb20vQGp1c3RpbnNlY3VyaXR5L3RoZS1jYXNlLWZvci1vYXV0aC0zLTAtd2h5LWEtbmV3LXdv cmtpbmctZ3JvdXAtZDYyMjliYThlMzY/IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aHR0cHM6Ly9tZWRpdW0uY29tL0BqdXN0aW5zZWN1cml0eS90aGUtY2FzZS1m b3Itb2F1dGgtMy0wLXdoeS1hLW5ldy13b3JraW5nLWdyb3VwLWQ2MjI5YmE4ZTM2Pzwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBzdWdnZXN0IGNoYW5nZXMgdG8g dGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dCBhYm92ZS4gSXTigJlzIG15IGhvcGUgdGhhdCB3ZSBj YW4gZ2V0IHRoZSBjaGFydGVyaW5nIHByb2Nlc3Mgc3RhcnRlZC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpUeGF1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOlR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPlR4YXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3R4YXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LS08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0K VHhhdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5UeGF1dGhAaWV0Zi5v cmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdHhhdXRoIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_FD7172F9ADFF49E1ABCADBCFB8FC8639amazoncom_-- From nobody Thu Jan 2 17:37: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 0702112006B for ; Thu, 2 Jan 2020 17:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 IZtG23rfhO5k for ; Thu, 2 Jan 2020 17:37:31 -0800 (PST) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.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 DF5A6120058 for ; Thu, 2 Jan 2020 17:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578015452; x=1609551452; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zlFejCaSqJCxlh8MIgD2o+SbZB7TO2Bg44QmfONlTh4=; b=UQG4fp2jxSFqPpT7CXqTI71cNyMOSuVwGmc1ixLcdOJcQ0YpRdaxZQml MR0DIMuLvwzUN00g/0HN7s/WJ5H4ZjtHrSpjqDpzkB+hJRsKCWXuxTY+n 0+aq/srtSaHz2nLZJRJHTb8vVRZ89inaT5tgwpP/Xnac9SX6O/SuKq8da E=; IronPort-SDR: COPgZ6hUUnASeS6cFGvLxUFbtvHkOYxPE7FDoq5gHIhvPJwso6k48MLZYadqiH4YTnTGF6kYl6 0v/yVQ1CBuXA== X-IronPort-AV: E=Sophos; i="5.69,388,1571702400"; d="scan'208,217"; a="10759302" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1e-27fb8269.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 03 Jan 2020 01:37:30 +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-27fb8269.us-east-1.amazon.com (Postfix) with ESMTPS id AA974A218E; Fri, 3 Jan 2020 01:37:27 +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; Fri, 3 Jan 2020 01:37:26 +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.1367.3; Fri, 3 Jan 2020 01:37:26 +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.1367.000; Fri, 3 Jan 2020 01:37:26 +0000 From: "Richard Backman, Annabelle" To: Justin Richer , Dick Hardt CC: "rdd@cert.org" , Eve Maler , "txauth@ietf.org" , Benjamin Kaduk Thread-Topic: [Txauth] TxAuth Proposed Charter Thread-Index: AQHVt4W+Cd5+sniY+0u9RUqE6+8fD6fDqwuAgAAMvQCAANLLAIAJyHMAgAGDMgCAA46FAIABRZkAgAAb1YCAAbiUAIABOM0A Date: Fri, 3 Jan 2020 01:37:26 +0000 Message-ID: <3CE4CF77-4E71-423E-9E5B-AAEAEC17B92B@amazon.com> References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <07AEE8DB-A0EE-4780-9CE7-B578F69948F9@mit.edu> <68CA5C79-10AB-42E6-B4A9-06A594CA436C@mit.edu> <3066B58F-47D5-48C6-B705-A9F3F58EB496@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.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.118] Content-Type: multipart/alternative; boundary="_000_3CE4CF774E71423E9E5BAAEAEC17B92Bamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] TxAuth Proposed 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, 03 Jan 2020 01:37:35 -0000 --_000_3CE4CF774E71423E9E5BAAEAEC17B92Bamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJ4oCZbSBjdXJyZW50bHkgdGhpbmtpbmcgc29tZXRoaW5nIGxpa2UgdGhpcyBmb3IgdGhlIGNo YXJ0ZXIgdGV4dCB0byBzZXQgdGhlIHJpZ2h0IHNjb3BlOg0KPg0KPiByZXN1bHRpbmcgaW4gaW5m b3JtYXRpb24gYWJvdXQgdGhlIHJlcXVlc3QgKHN1Y2ggYXMgYSB1c2Vy4oCZcyBpZGVudGl0eSBv ciBjdXJyZW50IHN0YXR1cykgYW5kL29yIGFuIGFydGlmYWN0IHRoYXQgd2lsbCBhbGxvdyB0aGUg Y2xpZW50IHRvIHVuZGVydGFrZSB0aGUgZGVsZWdhdGVkIGFjdGlvbi4NCj4NCj4gSW4gb3RoZXIg d29yZHMsIG91ciBmb2N1cyBpcyBvbiB0aGUgZGVsZWdhdGlvbiBwcm90b2NvbCwgbm90IHdoYXQg aXTigJlzIGRlbGVnYXRpbmcgdG8uIEJ1dCB0aGUgYWJpbGl0eSB0byBpbmNsdWRlIGluZm9ybWF0 aW9uIGluIHRoYXQgcHJvdG9jb2wgZGlyZWN0bHkgaXMgYSBwb3RlbnRpYWxseSBwb3dlcmZ1bCBw YXR0ZXJuIGFuZCB3ZSBzaG91bGQgcHJvYmFibHkgaW5jbHVkZSBzb21lIG9mIHRoYXQgaW4gb3Vy IHNjb3BlLiBJIHRoaW5rIHRoZSBpZGVudGl0eSBwb3J0aW9uIGNhbiBiZSBmYWlybHkgbWluaW1h bCwgYXQgbGVhc3QgYXMgYSBzdGFydGluZyBwb2ludC4NCg0KVGhpcyB0cmVhdHMgaWRlbnRpdHkg YXMgYSBzcGVjaWFsIGNhc2UgcmVzb3VyY2Ugd2hlcmUgdGhlIHRyYW5zYWN0aW9uIGVuZHBvaW50 IGRvdWJsZXMgYXMgdGhlIHJlc291cmNlIHNlcnZlci4gT0lEQyBkb2VzIHRoZSBzYW1lIHRoaW5n LCBzbyBpdOKAmXMgbm90IHVucHJlY2VkZW50ZWQuIEFyZSB5b3UgcHJvcG9zaW5nIHRoYXQgd2Ug c3VwcG9ydCB0aGlzIG1vZGVsIG9ubHkgZm9yIGlkZW50aXR5LCBvciBmb3IgYXJiaXRyYXJ5IHJl c291cmNlcyBhcyB3ZWxsPyBJZiBpdOKAmXMganVzdCBzdXBwb3J0ZWQgZm9yIGlkZW50aXR5LCB3 ZSBuZWVkIHRvIG1ha2UgdGhlIGNhc2UgZm9yIHdoeSBpZGVudGl0eSBkZXNlcnZlcyBzcGVjaWFs IHRyZWF0bWVudC4gSS5lLiwgd2hhdCBtYWtlcyBpZGVudGl0eSBzcGVjaWFsIGVub3VnaCB0byB3 YXJyYW50IGJlaW5nIGFibGUgdG8gcmV0cmlldmUgaXQgZGlyZWN0bHkgZnJvbSB0aGUgdHJhbnNh Y3Rpb24gZW5kcG9pbnQsIGFuZCB3aGF0IG1ha2VzIHVzIGNlcnRhaW4gdGhhdCBubyBvdGhlciBy ZXNvdXJjZXMgbWVldCB0aG9zZSByZXF1aXJlbWVudHM/DQoNCuKAkw0KQW5uYWJlbGxlIFJpY2hh cmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4N CkRhdGU6IFdlZG5lc2RheSwgSmFudWFyeSAxLCAyMDIwIGF0IDI6NTggUE0NClRvOiBEaWNrIEhh cmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT4NCkNjOiAicmRkQGNlcnQub3JnIiA8cmRkQGNlcnQu b3JnPiwgRXZlIE1hbGVyIDxldmVAeG1sZ3JybC5jb20+LCAidHhhdXRoQGlldGYub3JnIiA8dHhh dXRoQGlldGYub3JnPiwgQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+DQpTdWJqZWN0OiBS ZTogW1R4YXV0aF0gVHhBdXRoIFByb3Bvc2VkIENoYXJ0ZXINCg0KDQoNCg0KT24gRGVjIDMxLCAy MDE5LCBhdCAzOjQwIFBNLCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86 ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCg0KT24gVHVlLCBEZWMgMzEsIDIwMTkgYXQg MTE6MDEgQU0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1p dC5lZHU+PiB3cm90ZToNCg0KDQoNCg0KDQoyLiBXaHkgZG8geW91IHJlc3RyaWN0IHRoaXMgdG8g SFRUUD8NCg0KQmVjYXVzZSBJIHdhbnQgdXMgdG8gdXNlIGFsbCBvZiB0aGUgZmVhdHVyZXMgYW5k IGJlbmVmaXRzIG9mIEhUVFAgaW5zdGVhZCBvZiBoYXZpbmcgdG8gaW52ZW50IHdpdGhpbi1wcm90 b2NvbCBmdW5jdGlvbnMgdG8gcmVwbGljYXRlIHRoZW0uIEkgZG9u4oCZdCB3YW50IFNPQVAsIHdo aWNoIHByZXRlbmRzIHRvIGJlIHRyYW5zcG9ydCBhZ25vc3RpYyBtdWNoIHRvIGl0cyBkZXRyaW1l bnQuIElmIHNvbWVvbmUgd2FudHMgdG8gZG8gT0F1dGggMyBvbiBub3QtSFRUUCwgdGhleSBjYW4g ZGVmaW5lIHdoYXQgdGhhdCBsb29rcyBsaWtlLiBUaGlzIGlzIHdoYXQgaGFwcGVuZWQgd2l0aCB0 aGUgQ09BUC9DT1JFIHN0dWZmIGFuZCBPQXV0aCAyLg0KDQpJIGFncmVlIFNPQVAgd2FzIGNvbXBs aWNhdGVkLiBXaGljaCBmZWF0dXJlcyBhbmQgYmVuZWZpdHMgb2YgSFRUUCBhcmUgeW91IHdhbnRp bmcgdG8gdXNlPw0KDQoNCldlbGwgc28gZmFyIHdl4oCZdmUgZ290IGhlYWRlcnMsIFVSTHMsIG1l dGhvZHMsIGRhdGEgcGF5bG9hZCB0eXBlcywgYW5kIHRoZSB3aG9sZSBhcnJheSBvZiB0ZWNobm9s b2dpZXMgdGhhdCB3ZSBjYW4gcmVseSBvbiB3b3JraW5nIHRvZ2V0aGVyIGFsb25nIHdpdGggSFRU UC4NCg0KQnV0IHdoaWNoIG9uZXMgZG8geW91IHdhbnQgdG8gdXNlPw0KDQoNClRob3NlIHRoaW5n cyB0aGF0IEkgYWxyZWFkeSBsaXN0ZWQgYXJlIHdoYXQgSSB3YW50IHRvIHVzZS4gSSB3YW50IHRv IHVzZSB0aGUgaGVhZGVycyBmb3Igc2VuZGluZyBrZXkgcHJvb2ZzIGFuZCBwcm9iYWJseSBjb250 ZW50IG5lZ290aWF0aW9uLiBJIHdhbnQgdG8gaGF2ZSBjb250ZW50IG5lZ290aWF0aW9uIHNvIHRo YXQgd2UgY2FuIGhhdmUgYW4gb3B0aW9uIHRvIHVzZSBKT1NFIChvciBDT1NFKSBhcyB0aGUgYm9k eSBmb3JtYXQgaW5zdGVhZCBvZiBKU09OLCBidXQgdGhhdCBmdW5jdGlvbiBzd2l0Y2ggc2hvdWxk IGNvbWUgZnJvbSB0aGUgdHJhbnNwb3J0IHByb3RvY29sIChIVFRQKSBhbmQgbm90IHNvbWV0aGlu ZyBpbnRlcm5hbCB0byBvdXIgcHJvdG9jb2wuIEkgd2FudCB0byBiZSBhYmxlIHRvIHVzZSByZWRp cmVjdHMgdG8gZ2V0IHRoZSB1c2VyIHRvIGludGVyYWN0LCBhbmQgZ2V0IGJhY2sgZnJvbSB0aGUg aW50ZXJhY3Rpb24uIEkgd2FudCB0byAoZXZlbnR1YWxseSkgZG8gdGhpbmdzIGxpa2UgdG9rZW4g cmV2b2NhdGlvbiB1c2luZyBhIERFTEVURSB2ZXJiIGluc3RlYWQgb2YgYSBzZXBhcmF0ZSBlbmRw b2ludC4gSSB3YW50IHRvIHVzZSBIVFRQIE1lc3NhZ2UgU2lnbmF0dXJlcyAob25jZSB0aGV5IGV4 aXN0KSBhcyBhIGtleSBwcmVzZW50YXRpb24gbWVjaGFuaXNtLiBBbmQgSSB3YW50IG91ciBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyB0byBiZSBhYmxlIHRvIHRha2UgaW50byBhY2NvdW50IHRoZSBw YXJ0aWN1bGFycyBvZiBIVFRQLCBUTFMsIGFuZCB0aGUgbGlrZSB3aGVuIHdlIHdyaXRlIHRoZW0u DQoNClRoYW5rcyBmb3IgY2xhcmlmeWluZy4gSSBhZ3JlZSB0aGF0IHVzaW5nIHRoZSBodHRwIGNv bnRlbnQtdHlwZSBoZWFkZXIsIGFuZCBodHRwIHZlcmJzIGlzIHByZWZlcmFibGUgdG8gaW52ZW50 aW5nIG5ldyBtZWNoYW5pc21zLg0KDQpUaGFua3MsIGFuZCB0aG9zZSBhcmUganVzdCBzb21lIGV4 YW1wbGVzLiBJIHdhbnQgdXMgdG8gaGF2ZSBhbGwgb2YgSFRUUOKAmXMgZmVhdHVyZXMgYXMgb3B0 aW9ucyB0aGF0IHdlIGNhbiB1c2Ugd2l0aG91dCByZWludmVudGluZyB0aGVtLCBldmVuIHRoaW5n cyBJIGNhbuKAmXQgdGhpbmsgb2YgcmlnaHQgbm93Lg0KDQoNCg0KDQoNCg0KDQoNCklmIGl0IHdh cyBzaW1wbGUgdG8gc3VwcG9ydCBDT0FQLCB3aHkgd291bGQgd2Ugbm90IGRvIHRoYXQ/DQoNCkJl Y2F1c2UgaXTigJlzIG5vdCBqdXN0IENPQVAg4oCUIHlvdeKAmXZlIGdvdCBhIGRpZmZlcmVudCBz ZXQgb2YgYXNzdW1wdGlvbnMgZm9yIHRoZSBsb3dlciBsYXllciBwcm90b2NvbHMsIGFuZCB5b3Xi gJl2ZSBnb3QgbG90cyBvZiBjb25zaWRlcmF0aW9ucyBhYm91dCBob3cgdGhlIGRpZmZlcmVudCBj b21wb25lbnRzIGNhbiB0YWxrIHRvIGVhY2ggb3RoZXIgaW4gdGhlIGVtYmVkZGVkIHNwYWNlLg0K DQpZb3UgYXJlIHN1Z2dlc3Rpbmcgd2UgcnVsZSBvdXQgaXQgd29ya2luZyB3aXRoIENPQVAgaW4g dGhlIGNoYXJ0ZXIsIGJlZm9yZSB3ZSBoYXZlIGV2ZW4gaGFkIGEgY2hhbmNlIHRvIHdvcmsgb24g aXQuDQoNClBlcmhhcHMgaXQgd2lsbCBiZSB0cml2aWFsIHRvIHN1cHBvcnQgQ09BUC4gV2Ugd29u J3Qga25vdyBpZiB0aGUgY2hhcnRlciBmb3JiaWRzIGl0Lg0KDQpJZiBpdCB0dXJucyBvdXQgdG8g YmUgdHJpdmlhbCBhbmQgcGVvcGxlIHdhbnQgdG8gaW5jbHVkZSBpdCBhbmQgZG8gdGhlIHdvcmsg aGVyZSwgdGhlbiB3ZSBjb3VsZCBhbHdheXMgdXBkYXRlIHRoZSBjaGFydGVyIHRvIGluY2x1ZGUg aXQuIEkgd291bGQgcmF0aGVyIHNlZSB0aGF0IHRoYW4gdXMgdHJ5aW5nIHRvIGVudW1lcmF0ZSBh bGwgb2YgdGhlIHRhcmdldCBjYXJyaWVyIG1lY2hhbmlzbXMuIEJlY2F1c2UgaWYgd2UgZG8gQ09B UCwgd2h5IG5vdCBNUVRUPyBPciBCbHVldG9vdGhMRT8NCg0KSWYgd2UgaW5jbHVkZSBDT0FQLCB0 aGVuIHRvIG15IG1pbmQgdGhhdCBuZWNlc3NpdGF0ZXMgb25lIG9mIHR3byB0aGluZ3MsIGlmIG5v dCBib3RoOg0KDQoxKSBXZSBoYXZlIGEgZG9jdW1lbnQgdGhhdCBzYXlzIOKAnElGIHlvdeKAmXJl IGRvaW5nIEhUVFAgZG8gKEEpIGlmIHlvdeKAmXJlIGRvaW5nIENPQVAgZG8gKEIp4oCdDQoyKSBX ZSBoYXZlIGFuIOKAnGFic3RyYWN04oCdIGRvY3VtZW50IHRoYXQgc2F5cyDigJxoZXJl4oCZcyB0 aGlzIHRoaW5nIGJ1dCBmb3IgZGV0YWlscyBvbiBob3cgdG8gZG8gaXQgZ28gcmVhZCB0aGUgSFRU UCBkb2N1bWVudCBhbmQvb3IgdGhlIENPQVAgZG9jdW1lbnTigJ0sIGJ1dCB3aGVuIHlvdSByZWFk IHRoZSBIVFRQIG9yIENPQVAgZG9jdW1lbnRzLCB0aGV5IGRvbuKAmXQgaGF2ZSBhbnkgaW5mb3Jt YXRpb24gYWJvdXQgd2hhdCB0aGUgdGhpbmcgaXMgYmVjYXVzZSBpdOKAmXMgaW4gdGhlIGFic3Ry YWN0Lg0KDQpGcm9tIGEgZGV2ZWxvcGVy4oCZcyBwZXJzcGVjdGl2ZSwgSSB3b3VsZCByYXRoZXIg aGF2ZSBhbiBIVFRQIGRvY3VtZW50IGJlIHNlbGYtY29udGFpbmVkLCBhbmQgYSBDT0FQIGRvY3Vt ZW50IGJlIHNlbGYtY29udGFpbmVkLiBBbmQgaWYgdGhlIHR3byBkZXNjcmliZSB0aGUgc2FtZSBw cm9jZXNzLCBvciBvbmUgaW5oZXJpdHMgZnJvbSB0aGUgb3RoZXIgYnV0IHNheXMg4oCcaW5zdGVh ZCBvZiBkb2luZyBIVFRQIHRoaW5nIFggZG8gQ09BUCBlcXVpdmFsZW50IFnigJ0sIHRoZW4gdGhh dOKAmXMgZ29vZC4NCg0KSSBhZ3JlZSBjb21wbGV0ZWx5Lg0KDQoNCkJ1dCBvdmVybHkgYWJzdHJh Y3RpbmcgYSBzeXN0ZW0gaXMgYm90aCB0ZW1wdGluZyBhbmQgcG90ZW50aWFsbHkgZGlzYXN0cm91 cy4NCg0KSSBhZ3JlZS4NCg0KSSBhbGlnbiB3aXRoIHRoZSBkZXNpZ24gdGVuZXQ6DQoNCiJFYXN5 IHRoaW5ncyBzaG91bGQgYmUgZWFzeSwgaGFyZCB0aGluZ3Mgc2hvdWxkIGJlIHBvc3NpYmxlIiAt LSBMYXJyeSBXYWxsDQoNCklmIHRoZSBXRyBoYXMgYSBjaG9pY2UgYmV0d2VlbiBBIGFuZCBCLCBh bmQgdGhleSBhbGwgb3RoZXIgdGhpbmdzIGFyZSBlcXVhbCBmb3IgYW4gSFRUUCBpbXBsZW1lbnRh dGlvbiwgYnV0IEIgaXMgbXVjaCBiZXR0ZXIgZm9yIENPQVAsIHRoZW4gSSB3b3VsZCBzdWdnZXN0 IHdlIGNob29zZSBCLg0KDQpJJ20gbm90IHNheWluZyBDT0FQIHN1cHBvcnQgc2hvdWxkIGJlIGEg cHJpb3JpdHksIEknbSBzYXlpbmcgd2Ugc2hvdWxkIG5vdCBjb21wbGV0ZWx5IGlnbm9yZSBpdC4N Cg0KSSBhbSBpbiBmdWxsIGFncmVlbWVudCB3aXRoIHRoZXNlIHByaW5jaXBsZXMsIHNpbmNlIGl0 IHdvdWxkIG1ha2UgYWxpZ25tZW50IGZvciBhbnkgcHJlc2VudCBvciBmdXR1cmUgQ09BUCB2ZXJz aW9uIG9mIHRoaXMgcHJvdG9jb2wgdG8gYmUgYnVpbHQuIEkgdGhpbmsgd2UgY2FuIG1hbmFnZSB0 aGF0IHdoaWxlIHN0aWxsIGZvY3VzaW5nIG9uIGFuIEhUVFAtYm91bmQgcHJvY2Vzcywgd2l0aG91 dCBnZXR0aW5nIGludG8gdGhlIG92ZXItYWJzdHJhY3Rpb24gcHJvYmxlbS4NCg0KDQoNCg0KDQoN Cg0KSW4gbXkgZXhwZXJpZW5jZSwgaXTigJlzIG11Y2ggbW9yZSBzdWNjZXNzZnVsIHRvIGhhdmUg YSBwcm90b2NvbCBzdHJvbmdseSBpbnRlZ3JhdGVkIHdpdGggaXRzIHRyYW5zcG9ydCBtZWNoYW5p c20gYW5kIHRoZW4gdHJhbnNsYXRlZCBvdXQgdG8gb3RoZXIgbWVjaGFuaXNtcywgaW5zdGVhZCBv ZiB0cnlpbmcgdG8gY29tZSB1cCB3aXRoIG9uZSB1bml2ZXJzYWwgaW50ZXJsaW5ndWEgb2YgYSBw cm90b2NvbCB0aGF0IGp1c3QgZ2V0IHNodW50ZWQgYWxvbmcuDQoNCldvdWxkIHlvdSBwcm92aWRl IGFuIGV4YW1wbGUgYmVzaWRlcyBTT0FQIGZvciB0aGlzPw0KDQpJdOKAmXMgdGhlIG1vc3QgZWdy ZWdpb3VzIGV4YW1wbGUgdGhhdCBjb21lcyB0byBtaW5kIGZvciBtZSwgc28gdGhhdOKAmXMgd2h5 IEkga2VlcCBjb21pbmcgYmFjayB0byBpdC4gSSBhbHNvIGhhdmUgaW4gbWluZCBhIGRvemVuIHBy b2plY3RzIHRoYXQgbmV2ZXIgd2VudCBhbnl3aGVyZSwgYW5kIG5vYm9keeKAmXMgaGVhcmQgb2Ys IGJlY2F1c2Ugb2YgYW4gb3V0bW9kZWQgZWZmb3J0IGJlaW5nIHB1dCBpbnRvIGRlZmluaW5nIGFi c3RyYWN0aW9ucyBhaGVhZCBvZiB0aW1lIGluIG9yZGVyIHRvIGFsbG93IHRyYW5zcG9ydC1hZ25v c3RpYyBtZXNzYWdpbmcuDQoNCkEgc2ltaWxhciBsZXZlbCBvZiBvdmVybHktZWFnZXIgYWJzdHJh Y3Rpb24gd2VudCBpbnRvIEpPU0UsIHdpdGggdGhlIEpXQSBkb2N1bWVudC4gSXQgbWFrZXMgaXQg c28gdGhhdCBKV1MsIEpXRSwgYW5kIEpXSyBtYWtlIG5vIHNlbnNlIHdpdGhvdXQgSldBLCBhbmQg SldBIGlzIGp1c3QgYSBjb2xsZWN0aW9uIG9mIGNvbnRlbnQgdGhhdCByZWFsbHkgc2hvdWxkIGhh dmUgYmVlbiBpbmNsdWRlZCBpbmxpbmUgd2l0aCB0aGUgb3RoZXIgZG9jdW1lbnRzLg0KDQpJIHdh bnQgdG8gYXZvaWQgdGhhdCBraW5kIG9mIHRoaW5nLg0KDQpBZ3JlZWQNCg0KDQoNCg0KVGhpcyBp cyB3aHkgU09BUCBjYW7igJl0IHVzZSBIVFRQIHZlcmJzIHRvIGNvbW11bmljYXRlIHRoaW5ncywg YW5kIHdoeSB0aGUgb25seSBzaWduYXR1cmVzIGl0IGNhbiB1c2UgYXJlIGludGVybmFsLiBXaGVu IHlvdSBkbyB0aGF0IGtpbmQgb2Ygc3lzdGVtLCB5b3UgYWxtb3N0IGFsd2F5cyBlbmQgdXAgaGF2 aW5nIHBlb3BsZSBqdXN0IHVzZSBpdCB3aXRoIG9uZSB0cmFuc3BvcnQgYW55d2F5LCBsaWtlIFNP QVAgb3ZlciBIVFRQLg0KDQoNCg0KDQoNCg0KMy4gV2h5IGlzIGF1dGhlbnRpY2F0aW9uIG5vdCBp biBzY29wZT8NCg0KSXQgZmVsdCwgdG8gbWUsIGxpa2UgdGhhdCBtaWdodCBiZSBhIGJyaWRnZSB0 b28gZmFyLg0KDQpJIGRpc2FncmVlLiBCdXQgSSBhbHNvIHRoaW5rIHRoYXQgYXV0aGVudGljYXRp b24gaXMgdGhlIHdyb25nIHRlcm0uIElkZW50aXR5KiBtYXkgYmUgYSB0ZXJtIHRoYXQgbWFwcyBi ZXR0ZXIsIGFzIHRoZSBDbGllbnQgaXMgd2FudGluZyB0byBnZXQgImlkZW50aXR5IiBkYXRhIGZy b20gdGhlIEFTLg0KDQoqIFRoZSBpZGVudGl0eSB0ZXJtIGlzIHN1cGVyIGNvbmZ1c2luZywgYnV0 IGF1dGhlbnRpY2F0aW9uIGltcGxpZXMganVzdCBrbm93aW5nIGl0IGlzIHRoZSBzYW1lIHVzZXIs IHdoZXJlIE9wZW5JRCBDb25uZWN0IGFsc28gcHJvdmlkZXMgY2xhaW1zIGFib3V0IHRoZSB1c2Vy Lg0KDQpJ4oCZbSBjb21pbmcgYXJvdW5kIHRvIHRoaXMgdmlldywgYnV0IEkgd291bGQgc3RpbGwg bGlrZSBpdCB0byBiZSBzZXBhcmF0ZS4NCg0KV2hhdCBkb2VzIHNlcGFyYXRlIG1lYW4/DQoNCkl0 IG1lYW5zIHRoYXQgdGhlIGJpdHMgdGhhdCBzYXkg4oCcdGhpcyBpcyBob3cgeW91IHRhbGsgYWJv dXQgaWRlbnRpdHkgaW5mb3JtYXRpb24gaW4gdGhlIHJlc3BvbnNl4oCdIGFyZSBjb250cm9sbGVk IGJ5IGEgc2VwYXJhdGUgc3BlYyB0aGF0IG5vdCBldmVyeW9uZSBuZWVkcyB0byB1bmRlcnN0YW5k LiBJIHRoaW5rIHRoZXJlIGFyZSB0b28gbWFueSB1c2UgY2FzZXMgb2Ygd2FudGluZyB0byBnZXQg QVBJIGFjY2VzcyBhbmQgTk9UIHVzZXIgaW5mb3JtYXRpb24gZm9yIGl0IHRvIGJlIGEgY29yZSBw aWVjZS4NCg0KU29tZSBkZXZlbG9wZXJzIG9ubHkgY2FyZSBhYm91dCBpZGVudGl0eS4gU29tZSBv bmx5IGNhcmUgYWJvdXQgQVBJIGFjY2Vzcy4gSXQgc2hvdWxkIGJlIGVhc3kgZm9yIGJvdGguDQoN ClBlcmhhcHMsIGJ1dCB0aGF0IGdldHMgdXMgaW50byBhbiBpbXBvcnRhbnQgcXVlc3Rpb24gb2Yg d2hhdCB0aGUgcmVzdWx0IG9mIHRoZSB0cmFuc2FjdGlvbiBzaG91bGQgYmUuIEluIG15IHZpZXcs IGl04oCZcyBkZWxlZ2F0aW9uIGZvciBhY2Nlc3MgdG8gc29tZXRoaW5nIOKAlCBzb21lIGJpdCBv ZiBpbmZvcm1hdGlvbi4gSW4gdGhlIE9JREMgbW9kZWwsIHRoYXQgaW5jbHVkZXMgaW5mb3JtYXRp b24gYWJvdXQgd2hvIHRoZSBjdXJyZW50IHVzZXIgaXMuIE9BdXRoIDIgYWx3YXlzIHJldHVybnMg YW4gYWNjZXNzIHRva2VuLCBubyBtYXR0ZXIgd2hhdCB5b3UgZG8uIElzIHRoaXMgc3RpbGwgdGhl IHJpZ2h0IG1vZGVsPyBSaWdodCBub3cgaW4gWFlaIHRoYXTigJlzIGhvdyBpdCB3b3JrcywgYnV0 IGluIHRoZSBwdXJlLWlkZW50aXR5IGNhc2UgYW5kIGluIEFubmFiZWxsZeKAmXMgZXh0ZW5kZWQg dXNlIGNhc2UsIHRoYXQgaXNu4oCZdCB0cnVlLg0KDQpUaGUgaGFyZCBxdWVzdGlvbiB0aGVyZSwg dG8gbWUsIGlzIGhvdyBkbyB3ZSBzd2l0Y2ggdGhhdCBraW5kIG9mIGJlaGF2aW9yLiBJ4oCZbSBu b3QgZm9uZCBvZiBzb21ldGhpbmcgbGlrZSDigJxyZXR1cm5fdHlwZT1pZGVudGl0eeKAnSBvciDi gJxyZXR1cm5fdHlwZT1hY2Nlc3NfdG9rZW7igJ0sIHNpbmNlIHRoZXNlIHRlbmQgdG8gYmUgYm90 aCBsaW1pdGluZyBhbmQgb3ZlcmJ1aWx0IGF0IHRoZSBzYW1lIHRpbWUuIEJ1dCBJ4oCZdmUgc3Ry dWdnbGVkIHdpdGggaG93IHRvIG1hbmFnZSB0aGlzLCBhbmQgaWYgd2XigJlyZSBnb2luZyB0byBp bmNsdWRlIGlkZW50aXR5IGFuZCBvdGhlciB1c2UgY2FzZXMgaW4gdGhlIGNoYXJ0ZXIgZXhwbGlj aXRseSwgdGhlbiBpdOKAmXMgc29tZXRoaW5nIHdl4oCZbGwgbmVlZCB0byBoYXZlIGEgZ29vZCBz b2x1dGlvbiBmb3IuDQoNCg0KDQoNCkhvd2V2ZXIsIHRoaXMgaXMgYXJndWFibHkgZ2V0dGluZyBp bnRvIHRoZSBkZXRhaWxzIG9mIGhvdyB0byBzbGljZSB1cCBkaWZmZXJlbnQgZG9jdW1lbnRzLCB3 aGljaCBpcyByZWFsbHkgYSBkZWNpc2lvbiB0byBiZSBtYWRlIG9uY2UgdGhlIFdHIGlzIHJ1bm5p bmcgYW5kIG5vdCBkdXJpbmcgdGhlIGNoYXJ0ZXIuDQoNCkN1cnJlbnRseSwgaWRlbnRpdHkgaXMg bm90IGluIHNjb3BlIG9mIHRoZSBjaGFydGVyLCB3aGljaCBpcyB3aHkgSSBhbSBicmluZ2luZyBp dCB1cC4NCg0KSeKAmW0gY3VycmVudGx5IHRoaW5raW5nIHNvbWV0aGluZyBsaWtlIHRoaXMgZm9y IHRoZSBjaGFydGVyIHRleHQgdG8gc2V0IHRoZSByaWdodCBzY29wZToNCg0KcmVzdWx0aW5nIGlu IGluZm9ybWF0aW9uIGFib3V0IHRoZSByZXF1ZXN0IChzdWNoIGFzIGEgdXNlcuKAmXMgaWRlbnRp dHkgb3IgY3VycmVudCBzdGF0dXMpIGFuZC9vciBhbiBhcnRpZmFjdCB0aGF0IHdpbGwgYWxsb3cg dGhlIGNsaWVudCB0byB1bmRlcnRha2UgdGhlIGRlbGVnYXRlZCBhY3Rpb24uDQoNCkluIG90aGVy IHdvcmRzLCBvdXIgZm9jdXMgaXMgb24gdGhlIGRlbGVnYXRpb24gcHJvdG9jb2wsIG5vdCB3aGF0 IGl04oCZcyBkZWxlZ2F0aW5nIHRvLiBCdXQgdGhlIGFiaWxpdHkgdG8gaW5jbHVkZSBpbmZvcm1h dGlvbiBpbiB0aGF0IHByb3RvY29sIGRpcmVjdGx5IGlzIGEgcG90ZW50aWFsbHkgcG93ZXJmdWwg cGF0dGVybiBhbmQgd2Ugc2hvdWxkIHByb2JhYmx5IGluY2x1ZGUgc29tZSBvZiB0aGF0IGluIG91 ciBzY29wZS4gSSB0aGluayB0aGUgaWRlbnRpdHkgcG9ydGlvbiBjYW4gYmUgZmFpcmx5IG1pbmlt YWwsIGF0IGxlYXN0IGFzIGEgc3RhcnRpbmcgcG9pbnQuDQoNCg0KDQoNCg0KDQoNCg0KDQpJZiB3 ZSBkbyBkZWNpZGUgaXTigJlzIGluIHNjb3BlLCB0aGVuIEkgdGhpbmsgaXQgc2hvdWxkIGJlIGNs ZWFybHkgbGF5ZXJlZCBvbiB0b3Agb2YgdGhlIGF1dGhvcml6YXRpb24gbGF5ZXIuDQoNCkJlaW5n IGxheWVyZWQgb24gdG9wIGlzIGNvbmZ1c2luZy4gQW4gT3BlbklEIENvbm5lY3QgZmxvdyB3aGVy ZSB0aGUgQ2xpZW50IHJlY2VpdmVzIGFuIElEIHRva2VuLCBoYXMgbm90IGF1dGhvcml6YXRpb24s IHVubGVzcyB5b3UgYXJlIGNvdW50aW5nIHRoZSBVWCBhcyBhdXRob3JpemF0aW9uIC0tIGJ1dCB0 aGF0IGRvZXMgbm90IHNlZW0gbGlrZSBhIGxheWVyLiBXb3VsZCB5b3UgZWxhYm9yYXRlPw0KDQoN CldoYXQgeW914oCZcmUgZG9pbmcgaW4gT0lEQyBpcyBhdXRob3JpemluZyB0aGUgYXBwbGljYXRp b24gdG8ga25vdyB3aG8geW91IGFyZSDigJQgdG8gZ2V0IHlvdXIgaWRlbnRpdHkgaW5mb3JtYXRp b24uIFRoYXQga2V5IGluc2lnaHQgaXMgd2hhdCBtYWtlcyB0aGUgY29tYmluYXRpb24gb2YgT0F1 dGggYW5kIE9JREMgd29yayBhcyB3ZWxsIGFzIGl0IGRvZXMuIEFuZCwgaW1wb3J0YW50bHksIG9u Y2UgeW91IGF1dGhvcml6ZSBpZGVudGl0eSBhY2Nlc3MsIHlvdSBjYW4gYXV0aG9yaXplIG90aGVy IHN0dWZmIGFzIHdlbGwuDQoNCg0KQXMgSSBzdGF0ZWQsIHRoZXJlIGlzIHRoZSBVWCBvZiBhdXRo b3JpemluZyBrbm93aW5nIHdobyB0aGUgdXNlciBpcywgYnV0IHRoZXJlIGlzIG5vIGFydGlmYWN0 IHJlcHJlc2VudGluZyB0aGF0IGF1dGhvcml6YXRpb24gYXMgdGhlcmUgaXMgaW4gT0F1dGggLS0g aWUgdGhlcmUgaXMgbm8gYWNjZXNzIHRva2VuIHRvIGFjY2VzcyBhIHJlc291cmNlLiAoeWVzLCBh biBhY2Nlc3MgdG9rZW4gbWF5IGJlIHVzZWQgdG8gcmVhZCB0aGUgdXNlciBpbmZvIGVuZHBvaW50 LCBidXQgdGhhdCBpcyBhbGwgaXQgY2FuIGRvLg0KDQpBbmQgaXTigJlzIHRoZSDigJxhbmQgb3Ro ZXIgc3R1ZmbigJ0gdGhhdCBwZW9wbGUgcmVhbGx5LCByZWFsbHksIHJlYWxseSBsaWtlIGFib3V0 IE9JREMuIE5vYm9keSBldmVyIHdhbnRzIGp1c3QgYXV0aG9yaXphdGlvbiwgaW4gcHJhY3RpY2Uu DQoNCkRpZCB5b3UgbWVhbiB0byBzYXkgImF1dGhlbnRpY2F0aW9uIj8NCg0KSWYgc28sIHRoZW4g SSB3b3VsZCBwb3NpdCB0aGF0IHRoZXJlIGFyZSBtb3JlIE9JREMgdXNlciBpbnRlcmFjdGlvbnMg dGhhbiBwbGFpbiBPQXV0aCAyLjAgdXNlciBpbnRlcmFjdGlvbnMsIGFuZCB0aGF0IGFsbW9zdCBh bGwgb2YgdGhvc2UgT0lEQyB1c2VyIGludGVyYWN0aW9ucyBhcmUganVzdCBsb2dnaW5nIGluIHdp dGggR29vZ2xlIG9yIEZhY2Vib29rIC0tIGFuZCB0aGF0IHRoZXJlIGlzIG5vICJhbmQgb3RoZXIg c3R1ZmYiLg0KDQoNClllcywgSSBtZWFudCBhdXRoZW50aWNhdGlvbiwgdGhhbmsgeW91Lg0KDQpJ 4oCZbSBub3Qgc3VyZSBpdOKAmXMgdHJ1ZSwgYnV0IEnigJlsbCBhZ3JlZSB0aGF0IGl04oCZcyBt b3JlIHB1YmxpYy1mYWNpbmcuIEJ1dCBldmVuIGlmIHdoYXQgeW91IHBvc2l0IGlzIGFjdHVhbGx5 IHRydWUgYnkgcmF3IG51bWJlcnMsIGl04oCZcyBub3QgdW5pdmVyc2FsLiBJbiBwYXJ0aWN1bGFy LCB0aGVyZSBhcmUgYSBsYXJnZSBudW1iZXIgb2Ygc3lzdGVtLXRvLXN5c3RlbSBjYXNlcyB0aGF0 IE9BdXRoIDIgY292ZXJzLCB3aGljaCBoYXZlIG5vdGhpbmcgdG8gZG8gd2l0aCBpZGVudGl0eSwg dGhhdCB3ZSBkb27igJl0IHdhbnQgdG8gdGhyb3cgb3V0Lg0KDQpJJ20gbm90IHN1Z2dlc3Rpbmcg dGhhdCB0aG9zZSB1c2UgY2FzZXMgc2hvdWxkIGJlIHRocm93biBvdXQsIG5vciBzZWNvbmQgY2xh c3MuDQoNCkdvb2QsIGJlY2F1c2UgaXTigJlzIGltcG9ydGFudCB0aGF0IHdlIGRvIHRoaW5rIG9m IHRoaXMgYXMgbW9yZSB0aGFuIGp1c3QgYSBwdXJlIGF1dGhlbnRpY2F0aW9uIHN5c3RlbS4NCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KNC4gV2hlbiB5b3Ugc2F5ICJub3QgYmFja3dhcmRzIGNv bXBhdGlibGUgd2l0aCBPQXV0aCAyLjAgYW5kIGl0cyBleHRlbnNpb25zIiwgZG8geW91IGV4cGVj dCB0byBkZWZpbmUgYSBuZXcgc3RhbmRhcmQgdG8gcmVwbGFjZSBSRkMgNjc1MD8gRGV2ZWxvcGVy cyB3aWxsIGhhdmUgdG8gaGF2ZSBhIG5ldyBtZXRob2QgdG8gY2FsbCBBUElzPw0KDQpLaW5kYS4g Rmlyc3QsIGl04oCZcyBtb3JlIDY3NDkgdGhhdCBJIHdhbnQgdG8gc3RlcCBhd2F5IGZyb20uIEJ1 dCBldmVuIHRoZW4sIEkgdGhpbmsga2VlcGluZyBqdXN0IHRoZSBoZWFkZXIgdmVyc2lvbiBvZiA2 NzUwIGlzIE9LIGVub3VnaCBpZiBzb21lb25lIHdhbnRzIHRvIGtlZXAgdXNpbmcgdGhhdC4gVGhl IHRoaW5nIGlzLCB3b27igJl0IHNvbWVvbmUgc2VlaW5nIGFuIE9BdXRoIDIgaGVhZGVyIGFzc3Vt ZSB0aGUgcmVzdCBvZiBPQXV0aCAyIGluZnJhc3RydWN0dXJlPyBJbiBzb21lIGNhc2VzIHRoaXMg d29u4oCZdCBtYXR0ZXIsIGJ1dCBpbiBtYW55IHRoYXQgY291bGQgYmUgcmVhbGx5IGNvbmZ1c2lu Zy4NCg0KT25lIG9mIHRoZSBwcm9ibGVtcywgdGhvdWdoLCBpcyB0aGF0IDY3NTAgaGFzIGFscmVh ZHkgYmVlbiBjbG91ZGVkIGJ5IHRoaW5ncyBsaWtlIHRoZSBNVExTIGJpbmRpbmcsIHdoZXJlIHRo ZXkgdXNlIOKAnGJlYXJlcuKAnSB0b2tlbnMgdGhhdCBoYXZlIHRvIGJlIGJvdW5kIHRvIHRoZSBj bGllbnTigJlzIGNlcnRpZmljYXRlLiBTbyDigKYgbm90IG11Y2ggb2YgYSBiZWFyZXIgdG9rZW4g YW55bW9yZS4NCg0KU28sIGFyZSB5b3UgYXJlIHlvdSBwcm9wb3NpbmcgdGhhdCBUeCBoYXZlIGEg bmV3IG1lY2hhbmlzbSBmb3IgQVBJIGNhbGxzPw0KDQpZZXMsIEkgdGhpbmsgdGhlcmUgd2lsbCBi ZSBuZXcgbWVjaGFuaXNtcyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIGtleS1ib3VuZCB0b2tlbnMu DQoNClNvIGFyZSB5b3UgcHJvcG9zaW5nIHRoYXQgT0F1dGggMy4wIHdpbGwgbm90IHN1cHBvcnQg YmVhcmVyIHRva2Vucz8NCg0KVGhhdCBpcyBub3QgY29ycmVjdCBhbmQgSeKAmW0gbm90IHN1cmUg d2hlcmUgeW91IGdvdCB0aGF0LiBCZWFyZXIgdG9rZW5zIGFyZSBzdGlsbCB1c2VmdWwuIEJ1dCB0 aGV5IHNob3VsZCBsb29rIGFuZCBiZWhhdmUgYXMgZGlzdGluY3QgZnJvbSBzZW5kZXItY29uc3Ry YWluZWQgdG9rZW5zLiBCdXQgdWx0aW1hdGVseSB3ZSBjYW4gdGVsbCB0aGUgY2xpZW50IGhvdyB0 aGUgdG9rZW4gZ2V0cyB1c2VkLCBhcyBiZWxvdy4NCg0KSXQgd2FzIG5vdCBjbGVhciBmcm9tIHlv dXIgcmVzcG9uc2UsIGFzIGEgbmV3IG1lY2hhbmlzbSBjb3VsZCBtZWFuIHRoYXQgdGhlIG9sZCBv bmUgaXMgbm90IHVzZWQgYW55bW9yZS4NCg0KVG8gY2xhcmlmeSwgeW91IGV4cGVjdCB0aGVyZSB3 aWxsIGJlIGFkZGl0aW9uYWwgbWVjaGFuaXNtcy4NCg0KQ29ycmVjdC4gSSB3b3VsZCBleHBlY3Qg dXMgdG8gZWl0aGVyIHJlZGVmaW5lIG9yIHJlLXVzZSBiZWFyZXIgdG9rZW5zIGEgbGEgNjc1MCBp biBzb21lIGNhcGFjaXR5IGJ1dCBhbHNvIGhhdmUgb3RoZXIgcHJlc2VudGF0aW9uIG1lY2hhbmlz bSwgbGlrZSB1c2luZyBIVFRQIFNpZ25hdHVyZXMgKG9uY2UgQW5uYWJlbGxlIGFuZCBteSBkcmFm dCBpcyByZWFsKSBhbmQgTVRMUyBiaW5kaW5nIChsaWtlIHRoZSBPQXV0aCBNVExTIGJpbmRpbmcp Lg0KDQpUaGFua3MgYWdhaW4gZm9yIHRoZSBncmVhdCBkaXNjdXNzaW9uISBJdOKAmXMgaW1wb3J0 YW50IHRvIGdldCB0aGVzZSBkZXRhaWxzIG91dCB3aGVyZSB0aGV54oCZcmUgcmVhZGFibGUuDQoN CiDigJQgSnVzdGluDQo= --_000_3CE4CF774E71423E9E5BAAEAEC17B92Bamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <3EF3FE87A293CD4FB2120AA0893E0778@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGlu Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3Jt YWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29u b3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxl LXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsg SeKAmW0gY3VycmVudGx5IHRoaW5raW5nIHNvbWV0aGluZyBsaWtlIHRoaXMgZm9yIHRoZSBjaGFy dGVyIHRleHQgdG8gc2V0IHRoZSByaWdodCBzY29wZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDsgcmVzdWx0aW5nIGluIGluZm9ybWF0aW9uIGFib3V0IHRoZSByZXF1ZXN0IChzdWNo IGFzIGEgdXNlcuKAmXMgaWRlbnRpdHkgb3IgY3VycmVudCBzdGF0dXMpIGFuZC9vciBhbiBhcnRp ZmFjdCB0aGF0IHdpbGwgYWxsb3cgdGhlIGNsaWVudCB0byB1bmRlcnRha2UgdGhlIGRlbGVnYXRl ZCBhY3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEluIG90aGVyIHdvcmRz LCBvdXIgZm9jdXMgaXMgb24gdGhlIGRlbGVnYXRpb24gcHJvdG9jb2wsIG5vdCB3aGF0IGl04oCZ cyBkZWxlZ2F0aW5nIHRvLiBCdXQgdGhlIGFiaWxpdHkgdG8gaW5jbHVkZSBpbmZvcm1hdGlvbiBp biB0aGF0IHByb3RvY29sIGRpcmVjdGx5IGlzIGEgcG90ZW50aWFsbHkgcG93ZXJmdWwgcGF0dGVy biBhbmQgd2Ugc2hvdWxkIHByb2JhYmx5IGluY2x1ZGUgc29tZSBvZiB0aGF0IGluIG91cg0KIHNj b3BlLiBJIHRoaW5rIHRoZSBpZGVudGl0eSBwb3J0aW9uIGNhbiBiZSBmYWlybHkgbWluaW1hbCwg YXQgbGVhc3QgYXMgYSBzdGFydGluZyBwb2ludC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoaXMgdHJlYXRzIGlkZW50aXR5IGFzIGEgc3BlY2lhbCBjYXNlIHJlc291cmNlIHdoZXJl IHRoZSB0cmFuc2FjdGlvbiBlbmRwb2ludCBkb3VibGVzIGFzIHRoZSByZXNvdXJjZSBzZXJ2ZXIu IE9JREMgZG9lcyB0aGUgc2FtZSB0aGluZywgc28gaXTigJlzIG5vdCB1bnByZWNlZGVudGVkLiBB cmUgeW91IHByb3Bvc2luZyB0aGF0IHdlIHN1cHBvcnQgdGhpcyBtb2RlbCBvbmx5IGZvciBpZGVu dGl0eSwgb3IgZm9yIGFyYml0cmFyeQ0KIHJlc291cmNlcyBhcyB3ZWxsPyBJZiBpdOKAmXMganVz dCBzdXBwb3J0ZWQgZm9yIGlkZW50aXR5LCB3ZSBuZWVkIHRvIG1ha2UgdGhlIGNhc2UgZm9yIHdo eSBpZGVudGl0eSBkZXNlcnZlcyBzcGVjaWFsIHRyZWF0bWVudC4gSS5lLiwgd2hhdCBtYWtlcyBp ZGVudGl0eSBzcGVjaWFsIGVub3VnaCB0byB3YXJyYW50IGJlaW5nIGFibGUgdG8gcmV0cmlldmUg aXQgZGlyZWN0bHkgZnJvbSB0aGUgdHJhbnNhY3Rpb24gZW5kcG9pbnQsIGFuZCB3aGF0IG1ha2Vz DQogdXMgY2VydGFpbiB0aGF0IG5vIG90aGVyIHJlc291cmNlcyBtZWV0IHRob3NlIHJlcXVpcmVt ZW50cz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPuKAkyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5UeGF1dGggJmx0O3R4YXV0aC1ib3VuY2VzQGlldGYub3JnJmd0 OyBvbiBiZWhhbGYgb2YgSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0Ozxicj4N CjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEphbnVhcnkgMSwgMjAyMCBhdCAyOjU4IFBNPGJyPg0K PGI+VG86IDwvYj5EaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs8YnI+DQo8 Yj5DYzogPC9iPiZxdW90O3JkZEBjZXJ0Lm9yZyZxdW90OyAmbHQ7cmRkQGNlcnQub3JnJmd0Oywg RXZlIE1hbGVyICZsdDtldmVAeG1sZ3JybC5jb20mZ3Q7LCAmcXVvdDt0eGF1dGhAaWV0Zi5vcmcm cXVvdDsgJmx0O3R4YXV0aEBpZXRmLm9yZyZndDssIEJlbmphbWluIEthZHVrICZsdDtrYWR1a0Bt aXQuZWR1Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1R4YXV0aF0gVHhBdXRoIFByb3Bv c2VkIENoYXJ0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBEZWMgMzEsIDIwMTksIGF0IDM6NDAgUE0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9 Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+ T24gVHVlLCBEZWMgMzEsIDIwMTkgYXQgMTE6MDEgQU0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRp Y2EiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OkhlbHZldGljYSI+Mi4gV2h5IGRvIHlvdSByZXN0cmljdCB0aGlzIHRvIEhUVFA/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5CZWNhdXNlIEkgd2FudCB1 cyB0byB1c2UgYWxsIG9mIHRoZSBmZWF0dXJlcyBhbmQgYmVuZWZpdHMgb2YgSFRUUCBpbnN0ZWFk IG9mIGhhdmluZyB0byBpbnZlbnQgd2l0aGluLXByb3RvY29sIGZ1bmN0aW9ucyB0byByZXBsaWNh dGUgdGhlbS4gSSBkb27igJl0IHdhbnQgU09BUCwgd2hpY2ggcHJldGVuZHMgdG8gYmUgdHJhbnNw b3J0DQogYWdub3N0aWMgbXVjaCB0byBpdHMgZGV0cmltZW50LiBJZiBzb21lb25lIHdhbnRzIHRv IGRvIE9BdXRoIDMgb24gbm90LUhUVFAsIHRoZXkgY2FuIGRlZmluZSB3aGF0IHRoYXQgbG9va3Mg bGlrZS4gVGhpcyBpcyB3aGF0IGhhcHBlbmVkIHdpdGggdGhlIENPQVAvQ09SRSBzdHVmZiBhbmQg T0F1dGggMi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5JIGFncmVlIFNPQVAgd2Fz IGNvbXBsaWNhdGVkLiBXaGljaCBmZWF0dXJlcyBhbmQgYmVuZWZpdHMgb2YgSFRUUCBhcmUgeW91 IHdhbnRpbmcgdG8gdXNlPyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpI ZWx2ZXRpY2EiPldlbGwgc28gZmFyIHdl4oCZdmUgZ290IGhlYWRlcnMsIFVSTHMsIG1ldGhvZHMs IGRhdGEgcGF5bG9hZCB0eXBlcywgYW5kIHRoZSB3aG9sZSBhcnJheSBvZiB0ZWNobm9sb2dpZXMg dGhhdCB3ZSBjYW4gcmVseSBvbiB3b3JraW5nIHRvZ2V0aGVyIGFsb25nIHdpdGggSFRUUC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5CdXQgd2hpY2ggb25lcyBkbyB5b3Ugd2FudCB0 byB1c2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRp Y2EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRob3NlIHRoaW5ncyB0 aGF0IEkgYWxyZWFkeSBsaXN0ZWQgYXJlIHdoYXQgSSB3YW50IHRvIHVzZS4gSSB3YW50IHRvIHVz ZSB0aGUgaGVhZGVycyBmb3Igc2VuZGluZyBrZXkgcHJvb2ZzIGFuZCBwcm9iYWJseSBjb250ZW50 IG5lZ290aWF0aW9uLiBJIHdhbnQgdG8gaGF2ZSBjb250ZW50IG5lZ290aWF0aW9uIHNvIHRoYXQN CiB3ZSBjYW4gaGF2ZSBhbiBvcHRpb24gdG8gdXNlIEpPU0UgKG9yIENPU0UpIGFzIHRoZSBib2R5 IGZvcm1hdCBpbnN0ZWFkIG9mIEpTT04sIGJ1dCB0aGF0IGZ1bmN0aW9uIHN3aXRjaCBzaG91bGQg Y29tZSBmcm9tIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgKEhUVFApIGFuZCBub3Qgc29tZXRoaW5n IGludGVybmFsIHRvIG91ciBwcm90b2NvbC4gSSB3YW50IHRvIGJlIGFibGUgdG8gdXNlIHJlZGly ZWN0cyB0byBnZXQgdGhlIHVzZXIgdG8gaW50ZXJhY3QsDQogYW5kIGdldCBiYWNrIGZyb20gdGhl IGludGVyYWN0aW9uLiBJIHdhbnQgdG8gKGV2ZW50dWFsbHkpIGRvIHRoaW5ncyBsaWtlIHRva2Vu IHJldm9jYXRpb24gdXNpbmcgYSBERUxFVEUgdmVyYiBpbnN0ZWFkIG9mIGEgc2VwYXJhdGUgZW5k cG9pbnQuIEkgd2FudCB0byB1c2UgSFRUUCBNZXNzYWdlIFNpZ25hdHVyZXMgKG9uY2UgdGhleSBl eGlzdCkgYXMgYSBrZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbS4gQW5kIEkgd2FudCBvdXIgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMNCiB0byBiZSBhYmxlIHRvIHRha2UgaW50byBhY2NvdW50IHRo ZSBwYXJ0aWN1bGFycyBvZiBIVFRQLCBUTFMsIGFuZCB0aGUgbGlrZSB3aGVuIHdlIHdyaXRlIHRo ZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+VGhhbmtzIGZvciBjbGFyaWZ5aW5n LiBJIGFncmVlIHRoYXQgdXNpbmcgdGhlIGh0dHAgY29udGVudC10eXBlIGhlYWRlciwgYW5kIGh0 dHAgdmVyYnMgaXMgcHJlZmVyYWJsZSB0byBpbnZlbnRpbmcgbmV3IG1lY2hhbmlzbXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLCBhbmQgdGhvc2UgYXJlIGp1c3Qg c29tZSBleGFtcGxlcy4gSSB3YW50IHVzIHRvIGhhdmUgYWxsIG9mIEhUVFDigJlzIGZlYXR1cmVz IGFzIG9wdGlvbnMgdGhhdCB3ZSBjYW4gdXNlIHdpdGhvdXQgcmVpbnZlbnRpbmcgdGhlbSwgZXZl biB0aGluZ3MgSSBjYW7igJl0IHRoaW5rIG9mIHJpZ2h0IG5vdy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0 aWNhIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OkhlbHZldGljYSI+SWYgaXQgd2FzIHNpbXBsZSB0byBzdXBwb3J0IENPQVAsIHdoeSB3b3Vs ZCB3ZSBub3QgZG8gdGhhdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2Ei PkJlY2F1c2UgaXTigJlzIG5vdCBqdXN0IENPQVAg4oCUIHlvdeKAmXZlIGdvdCBhIGRpZmZlcmVu dCBzZXQgb2YgYXNzdW1wdGlvbnMgZm9yIHRoZSBsb3dlciBsYXllciBwcm90b2NvbHMsIGFuZCB5 b3XigJl2ZSBnb3QgbG90cyBvZiBjb25zaWRlcmF0aW9ucyBhYm91dCBob3cgdGhlIGRpZmZlcmVu dCBjb21wb25lbnRzIGNhbiB0YWxrDQogdG8gZWFjaCBvdGhlciBpbiB0aGUgZW1iZWRkZWQgc3Bh Y2UuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+WW91IGFyZSBzdWdnZXN0 aW5nIHdlIHJ1bGUgb3V0IGl0IHdvcmtpbmcgd2l0aCBDT0FQIGluIHRoZSBjaGFydGVyLCBiZWZv cmUgd2UgaGF2ZSBldmVuIGhhZCBhIGNoYW5jZSB0byB3b3JrIG9uIGl0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+UGVyaGFwcyBpdCB3 aWxsIGJlIHRyaXZpYWwgdG8gc3VwcG9ydCBDT0FQLiBXZSB3b24ndCBrbm93IGlmIHRoZSBjaGFy dGVyIGZvcmJpZHMgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+SWYgaXQgdHVy bnMgb3V0IHRvIGJlIHRyaXZpYWwgYW5kIHBlb3BsZSB3YW50IHRvIGluY2x1ZGUgaXQgYW5kIGRv IHRoZSB3b3JrIGhlcmUsIHRoZW4gd2UgY291bGQgYWx3YXlzIHVwZGF0ZSB0aGUgY2hhcnRlciB0 byBpbmNsdWRlIGl0LiBJIHdvdWxkIHJhdGhlciBzZWUgdGhhdCB0aGFuIHVzIHRyeWluZyB0byBl bnVtZXJhdGUNCiBhbGwgb2YgdGhlIHRhcmdldCBjYXJyaWVyIG1lY2hhbmlzbXMuIEJlY2F1c2Ug aWYgd2UgZG8gQ09BUCwgd2h5IG5vdCBNUVRUPyBPciBCbHVldG9vdGhMRT8mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPklmIHdl IGluY2x1ZGUgQ09BUCwgdGhlbiB0byBteSBtaW5kIHRoYXQgbmVjZXNzaXRhdGVzIG9uZSBvZiB0 d28gdGhpbmdzLCBpZiBub3QgYm90aDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjEpIFdlIGhhdmUgYSBkb2N1bWVudCB0aGF0IHNheXMg 4oCcSUYgeW914oCZcmUgZG9pbmcgSFRUUCBkbyAoQSkgaWYgeW914oCZcmUgZG9pbmcgQ09BUCBk byAoQinigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYSI+MikgV2UgaGF2ZSBhbiDigJxhYnN0cmFjdOKAnSBkb2N1bWVudCB0aGF0IHNheXMg4oCc aGVyZeKAmXMgdGhpcyB0aGluZyBidXQgZm9yIGRldGFpbHMgb24gaG93IHRvIGRvIGl0IGdvIHJl YWQgdGhlIEhUVFAgZG9jdW1lbnQgYW5kL29yIHRoZSBDT0FQIGRvY3VtZW504oCdLCBidXQgd2hl biB5b3UgcmVhZCB0aGUgSFRUUCBvciBDT0FQIGRvY3VtZW50cywNCiB0aGV5IGRvbuKAmXQgaGF2 ZSBhbnkgaW5mb3JtYXRpb24gYWJvdXQgd2hhdCB0aGUgdGhpbmcgaXMgYmVjYXVzZSBpdOKAmXMg aW4gdGhlIGFic3RyYWN0LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+RnJvbSBhIGRldmVsb3BlcuKAmXMgcGVyc3BlY3RpdmUs IEkgd291bGQgcmF0aGVyIGhhdmUgYW4gSFRUUCBkb2N1bWVudCBiZSBzZWxmLWNvbnRhaW5lZCwg YW5kIGEgQ09BUCBkb2N1bWVudCBiZSBzZWxmLWNvbnRhaW5lZC4gQW5kIGlmIHRoZSB0d28gZGVz Y3JpYmUgdGhlIHNhbWUgcHJvY2Vzcywgb3Igb25lIGluaGVyaXRzDQogZnJvbSB0aGUgb3RoZXIg YnV0IHNheXMg4oCcaW5zdGVhZCBvZiBkb2luZyBIVFRQIHRoaW5nIFggZG8gQ09BUCBlcXVpdmFs ZW50IFnigJ0sIHRoZW4gdGhhdOKAmXMgZ29vZC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2 ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhIj5JIGFncmVlIGNvbXBsZXRlbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNh Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYSI+QnV0IG92ZXJseSBhYnN0cmFjdGluZyBhIHN5c3RlbSBpcyBib3RoIHRlbXB0aW5nIGFu ZCBwb3RlbnRpYWxseSBkaXNhc3Ryb3VzLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj YSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2 ZXRpY2EiPkkgYWdyZWUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5JIGFsaWduIHdpdGggdGhlIGRlc2lnbiB0ZW5ldDo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZx dW90O0Vhc3kgdGhpbmdzIHNob3VsZCBiZSBlYXN5LCBoYXJkIHRoaW5ncyBzaG91bGQgYmUgcG9z c2libGUmcXVvdDsgLS0gTGFycnkgV2FsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+SWYgdGhlIFdHIGhhcyBhIGNob2ljZSBiZXR3ZWVu IEEgYW5kIEIsIGFuZCB0aGV5IGFsbCBvdGhlciB0aGluZ3MgYXJlIGVxdWFsIGZvciBhbiBIVFRQ IGltcGxlbWVudGF0aW9uLCBidXQgQiBpcyBtdWNoIGJldHRlciBmb3IgQ09BUCwgdGhlbiBJIHdv dWxkIHN1Z2dlc3Qgd2UgY2hvb3NlIEIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5JJ20gbm90IHNheWluZyBDT0FQIHN1cHBvcnQgc2hv dWxkIGJlIGEgcHJpb3JpdHksIEknbSBzYXlpbmcgd2Ugc2hvdWxkIG5vdCBjb21wbGV0ZWx5IGln bm9yZSBpdC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIGlu IGZ1bGwgYWdyZWVtZW50IHdpdGggdGhlc2UgcHJpbmNpcGxlcywgc2luY2UgaXQgd291bGQgbWFr ZSBhbGlnbm1lbnQgZm9yIGFueSBwcmVzZW50IG9yIGZ1dHVyZSBDT0FQIHZlcnNpb24gb2YgdGhp cyBwcm90b2NvbCB0byBiZSBidWlsdC4gSSB0aGluayB3ZSBjYW4gbWFuYWdlIHRoYXQgd2hpbGUg c3RpbGwgZm9jdXNpbmcgb24gYW4gSFRUUC1ib3VuZCBwcm9jZXNzLCB3aXRob3V0IGdldHRpbmcg aW50bw0KIHRoZSBvdmVyLWFic3RyYWN0aW9uIHByb2JsZW0uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj YSI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5J biBteSBleHBlcmllbmNlLCBpdOKAmXMgbXVjaCBtb3JlIHN1Y2Nlc3NmdWwgdG8gaGF2ZSBhIHBy b3RvY29sIHN0cm9uZ2x5IGludGVncmF0ZWQgd2l0aCBpdHMgdHJhbnNwb3J0IG1lY2hhbmlzbSBh bmQgdGhlbiB0cmFuc2xhdGVkIG91dCB0byBvdGhlciBtZWNoYW5pc21zLCBpbnN0ZWFkIG9mIHRy eWluZyB0byBjb21lIHVwDQogd2l0aCBvbmUgdW5pdmVyc2FsIGludGVybGluZ3VhIG9mIGEgcHJv dG9jb2wgdGhhdCBqdXN0IGdldCBzaHVudGVkIGFsb25nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpI ZWx2ZXRpY2EiPldvdWxkIHlvdSBwcm92aWRlIGFuIGV4YW1wbGUgYmVzaWRlcyBTT0FQIGZvciB0 aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkl04oCZcyB0aGUgbW9zdCBlZ3Jl Z2lvdXMgZXhhbXBsZSB0aGF0IGNvbWVzIHRvIG1pbmQgZm9yIG1lLCBzbyB0aGF04oCZcyB3aHkg SSBrZWVwIGNvbWluZyBiYWNrIHRvIGl0LiBJIGFsc28gaGF2ZSBpbiBtaW5kIGEgZG96ZW4gcHJv amVjdHMgdGhhdCBuZXZlciB3ZW50IGFueXdoZXJlLCBhbmQgbm9ib2R54oCZcyBoZWFyZCBvZiwN CiBiZWNhdXNlIG9mIGFuIG91dG1vZGVkIGVmZm9ydCBiZWluZyBwdXQgaW50byBkZWZpbmluZyBh YnN0cmFjdGlvbnMgYWhlYWQgb2YgdGltZSBpbiBvcmRlciB0byBhbGxvdyB0cmFuc3BvcnQtYWdu b3N0aWMgbWVzc2FnaW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+QSBzaW1pbGFyIGxldmVsIG9mIG92ZXJseS1lYWdlciBh YnN0cmFjdGlvbiB3ZW50IGludG8gSk9TRSwgd2l0aCB0aGUgSldBIGRvY3VtZW50LiBJdCBtYWtl cyBpdCBzbyB0aGF0IEpXUywgSldFLCBhbmQgSldLIG1ha2Ugbm8gc2Vuc2Ugd2l0aG91dCBKV0Es IGFuZCBKV0EgaXMganVzdCBhIGNvbGxlY3Rpb24gb2YgY29udGVudA0KIHRoYXQgcmVhbGx5IHNo b3VsZCBoYXZlIGJlZW4gaW5jbHVkZWQgaW5saW5lIHdpdGggdGhlIG90aGVyIGRvY3VtZW50cy4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj YSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2 ZXRpY2EiPkkgd2FudCB0byBhdm9pZCB0aGF0IGtpbmQgb2YgdGhpbmcuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OkhlbHZldGljYSI+QWdyZWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2 ZXRpY2EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5UaGlzIGlzIHdoeSBTT0FQIGNh buKAmXQgdXNlIEhUVFAgdmVyYnMgdG8gY29tbXVuaWNhdGUgdGhpbmdzLCBhbmQgd2h5IHRoZSBv bmx5IHNpZ25hdHVyZXMgaXQgY2FuIHVzZSBhcmUgaW50ZXJuYWwuIFdoZW4geW91IGRvIHRoYXQg a2luZCBvZiBzeXN0ZW0sIHlvdSBhbG1vc3QgYWx3YXlzIGVuZCB1cCBoYXZpbmcgcGVvcGxlDQog anVzdCB1c2UgaXQgd2l0aCBvbmUgdHJhbnNwb3J0IGFueXdheSwgbGlrZSBTT0FQIG92ZXIgSFRU UC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpI ZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6SGVsdmV0aWNhIj4zLiBXaHkgaXMgYXV0aGVudGljYXRpb24gbm90IGluIHNjb3BlPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+SXQgZmVsdCwgdG8gbWUsIGxpa2Ug dGhhdCBtaWdodCBiZSBhIGJyaWRnZSB0b28gZmFyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj YSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2 ZXRpY2EiPkkgZGlzYWdyZWUuIEJ1dCBJIGFsc28gdGhpbmsgdGhhdCBhdXRoZW50aWNhdGlvbiBp cyB0aGUgd3JvbmcgdGVybS4gSWRlbnRpdHkqIG1heSBiZSBhIHRlcm0gdGhhdCBtYXBzIGJldHRl ciwgYXMgdGhlIENsaWVudCBpcyB3YW50aW5nIHRvIGdldCAmcXVvdDtpZGVudGl0eSZxdW90OyBk YXRhIGZyb20gdGhlIEFTLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+KiBUaGUgaWRlbnRpdHkgdGVybSBpcyBzdXBlciBjb25m dXNpbmcsIGJ1dCBhdXRoZW50aWNhdGlvbiBpbXBsaWVzIGp1c3Qga25vd2luZyBpdCBpcyB0aGUg c2FtZSB1c2VyLCB3aGVyZSBPcGVuSUQgQ29ubmVjdCBhbHNvIHByb3ZpZGVzIGNsYWltcyBhYm91 dCB0aGUgdXNlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPknigJlt IGNvbWluZyBhcm91bmQgdG8gdGhpcyB2aWV3LCBidXQgSSB3b3VsZCBzdGlsbCBsaWtlIGl0IHRv IGJlIHNlcGFyYXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPldoYXQgZG9lcyBz ZXBhcmF0ZSBtZWFuPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkl0IG1lYW5zIHRo YXQgdGhlIGJpdHMgdGhhdCBzYXkg4oCcdGhpcyBpcyBob3cgeW91IHRhbGsgYWJvdXQgaWRlbnRp dHkgaW5mb3JtYXRpb24gaW4gdGhlIHJlc3BvbnNl4oCdIGFyZSBjb250cm9sbGVkIGJ5IGEgc2Vw YXJhdGUgc3BlYyB0aGF0IG5vdCBldmVyeW9uZSBuZWVkcyB0byB1bmRlcnN0YW5kLiBJIHRoaW5r IHRoZXJlDQogYXJlIHRvbyBtYW55IHVzZSBjYXNlcyBvZiB3YW50aW5nIHRvIGdldCBBUEkgYWNj ZXNzIGFuZCBOT1QgdXNlciBpbmZvcm1hdGlvbiBmb3IgaXQgdG8gYmUgYSBjb3JlIHBpZWNlLiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlNvbWUgZGV2ZWxvcGVycyBvbmx5 IGNhcmUgYWJvdXQgaWRlbnRpdHkuIFNvbWUgb25seSBjYXJlIGFib3V0IEFQSSBhY2Nlc3MuIEl0 IHNob3VsZCBiZSBlYXN5IGZvciBib3RoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlBlcmhhcHMsIGJ1dCB0aGF0IGdldHMgdXMgaW50byBhbiBpbXBvcnRhbnQgcXVlc3Rpb24g b2Ygd2hhdCB0aGUgcmVzdWx0IG9mIHRoZSB0cmFuc2FjdGlvbiBzaG91bGQgYmUuIEluIG15IHZp ZXcsIGl04oCZcyBkZWxlZ2F0aW9uIGZvciBhY2Nlc3MgdG8gc29tZXRoaW5nIOKAlCBzb21lIGJp dCBvZiBpbmZvcm1hdGlvbi4gSW4gdGhlIE9JREMgbW9kZWwsIHRoYXQgaW5jbHVkZXMgaW5mb3Jt YXRpb24gYWJvdXQgd2hvDQogdGhlIGN1cnJlbnQgdXNlciBpcy4gT0F1dGggMiBhbHdheXMgcmV0 dXJucyBhbiBhY2Nlc3MgdG9rZW4sIG5vIG1hdHRlciB3aGF0IHlvdSBkby4gSXMgdGhpcyBzdGls bCB0aGUgcmlnaHQgbW9kZWw/IFJpZ2h0IG5vdyBpbiBYWVogdGhhdOKAmXMgaG93IGl0IHdvcmtz LCBidXQgaW4gdGhlIHB1cmUtaWRlbnRpdHkgY2FzZSBhbmQgaW4gQW5uYWJlbGxl4oCZcyBleHRl bmRlZCB1c2UgY2FzZSwgdGhhdCBpc27igJl0IHRydWUuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBoYXJkIHF1ZXN0aW9uIHRo ZXJlLCB0byBtZSwgaXMgaG93IGRvIHdlIHN3aXRjaCB0aGF0IGtpbmQgb2YgYmVoYXZpb3IuIEni gJltIG5vdCBmb25kIG9mIHNvbWV0aGluZyBsaWtlIOKAnHJldHVybl90eXBlPWlkZW50aXR54oCd IG9yIOKAnHJldHVybl90eXBlPWFjY2Vzc190b2tlbuKAnSwgc2luY2UgdGhlc2UgdGVuZCB0byBi ZSBib3RoIGxpbWl0aW5nIGFuZCBvdmVyYnVpbHQgYXQgdGhlIHNhbWUgdGltZS4gQnV0IEnigJl2 ZQ0KIHN0cnVnZ2xlZCB3aXRoIGhvdyB0byBtYW5hZ2UgdGhpcywgYW5kIGlmIHdl4oCZcmUgZ29p bmcgdG8gaW5jbHVkZSBpZGVudGl0eSBhbmQgb3RoZXIgdXNlIGNhc2VzIGluIHRoZSBjaGFydGVy IGV4cGxpY2l0bHksIHRoZW4gaXTigJlzIHNvbWV0aGluZyB3ZeKAmWxsIG5lZWQgdG8gaGF2ZSBh IGdvb2Qgc29sdXRpb24gZm9yLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj YSI+SG93ZXZlciwgdGhpcyBpcyBhcmd1YWJseSBnZXR0aW5nIGludG8gdGhlIGRldGFpbHMgb2Yg aG93IHRvIHNsaWNlIHVwIGRpZmZlcmVudCBkb2N1bWVudHMsIHdoaWNoIGlzIHJlYWxseSBhIGRl Y2lzaW9uIHRvIGJlIG1hZGUgb25jZSB0aGUgV0cgaXMgcnVubmluZyBhbmQgbm90IGR1cmluZyB0 aGUgY2hhcnRlci4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5DdXJyZW50 bHksIGlkZW50aXR5IGlzIG5vdCBpbiBzY29wZSBvZiB0aGUgY2hhcnRlciwgd2hpY2ggaXMgd2h5 IEkgYW0gYnJpbmdpbmcgaXQgdXAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SeKAmW0gY3VycmVudGx5IHRoaW5raW5nIHNvbWV0aGluZyBsaWtlIHRoaXMgZm9yIHRoZSBjaGFy dGVyIHRleHQgdG8gc2V0IHRoZSByaWdodCBzY29wZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVzdWx0aW5nIGluIGluZm9ybWF0aW9uIGFi b3V0IHRoZSByZXF1ZXN0IChzdWNoIGFzIGEgdXNlcuKAmXMgaWRlbnRpdHkgb3IgY3VycmVudCBz dGF0dXMpIGFuZC9vciBhbiBhcnRpZmFjdCB0aGF0IHdpbGwgYWxsb3cgdGhlIGNsaWVudCB0byB1 bmRlcnRha2UgdGhlIGRlbGVnYXRlZCBhY3Rpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIG90aGVyIHdvcmRzLCBvdXIgZm9jdXMgaXMg b24gdGhlIGRlbGVnYXRpb24gcHJvdG9jb2wsIG5vdCB3aGF0IGl04oCZcyBkZWxlZ2F0aW5nIHRv LiBCdXQgdGhlIGFiaWxpdHkgdG8gaW5jbHVkZSBpbmZvcm1hdGlvbiBpbiB0aGF0IHByb3RvY29s IGRpcmVjdGx5IGlzIGEgcG90ZW50aWFsbHkgcG93ZXJmdWwgcGF0dGVybiBhbmQgd2Ugc2hvdWxk IHByb2JhYmx5IGluY2x1ZGUgc29tZSBvZiB0aGF0IGluIG91cg0KIHNjb3BlLiBJIHRoaW5rIHRo ZSBpZGVudGl0eSBwb3J0aW9uIGNhbiBiZSBmYWlybHkgbWluaW1hbCwgYXQgbGVhc3QgYXMgYSBz dGFydGluZyBwb2ludC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6SGVsdmV0aWNhIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpIZWx2ZXRpY2EiPklmIHdlIGRvIGRlY2lkZSBpdOKAmXMgaW4gc2NvcGUsIHRo ZW4gSSB0aGluayBpdCBzaG91bGQgYmUgY2xlYXJseSBsYXllcmVkIG9uIHRvcCBvZiB0aGUgYXV0 aG9yaXphdGlvbiBsYXllci4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5C ZWluZyBsYXllcmVkIG9uIHRvcCBpcyBjb25mdXNpbmcuIEFuIE9wZW5JRCBDb25uZWN0IGZsb3cg d2hlcmUgdGhlIENsaWVudCByZWNlaXZlcyBhbiBJRCB0b2tlbiwgaGFzIG5vdCBhdXRob3JpemF0 aW9uLCB1bmxlc3MgeW91IGFyZSBjb3VudGluZyB0aGUgVVggYXMgYXV0aG9yaXphdGlvbiAtLSBi dXQgdGhhdCBkb2VzDQogbm90IHNlZW0gbGlrZSBhIGxheWVyLiBXb3VsZCB5b3UgZWxhYm9yYXRl PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPldoYXQgeW914oCZ cmUgZG9pbmcgaW4gT0lEQyBpcyBhdXRob3JpemluZyB0aGUgYXBwbGljYXRpb24gdG8ga25vdyB3 aG8geW91IGFyZSDigJQgdG8gZ2V0IHlvdXIgaWRlbnRpdHkgaW5mb3JtYXRpb24uIFRoYXQga2V5 IGluc2lnaHQgaXMgd2hhdCBtYWtlcyB0aGUgY29tYmluYXRpb24gb2YgT0F1dGggYW5kIE9JREMg d29yayBhcw0KIHdlbGwgYXMgaXQgZG9lcy4gQW5kLCBpbXBvcnRhbnRseSwgb25jZSB5b3UgYXV0 aG9yaXplIGlkZW50aXR5IGFjY2VzcywgeW91IGNhbiBhdXRob3JpemUgb3RoZXIgc3R1ZmYgYXMg d2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+QXMgSSBzdGF0ZWQsIHRo ZXJlIGlzIHRoZSBVWCBvZiBhdXRob3JpemluZyBrbm93aW5nIHdobyB0aGUgdXNlciBpcywgYnV0 IHRoZXJlIGlzIG5vIGFydGlmYWN0IHJlcHJlc2VudGluZyB0aGF0IGF1dGhvcml6YXRpb24gYXMg dGhlcmUgaXMgaW4gT0F1dGggLS0gaWUgdGhlcmUgaXMgbm8gYWNjZXNzIHRva2VuIHRvIGFjY2Vz cw0KIGEgcmVzb3VyY2UuICh5ZXMsIGFuIGFjY2VzcyB0b2tlbiBtYXkgYmUgdXNlZCB0byByZWFk IHRoZSB1c2VyIGluZm8gZW5kcG9pbnQsIGJ1dCB0aGF0IGlzIGFsbCBpdCBjYW4gZG8uJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5BbmQgaXTigJlzIHRoZSDigJxhbmQgb3RoZXIg c3R1ZmbigJ0gdGhhdCBwZW9wbGUgcmVhbGx5LCByZWFsbHksIHJlYWxseSBsaWtlIGFib3V0IE9J REMuIE5vYm9keSBldmVyIHdhbnRzIGp1c3QgYXV0aG9yaXphdGlvbiwgaW4gcHJhY3RpY2UuJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+RGlkIHlvdSBtZWFuIHRvIHNheSAm cXVvdDthdXRoZW50aWNhdGlvbiZxdW90Oz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPklmIHNvLCB0aGVuIEkgd291bGQgcG9zaXQgdGhh dCB0aGVyZSBhcmUgbW9yZSBPSURDIHVzZXIgaW50ZXJhY3Rpb25zIHRoYW4gcGxhaW4gT0F1dGgg Mi4wIHVzZXIgaW50ZXJhY3Rpb25zLCBhbmQgdGhhdCBhbG1vc3QgYWxsIG9mIHRob3NlIE9JREMg dXNlciBpbnRlcmFjdGlvbnMgYXJlIGp1c3QgbG9nZ2luZyBpbiB3aXRoDQogR29vZ2xlIG9yIEZh Y2Vib29rIC0tIGFuZCB0aGF0IHRoZXJlIGlzIG5vICZxdW90O2FuZCBvdGhlciBzdHVmZiZxdW90 Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+WWVzLCBJIG1lYW50IGF1dGhl bnRpY2F0aW9uLCB0aGFuayB5b3UuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5J4oCZbSBub3Qgc3VyZSBpdOKAmXMgdHJ1ZSwg YnV0IEnigJlsbCBhZ3JlZSB0aGF0IGl04oCZcyBtb3JlIHB1YmxpYy1mYWNpbmcuIEJ1dCBldmVu IGlmIHdoYXQgeW91IHBvc2l0IGlzIGFjdHVhbGx5IHRydWUgYnkgcmF3IG51bWJlcnMsIGl04oCZ cyBub3QgdW5pdmVyc2FsLiBJbiBwYXJ0aWN1bGFyLCB0aGVyZSBhcmUgYSBsYXJnZSBudW1iZXIN CiBvZiBzeXN0ZW0tdG8tc3lzdGVtIGNhc2VzIHRoYXQgT0F1dGggMiBjb3ZlcnMsIHdoaWNoIGhh dmUgbm90aGluZyB0byBkbyB3aXRoIGlkZW50aXR5LCB0aGF0IHdlIGRvbuKAmXQgd2FudCB0byB0 aHJvdyBvdXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+SSdtIG5vdCBzdWdnZXN0 aW5nIHRoYXQgdGhvc2UgdXNlIGNhc2VzIHNob3VsZCBiZSB0aHJvd24gb3V0LCBub3Igc2Vjb25k IGNsYXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdvb2QsIGJlY2F1c2Ug aXTigJlzIGltcG9ydGFudCB0aGF0IHdlIGRvIHRoaW5rIG9mIHRoaXMgYXMgbW9yZSB0aGFuIGp1 c3QgYSBwdXJlIGF1dGhlbnRpY2F0aW9uIHN5c3RlbS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0 aWNhIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OkhlbHZldGljYSI+NC4gV2hlbiB5b3Ugc2F5ICZxdW90O25vdCBiYWNrd2FyZHMgY29tcGF0 aWJsZSB3aXRoIE9BdXRoIDIuMCBhbmQgaXRzIGV4dGVuc2lvbnMmcXVvdDssIGRvIHlvdSBleHBl Y3QgdG8gZGVmaW5lIGEgbmV3IHN0YW5kYXJkIHRvIHJlcGxhY2UgUkZDIDY3NTA/IERldmVsb3Bl cnMgd2lsbCBoYXZlIHRvIGhhdmUgYSBuZXcgbWV0aG9kIHRvIGNhbGwNCiBBUElzPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+S2luZGEuIEZpcnN0LCBpdOKAmXMgbW9y ZSA2NzQ5IHRoYXQgSSB3YW50IHRvIHN0ZXAgYXdheSBmcm9tLiBCdXQgZXZlbiB0aGVuLCBJIHRo aW5rIGtlZXBpbmcganVzdCB0aGUgaGVhZGVyIHZlcnNpb24gb2YgNjc1MCBpcyBPSyBlbm91Z2gg aWYgc29tZW9uZSB3YW50cyB0byBrZWVwIHVzaW5nIHRoYXQuIFRoZSB0aGluZyBpcywNCiB3b27i gJl0IHNvbWVvbmUgc2VlaW5nIGFuIE9BdXRoIDIgaGVhZGVyIGFzc3VtZSB0aGUgcmVzdCBvZiBP QXV0aCAyIGluZnJhc3RydWN0dXJlPyBJbiBzb21lIGNhc2VzIHRoaXMgd29u4oCZdCBtYXR0ZXIs IGJ1dCBpbiBtYW55IHRoYXQgY291bGQgYmUgcmVhbGx5IGNvbmZ1c2luZy4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPk9uZSBv ZiB0aGUgcHJvYmxlbXMsIHRob3VnaCwgaXMgdGhhdCA2NzUwIGhhcyBhbHJlYWR5IGJlZW4gY2xv dWRlZCBieSB0aGluZ3MgbGlrZSB0aGUgTVRMUyBiaW5kaW5nLCB3aGVyZSB0aGV5IHVzZSDigJxi ZWFyZXLigJ0gdG9rZW5zIHRoYXQgaGF2ZSB0byBiZSBib3VuZCB0byB0aGUgY2xpZW504oCZcyBj ZXJ0aWZpY2F0ZS4gU28NCiDigKYgbm90IG11Y2ggb2YgYSBiZWFyZXIgdG9rZW4gYW55bW9yZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5TbywgYXJlIHlvdSBhcmUgeW91IHByb3Bv c2luZyB0aGF0IFR4IGhhdmUgYSBuZXcgbWVjaGFuaXNtIGZvciBBUEkgY2FsbHM/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5ZZXMsIEkgdGhpbmsgdGhlcmUgd2lsbCBi ZSBuZXcgbWVjaGFuaXNtcyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIGtleS1ib3VuZCB0b2tlbnMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+U28gYXJlIHlvdSBwcm9wb3NpbmcgdGhh dCBPQXV0aCAzLjAgd2lsbCBub3Qgc3VwcG9ydCBiZWFyZXIgdG9rZW5zPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpIZWx2ZXRpY2EiPlRoYXQgaXMgbm90IGNvcnJlY3QgYW5kIEnigJltIG5vdCBzdXJl IHdoZXJlIHlvdSBnb3QgdGhhdC4gQmVhcmVyIHRva2VucyBhcmUgc3RpbGwgdXNlZnVsLiBCdXQg dGhleSBzaG91bGQgbG9vayBhbmQgYmVoYXZlIGFzIGRpc3RpbmN0IGZyb20gc2VuZGVyLWNvbnN0 cmFpbmVkIHRva2Vucy4gQnV0IHVsdGltYXRlbHkgd2UgY2FuDQogdGVsbCB0aGUgY2xpZW50IGhv dyB0aGUgdG9rZW4gZ2V0cyB1c2VkLCBhcyBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRp Y2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVs dmV0aWNhIj5JdCB3YXMgbm90IGNsZWFyIGZyb20geW91ciByZXNwb25zZSwgYXMgYSBuZXcgbWVj aGFuaXNtIGNvdWxkIG1lYW4gdGhhdCB0aGUgb2xkIG9uZSBpcyBub3QgdXNlZCBhbnltb3JlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+ VG8gY2xhcmlmeSwgeW91IGV4cGVjdCB0aGVyZSB3aWxsIGJlIGFkZGl0aW9uYWwgbWVjaGFuaXNt cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db3JyZWN0LiBJIHdvdWxkIGV4 cGVjdCB1cyB0byBlaXRoZXIgcmVkZWZpbmUgb3IgcmUtdXNlIGJlYXJlciB0b2tlbnMgYSBsYSA2 NzUwIGluIHNvbWUgY2FwYWNpdHkgYnV0IGFsc28gaGF2ZSBvdGhlciBwcmVzZW50YXRpb24gbWVj aGFuaXNtLCBsaWtlIHVzaW5nIEhUVFAgU2lnbmF0dXJlcyAob25jZSBBbm5hYmVsbGUgYW5kIG15 IGRyYWZ0IGlzIHJlYWwpIGFuZCBNVExTIGJpbmRpbmcgKGxpa2UgdGhlIE9BdXRoDQogTVRMUyBi aW5kaW5nKS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3MgYWdhaW4gZm9yIHRoZSBncmVhdCBkaXNjdXNzaW9uISBJdOKAmXMgaW1wb3J0 YW50IHRvIGdldCB0aGVzZSBkZXRhaWxzIG91dCB3aGVyZSB0aGV54oCZcmUgcmVhZGFibGUuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw O+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_3CE4CF774E71423E9E5BAAEAEC17B92Bamazoncom_-- From nobody Fri Jan 3 00:27: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 AB02A1200E0 for ; Fri, 3 Jan 2020 00:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.228 X-Spam-Level: ** X-Spam-Status: No, score=2.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0sCyFH0N-f8 for ; Fri, 3 Jan 2020 00:27:33 -0800 (PST) Received: from alkaline-solutions.com (unknown [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 4455D120046 for ; Fri, 3 Jan 2020 00:27:33 -0800 (PST) Received: from [IPv6:2601:282:202:b210:e9b6:87f6:33db:1d69] (unknown [IPv6:2601:282:202:b210:e9b6:87f6:33db:1d69]) by alkaline-solutions.com (Postfix) with ESMTPSA id 723853155D; Fri, 3 Jan 2020 08:29:13 +0000 (UTC) From: David Waite Message-Id: <9C6149E5-144F-442E-862E-D849A9A9FF57@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7A976CBA-078B-4A1A-A1C8-CD4C4D8B8AE6" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.1\)) Date: Fri, 3 Jan 2020 01:27:31 -0700 In-Reply-To: <6DFD1CA6-D334-4FCA-9881-834571A5DE7C@amazon.com> Cc: Justin Richer , Dick Hardt , "txauth@ietf.org" To: "Richard Backman, Annabelle" References: <6DFD1CA6-D334-4FCA-9881-834571A5DE7C@amazon.com> X-Mailer: Apple Mail (2.3608.60.0.2.1) Archived-At: Subject: Re: [Txauth] Framework vs Protocol 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, 03 Jan 2020 08:27:35 -0000 --Apple-Mail=_7A976CBA-078B-4A1A-A1C8-CD4C4D8B8AE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 2, 2020, at 5:18 PM, Richard Backman, Annabelle = wrote: > The current document seems to do a better job of laying out a core = message and communication pattern, but it doesn=E2=80=99t align well = with the implicit grant. We will want to dig into persistent use cases = for implicit (e.g., Brian Campbell=E2=80=99s use case in this OAuth = mailing list thread = )= to see if the TxAuth pattern can serve them, or if there are gaps that = need to be filled. My understanding is that most complications are due to the compatibility = and migration that comes from the WG recommending against = front-channel/implicit patterns in the front channel for OAuth 2. I = don=E2=80=99t think these use cases would have been precluded in a world = where only code flow had been standardized, and where technologies to = make code flow viable at initial OAuth 2 standardization had been = available (such as CORS). Since we now live in that world and are = talking about an incompatible protocol, I don=E2=80=99t believe these = sorts of compatibility or migration considerations apply. The only use case I know of indirectly pushing for implicit is OIDC = self-issued use case. I would instead describe this as pushing to solve = several new use cases at once: 1. Use of a local (e.g. non-globally reachable) OP 2. Communication when the client and the OP cannot establish direct = network communication, such as when both exist sandboxed on a local = device 3. Defining and mandating client and OP security policy to fit into the = model of the above two points,=20 I personally don=E2=80=99t think the mechanics self-issued OIDC = leverages (custom URL redirects and/or localhost listeners) has = appropriate security or privacy considerations. There are actually zero = security or privacy considerations regarding self-issued, which I find = somewhat disappointing. I also know that one mobile OS vendor has explicitly recommended against = developers using custom URL schemes to solve new use cases, strongly = recommending mechanisms such as claimed HTTPS URLs be used instead. This = vendor has has also gradually increased the complexity and restrictions = for custom URL use by application developers. In my opinion, there is = risk in new use of custom URL schemes for local IPC. It is likely not a = coincidence that custom URL schemes are chosen as they are historically = the only cross-platform local IPC mechanism without privacy controls, = user consent, and and other usability restrictions placed upon them. It is also worth mentioning that OIDC self-issued does not have = provisions to gain authorization, which might make it difficult to = consider it in scope for this group=E2=80=99s charter. -DW= --Apple-Mail=_7A976CBA-078B-4A1A-A1C8-CD4C4D8B8AE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 2, 2020, at 5:18 PM, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> = wrote:
The current document seems = to do a better job of laying out a core message and communication = pattern, but it doesn=E2=80=99t align well with the implicit grant. We = will want to dig into persistent use cases for implicit (e.g., Brian = Campbell=E2=80=99s use case in this OAuth mailing list thread) to see if the TxAuth = pattern can serve them, or if there are gaps that need to be filled.

My understanding is that most complications are due to the = compatibility and migration that comes from the WG recommending against = front-channel/implicit patterns in the front channel for OAuth = 2. I don=E2=80=99t think these use cases would have been = precluded in a world where only code flow had been standardized, and = where technologies to make code flow viable at initial OAuth 2 = standardization had been available (such as CORS). Since we now live in = that world and are talking about an incompatible protocol, I don=E2=80=99t = believe these sorts of compatibility or migration considerations = apply.


The only use case I know of indirectly pushing for = implicit is OIDC self-issued use case. I would instead describe this as = pushing to solve several new use cases at once:

1. Use of a local (e.g. non-globally reachable) OP
2. = Communication when the client and the OP cannot establish direct network = communication, such as when both exist sandboxed on a local = device
3. Defining and mandating client and OP security policy = to fit into the model of the above two points, 

I personally don=E2=80=99t think the mechanics = self-issued OIDC leverages (custom URL redirects and/or localhost = listeners) has appropriate security or privacy considerations. There are = actually zero security or privacy considerations regarding self-issued, = which I find somewhat disappointing.

I= also know that one mobile OS vendor has explicitly recommended against = developers using custom URL schemes to solve new use cases, strongly = recommending mechanisms such as claimed HTTPS URLs be used instead. This = vendor has has also gradually increased the complexity and restrictions = for custom URL use by application developers. In my opinion, there is = risk in new use of custom URL schemes for local IPC. It is likely not a = coincidence that custom URL schemes are chosen as they are historically = the only cross-platform local IPC mechanism without privacy controls, = user consent, and and other usability restrictions placed upon = them.

It is also worth mentioning = that OIDC self-issued does not have provisions to gain authorization, = which might make it difficult to consider it in scope for this group=E2=80= =99s charter.

-DW
= --Apple-Mail=_7A976CBA-078B-4A1A-A1C8-CD4C4D8B8AE6-- From nobody Fri Jan 3 10:59: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 CDDF7120867 for ; Fri, 3 Jan 2020 10:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 gYcfilgmGAkz for ; Fri, 3 Jan 2020 10:58:58 -0800 (PST) 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 4420D120805 for ; Fri, 3 Jan 2020 10:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578077938; x=1609613938; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GXF3jz8EzuJNoNfK7MPQ//XgA3b52TaNYSyLT9wCDcE=; b=c/QEyZjbSW9QuP8prTLKPKPbKYavvEGWUaoCck0malIopOCpOmddfWRH ExxfACKzi9XS7XIsfNZTbBS1OYb/LxW42v4inDXkqD7sngER/mysQlWCg qKvO6OlbWx/BN+7EBYx/OViUFuUDh6qV266CfDtidUluY8dOACY8FfPzA Y=; IronPort-SDR: CgTuliczhVXUPFUcriFqVpf0tqS/7Ix78J0/iNgype2WMHU25Nclm0ZIIg9HyrNYLEJyMDZEPh f5wLelkhgBGQ== X-IronPort-AV: E=Sophos;i="5.69,391,1571702400"; d="scan'208,217";a="8283756" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1d-9ec21598.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 03 Jan 2020 18:58:46 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1d-9ec21598.us-east-1.amazon.com (Postfix) with ESMTPS id 8D1F4A1E6B; Fri, 3 Jan 2020 18:58:45 +0000 (UTC) Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 3 Jan 2020 18:58:44 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 3 Jan 2020 18:58:44 +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.1367.000; Fri, 3 Jan 2020 18:58:44 +0000 From: "Richard Backman, Annabelle" To: David Waite CC: Justin Richer , Dick Hardt , "txauth@ietf.org" Thread-Topic: [UNVERIFIED SENDER] Re: [Txauth] Framework vs Protocol Thread-Index: AQHVv3BLjLjPvzgVakaionCxh87rBKfUN1kAgABiyoCAAAObgIAC8+4AgAEOu4CAACpAAA== Date: Fri, 3 Jan 2020 18:58:44 +0000 Message-ID: References: <6DFD1CA6-D334-4FCA-9881-834571A5DE7C@amazon.com> <9C6149E5-144F-442E-862E-D849A9A9FF57@alkaline-solutions.com> In-Reply-To: <9C6149E5-144F-442E-862E-D849A9A9FF57@alkaline-solutions.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.16] Content-Type: multipart/alternative; boundary="_000_C841437DF8C740CB98929A4DC5BC4B25amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: Framework vs Protocol 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, 03 Jan 2020 18:59:01 -0000 --_000_C841437DF8C740CB98929A4DC5BC4B25amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlbuKAmXQgc2VlbiBhIGRldGFpbGVkIGFuYWx5c2lzIG9mIGhvdyBpbXBsaWNpdCB1c2Ug Y2FzZXMgd291bGQgbWFwIG9udG8gVHhBdXRoLCBzbyB3aGlsZSBJIHRoaW5rIHlvdSBhcmUgY29y cmVjdCBJ4oCZbSBub3QgeWV0IGNvbmZpZGVudCB0aGF0IHRoZSBvbmx5IGNoYWxsZW5nZXMgYXJl IG1pZ3JhdGlvbiByZWxhdGVkLCBhbmQgdGhhdCB0aGVyZSBhcmVu4oCZdCBzdGlsbCBzb21lIGlt cG9ydGFudCBlZGdlIGNhc2VzIGx1cmtpbmcgaW4gdGhlIGltcGxpY2l0IHNwYWNlIHRoYXQgYXJl buKAmXQgd2VsbCBzZXJ2ZWQgYnkgdGhlIFR4QXV0aCBhcHByb2FjaC4NCg0KSSBnZW5lcmFsbHkg YWdyZWUgdGhhdCBPSURDIHNlbGYtaXNzdWVkIE9QIGlzIGNvbmZsYXRpbmcgc2V2ZXJhbCBkaWZm ZXJlbnQgcHJvYmxlbXMgdGhhdCB3b3VsZCBiZSBiZXR0ZXIgYWRkcmVzc2VkIG9uIGFuIGluZGl2 aWR1YWwgYmFzaXMuIFRob3VnaCBpdCBkb2VzIGRlbW9uc3RyYXRlIGhvdyBUeEF1dGjigJlzIGRl cGVuZGVuY3kgb24gYSB0cmFuc2FjdGlvbiBlbmRwb2ludCByZWFjaGFibGUgYnkgdGhlIGNsaWVu dCBmYXZvcnMgZXh0ZXJuYWwgaWRlbnRpdHkgc29sdXRpb25zIG92ZXIgdGhvc2UgdW5kZXIgdGhl IGRpcmVjdCBjb250cm9sIG9mIHRoZSBlbmQgdXNlci4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFy ZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBEYXZpZCBXYWl0ZSA8ZGF2aWRAYWxr YWxpbmUtc29sdXRpb25zLmNvbT4NCkRhdGU6IEZyaWRheSwgSmFudWFyeSAzLCAyMDIwIGF0IDEy OjI3IEFNDQpUbzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9u LmNvbT4NCkNjOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+LCBEaWNrIEhhcmR0IDxk aWNrLmhhcmR0QGdtYWlsLmNvbT4sICJ0eGF1dGhAaWV0Zi5vcmciIDx0eGF1dGhAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbVHhhdXRoXSBGcmFtZXdvcmsgdnMg UHJvdG9jb2wNCg0KDQoNCk9uIEphbiAyLCAyMDIwLCBhdCA1OjE4IFBNLCBSaWNoYXJkIEJhY2tt YW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0 bzpyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNClRoZSBjdXJy ZW50IGRvY3VtZW50IHNlZW1zIHRvIGRvIGEgYmV0dGVyIGpvYiBvZiBsYXlpbmcgb3V0IGEgY29y ZSBtZXNzYWdlIGFuZCBjb21tdW5pY2F0aW9uIHBhdHRlcm4sIGJ1dCBpdCBkb2VzbuKAmXQgYWxp Z24gd2VsbCB3aXRoIHRoZSBpbXBsaWNpdCBncmFudC4gV2Ugd2lsbCB3YW50IHRvIGRpZyBpbnRv IHBlcnNpc3RlbnQgdXNlIGNhc2VzIGZvciBpbXBsaWNpdCAoZS5nLiwgQnJpYW4gQ2FtcGJlbGzi gJlzIHVzZSBjYXNlIGluIHRoaXMgT0F1dGggbWFpbGluZyBsaXN0IHRocmVhZDxodHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoL1J1Y1pIS3VSZjZIQ3NXVXlKREswWFJ3 dWIzdz4pIHRvIHNlZSBpZiB0aGUgVHhBdXRoIHBhdHRlcm4gY2FuIHNlcnZlIHRoZW0sIG9yIGlm IHRoZXJlIGFyZSBnYXBzIHRoYXQgbmVlZCB0byBiZSBmaWxsZWQuDQoNCk15IHVuZGVyc3RhbmRp bmcgaXMgdGhhdCBtb3N0IGNvbXBsaWNhdGlvbnMgYXJlIGR1ZSB0byB0aGUgY29tcGF0aWJpbGl0 eSBhbmQgbWlncmF0aW9uIHRoYXQgY29tZXMgZnJvbSB0aGUgV0cgcmVjb21tZW5kaW5nIGFnYWlu c3QgZnJvbnQtY2hhbm5lbC9pbXBsaWNpdCBwYXR0ZXJucyBpbiB0aGUgZnJvbnQgY2hhbm5lbCBm b3IgT0F1dGggMi4gSSBkb27igJl0IHRoaW5rIHRoZXNlIHVzZSBjYXNlcyB3b3VsZCBoYXZlIGJl ZW4gcHJlY2x1ZGVkIGluIGEgd29ybGQgd2hlcmUgb25seSBjb2RlIGZsb3cgaGFkIGJlZW4gc3Rh bmRhcmRpemVkLCBhbmQgd2hlcmUgdGVjaG5vbG9naWVzIHRvIG1ha2UgY29kZSBmbG93IHZpYWJs ZSBhdCBpbml0aWFsIE9BdXRoIDIgc3RhbmRhcmRpemF0aW9uIGhhZCBiZWVuIGF2YWlsYWJsZSAo c3VjaCBhcyBDT1JTKS4gU2luY2Ugd2Ugbm93IGxpdmUgaW4gdGhhdCB3b3JsZCBhbmQgYXJlIHRh bGtpbmcgYWJvdXQgYW4gaW5jb21wYXRpYmxlIHByb3RvY29sLCBJIGRvbuKAmXQgYmVsaWV2ZSB0 aGVzZSBzb3J0cyBvZiBjb21wYXRpYmlsaXR5IG9yIG1pZ3JhdGlvbiBjb25zaWRlcmF0aW9ucyBh cHBseS4NCg0KDQpUaGUgb25seSB1c2UgY2FzZSBJIGtub3cgb2YgaW5kaXJlY3RseSBwdXNoaW5n IGZvciBpbXBsaWNpdCBpcyBPSURDIHNlbGYtaXNzdWVkIHVzZSBjYXNlLiBJIHdvdWxkIGluc3Rl YWQgZGVzY3JpYmUgdGhpcyBhcyBwdXNoaW5nIHRvIHNvbHZlIHNldmVyYWwgbmV3IHVzZSBjYXNl cyBhdCBvbmNlOg0KDQoxLiBVc2Ugb2YgYSBsb2NhbCAoZS5nLiBub24tZ2xvYmFsbHkgcmVhY2hh YmxlKSBPUA0KMi4gQ29tbXVuaWNhdGlvbiB3aGVuIHRoZSBjbGllbnQgYW5kIHRoZSBPUCBjYW5u b3QgZXN0YWJsaXNoIGRpcmVjdCBuZXR3b3JrIGNvbW11bmljYXRpb24sIHN1Y2ggYXMgd2hlbiBi b3RoIGV4aXN0IHNhbmRib3hlZCBvbiBhIGxvY2FsIGRldmljZQ0KMy4gRGVmaW5pbmcgYW5kIG1h bmRhdGluZyBjbGllbnQgYW5kIE9QIHNlY3VyaXR5IHBvbGljeSB0byBmaXQgaW50byB0aGUgbW9k ZWwgb2YgdGhlIGFib3ZlIHR3byBwb2ludHMsDQoNCkkgcGVyc29uYWxseSBkb27igJl0IHRoaW5r IHRoZSBtZWNoYW5pY3Mgc2VsZi1pc3N1ZWQgT0lEQyBsZXZlcmFnZXMgKGN1c3RvbSBVUkwgcmVk aXJlY3RzIGFuZC9vciBsb2NhbGhvc3QgbGlzdGVuZXJzKSBoYXMgYXBwcm9wcmlhdGUgc2VjdXJp dHkgb3IgcHJpdmFjeSBjb25zaWRlcmF0aW9ucy4gVGhlcmUgYXJlIGFjdHVhbGx5IHplcm8gc2Vj dXJpdHkgb3IgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyByZWdhcmRpbmcgc2VsZi1pc3N1ZWQsIHdo aWNoIEkgZmluZCBzb21ld2hhdCBkaXNhcHBvaW50aW5nLg0KDQpJIGFsc28ga25vdyB0aGF0IG9u ZSBtb2JpbGUgT1MgdmVuZG9yIGhhcyBleHBsaWNpdGx5IHJlY29tbWVuZGVkIGFnYWluc3QgZGV2 ZWxvcGVycyB1c2luZyBjdXN0b20gVVJMIHNjaGVtZXMgdG8gc29sdmUgbmV3IHVzZSBjYXNlcywg c3Ryb25nbHkgcmVjb21tZW5kaW5nIG1lY2hhbmlzbXMgc3VjaCBhcyBjbGFpbWVkIEhUVFBTIFVS THMgYmUgdXNlZCBpbnN0ZWFkLiBUaGlzIHZlbmRvciBoYXMgaGFzIGFsc28gZ3JhZHVhbGx5IGlu Y3JlYXNlZCB0aGUgY29tcGxleGl0eSBhbmQgcmVzdHJpY3Rpb25zIGZvciBjdXN0b20gVVJMIHVz ZSBieSBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzLiBJbiBteSBvcGluaW9uLCB0aGVyZSBpcyByaXNr IGluIG5ldyB1c2Ugb2YgY3VzdG9tIFVSTCBzY2hlbWVzIGZvciBsb2NhbCBJUEMuIEl0IGlzIGxp a2VseSBub3QgYSBjb2luY2lkZW5jZSB0aGF0IGN1c3RvbSBVUkwgc2NoZW1lcyBhcmUgY2hvc2Vu IGFzIHRoZXkgYXJlIGhpc3RvcmljYWxseSB0aGUgb25seSBjcm9zcy1wbGF0Zm9ybSBsb2NhbCBJ UEMgbWVjaGFuaXNtIHdpdGhvdXQgcHJpdmFjeSBjb250cm9scywgdXNlciBjb25zZW50LCBhbmQg YW5kIG90aGVyIHVzYWJpbGl0eSByZXN0cmljdGlvbnMgcGxhY2VkIHVwb24gdGhlbS4NCg0KSXQg aXMgYWxzbyB3b3J0aCBtZW50aW9uaW5nIHRoYXQgT0lEQyBzZWxmLWlzc3VlZCBkb2VzIG5vdCBo YXZlIHByb3Zpc2lvbnMgdG8gZ2FpbiBhdXRob3JpemF0aW9uLCB3aGljaCBtaWdodCBtYWtlIGl0 IGRpZmZpY3VsdCB0byBjb25zaWRlciBpdCBpbiBzY29wZSBmb3IgdGhpcyBncm91cOKAmXMgY2hh cnRlci4NCg0KLURXDQo= --_000_C841437DF8C740CB98929A4DC5BC4B25amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWlu Y2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTph cHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlbuKAmXQgc2VlbiBhIGRldGFpbGVkIGFuYWx5 c2lzIG9mIGhvdyBpbXBsaWNpdCB1c2UgY2FzZXMgd291bGQgbWFwIG9udG8gVHhBdXRoLCBzbyB3 aGlsZSBJIHRoaW5rIHlvdSBhcmUgY29ycmVjdCBJ4oCZbSBub3QgeWV0IGNvbmZpZGVudCB0aGF0 IHRoZSBvbmx5IGNoYWxsZW5nZXMgYXJlIG1pZ3JhdGlvbiByZWxhdGVkLCBhbmQgdGhhdCB0aGVy ZSBhcmVu4oCZdCBzdGlsbCBzb21lIGltcG9ydGFudCBlZGdlIGNhc2VzDQogbHVya2luZyBpbiB0 aGUgaW1wbGljaXQgc3BhY2UgdGhhdCBhcmVu4oCZdCB3ZWxsIHNlcnZlZCBieSB0aGUgVHhBdXRo IGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGdlbmVyYWxseSBhZ3JlZSB0aGF0 IE9JREMgc2VsZi1pc3N1ZWQgT1AgaXMgY29uZmxhdGluZyBzZXZlcmFsIGRpZmZlcmVudCBwcm9i bGVtcyB0aGF0IHdvdWxkIGJlIGJldHRlciBhZGRyZXNzZWQgb24gYW4gaW5kaXZpZHVhbCBiYXNp cy4gVGhvdWdoIGl0IGRvZXMgZGVtb25zdHJhdGUgaG93IFR4QXV0aOKAmXMgZGVwZW5kZW5jeSBv biBhIHRyYW5zYWN0aW9uIGVuZHBvaW50IHJlYWNoYWJsZSBieSB0aGUgY2xpZW50DQogZmF2b3Jz IGV4dGVybmFsIGlkZW50aXR5IHNvbHV0aW9ucyBvdmVyIHRob3NlIHVuZGVyIHRoZSBkaXJlY3Qg Y29udHJvbCBvZiB0aGUgZW5kIHVzZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkRhdmlkIFdhaXRl ICZsdDtkYXZpZEBhbGthbGluZS1zb2x1dGlvbnMuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5G cmlkYXksIEphbnVhcnkgMywgMjAyMCBhdCAxMjoyNyBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7 UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20m Z3Q7PGJyPg0KPGI+Q2M6IDwvYj5KdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7 LCBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDssICZxdW90O3R4YXV0aEBp ZXRmLm9yZyZxdW90OyAmbHQ7dHhhdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5bVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbVHhhdXRoXSBGcmFtZXdvcmsgdnMgUHJvdG9jb2w8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gSmFuIDIsIDIwMjAsIGF0IDU6MTggUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJl bGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYu b3JnIj5yaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgY3VycmVudCBkb2N1bWVudCBzZWVtcyB0byBkbyBhIGJldHRlciBqb2Igb2YgbGF5aW5n IG91dCBhIGNvcmUgbWVzc2FnZSBhbmQgY29tbXVuaWNhdGlvbiBwYXR0ZXJuLCBidXQgaXQgZG9l c27igJl0IGFsaWduIHdlbGwgd2l0aCB0aGUgaW1wbGljaXQgZ3JhbnQuIFdlIHdpbGwgd2FudCB0 byBkaWcgaW50byBwZXJzaXN0ZW50IHVzZSBjYXNlcyBmb3IgaW1wbGljaXQgKGUuZy4sIEJyaWFu IENhbXBiZWxs4oCZcw0KIHVzZSBjYXNlIGluPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvb2F1dGgvUnVjWkhLdVJmNkhDc1dVeUpESzBYUnd1YjN3Ij48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj50aGlzIE9BdXRoIG1haWxpbmcgbGlzdCB0aHJlYWQ8L3NwYW4+PC9hPikg dG8gc2VlIGlmIHRoZSBUeEF1dGggcGF0dGVybiBjYW4gc2VydmUgdGhlbSwgb3IgaWYNCiB0aGVy ZSBhcmUgZ2FwcyB0aGF0IG5lZWQgdG8gYmUgZmlsbGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5NeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgbW9zdCBjb21wbGljYXRp b25zIGFyZSBkdWUgdG8gdGhlIGNvbXBhdGliaWxpdHkgYW5kIG1pZ3JhdGlvbiB0aGF0IGNvbWVz IGZyb20gdGhlIFdHIHJlY29tbWVuZGluZyBhZ2FpbnN0IGZyb250LWNoYW5uZWwvaW1wbGljaXQg cGF0dGVybnMgaW4gdGhlIGZyb250IGNoYW5uZWwgZm9yIE9BdXRoIDIuJm5ic3A7SSBkb27igJl0 IHRoaW5rDQogdGhlc2UgdXNlIGNhc2VzIHdvdWxkIGhhdmUgYmVlbiBwcmVjbHVkZWQgaW4gYSB3 b3JsZCB3aGVyZSBvbmx5IGNvZGUgZmxvdyBoYWQgYmVlbiBzdGFuZGFyZGl6ZWQsIGFuZCB3aGVy ZSB0ZWNobm9sb2dpZXMgdG8gbWFrZSBjb2RlIGZsb3cgdmlhYmxlIGF0IGluaXRpYWwgT0F1dGgg MiBzdGFuZGFyZGl6YXRpb24gaGFkIGJlZW4gYXZhaWxhYmxlIChzdWNoIGFzIENPUlMpLiBTaW5j ZSB3ZSBub3cgbGl2ZSBpbiB0aGF0IHdvcmxkIGFuZCBhcmUgdGFsa2luZw0KIGFib3V0IGFuIGlu Y29tcGF0aWJsZSBwcm90b2NvbCwgSSBkb27igJl0IGJlbGlldmUgdGhlc2Ugc29ydHMgb2YgY29t cGF0aWJpbGl0eSBvciBtaWdyYXRpb24gY29uc2lkZXJhdGlvbnMgYXBwbHkuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBv bmx5IHVzZSBjYXNlIEkga25vdyBvZiBpbmRpcmVjdGx5IHB1c2hpbmcgZm9yIGltcGxpY2l0IGlz IE9JREMgc2VsZi1pc3N1ZWQgdXNlIGNhc2UuIEkgd291bGQgaW5zdGVhZCBkZXNjcmliZSB0aGlz IGFzIHB1c2hpbmcgdG8gc29sdmUgc2V2ZXJhbCBuZXcgdXNlIGNhc2VzIGF0IG9uY2U6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+MS4gVXNlIG9mIGEgbG9jYWwgKGUuZy4gbm9uLWdsb2JhbGx5IHJl YWNoYWJsZSkgT1A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4yLiBDb21tdW5pY2F0aW9uIHdoZW4gdGhlIGNsaWVudCBhbmQgdGhlIE9Q IGNhbm5vdCBlc3RhYmxpc2ggZGlyZWN0IG5ldHdvcmsgY29tbXVuaWNhdGlvbiwgc3VjaCBhcyB3 aGVuIGJvdGggZXhpc3Qgc2FuZGJveGVkIG9uIGEgbG9jYWwgZGV2aWNlPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBEZWZpbmluZyBhbmQgbWFu ZGF0aW5nIGNsaWVudCBhbmQgT1Agc2VjdXJpdHkgcG9saWN5IHRvIGZpdCBpbnRvIHRoZSBtb2Rl bCBvZiB0aGUgYWJvdmUgdHdvIHBvaW50cywmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBwZXJzb25hbGx5IGRvbuKAmXQgdGhpbmsg dGhlIG1lY2hhbmljcyBzZWxmLWlzc3VlZCBPSURDIGxldmVyYWdlcyAoY3VzdG9tIFVSTCByZWRp cmVjdHMgYW5kL29yIGxvY2FsaG9zdCBsaXN0ZW5lcnMpIGhhcyBhcHByb3ByaWF0ZSBzZWN1cml0 eSBvciBwcml2YWN5IGNvbnNpZGVyYXRpb25zLiBUaGVyZSBhcmUgYWN0dWFsbHkgemVybyBzZWN1 cml0eSBvciBwcml2YWN5IGNvbnNpZGVyYXRpb25zIHJlZ2FyZGluZw0KIHNlbGYtaXNzdWVkLCB3 aGljaCBJIGZpbmQgc29tZXdoYXQgZGlzYXBwb2ludGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbHNvIGtub3cgdGhhdCBvbmUgbW9i aWxlIE9TIHZlbmRvciBoYXMgZXhwbGljaXRseSByZWNvbW1lbmRlZCBhZ2FpbnN0IGRldmVsb3Bl cnMgdXNpbmcgY3VzdG9tIFVSTCBzY2hlbWVzIHRvIHNvbHZlIG5ldyB1c2UgY2FzZXMsIHN0cm9u Z2x5IHJlY29tbWVuZGluZyBtZWNoYW5pc21zIHN1Y2ggYXMgY2xhaW1lZCBIVFRQUyBVUkxzIGJl IHVzZWQgaW5zdGVhZC4gVGhpcyB2ZW5kb3IgaGFzIGhhcyBhbHNvIGdyYWR1YWxseQ0KIGluY3Jl YXNlZCB0aGUgY29tcGxleGl0eSBhbmQgcmVzdHJpY3Rpb25zIGZvciBjdXN0b20gVVJMIHVzZSBi eSBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzLiBJbiBteSBvcGluaW9uLCB0aGVyZSBpcyByaXNrIGlu IG5ldyB1c2Ugb2YgY3VzdG9tIFVSTCBzY2hlbWVzIGZvciBsb2NhbCBJUEMuIEl0IGlzIGxpa2Vs eSBub3QgYSBjb2luY2lkZW5jZSB0aGF0IGN1c3RvbSBVUkwgc2NoZW1lcyBhcmUgY2hvc2VuIGFz IHRoZXkgYXJlIGhpc3RvcmljYWxseQ0KIHRoZSBvbmx5IGNyb3NzLXBsYXRmb3JtIGxvY2FsIElQ QyBtZWNoYW5pc20gd2l0aG91dCBwcml2YWN5IGNvbnRyb2xzLCB1c2VyIGNvbnNlbnQsIGFuZCBh bmQgb3RoZXIgdXNhYmlsaXR5IHJlc3RyaWN0aW9ucyBwbGFjZWQgdXBvbiB0aGVtLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBhbHNv IHdvcnRoIG1lbnRpb25pbmcgdGhhdCBPSURDIHNlbGYtaXNzdWVkIGRvZXMgbm90IGhhdmUgcHJv dmlzaW9ucyB0byBnYWluIGF1dGhvcml6YXRpb24sIHdoaWNoIG1pZ2h0IG1ha2UgaXQgZGlmZmlj dWx0IHRvIGNvbnNpZGVyIGl0IGluIHNjb3BlIGZvciB0aGlzIGdyb3Vw4oCZcyBjaGFydGVyLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRFc8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C841437DF8C740CB98929A4DC5BC4B25amazoncom_-- From nobody Fri Jan 3 12:21: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 25765120045 for ; Fri, 3 Jan 2020 12:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.601, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 SUyJ9W1KQ5Ds for ; Fri, 3 Jan 2020 12:21:41 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8CD5120099 for ; Fri, 3 Jan 2020 12:21:40 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id q10so4560993wrm.11 for ; Fri, 03 Jan 2020 12:21:40 -0800 (PST) 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=TeIoupykzH9A9sh9Thch7bCgLcjddvLnYMlv6wltIUk=; b=oGgKd6x98robZ8nOAyaNYBm8dI1klOQkCq9ugGVvmsjDLh3eNjGFSkRs4yZsVp3mAu NJi3AlTaOuidCh90t7TOJxgrRdZ1pu6vjqrCOasdDb+CX0vddUL8HpLX9zgG6I1Xqoa8 G/+P3sIZfl+8j6FIvB3xR+o87ka0R7kZAu50dmuZo2rz5eG1OZFjf6dgb3xWDmuEyrOW q4FvypLI/FxxcqGLV32ihs/mgyohdJTgqW7cMe/WNiquFREl3lIpBie/hljSLNV2Msde A1X/wRvZcuzm7NRxD88p1pmmYkI/OOopnHNz/bAV18oqeuhS64Yp/tDzn6vSn8x6AsTu 4ZrQ== 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=TeIoupykzH9A9sh9Thch7bCgLcjddvLnYMlv6wltIUk=; b=KsJHJisdwa5top6S06uWI5MeZ9yXOtTsKsHvqKYcNy430WHXVHTzPgv1w0fRIG2ibN s2StDRlhaKmpSlgMLmGvVMslUFI6F/BiY14orkLY515vyThhUBui3NXztGgYHFaEVCE/ fH5bt/f6yCc61wWQqdDPpSuE5MNCX7z3fRMLIKiZZEece6I2XK3wyIRyPgDpqSgDBlpL jgkMyR9Cb6hVDWIFXUwxH7kB2WKrmtWe6+Gj5aXWAsCRsd+rQjqj0rRPKQaJ+VlAA3ag nqNnqN5x+EITN4U8g0+en8Q60E36pjfUFt3EhBRnc/kCGCwF5emc/xRIyJSXgIezemes qf4Q== X-Gm-Message-State: APjAAAXf+12YpoSTpcmv8lRkTRWm/kgyZdiAn9/xC9ad9CEljZllPtPw rEBW37zve03vrDLhMv677a8= X-Google-Smtp-Source: APXvYqy+D0Vp2O1VmA5qQ0cy1YxbIu0/j7JNIy65ShzlYvW7SjGLPopNBI5Q0qkA4mlUKNYeio5fHQ== X-Received: by 2002:adf:9b83:: with SMTP id d3mr88995726wrc.54.1578082899253; Fri, 03 Jan 2020 12:21:39 -0800 (PST) Received: from [10.0.0.144] (bzq-79-180-23-198.red.bezeqint.net. [79.180.23.198]) by smtp.gmail.com with ESMTPSA id o15sm62793838wra.83.2020.01.03.12.21.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jan 2020 12:21:37 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.20.0.191208 Date: Fri, 03 Jan 2020 22:21:35 +0200 From: Yaron Sheffer To: Justin Richer , Dick Hardt CC: "rdd@cert.org" , Aaron Parecki , Benjamin Kaduk , Brian Campbell , Message-ID: <59704751-FF32-4CA6-B9A0-E0714CC15EBE@gmail.com> Thread-Topic: [Txauth] TxAuth Proposed Charter References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> <2305299E-FB2C-426D-A9BF-F2E2492A311A@mit.edu> <0AB6001B-43AF-42F1-87CA-BE621DEBE0FB@mit.edu> <5137E82A-F4F1-425F-9DCA-785B3927E509@mit.edu> In-Reply-To: <5137E82A-F4F1-425F-9DCA-785B3927E509@mit.edu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3660934897_493676655" Archived-At: Subject: Re: [Txauth] TxAuth Proposed 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, 03 Jan 2020 20:21:45 -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_3660934897_493676655 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I strongly agree with Justin=E2=80=99s plan, and suggest that we revisit the name= a year after chartering this work. =20 Naming *is* important. The OAuth3 name indicates to the market that this is= the next iteration of OAuth2, regardless of technical backward compatibilit= y. By =E2=80=9Cnext iteration=E2=80=9D I mean that most of the OAuth2 use cases are cove= red, and the new protocol is =E2=80=9Cbetter=E2=80=9D than the old one in some sense. =20 In a year we will be able to make a call whether there is good coverage of = use cases with this protocol, and then we will need to reach community conse= nsus that this is the next protocol iteration, where the community includes = some people who will not deploy it for years to come. =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: Justin Richer Date: Tuesday, December 31, 2019 at 20:37 To: Dick Hardt Cc: "rdd@cert.org" , Aaron Parecki , Yaron= Sheffer , Benjamin Kaduk , Brian Camp= bell , Subject: Re: [Txauth] TxAuth Proposed Charter =20 And just to reiterate a previous point =E2=80=94 as much as I want to make the ca= se for calling this work OAuth 3, it=E2=80=99s not something I=E2=80=99m going to die fo= r. The work is way more important than the name.=20 =20 So with that, I would propose that we basically punt on naming things until= that becomes important. I say we name both the working group and the first = document =E2=80=9CTxAuth=E2=80=9D, and keep this mailing list as its base. =20 If the working group decides in a couple years that this really should be r= enamed, we can do that. It=E2=80=99s happened before =E2=80=94 and again I=E2=80=99m calling t= o the model of HTTP/3. It started as QUIC in the QUIC working group, and a y= ear ago the QUIC working group decided to rename it to HTTP/3, with the coor= dination and blessing of the HTTP working group. Once QUIC group winds down,= the HTTP/3 protocol will come under the stewardship of the HTTP working gro= up. I can easily see a similar pattern happening here, where we create TxAut= h and eventually it gets handed over to the OAuth WG. =20 =E2=80=94 Justin On Dec 31, 2019, at 8:09 AM, Justin Richer wrote: =20 My understanding is that HTTP3 is not backwards compatible, since QUIC was = built on UDP from the start and the considerations are pretty different from= TCP there.=20 =20 I don=E2=80=99t think the safe answer is =E2=80=9Cdo nothing=E2=80=9D today because there is = a large and vibrant community around OAuth 2. The safe answer is to deploy s= omething that solves your problems. =20 I think that we=E2=80=99re going to have the imaging issue vis a vis =E2=80=9Creplacing= OAuth 2=E2=80=9D whether we call this OAuth 3 or TxAuth or whatever. Truth is for= some people we will be replacing OAuth 2, and some people will be throwing = out their OAuth 2 implementations (if we=E2=80=99re successful). But that=E2=80=99s the = cost of tracking new technology, and it=E2=80=99s pretty clear to me that this wor= k has a long ways to go. =20 =E2=80=94 Justin On Dec 30, 2019, at 6:25 PM, Dick Hardt wrote: =20 I significant difference in this case is that OAuth 3 is NOT backward compa= tible with OAuth 2. =20 HTTP 2 was backwards compatible, as is HTTP 3 from what I understand. =20 This has enterprises question what they should do, and the safe answer is d= o nothing. I think this is what Brian was getting at on confusion. People ar= e confused on what they should do. OAuth 3 not being backward compatible imp= lies work done with OAuth 2 may have to be thrown away. =20 =20 On Sat, Dec 28, 2019 at 9:07 AM Justin Richer wrote: This is going to be the case whatever we call this new work. Progress is go= ing to continue to happen, and if a large enterprise decides to wait for the= new shiny thing 3 years from now, then that=E2=80=99s on them.=20 =20 In my experience, it=E2=80=99s more likely that a large enterprise is going to sh= y away from the new shiny thing and go with what they can buy in a supported= package off the shelf. And I think that=E2=80=99s the kind of timescale that=E2=80=99s = going to drive most of the developers decisions around whether to track the = new work or use what=E2=80=99s out there =E2=80=94 they need to ask =E2=80=9Cwhat do I need?=E2=80= =9D And =E2=80=9Cwhen do I need it?=E2=80=9D =20 But these are :always: the questions that you need to ask when starting a p= roject and choosing technologies.=20 =20 I still contend that the name OAuth 3 does a better job at communicating wh= at=E2=80=99s going on here. =20 =E2=80=94 Justin On Dec 27, 2019, at 1:27 PM, Dick Hardt wrote: =20 I agree with Brian. Developers such as large enterprise customers are going= to be confused when they hear there is an OAuth 3 in the works. Some will p= ush pause on projects because they worry that it will be outdated when it is= released. They won't know which to deploy, even though OAuth 3 is not avail= able.=20 =20 Also, if what we are working on includes authentication / identity -- it no= longer is just delegated authorization =20 See inline comments below. =20 =20 On Tue, Dec 24, 2019 at 4:22 PM Justin Richer wrote: Brian, I hear what you=E2=80=99re saying, but I disagree completely. =20 Who would be confused by seeing a major revision to an existing protocol th= at worked in a different way and did the same things but also new things? Th= at happens all the time. =20 And it causes market confusion all the time. Conservative organizations sto= p doing things when it is not clear what the future will be. =20 =20 Was there significant confusion between OAuth 1 and 2, enough to hamper ado= ption of either? For the people who deeply invested in OAuth 1 and didn=E2=80=99t = need or want the OAuth 2 newness, they stuck with it (see: twitter).=20 =20 Twitter stuck with OAuth 1 because they did not like bearer tokens.=20 =20 Yes, there was lots of confusion between OAuth 1 and 2. Erin did not want w= hat became OAuth 2 to be called OAuth because of the confusion. Hence it was= called WRAP early. The actual name of the WG is "Web Authorization Protocol= " =20 =20 =20 Was OpenID Connect a major disservice to OpenID 2? It was a disruption, for= sure, but people transitioned where it made sense for them, and in many cas= es that took years of dual-deployment and transition.=20 =20 The work that was being done on OpenID 3 was killed because a large platfor= m company that starts with G did not want to confuse their customers about a= new version. =20 =20 I see us walking along the same kind of path here, nearly a decade later. T= hat=E2=80=99s why I think OAuth 3 makes sense as a name for the output of this wor= k. Or at the very least, for the core delegation protocol portion of whateve= r we make. I think it sends the right message to implementers and developers= : the community that knows and understands OAuth 2 is working on the next ve= rsion of that thing, so when it=E2=80=99s ready, maybe you should look at it. Unti= l it=E2=80=99s done, and for a long time after, OAuth 2 is still going to be there= and be the right answer.=20 =20 I agree that people may be confused if it is called something else that OAu= th, but if it is broader than OAuth, then that is confusing as well. =20 =20 The name isn=E2=80=99t a hill I=E2=80=99m committed to dying alone on, but I think it s= ends a :bad: message if we call it something new entirely. Namely, that we t= hink people :should: abandon the entire world of OAuth, all of its ideas and= implementations. That=E2=80=99s not what we=E2=80=99re doing with this design, it=E2=80=99s a= n evolution as I see things. And as an evolution, a new major revision numbe= r makes sense. =20 =E2=80=94 Justin On Dec 24, 2019, at 9:54 AM, Brian Campbell wr= ote: =20 Naming any prospective resulting work here "OAuth 3.0" would significantly = exacerbate confusion in the whole space and would be a major disservice to t= he broader community.=20 =20 =20 On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki wrote: I definitely am not trying to discuss specifics of *how* authentication sho= uld be included right now, but I just want to make sure it's included in the= charter so that we can actually talk about it and it won't be "out of scope= " when we eventually do talk about the specifics. =20 Aaron =20 =20 =20 On Mon, Dec 23, 2019 at 1:51 PM Justin Richer wrote: I=E2=80=99m fine with it being in charter but I do think it should be a clearly s= eparate layer, much like OIDC/Facebook Connect/GitHub Login/etc are with OAu= th today. In all of these the authorization is first, and I think that=E2=80=99s t= he right pattern. So if we do take it on we=E2=80=99ll just need to be careful how= it=E2=80=99s structured in with everything else. Otherwise, I think the authentic= ation side can quickly overwhelm and drag down the authorization side. =20 Good news: A lot of the additional stuff in OIDC is there to patch holes in= core OAuth in a common fashion, and we=E2=80=99ll at least be in a position to no= t have to do that again.=20 =20 =20 =E2=80=94 Justin On Dec 22, 2019, at 10:46 PM, Aaron Parecki wrote: =20 I do think authentication should be part of the charter from the outset. Fr= ankly the fact that authentication is intentionally left out of OAuth and ha= s to be bolted on to the side via OpenID Connect is one of the exact reasons= people get confused about the whole space to begin with.=20 =20 It's a relatively minor addition to the existing proposed spec to make it u= seful as a minimum viable authentication solution, and I'd like to see that = be addressed at the beginning of this work. =20 I think we can do this in a smart way and that authentication should be inc= luded in the charter. =20 Aaron =20 =20 =20 =20 On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer wrote= : Hi Justin, =20 I think the charter should mention target use cases. For example, =E2=80=9Call us= e cases supported by OAuth 2 will be supported by the new protocol=E2=80=9D or =E2=80=9C= the protocol will support at least use cases X and Y=E2=80=9D. =20 And given the importance of OIDC, we could say something like: =E2=80=9CThe proto= col will allow future extension to support authentication, in an analogous w= ay to OpenID Connect. However authentication is explicitly not part of the i= nitial scope.=E2=80=9D =20 Thanks, Yaron =20 From: Txauth on behalf of Justin Richer Date: Saturday, December 21, 2019 at 00:34 To: Cc: "rdd@cert.org" , Benjamin Kaduk Subject: [Txauth] TxAuth Proposed Charter =20 Hi all, =20 As discussed in Singapore, no matter what forum TxAuth takes, its work will= require a new charter. With that in mind, I=E2=80=99ve taken a bit of time to put= together a proposed charter text for the TxAuth work: =20 This group is chartered to develop a next-generation transactional authoriz= ation and delegation protocol for HTTP-based APIs and their clients. These t= ransactions will allow an authorizing party to delegate a right of access fo= r an API or set of APIs through an authorization server to a software client= acting on behalf of an authorizing party.=20 =20 The group will deliver a protocol specification detailing how a client can = request and obtain delegated access, how an authorization server can provide= delegated access, how an authorized party can authorize delegated access, a= nd how that authorized access can be communicated to the resources being pro= tected. These actions will be connected through an explicit transaction betw= een the client and authorization server, resulting in an artifact that will = allow the client to undertake the delegated action.=20 =20 Additionally, the delegation process will allow for: - Fine-grained specification of resource access - Delegation between multiple users - Web, mobile, single-page, and other client applications =20 The group will define extension points for this protocol to allow for flexi= bility in areas including: =20 - Cryptographic agility for keys, message signatures, and proof of possessi= on=20 - User interaction mechanisms including web and non-web methods - Token presentation mechanisms and key bindings =20 The artifacts for this work are not intended or expected to be backwards-co= mpatible with OAuth 2.0 and its extensions.=20 =20 While this work could be done in within the OAuth working group, I now beli= eve that it should be done in a new working group, and that we should try to= get that working group up and running prior to the Vancouver meeting in Mar= ch. I think this group should stay here on the TxAuth list, and it=E2=80=99s my su= ggestion that the resulting work be called OAuth 3.0.=20 =20 Why a new group? I think that the OAuth working group should remain focused= on extending, patching, and adapting OAuth 2.0 to a changing world. I plan = to be engaged in both groups, and I know most of you are as well, but that=E2=80= =99s not universal. Since OAuth 2.0 is so established already, there are a LOT= of people who aren=E2=80=99t going to be interested in something new any time soo= n. But on the other hand, there are a number of people for whom OAuth 2.0 do= es not work, or is at the very least a poor fit, and we=E2=80=99ll want to bring t= hem in at this early stage. So even with significant overlap, I think there=E2= =80=99s enough disconnect in the community from both sides that warrants a new g= roup. In addition, I think this is a big enough piece of work that it=E2=80=99s si= mply too much for the OAuth working group to be able to focus on. We wouldn=E2= =80=99t be able to get additional meeting time, and OAuth already has trouble fi= tting into its two meeting slots as it is. =20 I=E2=80=99ve published a blog post detailing more of my rationale: =20 https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? =20 Please suggest changes to the proposed charter text above. It=E2=80=99s my hope t= hat we can get the chartering process started. =20 =E2=80=94 Justin -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --=20 ---- Aaron Parecki aaronparecki.com @aaronpk =20 =20 --=20 ---- Aaron Parecki aaronparecki.com @aaronpk =20 --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth CONFIDENTIALITY NOTICE: This email may contain confidential and privileged = material for the sole use of the intended recipient(s). Any review, use, dis= tribution or disclosure by others is strictly prohibited. If you have recei= ved this communication in error, please notify the sender immediately by e-m= ail and delete the message and any file attachments from your computer. Than= k you. =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 --B_3660934897_493676655 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I strongly agree with Justin=E2=80=99s plan, and suggest= that we revisit the name a year after chartering this work.

<= p class=3DMsoNormal> 

Naming *is*= important. The OAuth3 name indicates to the market that this is the next it= eration of OAuth2, regardless of technical backward compatibility. By =E2=80=9Cnex= t iteration=E2=80=9D I mean that most of the OAuth2 use cases are covered, and the= new protocol is =E2=80=9Cbetter=E2=80=9D than the old one in some sense.

=

 

In a year we will= be able to make a call whether there is good coverage of use cases with thi= s protocol, and then we will need to reach community consensus that this is = the next protocol iteration, where the community includes some people who wi= ll not deploy it for years to come.

&n= bsp;

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

&nb= sp;

From: Justin R= icher <jricher@mit.edu>
Date: Tuesday, December 31, 2019 at = 20:37
To: Dick Hardt <dick.hardt@gmail.com>
Cc: &q= uot;rdd@cert.org" <rdd@cert.org>, Aaron Parecki <aaron@parecki= .com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Benjamin Kaduk <ka= duk@mit.edu>, Brian Campbell <bcampbell@pingidentity.com>, <txau= th@ietf.org>
Subject: Re: [Txauth] TxAuth Proposed Charter=

 

And just to reiterate a previous point =E2=80=94 as much as I wan= t to make the case for calling this work OAuth 3, it=E2=80=99s not something I=E2=80=99m= going to die for. The work is way more important than the name. <= /o:p>

 

So with that, I would propose that we basically punt on naming thing= s until that becomes important. I say we name both the working group and the= first document =E2=80=9CTxAuth=E2=80=9D, and keep this mailing list as its base.

 

If the working group decides in a couple years that this really= should be renamed, we can do that. It=E2=80=99s happened before =E2=80=94 and again I=E2=80= =99m calling to the model of HTTP/3. It started as QUIC in the QUIC working gr= oup, and a year ago the QUIC working group decided to rename it to HTTP/3, w= ith the coordination and blessing of the HTTP working group. Once QUIC group= winds down, the HTTP/3 protocol will come under the stewardship of the HTTP= working group. I can easily see a similar pattern happening here, where we = create TxAuth and eventually it gets handed over to the OAuth WG.=

 

 =E2=80=94 Justin



On Dec 31, 2019, at 8:09 AM, Justin Richer <jricher@mit.edu> wrote:

 

My understan= ding is that HTTP3 is not backwards compatible, since QUIC was built on UDP = from the start and the considerations are pretty different from TCP there.&n= bsp;

 

<= p class=3DMsoNormal>I don=E2=80=99t think the safe answer is =E2=80=9Cdo nothing=E2=80=9D today = because there is a large and vibrant community around OAuth 2. The safe answ= er is to deploy something that solves your problems.

 

I th= ink that we=E2=80=99re going to have the imaging issue vis a vis =E2=80=9Creplacing OAut= h 2=E2=80=9D whether we call this OAuth 3 or TxAuth or whatever. Truth is for some= people we will be replacing OAuth 2, and some people will be throwing out t= heir OAuth 2 implementations (if we=E2=80=99re successful). But that=E2=80=99s the cost = of tracking new technology, and it=E2=80=99s pretty clear to me that this work has= a long ways to go.

 <= /o:p>

 =E2=80=94 Justin

<= p class=3DMsoNormal>

On Dec 30, 2019, at 6:25 PM, D= ick Hardt <dick.hardt@gmail.com= > wrote:

 

I significant difference in this case is that OAuth= 3 is NOT backward compatible with OAuth 2.

 

HTTP 2 was backward= s compatible, as is HTTP 3 from what I understand.

=

 

This h= as enterprises question what they should do, and the safe answer is do nothi= ng. I think this is what Brian was getting at on confusion. People are confu= sed on what they should do. OAuth 3 not being backward compatible implies wo= rk done with OAuth 2 may have to be thrown away.

 

&n= bsp;

On Sat, Dec 28, 2019 at 9:07 AM J= ustin Richer <jricher@mit.edu> wr= ote:

This is going to be the case whatever we call this new= work. Progress is going to continue to happen, and if a large enterprise de= cides to wait for the new shiny thing 3 years from now, then that=E2=80=99s on the= m. 

 

In my experience, it=E2=80=99s more likely that a large ente= rprise is going to shy away from the new shiny thing and go with what they c= an buy in a supported package off the shelf. And I think that=E2=80=99s the kind o= f timescale that=E2=80=99s going to drive most of the developers decisions around = whether to track the new work or use what=E2=80=99s out there =E2=80=94 they need to ask= =E2=80=9Cwhat do I need?=E2=80=9D And =E2=80=9Cwhen do I need it?=E2=80=9D

 

But t= hese are :always: the questions that you need to ask when starting a project= and choosing technologies. 

 

I still contend that th= e name OAuth 3 does a better job at communicating what=E2=80=99s going on here.

 

 =E2=80=94 Justin


=

=

On Dec 27, 2019, at 1:27 PM, Dick Hardt <dick.hardt@gmail.com> w= rote:

 

=

I agree with Brian. Developers such as large en= terprise customers are going to be confused when they hear there is an = OAuth 3 in the works. Some will push pause on projects because they worry th= at it will be outdated when it is released. They won't know which to deploy,= even though OAuth 3 is not available. 

 

Also, if what we a= re working on includes authentication / identity -- it no longer is just del= egated authorization

 =

See inline comments below.

 

 

On Tue, D= ec 24, 2019 at 4:22 PM Justin Richer <jricher@mit.edu> wrote:

Brian, I hear = what you=E2=80=99re saying, but I disagree completely.

 

Who would be c= onfused by seeing a major revision to an existing protocol that worked in a = different way and did the same things but also new things? That happens all = the time.

 

And it causes market confusi= on all the time. Conservative organizations stop doing things when it is not= clear what the future will be.

=  

=

 

Was there significant confusion between OAuth 1 and 2, enough to hamper = adoption of either? For the people who deeply invested in OAuth 1 and didn=E2=80= =99t need or want the OAuth 2 newness, they stuck with it (see: twitter). = ;

 =

Twitter stuck with OAuth 1 because t= hey did not like bearer tokens. 

 

Yes, there was lots= of confusion between OAuth 1 and 2. Erin did not want what became OAuth 2 t= o be called OAuth because of the confusion. Hence it was called WRAP early. = The actual name of the WG is "Web Authorization Protocol"

 

 

 

Was OpenID Connect a major disservice to OpenID 2? It was a d= isruption, for sure, but people transitioned where it made sense for them, a= nd in many cases that took years of dual-deployment and transition. 

 

The work that was being done on OpenID 3= was killed because a large platform company that starts with G did not want= to confuse their customers about a new version.

 

 

I see us walking along the same kind of path here, near= ly a decade later. That=E2=80=99s why I think OAuth 3 makes sense as a name for th= e output of this work. Or at the very least, for the core delegation protoco= l portion of whatever we make. I think it sends the right message to impleme= nters and developers: the community that knows and understands OAuth 2 is wo= rking on the next version of that thing, so when it=E2=80=99s ready, maybe you sho= uld look at it. Until it=E2=80=99s done, and for a long time after, OAuth 2 is sti= ll going to be there and be the right answer. 

 

I agree that people may be confused if it is called something = else that OAuth, but if it is broader than OAuth, then that is confusing as = well.

 

 

The name isn=E2=80=99t a hil= l I=E2=80=99m committed to dying alone on, but I think it sends a :bad: message if= we call it something new entirely. Namely, that we think people :should: ab= andon the entire world of OAuth, all of its ideas and implementations. That=E2= =80=99s not what we=E2=80=99re doing with this design, it=E2=80=99s an evolution as I see th= ings. And as an evolution, a new major revision number makes sense.

 

 =E2=80=94 Justin



<= p class=3DMsoNormal>On Dec 24, 2019, at 9:54 AM, Brian Campbell <bcampbell@pingidentity.com= > wrote:

 

=

Naming any prospective resulting work here= "OAuth 3.0" would significantly exacerbate confusion in the whole= space and would be a major disservice to the broader community. =

 

 

On Mon, Dec= 23, 2019 at 7:39 PM Aaron Parecki <aaron@parecki.com> wrote:

I defin= itely am not trying to discuss specifics of *how* authentication should be i= ncluded right now, but I just want to make sure it's included in the charter= so that we can actually talk about it and it won't be "out of scope&qu= ot; when we eventually do talk about the specifics.

 

Aaron

 

 

 

On Mon, Dec 23, 2019 at 1= :51 PM Justin Richer <jr= icher@mit.edu> wrote:

I=E2=80=99m fine with it being in ch= arter but I do think it should be a clearly separate layer, much like OIDC/F= acebook Connect/GitHub Login/etc are with OAuth today. In all of these the a= uthorization is first, and I think that=E2=80=99s the right pattern. So if we do t= ake it on we=E2=80=99ll just need to be careful how it=E2=80=99s structured in with ever= ything else. Otherwise, I think the authentication side can quickly overwhel= m and drag down the authorization side.

 

Good news: A lot of the= additional stuff in OIDC is there to patch holes in core OAuth in a common = fashion, and we=E2=80=99ll at least be in a position to not have to do that again.=  

 

 

 =E2=80=94 Justin



On Dec 22, 2019, at 10:46 PM, Aaron Parecki <aaron@parecki.com> wrote:

 

I do think authentication should be part of the charter from the = outset. Frankly the fact that authentication is intentionally left out of OA= uth and has to be bolted on to the side via OpenID Connect is one of the exa= ct reasons people get confused about the whole space to begin with. 

 

<= div>

It's a relatively minor addition to the existing prop= osed spec to make it useful as a minimum viable authentication solution, and= I'd like to see that be addressed at the beginning of this work.=

 

I think we can do this in a smart way and that authentication shoul= d be included in the charter.

 

Aaron

<= div>

 

 

 

=

 

On= Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi Just= in,

 

I think the charter should mentio= n target use cases. For example, =E2=80=9Call use cases supported by OAuth 2 will = be supported by the new protocol=E2=80=9D or =E2=80=9Cthe protocol will support at least= use cases X and Y=E2=80=9D.

 

And given the = importance of OIDC, we could say something like: =E2=80=9CThe protocol will allow = future extension to support authentication, in an analogous way to OpenID Co= nnect. However authentication is explicitly not part of the initial scope.=E2=80= =9D

 

Thanks,

  = ;            &nb= sp; Yaron

 

From: Txauth <txauth-bounces@ietf.org> on = behalf of Justin Richer <jricher@mit.edu>
Date: Saturday, December 21, 2019 at 00:3= 4
To: <txauth@= ietf.org>
Cc: "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>
Subject: [Txauth] TxAuth Pro= posed Charter

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= >Hi all,

 

As discussed= in Singapore, no matter what forum TxAuth takes, its work will require a ne= w charter. With that in mind, I=E2=80=99ve taken a bit of time to put together a p= roposed charter text for the TxAuth work:

 <= o:p>

This group is chartered to devel= op a next-generation transactional authorization and delegation protocol for= HTTP-based APIs and their clients. These transactions will allow an authori= zing party to delegate a right of access for an API or set of APIs through a= n authorization server to a software client acting on behalf of an authorizi= ng party. 

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= >The group will deliver a protocol specification detailing how a client can = request and obtain delegated access, how an authorization server can provide= delegated access, how an authorized party can authorize delegated access, a= nd how that authorized access can be communicated to the resources being pro= tected. These actions will be connected through an explicit transaction betw= een the client and authorization server, resulting in an artifact that will = allow the client to undertake the delegated action. 

 

Additionally, the delegation proc= ess will allow for:

- Fine-grained specification = of resource access

- Delegation between multiple = users

- Web, mobile, single-page, and other clien= t applications

 

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

 

- Cryptographic agility for keys, message signatures, and proof o= f possession 

- User interaction mechanisms = including web and non-web methods

- Token present= ation mechanisms and key bindings

 

The artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 and its extensions. 

 

While this= work could be done in within the OAuth working group, I now believe that it= should be done in a new working group, and that we should try to get that w= orking group up and running prior to the Vancouver meeting in March. I think= this group should stay here on the TxAuth list, and it=E2=80=99s my suggestion th= at the resulting work be called OAuth 3.0. 

=  

Why a new group? I think that the OAuth wo= rking group should remain focused on extending, patching, and adapting OAuth= 2.0 to a changing world. I plan to be engaged in both groups, and I know mo= st of you are as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so est= ablished already, there are a LOT of people who aren=E2=80=99t going to be interes= ted in something new any time soon. But on the other hand, there are a numbe= r of people for whom OAuth 2.0 does not work, or is at the very least a poor= fit, and we=E2=80=99ll want to bring them in at this early stage. So even with si= gnificant overlap, I think there=E2=80=99s enough disconnect in the community from= both sides that warrants a new group. In addition, I think this is a big en= ough piece of work that it=E2=80=99s simply too much for the OAuth working group t= o be able to focus on. We wouldn=E2=80=99t be able to get additional meeting time,= and OAuth already has trouble fitting into its two meeting slots as it is.<= o:p>

 

I=E2=80=99ve publishe= d a blog post detailing more of my rationale:

&nb= sp;

 

Please suggest changes to the proposed charter text above. It=E2=80=99s m= y hope that we can get the chartering process started.

<= div>

 

 =E2=80=94 Justin

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

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

--

----

<= /div>

Aaron Parecki

 

 

--

----

Aaron Parecki

 

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


CONFIDENTIALITY NOTICE: This email may contain confidentia= l and privileged material for the sole use of the intended recipient(s). Any= review, use, distribution or disclosure by others is strictly prohibited.&n= bsp; If you have received this communication in error, please notify the sen= der immediately by e-mail and delete the message and any file attachments fr= om your computer. Thank you.

 

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

 

= --B_3660934897_493676655-- From nobody Mon Jan 6 08: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 31FD6120889 for ; Mon, 6 Jan 2020 08:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ivX0mQWABLYb for ; Mon, 6 Jan 2020 08:08:40 -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 64121120865 for ; Mon, 6 Jan 2020 08:08:40 -0800 (PST) Received: from [192.168.1.16] (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 006G8CNr008290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jan 2020 11:08:13 -0500 From: Justin Richer Message-Id: <5D7A9B1D-20A4-4F9F-8586-BFA5CCF38B38@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_7CF80FBF-F5E6-447D-A5CE-5497353D10C3" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 6 Jan 2020 11:08:12 -0500 In-Reply-To: Cc: David Waite , Dick Hardt , "txauth@ietf.org" To: "Richard Backman, Annabelle" References: <6DFD1CA6-D334-4FCA-9881-834571A5DE7C@amazon.com> <9C6149E5-144F-442E-862E-D849A9A9FF57@alkaline-solutions.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Framework vs Protocol 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, 06 Jan 2020 16:08:43 -0000 --Apple-Mail=_7CF80FBF-F5E6-447D-A5CE-5497353D10C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t think =E2=80=9Calignment with the implicit grant=E2=80=9D = should be a goal here. I think addressing the same use cases as the = implicit grant is good, but for that we=E2=80=99ve got a lot better = tools today than we did a decade ago, and we don=E2=80=99t need to make = the same mistakes in new work just for the sake of aligning it.=20 The self-issued OP model does a decent enough job of using what tools = were there at the time to get around OIDC=E2=80=99s limitations, but I = think there=E2=80=99s a much better approach available to us here.=20 And in all truth, the answer might be =E2=80=9Csomething else = entirely=E2=80=9D. We can=E2=80=99t solve every problem and use case, = and I don=E2=80=99t think it does this work any favors to = over-generalize it at the expense of a set of things we do understand. = Grounding us like that is one of the reasons that I put the = =E2=80=9Ctransactional=E2=80=9D language in the proposed charter text. I = am proposing that we approach not just a certain set of problems but do = so in a particular way, without necessarily presuming the solution. I = think we would all want this new work to be focused on something = tractable. =E2=80=94 Justin > On Jan 3, 2020, at 1:58 PM, Richard Backman, Annabelle = wrote: >=20 > I haven=E2=80=99t seen a detailed analysis of how implicit use cases = would map onto TxAuth, so while I think you are correct I=E2=80=99m not = yet confident that the only challenges are migration related, and that = there aren=E2=80=99t still some important edge cases lurking in the = implicit space that aren=E2=80=99t well served by the TxAuth approach. > =20 > I generally agree that OIDC self-issued OP is conflating several = different problems that would be better addressed on an individual = basis. Though it does demonstrate how TxAuth=E2=80=99s dependency on a = transaction endpoint reachable by the client favors external identity = solutions over those under the direct control of the end user. > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: David Waite > Date: Friday, January 3, 2020 at 12:27 AM > To: "Richard Backman, Annabelle" > Cc: Justin Richer , Dick Hardt = , "txauth@ietf.org" > Subject: [UNVERIFIED SENDER] Re: [Txauth] Framework vs Protocol > =20 >=20 >=20 >> On Jan 2, 2020, at 5:18 PM, Richard Backman, Annabelle = > wrote: >> The current document seems to do a better job of laying out a core = message and communication pattern, but it doesn=E2=80=99t align well = with the implicit grant. We will want to dig into persistent use cases = for implicit (e.g., Brian Campbell=E2=80=99s use case in this OAuth = mailing list thread = )= to see if the TxAuth pattern can serve them, or if there are gaps that = need to be filled. > =20 > My understanding is that most complications are due to the = compatibility and migration that comes from the WG recommending against = front-channel/implicit patterns in the front channel for OAuth 2. I = don=E2=80=99t think these use cases would have been precluded in a world = where only code flow had been standardized, and where technologies to = make code flow viable at initial OAuth 2 standardization had been = available (such as CORS). Since we now live in that world and are = talking about an incompatible protocol, I don=E2=80=99t believe these = sorts of compatibility or migration considerations apply. > =20 > =20 > The only use case I know of indirectly pushing for implicit is OIDC = self-issued use case. I would instead describe this as pushing to solve = several new use cases at once: > =20 > 1. Use of a local (e.g. non-globally reachable) OP > 2. Communication when the client and the OP cannot establish direct = network communication, such as when both exist sandboxed on a local = device > 3. Defining and mandating client and OP security policy to fit into = the model of the above two points,=20 > =20 > I personally don=E2=80=99t think the mechanics self-issued OIDC = leverages (custom URL redirects and/or localhost listeners) has = appropriate security or privacy considerations. There are actually zero = security or privacy considerations regarding self-issued, which I find = somewhat disappointing. > =20 > I also know that one mobile OS vendor has explicitly recommended = against developers using custom URL schemes to solve new use cases, = strongly recommending mechanisms such as claimed HTTPS URLs be used = instead. This vendor has has also gradually increased the complexity and = restrictions for custom URL use by application developers. In my = opinion, there is risk in new use of custom URL schemes for local IPC. = It is likely not a coincidence that custom URL schemes are chosen as = they are historically the only cross-platform local IPC mechanism = without privacy controls, user consent, and and other usability = restrictions placed upon them. > =20 > It is also worth mentioning that OIDC self-issued does not have = provisions to gain authorization, which might make it difficult to = consider it in scope for this group=E2=80=99s charter. > =20 > -DW --Apple-Mail=_7CF80FBF-F5E6-447D-A5CE-5497353D10C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = don=E2=80=99t think =E2=80=9Calignment with the implicit grant=E2=80=9D = should be a goal here. I think addressing the same use cases as the = implicit grant is good, but for that we=E2=80=99ve got a lot better = tools today than we did a decade ago, and we don=E2=80=99t need to make = the same mistakes in new work just for the sake of aligning = it. 

The = self-issued OP model does a decent enough job of using what tools were = there at the time to get around OIDC=E2=80=99s limitations, but I think = there=E2=80=99s a much better approach available to us = here. 

And = in all truth, the answer might be =E2=80=9Csomething else entirely=E2=80=9D= . We can=E2=80=99t solve every problem and use case, and I don=E2=80=99t = think it does this work any favors to over-generalize it at the expense = of a set of things we do understand. Grounding us like that is one of = the reasons that I put the =E2=80=9Ctransactional=E2=80=9D language in = the proposed charter text. I am proposing that we approach not just a = certain set of problems but do so in a particular way, without = necessarily presuming the solution. I think we would all want this new = work to be focused on something tractable.

 =E2=80=94 Justin

On Jan 3, 2020, at 1:58 PM, Richard Backman, Annabelle <richanna@amazon.com>= wrote:

I = haven=E2=80=99t seen a detailed analysis of how implicit use cases would = map onto TxAuth, so while I think you are correct I=E2=80=99m not yet = confident that the only challenges are migration related, and that there = aren=E2=80=99t still some important edge cases lurking in the implicit = space that aren=E2=80=99t well served by the TxAuth approach.
 
I = generally agree that OIDC self-issued OP is conflating several different = problems that would be better addressed on an individual basis. Though = it does demonstrate how TxAuth=E2=80=99s dependency on a transaction = endpoint reachable by the client favors external identity solutions over = those under the direct control of the end user.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: David Waite <david@alkaline-solutions.com>
Date: Friday, January 3, 2020 = at 12:27 AM
To: "Richard Backman, = Annabelle" <richanna@amazon.com>
Cc: Justin Richer <jricher@mit.edu>, Dick = Hardt <dick.hardt@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: = [Txauth] Framework vs Protocol
 


On Jan 2, 2020, at 5:18 PM, Richard = Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
The current document seems to do a = better job of laying out a core message and communication pattern, but = it doesn=E2=80=99t align well with the implicit grant. We will want to = dig into persistent use cases for implicit (e.g., Brian Campbell=E2=80=99s= use case in this OAuth mailing = list thread) to see if the TxAuth pattern can serve them, or = if there are gaps that need to be filled.
 
My understanding is that most = complications are due to the compatibility and migration that comes from = the WG recommending against front-channel/implicit patterns in the front = channel for OAuth 2. I don=E2=80=99t think these use cases would = have been precluded in a world where only code flow had been = standardized, and where technologies to make code flow viable at initial = OAuth 2 standardization had been available (such as CORS). Since we now = live in that world and are talking about an incompatible protocol, I = don=E2=80=99t believe these sorts of compatibility or migration = considerations apply.
 
 
The only use case I know of indirectly = pushing for implicit is OIDC self-issued use case. I would instead = describe this as pushing to solve several new use cases at once:
 
1. Use of a = local (e.g. non-globally reachable) OP
2. Communication when the client and the OP cannot establish = direct network communication, such as when both exist sandboxed on a = local device
3. Defining and mandating client and OP = security policy to fit into the model of the above two points, 
 
I personally don=E2=80=99t think the = mechanics self-issued OIDC leverages (custom URL redirects and/or = localhost listeners) has appropriate security or privacy considerations. = There are actually zero security or privacy considerations regarding = self-issued, which I find somewhat disappointing.
 
I also know that one mobile OS vendor = has explicitly recommended against developers using custom URL schemes = to solve new use cases, strongly recommending mechanisms such as claimed = HTTPS URLs be used instead. This vendor has has also gradually increased = the complexity and restrictions for custom URL use by application = developers. In my opinion, there is risk in new use of custom URL = schemes for local IPC. It is likely not a coincidence that custom URL = schemes are chosen as they are historically the only cross-platform = local IPC mechanism without privacy controls, user consent, and and = other usability restrictions placed upon them.
 
It is also worth mentioning that OIDC = self-issued does not have provisions to gain authorization, which might = make it difficult to consider it in scope for this group=E2=80=99s = charter.
 
-DW

= --Apple-Mail=_7CF80FBF-F5E6-447D-A5CE-5497353D10C3-- From nobody Mon Jan 6 13:34: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 735C412007A for ; Mon, 6 Jan 2020 13:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.368 X-Spam-Level: X-Spam-Status: No, score=-0.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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_NONE=-0.0001, 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 f1J--gmhCKxz for ; Mon, 6 Jan 2020 13:34:07 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90EFC1208CE for ; Mon, 6 Jan 2020 13:34:06 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id m30so37346178lfp.8 for ; Mon, 06 Jan 2020 13:34:06 -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=pnw8i/2J1lfGnNniO/gfUPQqLaLb9TzNdwsjYTblMcI=; b=cG5SV4nFGJw8LnjjUbuS1+j8L3A0Y0Y3NQj+DDlH++8dQ7ezfruPEZBFD4FXG0DfwM Ku72gbLKAJ4oiEqCFZJQKHhWifOcPuAtBoTsHtkGAvl9l6nfdoCiW5CTq18AZ3tviUSR UWLvJLipAaSy1ko1mNr1CFF5OOmrc87v8gwnGmeoasjORqde44N+d+PMVGNypgGUdJFi NJ4sdYcolgHr5E6g817blQT14giWohENIuAoW0EQU1bGkwG6pLtz/GT9wBqmEKR9h4Ao C/df2eor3jqEck6PWDbihOFw6avsN0aBLDkIolNbbd641sJ0kFVZSMyd0FHRNeSH3KrX bsiA== 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=pnw8i/2J1lfGnNniO/gfUPQqLaLb9TzNdwsjYTblMcI=; b=U+uutAYfyV0xdZrY5oQm364Oh+HBndvHGoT9NbyqcBn6Yjq1UryQrBZQhrYFNvZiYz HA53gVx4NeGXcr9RDdJIg51dauyrzmMRUIQzP5oa5AwUsA0GjgUlnGa2vl8Hnpfbcu/b 2fqkzRuf5qQo9+mPHxu5mk0kKWoLc4h5jJkJhqyB3Rk2+y924p8qIeug7KD47N2FpflL mmVHznZtQdVheM8ASwyk0Prgc0rAM5qVxufJAu61AS5AHS2b8X91nslXfmVjgyP4wDeE ufwfkQ3Qj6Y0o0ANdrMHiWcNe+1JygQxMZAmOhwPsJEp4Fwx65pRxnD2BQ193/8I0X6T G/wA== X-Gm-Message-State: APjAAAUZXVGmmdnXcGQjJ3ZNY25de4eMZtxb2ieTtOdXrQpjrSgSuPQ6 yZXkMF/RZv2o2Jy26HDc90N9XtRfv5A2dzBEgxk= X-Google-Smtp-Source: APXvYqyhGghh0g1Hyu1iKvP4GtdgMAWPvQzAilaU/Y2VuWo0ukpSm4gXiamRZapAHo/yNL17rzho1kDwclojKttlI7k= X-Received: by 2002:a19:5057:: with SMTP id z23mr56921952lfj.132.1578346444723; Mon, 06 Jan 2020 13:34:04 -0800 (PST) MIME-Version: 1.0 References: <6DFD1CA6-D334-4FCA-9881-834571A5DE7C@amazon.com> <9C6149E5-144F-442E-862E-D849A9A9FF57@alkaline-solutions.com> <5D7A9B1D-20A4-4F9F-8586-BFA5CCF38B38@mit.edu> In-Reply-To: <5D7A9B1D-20A4-4F9F-8586-BFA5CCF38B38@mit.edu> From: Dick Hardt Date: Mon, 6 Jan 2020 13:33:53 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , David Waite , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002b99aa059b7f6b3c" Archived-At: Subject: [Txauth] Is it a transaction? (was Framework vs Protocol) 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, 06 Jan 2020 21:34:09 -0000 --0000000000002b99aa059b7f6b3c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 6, 2020 at 8:08 AM Justin Richer wrote: > > And in all truth, the answer might be =E2=80=9Csomething else entirely=E2= =80=9D. We can=E2=80=99t > solve every problem and use case, and I don=E2=80=99t think it does this = work any > favors to over-generalize it at the expense of a set of things we do > understand. Grounding us like that is one of the reasons that I put the > =E2=80=9Ctransactional=E2=80=9D language in the proposed charter text. I = am proposing that > we approach not just a certain set of problems but do so in a particular > way, without necessarily presuming the solution. I think we would all wan= t > this new work to be focused on something tractable. > I completely agree we don't want to solve every problem and use case, and we need to scope the problem space in some way. As I've thought about the term "transaction", it seems to be a misnomer, particularly when database semantics are applied, where a transaction is all or nothing. As I understand it, we would like the client to request scoped access to multiple resources. Not all of the request is required, which is not aligned with the definition of transaction above. Additionally, in the XYZ draft, the transaction handle is used to refresh tokens. I would consider this a new interaction, as the AS will be running policy again, and the refresh may be denied. I don't have a better suggestion at this time, but "transaction" does not quite seem right. /Dick =E1=90=A7 --0000000000002b99aa059b7f6b3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Jan 6, 2020 at 8:08 AM Justin Ric= her <jricher@mit.edu> wrote:
<snip>
And in all truth, the answ= er might be =E2=80=9Csomething else entirely=E2=80=9D. We can=E2=80=99t sol= ve every problem and use case, and I don=E2=80=99t think it does this work = any favors to over-generalize it at the expense of a set of things we do un= derstand. Grounding us like that is one of the reasons that I put the =E2= =80=9Ctransactional=E2=80=9D language in the proposed charter text. I am pr= oposing that we approach not just a certain set of problems but do so in a = particular way, without necessarily presuming the solution. I think we woul= d all want this new work to be focused on something tractable.
<= /blockquote>
=C2=A0
I completely agree we don't want to s= olve every problem and use case, and we need to scope the problem space in = some=C2=A0way.

As I've thought about the term = "transaction", it seems to be a misnomer, particularly when datab= ase semantics are applied, where a transaction is all or nothing.=C2=A0

As I understand it, we would like the client to reque= st scoped access to multiple=C2=A0resources. Not all of the request is requ= ired, which is not aligned with the definition of transaction above.=C2=A0<= /div>

Additionally, in the XYZ draft, the transaction ha= ndle is used to refresh tokens. I would consider this a new interaction, as= the AS will be running policy again, and the refresh may be denied.=C2=A0<= /div>

I don't have a better suggestion at this time,= but "transaction" does not quite seem right.

/Dick
3D""=E1=90=A7
--0000000000002b99aa059b7f6b3c-- From nobody Mon Jan 6 16:13: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 E50111200CE for ; Mon, 6 Jan 2020 16:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.799 X-Spam-Level: X-Spam-Status: No, score=-11.799 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 cq0LnT4d42_D for ; Mon, 6 Jan 2020 16:13:18 -0800 (PST) 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 C9ADF120110 for ; Mon, 6 Jan 2020 16:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578355999; x=1609891999; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OBH2YdK0BE2vkU1/hzcNgUnfmvidpTXfWOqtAZKB4GA=; b=DzPbFbFffMZpE2mJdrCsxCri/PXy9Hryh3tgwra1ouUfKy2VZA8odgQ3 RVerhAhukKU1w004bcBDQeFUuR0MLJcsSsnliGQtBSX86ruL53U+fSXFK h3kw/UYhQmX7Kg6h2Hy4BDWjVmaw7UbN5ZjKRxNCZ4/SiyDoid6UiE9w8 o=; IronPort-SDR: P69gbT4WghSkRznOtw3q5dh/RqpNDleUpFWpXFl7QARNzjcr1KFQ7nxYqlTvviPhULa5jjUoD9 RaNlj6dupJ+g== X-IronPort-AV: E=Sophos; i="5.69,404,1571702400"; d="scan'208,217"; a="18485066" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2a-53356bf6.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 07 Jan 2020 00:13:08 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2a-53356bf6.us-west-2.amazon.com (Postfix) with ESMTPS id 9E3E4A1F32; Tue, 7 Jan 2020 00:13:07 +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; Tue, 7 Jan 2020 00:13:07 +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.1367.3; Tue, 7 Jan 2020 00:13:06 +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.1367.000; Tue, 7 Jan 2020 00:13:07 +0000 From: "Richard Backman, Annabelle" To: Justin Richer CC: David Waite , Dick Hardt , "txauth@ietf.org" Thread-Topic: [UNVERIFIED SENDER] [Txauth] Framework vs Protocol Thread-Index: AQHVxKuwvx7sdbqHo0exP9TrHF7HKafdzwQA Date: Tue, 7 Jan 2020 00:13:06 +0000 Message-ID: <2E95304B-66B0-4D28-B56F-EF1B313F4BB9@amazon.com> References: <6DFD1CA6-D334-4FCA-9881-834571A5DE7C@amazon.com> <9C6149E5-144F-442E-862E-D849A9A9FF57@alkaline-solutions.com> <5D7A9B1D-20A4-4F9F-8586-BFA5CCF38B38@mit.edu> In-Reply-To: <5D7A9B1D-20A4-4F9F-8586-BFA5CCF38B38@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.118] Content-Type: multipart/alternative; boundary="_000_2E95304B66B04D28B56FEF1B313F4BB9amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Framework vs Protocol 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, 07 Jan 2020 00:13:21 -0000 --_000_2E95304B66B04D28B56FEF1B313F4BB9amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXTigJlzIG5vdCBhYm91dCBhbGlnbmluZyB3aXRoIGltcGxpY2l0IGdyYW50IChJIGFncmVlIHRo YXQgc2hvdWxkIG5vdCBiZSBhIGdvYWwpLCBpdOKAmXMgYWJvdXQgZW5zdXJpbmcgdGhhdCB0aGUg dXNlIGNhc2VzIGJlaW5nIHNlcnZlZCBieSBpbXBsaWNpdCBncmFudCB0b2RheSBjYW4gYmUgbWV0 IGJ5IFR4QXV0aCBvciBjYW4gYmUgZGlzbWlzc2VkIGFzIG91dCBvZiBzY29wZSwgYW5kIGJlaW5n IGludGVudGlvbmFsIGFib3V0IGFueSBkZWNpc2lvbnMgdG93YXJkIHRoZSBsYXR0ZXIuDQoNCuKA kw0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogSnVz dGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1Pg0KRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDYsIDIw MjAgYXQgODowOSBBTQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5h QGFtYXpvbi5jb20+DQpDYzogRGF2aWQgV2FpdGUgPGRhdmlkQGFsa2FsaW5lLXNvbHV0aW9ucy5j b20+LCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT4sICJ0eGF1dGhAaWV0Zi5vcmci IDx0eGF1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1VOVkVSSUZJRUQgU0VOREVSXSBbVHhh dXRoXSBGcmFtZXdvcmsgdnMgUHJvdG9jb2wNCg0KSSBkb27igJl0IHRoaW5rIOKAnGFsaWdubWVu dCB3aXRoIHRoZSBpbXBsaWNpdCBncmFudOKAnSBzaG91bGQgYmUgYSBnb2FsIGhlcmUuIEkgdGhp bmsgYWRkcmVzc2luZyB0aGUgc2FtZSB1c2UgY2FzZXMgYXMgdGhlIGltcGxpY2l0IGdyYW50IGlz IGdvb2QsIGJ1dCBmb3IgdGhhdCB3ZeKAmXZlIGdvdCBhIGxvdCBiZXR0ZXIgdG9vbHMgdG9kYXkg dGhhbiB3ZSBkaWQgYSBkZWNhZGUgYWdvLCBhbmQgd2UgZG9u4oCZdCBuZWVkIHRvIG1ha2UgdGhl IHNhbWUgbWlzdGFrZXMgaW4gbmV3IHdvcmsganVzdCBmb3IgdGhlIHNha2Ugb2YgYWxpZ25pbmcg aXQuDQoNClRoZSBzZWxmLWlzc3VlZCBPUCBtb2RlbCBkb2VzIGEgZGVjZW50IGVub3VnaCBqb2Ig b2YgdXNpbmcgd2hhdCB0b29scyB3ZXJlIHRoZXJlIGF0IHRoZSB0aW1lIHRvIGdldCBhcm91bmQg T0lEQ+KAmXMgbGltaXRhdGlvbnMsIGJ1dCBJIHRoaW5rIHRoZXJl4oCZcyBhIG11Y2ggYmV0dGVy IGFwcHJvYWNoIGF2YWlsYWJsZSB0byB1cyBoZXJlLg0KDQpBbmQgaW4gYWxsIHRydXRoLCB0aGUg YW5zd2VyIG1pZ2h0IGJlIOKAnHNvbWV0aGluZyBlbHNlIGVudGlyZWx54oCdLiBXZSBjYW7igJl0 IHNvbHZlIGV2ZXJ5IHByb2JsZW0gYW5kIHVzZSBjYXNlLCBhbmQgSSBkb27igJl0IHRoaW5rIGl0 IGRvZXMgdGhpcyB3b3JrIGFueSBmYXZvcnMgdG8gb3Zlci1nZW5lcmFsaXplIGl0IGF0IHRoZSBl eHBlbnNlIG9mIGEgc2V0IG9mIHRoaW5ncyB3ZSBkbyB1bmRlcnN0YW5kLiBHcm91bmRpbmcgdXMg bGlrZSB0aGF0IGlzIG9uZSBvZiB0aGUgcmVhc29ucyB0aGF0IEkgcHV0IHRoZSDigJx0cmFuc2Fj dGlvbmFs4oCdIGxhbmd1YWdlIGluIHRoZSBwcm9wb3NlZCBjaGFydGVyIHRleHQuIEkgYW0gcHJv cG9zaW5nIHRoYXQgd2UgYXBwcm9hY2ggbm90IGp1c3QgYSBjZXJ0YWluIHNldCBvZiBwcm9ibGVt cyBidXQgZG8gc28gaW4gYSBwYXJ0aWN1bGFyIHdheSwgd2l0aG91dCBuZWNlc3NhcmlseSBwcmVz dW1pbmcgdGhlIHNvbHV0aW9uLiBJIHRoaW5rIHdlIHdvdWxkIGFsbCB3YW50IHRoaXMgbmV3IHdv cmsgdG8gYmUgZm9jdXNlZCBvbiBzb21ldGhpbmcgdHJhY3RhYmxlLg0KDQog4oCUIEp1c3Rpbg0K DQoNCk9uIEphbiAzLCAyMDIwLCBhdCAxOjU4IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxs ZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3Rl Og0KDQpJIGhhdmVu4oCZdCBzZWVuIGEgZGV0YWlsZWQgYW5hbHlzaXMgb2YgaG93IGltcGxpY2l0 IHVzZSBjYXNlcyB3b3VsZCBtYXAgb250byBUeEF1dGgsIHNvIHdoaWxlIEkgdGhpbmsgeW91IGFy ZSBjb3JyZWN0IEnigJltIG5vdCB5ZXQgY29uZmlkZW50IHRoYXQgdGhlIG9ubHkgY2hhbGxlbmdl cyBhcmUgbWlncmF0aW9uIHJlbGF0ZWQsIGFuZCB0aGF0IHRoZXJlIGFyZW7igJl0IHN0aWxsIHNv bWUgaW1wb3J0YW50IGVkZ2UgY2FzZXMgbHVya2luZyBpbiB0aGUgaW1wbGljaXQgc3BhY2UgdGhh dCBhcmVu4oCZdCB3ZWxsIHNlcnZlZCBieSB0aGUgVHhBdXRoIGFwcHJvYWNoLg0KDQpJIGdlbmVy YWxseSBhZ3JlZSB0aGF0IE9JREMgc2VsZi1pc3N1ZWQgT1AgaXMgY29uZmxhdGluZyBzZXZlcmFs IGRpZmZlcmVudCBwcm9ibGVtcyB0aGF0IHdvdWxkIGJlIGJldHRlciBhZGRyZXNzZWQgb24gYW4g aW5kaXZpZHVhbCBiYXNpcy4gVGhvdWdoIGl0IGRvZXMgZGVtb25zdHJhdGUgaG93IFR4QXV0aOKA mXMgZGVwZW5kZW5jeSBvbiBhIHRyYW5zYWN0aW9uIGVuZHBvaW50IHJlYWNoYWJsZSBieSB0aGUg Y2xpZW50IGZhdm9ycyBleHRlcm5hbCBpZGVudGl0eSBzb2x1dGlvbnMgb3ZlciB0aG9zZSB1bmRl ciB0aGUgZGlyZWN0IGNvbnRyb2wgb2YgdGhlIGVuZCB1c2VyLg0KDQrigJMNCkFubmFiZWxsZSBS aWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IERhdmlkIFdhaXRlIDxkYXZp ZEBhbGthbGluZS1zb2x1dGlvbnMuY29tPG1haWx0bzpkYXZpZEBhbGthbGluZS1zb2x1dGlvbnMu Y29tPj4NCkRhdGU6IEZyaWRheSwgSmFudWFyeSAzLCAyMDIwIGF0IDEyOjI3IEFNDQpUbzogIlJp Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmlj aGFubmFAYW1hem9uLmNvbT4+DQpDYzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1h aWx0bzpqcmljaGVyQG1pdC5lZHU+PiwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208 bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4sICJ0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4 YXV0aEBpZXRmLm9yZz4iIDx0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBpZXRmLm9yZz4+ DQpTdWJqZWN0OiBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbVHhhdXRoXSBGcmFtZXdvcmsgdnMg UHJvdG9jb2wNCg0KDQoNCg0KT24gSmFuIDIsIDIwMjAsIGF0IDU6MTggUE0sIFJpY2hhcmQgQmFj a21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFp bHRvOnJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KVGhlIGN1 cnJlbnQgZG9jdW1lbnQgc2VlbXMgdG8gZG8gYSBiZXR0ZXIgam9iIG9mIGxheWluZyBvdXQgYSBj b3JlIG1lc3NhZ2UgYW5kIGNvbW11bmljYXRpb24gcGF0dGVybiwgYnV0IGl0IGRvZXNu4oCZdCBh bGlnbiB3ZWxsIHdpdGggdGhlIGltcGxpY2l0IGdyYW50LiBXZSB3aWxsIHdhbnQgdG8gZGlnIGlu dG8gcGVyc2lzdGVudCB1c2UgY2FzZXMgZm9yIGltcGxpY2l0IChlLmcuLCBCcmlhbiBDYW1wYmVs bOKAmXMgdXNlIGNhc2UgaW4gdGhpcyBPQXV0aCBtYWlsaW5nIGxpc3QgdGhyZWFkPGh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvUnVjWkhLdVJmNkhDc1dVeUpESzBY Und1YjN3PikgdG8gc2VlIGlmIHRoZSBUeEF1dGggcGF0dGVybiBjYW4gc2VydmUgdGhlbSwgb3Ig aWYgdGhlcmUgYXJlIGdhcHMgdGhhdCBuZWVkIHRvIGJlIGZpbGxlZC4NCg0KTXkgdW5kZXJzdGFu ZGluZyBpcyB0aGF0IG1vc3QgY29tcGxpY2F0aW9ucyBhcmUgZHVlIHRvIHRoZSBjb21wYXRpYmls aXR5IGFuZCBtaWdyYXRpb24gdGhhdCBjb21lcyBmcm9tIHRoZSBXRyByZWNvbW1lbmRpbmcgYWdh aW5zdCBmcm9udC1jaGFubmVsL2ltcGxpY2l0IHBhdHRlcm5zIGluIHRoZSBmcm9udCBjaGFubmVs IGZvciBPQXV0aCAyLiBJIGRvbuKAmXQgdGhpbmsgdGhlc2UgdXNlIGNhc2VzIHdvdWxkIGhhdmUg YmVlbiBwcmVjbHVkZWQgaW4gYSB3b3JsZCB3aGVyZSBvbmx5IGNvZGUgZmxvdyBoYWQgYmVlbiBz dGFuZGFyZGl6ZWQsIGFuZCB3aGVyZSB0ZWNobm9sb2dpZXMgdG8gbWFrZSBjb2RlIGZsb3cgdmlh YmxlIGF0IGluaXRpYWwgT0F1dGggMiBzdGFuZGFyZGl6YXRpb24gaGFkIGJlZW4gYXZhaWxhYmxl IChzdWNoIGFzIENPUlMpLiBTaW5jZSB3ZSBub3cgbGl2ZSBpbiB0aGF0IHdvcmxkIGFuZCBhcmUg dGFsa2luZyBhYm91dCBhbiBpbmNvbXBhdGlibGUgcHJvdG9jb2wsIEkgZG9u4oCZdCBiZWxpZXZl IHRoZXNlIHNvcnRzIG9mIGNvbXBhdGliaWxpdHkgb3IgbWlncmF0aW9uIGNvbnNpZGVyYXRpb25z IGFwcGx5Lg0KDQoNClRoZSBvbmx5IHVzZSBjYXNlIEkga25vdyBvZiBpbmRpcmVjdGx5IHB1c2hp bmcgZm9yIGltcGxpY2l0IGlzIE9JREMgc2VsZi1pc3N1ZWQgdXNlIGNhc2UuIEkgd291bGQgaW5z dGVhZCBkZXNjcmliZSB0aGlzIGFzIHB1c2hpbmcgdG8gc29sdmUgc2V2ZXJhbCBuZXcgdXNlIGNh c2VzIGF0IG9uY2U6DQoNCjEuIFVzZSBvZiBhIGxvY2FsIChlLmcuIG5vbi1nbG9iYWxseSByZWFj aGFibGUpIE9QDQoyLiBDb21tdW5pY2F0aW9uIHdoZW4gdGhlIGNsaWVudCBhbmQgdGhlIE9QIGNh bm5vdCBlc3RhYmxpc2ggZGlyZWN0IG5ldHdvcmsgY29tbXVuaWNhdGlvbiwgc3VjaCBhcyB3aGVu IGJvdGggZXhpc3Qgc2FuZGJveGVkIG9uIGEgbG9jYWwgZGV2aWNlDQozLiBEZWZpbmluZyBhbmQg bWFuZGF0aW5nIGNsaWVudCBhbmQgT1Agc2VjdXJpdHkgcG9saWN5IHRvIGZpdCBpbnRvIHRoZSBt b2RlbCBvZiB0aGUgYWJvdmUgdHdvIHBvaW50cywNCg0KSSBwZXJzb25hbGx5IGRvbuKAmXQgdGhp bmsgdGhlIG1lY2hhbmljcyBzZWxmLWlzc3VlZCBPSURDIGxldmVyYWdlcyAoY3VzdG9tIFVSTCBy ZWRpcmVjdHMgYW5kL29yIGxvY2FsaG9zdCBsaXN0ZW5lcnMpIGhhcyBhcHByb3ByaWF0ZSBzZWN1 cml0eSBvciBwcml2YWN5IGNvbnNpZGVyYXRpb25zLiBUaGVyZSBhcmUgYWN0dWFsbHkgemVybyBz ZWN1cml0eSBvciBwcml2YWN5IGNvbnNpZGVyYXRpb25zIHJlZ2FyZGluZyBzZWxmLWlzc3VlZCwg d2hpY2ggSSBmaW5kIHNvbWV3aGF0IGRpc2FwcG9pbnRpbmcuDQoNCkkgYWxzbyBrbm93IHRoYXQg b25lIG1vYmlsZSBPUyB2ZW5kb3IgaGFzIGV4cGxpY2l0bHkgcmVjb21tZW5kZWQgYWdhaW5zdCBk ZXZlbG9wZXJzIHVzaW5nIGN1c3RvbSBVUkwgc2NoZW1lcyB0byBzb2x2ZSBuZXcgdXNlIGNhc2Vz LCBzdHJvbmdseSByZWNvbW1lbmRpbmcgbWVjaGFuaXNtcyBzdWNoIGFzIGNsYWltZWQgSFRUUFMg VVJMcyBiZSB1c2VkIGluc3RlYWQuIFRoaXMgdmVuZG9yIGhhcyBoYXMgYWxzbyBncmFkdWFsbHkg aW5jcmVhc2VkIHRoZSBjb21wbGV4aXR5IGFuZCByZXN0cmljdGlvbnMgZm9yIGN1c3RvbSBVUkwg dXNlIGJ5IGFwcGxpY2F0aW9uIGRldmVsb3BlcnMuIEluIG15IG9waW5pb24sIHRoZXJlIGlzIHJp c2sgaW4gbmV3IHVzZSBvZiBjdXN0b20gVVJMIHNjaGVtZXMgZm9yIGxvY2FsIElQQy4gSXQgaXMg bGlrZWx5IG5vdCBhIGNvaW5jaWRlbmNlIHRoYXQgY3VzdG9tIFVSTCBzY2hlbWVzIGFyZSBjaG9z ZW4gYXMgdGhleSBhcmUgaGlzdG9yaWNhbGx5IHRoZSBvbmx5IGNyb3NzLXBsYXRmb3JtIGxvY2Fs IElQQyBtZWNoYW5pc20gd2l0aG91dCBwcml2YWN5IGNvbnRyb2xzLCB1c2VyIGNvbnNlbnQsIGFu ZCBhbmQgb3RoZXIgdXNhYmlsaXR5IHJlc3RyaWN0aW9ucyBwbGFjZWQgdXBvbiB0aGVtLg0KDQpJ dCBpcyBhbHNvIHdvcnRoIG1lbnRpb25pbmcgdGhhdCBPSURDIHNlbGYtaXNzdWVkIGRvZXMgbm90 IGhhdmUgcHJvdmlzaW9ucyB0byBnYWluIGF1dGhvcml6YXRpb24sIHdoaWNoIG1pZ2h0IG1ha2Ug aXQgZGlmZmljdWx0IHRvIGNvbnNpZGVyIGl0IGluIHNjb3BlIGZvciB0aGlzIGdyb3Vw4oCZcyBj aGFydGVyLg0KDQotRFcNCg0K --_000_2E95304B66B04D28B56FEF1B313F4BB9amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SXTigJlzIG5vdCBhYm91dCBhbGlnbmluZyB3aXRoIGltcGxpY2l0IGdyYW50IChJIGFncmVlIHRo YXQgc2hvdWxkIG5vdCBiZSBhIGdvYWwpLCBpdOKAmXMgYWJvdXQgZW5zdXJpbmcgdGhhdCB0aGUg dXNlIGNhc2VzIGJlaW5nIHNlcnZlZCBieSBpbXBsaWNpdCBncmFudCB0b2RheSBjYW4gYmUgbWV0 IGJ5IFR4QXV0aCBvciBjYW4gYmUgZGlzbWlzc2VkIGFzIG91dCBvZiBzY29wZSwgYW5kIGJlaW5n IGludGVudGlvbmFsDQogYWJvdXQgYW55IGRlY2lzaW9ucyB0b3dhcmQgdGhlIGxhdHRlci48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij7igJMmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+SnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEphbnVhcnkgNiwgMjAyMCBhdCA4OjA5IEFNPGJyPg0K PGI+VG86IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmlj aGFubmFAYW1hem9uLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPkRhdmlkIFdhaXRlICZsdDtkYXZp ZEBhbGthbGluZS1zb2x1dGlvbnMuY29tJmd0OywgRGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBn bWFpbC5jb20mZ3Q7LCAmcXVvdDt0eGF1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O3R4YXV0aEBpZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtVTlZFUklGSUVEIFNFTkRFUl0gW1R4 YXV0aF0gRnJhbWV3b3JrIHZzIFByb3RvY29sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCB0aGluayDigJxhbGlnbm1lbnQgd2l0 aCB0aGUgaW1wbGljaXQgZ3JhbnTigJ0gc2hvdWxkIGJlIGEgZ29hbCBoZXJlLiBJIHRoaW5rIGFk ZHJlc3NpbmcgdGhlIHNhbWUgdXNlIGNhc2VzIGFzIHRoZSBpbXBsaWNpdCBncmFudCBpcyBnb29k LCBidXQgZm9yIHRoYXQgd2XigJl2ZSBnb3QgYSBsb3QgYmV0dGVyIHRvb2xzIHRvZGF5IHRoYW4g d2UgZGlkIGEgZGVjYWRlIGFnbywgYW5kIHdlIGRvbuKAmXQgbmVlZCB0bw0KIG1ha2UgdGhlIHNh bWUgbWlzdGFrZXMgaW4gbmV3IHdvcmsganVzdCBmb3IgdGhlIHNha2Ugb2YgYWxpZ25pbmcgaXQu Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IHNlbGYtaXNzdWVkIE9QIG1vZGVsIGRvZXMgYSBkZWNlbnQgZW5vdWdoIGpvYiBvZiB1c2luZyB3 aGF0IHRvb2xzIHdlcmUgdGhlcmUgYXQgdGhlIHRpbWUgdG8gZ2V0IGFyb3VuZCBPSURD4oCZcyBs aW1pdGF0aW9ucywgYnV0IEkgdGhpbmsgdGhlcmXigJlzIGEgbXVjaCBiZXR0ZXIgYXBwcm9hY2gg YXZhaWxhYmxlIHRvIHVzIGhlcmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBpbiBhbGwgdHJ1dGgsIHRoZSBhbnN3ZXIgbWln aHQgYmUg4oCcc29tZXRoaW5nIGVsc2UgZW50aXJlbHnigJ0uIFdlIGNhbuKAmXQgc29sdmUgZXZl cnkgcHJvYmxlbSBhbmQgdXNlIGNhc2UsIGFuZCBJIGRvbuKAmXQgdGhpbmsgaXQgZG9lcyB0aGlz IHdvcmsgYW55IGZhdm9ycyB0byBvdmVyLWdlbmVyYWxpemUgaXQgYXQgdGhlIGV4cGVuc2Ugb2Yg YSBzZXQgb2YgdGhpbmdzIHdlIGRvIHVuZGVyc3RhbmQuIEdyb3VuZGluZw0KIHVzIGxpa2UgdGhh dCBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgdGhhdCBJIHB1dCB0aGUg4oCcdHJhbnNhY3Rpb25hbOKA nSBsYW5ndWFnZSBpbiB0aGUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0LiBJIGFtIHByb3Bvc2luZyB0 aGF0IHdlIGFwcHJvYWNoIG5vdCBqdXN0IGEgY2VydGFpbiBzZXQgb2YgcHJvYmxlbXMgYnV0IGRv IHNvIGluIGEgcGFydGljdWxhciB3YXksIHdpdGhvdXQgbmVjZXNzYXJpbHkgcHJlc3VtaW5nIHRo ZSBzb2x1dGlvbi4gSSB0aGluayB3ZQ0KIHdvdWxkIGFsbCB3YW50IHRoaXMgbmV3IHdvcmsgdG8g YmUgZm9jdXNlZCBvbiBzb21ldGhpbmcgdHJhY3RhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDvigJQgSnVzdGluPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKYW4gMywgMjAyMCwgYXQg MTo1OCBQTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpy aWNoYW5uYUBhbWF6b24uY29tIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmVu4oCZdCBz ZWVuIGEgZGV0YWlsZWQgYW5hbHlzaXMgb2YgaG93IGltcGxpY2l0IHVzZSBjYXNlcyB3b3VsZCBt YXAgb250byBUeEF1dGgsIHNvIHdoaWxlIEkgdGhpbmsgeW91IGFyZSBjb3JyZWN0IEnigJltIG5v dCB5ZXQgY29uZmlkZW50IHRoYXQgdGhlIG9ubHkgY2hhbGxlbmdlcyBhcmUgbWlncmF0aW9uIHJl bGF0ZWQsIGFuZCB0aGF0IHRoZXJlIGFyZW7igJl0IHN0aWxsIHNvbWUgaW1wb3J0YW50IGVkZ2Ug Y2FzZXMNCiBsdXJraW5nIGluIHRoZSBpbXBsaWNpdCBzcGFjZSB0aGF0IGFyZW7igJl0IHdlbGwg c2VydmVkIGJ5IHRoZSBUeEF1dGggYXBwcm9hY2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZ2VuZXJhbGx5IGFncmVlIHRoYXQgT0lEQyBz ZWxmLWlzc3VlZCBPUCBpcyBjb25mbGF0aW5nIHNldmVyYWwgZGlmZmVyZW50IHByb2JsZW1zIHRo YXQgd291bGQgYmUgYmV0dGVyIGFkZHJlc3NlZCBvbiBhbiBpbmRpdmlkdWFsIGJhc2lzLiBUaG91 Z2ggaXQgZG9lcyBkZW1vbnN0cmF0ZSBob3cgVHhBdXRo4oCZcyBkZXBlbmRlbmN5IG9uIGEgdHJh bnNhY3Rpb24gZW5kcG9pbnQgcmVhY2hhYmxlIGJ5IHRoZSBjbGllbnQNCiBmYXZvcnMgZXh0ZXJu YWwgaWRlbnRpdHkgc29sdXRpb25zIG92ZXIgdGhvc2UgdW5kZXIgdGhlIGRpcmVjdCBjb250cm9s IG9mIHRoZSBlbmQgdXNlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJMm bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJlbGxlIFJpY2hhcmQg QmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RGF2 aWQgV2FpdGUgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZEBhbGthbGluZS1zb2x1dGlvbnMuY29t Ij5kYXZpZEBhbGthbGluZS1zb2x1dGlvbnMuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+RnJpZGF5LCBK YW51YXJ5IDMsIDIwMjAgYXQgMTI6MjcgQU08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPiZxdW90O1JpY2hhcmQgQmFja21hbiwg QW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSI+ cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5KdXN0aW4gUmljaGVyICZsdDs8YSBo cmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1Ij5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OywgRGlj ayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj5kaWNrLmhh cmR0QGdtYWlsLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86dHhhdXRoQGlldGYu b3JnIj50eGF1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dHhhdXRo QGlldGYub3JnIj50eGF1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5bVU5WRVJJRklF RCBTRU5ERVJdIFJlOiBbVHhhdXRoXSBGcmFtZXdvcmsgdnMgUHJvdG9jb2w8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSmFuIDIsIDIw MjAsIGF0IDU6MTggUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJt YWlsdG86cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5yaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L3NwYW4+ PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGN1cnJlbnQgZG9jdW1lbnQgc2Vl bXMgdG8gZG8gYSBiZXR0ZXIgam9iIG9mIGxheWluZyBvdXQgYSBjb3JlIG1lc3NhZ2UgYW5kIGNv bW11bmljYXRpb24gcGF0dGVybiwgYnV0IGl0IGRvZXNu4oCZdCBhbGlnbiB3ZWxsIHdpdGggdGhl IGltcGxpY2l0IGdyYW50LiBXZSB3aWxsIHdhbnQgdG8gZGlnIGludG8gcGVyc2lzdGVudCB1c2Ug Y2FzZXMgZm9yIGltcGxpY2l0IChlLmcuLCBCcmlhbiBDYW1wYmVsbOKAmXMNCiB1c2UgY2FzZSBp bjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVm PSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoL1J1Y1pIS3VSZjZI Q3NXVXlKREswWFJ3dWIzdyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dGhpcyBPQXV0aCBt YWlsaW5nIGxpc3QgdGhyZWFkPC9zcGFuPjwvYT4pIHRvIHNlZSBpZiB0aGUgVHhBdXRoIHBhdHRl cm4gY2FuIHNlcnZlIHRoZW0sIG9yIGlmDQogdGhlcmUgYXJlIGdhcHMgdGhhdCBuZWVkIHRvIGJl IGZpbGxlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IHVu ZGVyc3RhbmRpbmcgaXMgdGhhdCBtb3N0IGNvbXBsaWNhdGlvbnMgYXJlIGR1ZSB0byB0aGUgY29t cGF0aWJpbGl0eSBhbmQgbWlncmF0aW9uIHRoYXQgY29tZXMgZnJvbSB0aGUgV0cgcmVjb21tZW5k aW5nIGFnYWluc3QgZnJvbnQtY2hhbm5lbC9pbXBsaWNpdCBwYXR0ZXJucyBpbiB0aGUgZnJvbnQg Y2hhbm5lbCBmb3IgT0F1dGggMi4mbmJzcDtJIGRvbuKAmXQgdGhpbmsgdGhlc2UgdXNlIGNhc2Vz IHdvdWxkIGhhdmUNCiBiZWVuIHByZWNsdWRlZCBpbiBhIHdvcmxkIHdoZXJlIG9ubHkgY29kZSBm bG93IGhhZCBiZWVuIHN0YW5kYXJkaXplZCwgYW5kIHdoZXJlIHRlY2hub2xvZ2llcyB0byBtYWtl IGNvZGUgZmxvdyB2aWFibGUgYXQgaW5pdGlhbCBPQXV0aCAyIHN0YW5kYXJkaXphdGlvbiBoYWQg YmVlbiBhdmFpbGFibGUgKHN1Y2ggYXMgQ09SUykuIFNpbmNlIHdlIG5vdyBsaXZlIGluIHRoYXQg d29ybGQgYW5kIGFyZSB0YWxraW5nIGFib3V0IGFuIGluY29tcGF0aWJsZQ0KIHByb3RvY29sLCBJ IGRvbuKAmXQgYmVsaWV2ZSB0aGVzZSBzb3J0cyBvZiBjb21wYXRpYmlsaXR5IG9yIG1pZ3JhdGlv biBjb25zaWRlcmF0aW9ucyBhcHBseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgb25seSB1c2UgY2FzZSBJIGtub3cgb2YgaW5kaXJlY3RseSBwdXNoaW5n IGZvciBpbXBsaWNpdCBpcyBPSURDIHNlbGYtaXNzdWVkIHVzZSBjYXNlLiBJIHdvdWxkIGluc3Rl YWQgZGVzY3JpYmUgdGhpcyBhcyBwdXNoaW5nIHRvIHNvbHZlIHNldmVyYWwgbmV3IHVzZSBjYXNl cyBhdCBvbmNlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBVc2Ugb2YgYSBsb2NhbCAo ZS5nLiBub24tZ2xvYmFsbHkgcmVhY2hhYmxlKSBPUDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gQ29tbXVuaWNhdGlv biB3aGVuIHRoZSBjbGllbnQgYW5kIHRoZSBPUCBjYW5ub3QgZXN0YWJsaXNoIGRpcmVjdCBuZXR3 b3JrIGNvbW11bmljYXRpb24sIHN1Y2ggYXMgd2hlbiBib3RoIGV4aXN0IHNhbmRib3hlZCBvbiBh IGxvY2FsIGRldmljZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gRGVmaW5pbmcgYW5kIG1hbmRhdGluZyBjbGllbnQg YW5kIE9QIHNlY3VyaXR5IHBvbGljeSB0byBmaXQgaW50byB0aGUgbW9kZWwgb2YgdGhlIGFib3Zl IHR3byBwb2ludHMsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcGVyc29uYWxs eSBkb27igJl0IHRoaW5rIHRoZSBtZWNoYW5pY3Mgc2VsZi1pc3N1ZWQgT0lEQyBsZXZlcmFnZXMg KGN1c3RvbSBVUkwgcmVkaXJlY3RzIGFuZC9vciBsb2NhbGhvc3QgbGlzdGVuZXJzKSBoYXMgYXBw cm9wcmlhdGUgc2VjdXJpdHkgb3IgcHJpdmFjeSBjb25zaWRlcmF0aW9ucy4gVGhlcmUgYXJlIGFj dHVhbGx5IHplcm8gc2VjdXJpdHkgb3IgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyByZWdhcmRpbmcN CiBzZWxmLWlzc3VlZCwgd2hpY2ggSSBmaW5kIHNvbWV3aGF0IGRpc2FwcG9pbnRpbmcuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyBrbm93IHRoYXQgb25lIG1vYmlsZSBPUyB2ZW5k b3IgaGFzIGV4cGxpY2l0bHkgcmVjb21tZW5kZWQgYWdhaW5zdCBkZXZlbG9wZXJzIHVzaW5nIGN1 c3RvbSBVUkwgc2NoZW1lcyB0byBzb2x2ZSBuZXcgdXNlIGNhc2VzLCBzdHJvbmdseSByZWNvbW1l bmRpbmcgbWVjaGFuaXNtcyBzdWNoIGFzIGNsYWltZWQgSFRUUFMgVVJMcyBiZSB1c2VkIGluc3Rl YWQuIFRoaXMgdmVuZG9yIGhhcyBoYXMgYWxzbyBncmFkdWFsbHkNCiBpbmNyZWFzZWQgdGhlIGNv bXBsZXhpdHkgYW5kIHJlc3RyaWN0aW9ucyBmb3IgY3VzdG9tIFVSTCB1c2UgYnkgYXBwbGljYXRp b24gZGV2ZWxvcGVycy4gSW4gbXkgb3BpbmlvbiwgdGhlcmUgaXMgcmlzayBpbiBuZXcgdXNlIG9m IGN1c3RvbSBVUkwgc2NoZW1lcyBmb3IgbG9jYWwgSVBDLiBJdCBpcyBsaWtlbHkgbm90IGEgY29p bmNpZGVuY2UgdGhhdCBjdXN0b20gVVJMIHNjaGVtZXMgYXJlIGNob3NlbiBhcyB0aGV5IGFyZSBo aXN0b3JpY2FsbHkNCiB0aGUgb25seSBjcm9zcy1wbGF0Zm9ybSBsb2NhbCBJUEMgbWVjaGFuaXNt IHdpdGhvdXQgcHJpdmFjeSBjb250cm9scywgdXNlciBjb25zZW50LCBhbmQgYW5kIG90aGVyIHVz YWJpbGl0eSByZXN0cmljdGlvbnMgcGxhY2VkIHVwb24gdGhlbS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SXQgaXMgYWxzbyB3b3J0aCBtZW50aW9uaW5nIHRoYXQgT0lEQyBzZWxmLWlzc3Vl ZCBkb2VzIG5vdCBoYXZlIHByb3Zpc2lvbnMgdG8gZ2FpbiBhdXRob3JpemF0aW9uLCB3aGljaCBt aWdodCBtYWtlIGl0IGRpZmZpY3VsdCB0byBjb25zaWRlciBpdCBpbiBzY29wZSBmb3IgdGhpcyBn cm91cOKAmXMgY2hhcnRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LURXPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2E95304B66B04D28B56FEF1B313F4BB9amazoncom_-- From nobody Wed Jan 8 10:23: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 CA6AA120059 for ; Wed, 8 Jan 2020 10:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hd9Tma9rtQQv for ; Wed, 8 Jan 2020 10:23:52 -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 2AA53120019 for ; Wed, 8 Jan 2020 10:23:52 -0800 (PST) Received: from [192.168.1.16] (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 008INPvf010694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Jan 2020 13:23:26 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8D6BFA4C-8C7F-46C6-A469-478BFF3A5DF0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 8 Jan 2020 13:23:25 -0500 In-Reply-To: <2E95304B-66B0-4D28-B56F-EF1B313F4BB9@amazon.com> Cc: David Waite , Dick Hardt , "txauth@ietf.org" To: "Richard Backman, Annabelle" References: <6DFD1CA6-D334-4FCA-9881-834571A5DE7C@amazon.com> <9C6149E5-144F-442E-862E-D849A9A9FF57@alkaline-solutions.com> <5D7A9B1D-20A4-4F9F-8586-BFA5CCF38B38@mit.edu> <2E95304B-66B0-4D28-B56F-EF1B313F4BB9@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Framework vs Protocol 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, 08 Jan 2020 18:23:55 -0000 --Apple-Mail=_8D6BFA4C-8C7F-46C6-A469-478BFF3A5DF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m definitely in line with that approach. SPA=E2=80=99s are = arguably much bigger today than they were when the implicit grant = started, but as a consequence we=E2=80=99ve also got much better tooling = to manage them. I would recommend that we as a group don=E2=80=99t talk = about them in terms of =E2=80=9Cthe implicit grant=E2=80=9D but rather = the aspects of the use cases we=E2=80=99re looking to solve.=20 - Justin > On Jan 6, 2020, at 7:13 PM, Richard Backman, Annabelle = wrote: >=20 > It=E2=80=99s not about aligning with implicit grant (I agree that = should not be a goal), it=E2=80=99s about ensuring that the use cases = being served by implicit grant today can be met by TxAuth or can be = dismissed as out of scope, and being intentional about any decisions = toward the latter. > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: Justin Richer > Date: Monday, January 6, 2020 at 8:09 AM > To: "Richard Backman, Annabelle" > Cc: David Waite , Dick Hardt = , "txauth@ietf.org" > Subject: Re: [UNVERIFIED SENDER] [Txauth] Framework vs Protocol > =20 > I don=E2=80=99t think =E2=80=9Calignment with the implicit grant=E2=80=9D= should be a goal here. I think addressing the same use cases as the = implicit grant is good, but for that we=E2=80=99ve got a lot better = tools today than we did a decade ago, and we don=E2=80=99t need to make = the same mistakes in new work just for the sake of aligning it. =20 > =20 > The self-issued OP model does a decent enough job of using what tools = were there at the time to get around OIDC=E2=80=99s limitations, but I = think there=E2=80=99s a much better approach available to us here.=20 > =20 > And in all truth, the answer might be =E2=80=9Csomething else = entirely=E2=80=9D. We can=E2=80=99t solve every problem and use case, = and I don=E2=80=99t think it does this work any favors to = over-generalize it at the expense of a set of things we do understand. = Grounding us like that is one of the reasons that I put the = =E2=80=9Ctransactional=E2=80=9D language in the proposed charter text. I = am proposing that we approach not just a certain set of problems but do = so in a particular way, without necessarily presuming the solution. I = think we would all want this new work to be focused on something = tractable. > =20 > =E2=80=94 Justin >=20 >=20 >> On Jan 3, 2020, at 1:58 PM, Richard Backman, Annabelle = > wrote: >> =20 >> I haven=E2=80=99t seen a detailed analysis of how implicit use cases = would map onto TxAuth, so while I think you are correct I=E2=80=99m not = yet confident that the only challenges are migration related, and that = there aren=E2=80=99t still some important edge cases lurking in the = implicit space that aren=E2=80=99t well served by the TxAuth approach. >> =20 >> I generally agree that OIDC self-issued OP is conflating several = different problems that would be better addressed on an individual = basis. Though it does demonstrate how TxAuth=E2=80=99s dependency on a = transaction endpoint reachable by the client favors external identity = solutions over those under the direct control of the end user. >> =20 >> =E2=80=93=20 >> Annabelle Richard Backman >> AWS Identity >> =20 >> =20 >> From: David Waite > >> Date: Friday, January 3, 2020 at 12:27 AM >> To: "Richard Backman, Annabelle" > >> Cc: Justin Richer >, Dick = Hardt >, = "txauth@ietf.org " > >> Subject: [UNVERIFIED SENDER] Re: [Txauth] Framework vs Protocol >> =20 >>=20 >>=20 >>=20 >>> On Jan 2, 2020, at 5:18 PM, Richard Backman, Annabelle = > wrote: >>> The current document seems to do a better job of laying out a core = message and communication pattern, but it doesn=E2=80=99t align well = with the implicit grant. We will want to dig into persistent use cases = for implicit (e.g., Brian Campbell=E2=80=99s use case in this OAuth = mailing list thread = )= to see if the TxAuth pattern can serve them, or if there are gaps that = need to be filled. >> =20 >> My understanding is that most complications are due to the = compatibility and migration that comes from the WG recommending against = front-channel/implicit patterns in the front channel for OAuth 2. I = don=E2=80=99t think these use cases would have been precluded in a world = where only code flow had been standardized, and where technologies to = make code flow viable at initial OAuth 2 standardization had been = available (such as CORS). Since we now live in that world and are = talking about an incompatible protocol, I don=E2=80=99t believe these = sorts of compatibility or migration considerations apply. >> =20 >> =20 >> The only use case I know of indirectly pushing for implicit is OIDC = self-issued use case. I would instead describe this as pushing to solve = several new use cases at once: >> =20 >> 1. Use of a local (e.g. non-globally reachable) OP >> 2. Communication when the client and the OP cannot establish direct = network communication, such as when both exist sandboxed on a local = device >> 3. Defining and mandating client and OP security policy to fit into = the model of the above two points,=20 >> =20 >> I personally don=E2=80=99t think the mechanics self-issued OIDC = leverages (custom URL redirects and/or localhost listeners) has = appropriate security or privacy considerations. There are actually zero = security or privacy considerations regarding self-issued, which I find = somewhat disappointing. >> =20 >> I also know that one mobile OS vendor has explicitly recommended = against developers using custom URL schemes to solve new use cases, = strongly recommending mechanisms such as claimed HTTPS URLs be used = instead. This vendor has has also gradually increased the complexity and = restrictions for custom URL use by application developers. In my = opinion, there is risk in new use of custom URL schemes for local IPC. = It is likely not a coincidence that custom URL schemes are chosen as = they are historically the only cross-platform local IPC mechanism = without privacy controls, user consent, and and other usability = restrictions placed upon them. >> =20 >> It is also worth mentioning that OIDC self-issued does not have = provisions to gain authorization, which might make it difficult to = consider it in scope for this group=E2=80=99s charter. >> =20 >> -DW --Apple-Mail=_8D6BFA4C-8C7F-46C6-A469-478BFF3A5DF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m definitely in line with that approach. SPA=E2=80=99s are arguably = much bigger today than they were when the implicit grant started, but as = a consequence we=E2=80=99ve also got much better tooling to manage them. = I would recommend that we as a group don=E2=80=99t talk about them in = terms of =E2=80=9Cthe implicit grant=E2=80=9D but rather the aspects of = the use cases we=E2=80=99re looking to solve. 

 -  Justin

On Jan 6, 2020, at 7:13 PM, Richard Backman, Annabelle <richanna@amazon.com>= wrote:

It=E2=80=99= s not about aligning with implicit grant (I agree that should not be a = goal), it=E2=80=99s about ensuring that the use cases being served by = implicit grant today can be met by TxAuth or can be dismissed as out of = scope, and being intentional about any decisions toward the latter.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: Justin Richer <jricher@mit.edu>
Date: Monday, January 6, 2020 = at 8:09 AM
To: "Richard Backman, = Annabelle" <richanna@amazon.com>
Cc: David= Waite <david@alkaline-solutions.com>, Dick Hardt <dick.hardt@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [UNVERIFIED SENDER] = [Txauth] Framework vs Protocol
 
I don=E2=80=99t think =E2=80=9Calignment with the implicit = grant=E2=80=9D should be a goal here. I think addressing the same use = cases as the implicit grant is good, but for that we=E2=80=99ve got a = lot better tools today than we did a decade ago, and we don=E2=80=99t = need to make the same mistakes in new work just for the sake of aligning = it.  
 
The self-issued OP model does a decent = enough job of using what tools were there at the time to get around = OIDC=E2=80=99s limitations, but I think there=E2=80=99s a much better = approach available to us here. 
 
And in all truth, the answer might be =E2=80=9Csomething else = entirely=E2=80=9D. We can=E2=80=99t solve every problem and use case, = and I don=E2=80=99t think it does this work any favors to = over-generalize it at the expense of a set of things we do understand. = Grounding us like that is one of the reasons that I put the = =E2=80=9Ctransactional=E2=80=9D language in the proposed charter text. I = am proposing that we approach not just a certain set of problems but do = so in a particular way, without necessarily presuming the solution. I = think we would all want this new work to be focused on something = tractable.
 
 =E2=80=94 Justin


On Jan 3, 2020, at 1:58 PM, Richard = Backman, Annabelle <richanna@amazon.com> wrote:
 
I haven=E2=80=99t seen a detailed = analysis of how implicit use cases would map onto TxAuth, so while I = think you are correct I=E2=80=99m not yet confident that the only = challenges are migration related, and that there aren=E2=80=99t still = some important edge cases lurking in the implicit space that aren=E2=80=99= t well served by the TxAuth approach.
 
I generally agree that OIDC self-issued = OP is conflating several different problems that would be better = addressed on an individual basis. Though it does demonstrate how = TxAuth=E2=80=99s dependency on a transaction endpoint reachable by the = client favors external identity solutions over those under the direct = control of the end user.
 
=E2=80=93 
Annabelle Richard Backman
AWS = Identity
 
 
From: David Waite <david@alkaline-solutions.com>
Date: Friday, January 3, 2020 = at 12:27 AM
To: "Richard Backman, = Annabelle" <richanna@amazon.com>
Cc: Justin Richer <jricher@mit.edu>, Dick Hardt <dick.hardt@gmail.com>, = "txauth@ietf.org" <txauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: = [Txauth] Framework vs Protocol
 



On Jan 2, 2020, at 5:18 PM, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> = wrote:
The = current document seems to do a better job of laying out a core message = and communication pattern, but it doesn=E2=80=99t align well with the = implicit grant. We will want to dig into persistent use cases for = implicit (e.g., Brian Campbell=E2=80=99s use case in this OAuth mailing = list thread) to see if the TxAuth pattern can serve them, or = if there are gaps that need to be filled.
 
My understanding is that most complications are due to the = compatibility and migration that comes from the WG recommending against = front-channel/implicit patterns in the front channel for OAuth 2. I = don=E2=80=99t think these use cases would have been precluded in a world = where only code flow had been standardized, and where technologies to = make code flow viable at initial OAuth 2 standardization had been = available (such as CORS). Since we now live in that world and are = talking about an incompatible protocol, I don=E2=80=99t believe these = sorts of compatibility or migration considerations apply.
 
 
The only use case I know of indirectly = pushing for implicit is OIDC self-issued use case. I would instead = describe this as pushing to solve several new use cases at once:
 
1. Use of a local (e.g. non-globally = reachable) OP
2. Communication when the = client and the OP cannot establish direct network communication, such as = when both exist sandboxed on a local device
3. Defining and mandating client and OP = security policy to fit into the model of the above two points, 
 
I personally don=E2=80=99t think the = mechanics self-issued OIDC leverages (custom URL redirects and/or = localhost listeners) has appropriate security or privacy considerations. = There are actually zero security or privacy considerations regarding = self-issued, which I find somewhat disappointing.
 
I also know that one mobile OS vendor = has explicitly recommended against developers using custom URL schemes = to solve new use cases, strongly recommending mechanisms such as claimed = HTTPS URLs be used instead. This vendor has has also gradually increased = the complexity and restrictions for custom URL use by application = developers. In my opinion, there is risk in new use of custom URL = schemes for local IPC. It is likely not a coincidence that custom URL = schemes are chosen as they are historically the only cross-platform = local IPC mechanism without privacy controls, user consent, and and = other usability restrictions placed upon them.
 
It is also worth mentioning that OIDC = self-issued does not have provisions to gain authorization, which might = make it difficult to consider it in scope for this group=E2=80=99s = charter.
 
-DW

= --Apple-Mail=_8D6BFA4C-8C7F-46C6-A469-478BFF3A5DF0-- From nobody Wed Jan 8 10:24: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 C563712012A for ; Wed, 8 Jan 2020 10:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 cK4YQAUwHxQR for ; Wed, 8 Jan 2020 10:23:57 -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 A480A120059 for ; Wed, 8 Jan 2020 10:23:57 -0800 (PST) Received: from [192.168.1.16] (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 008INPvg010694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Jan 2020 13:23:33 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9F85D389-A260-4D6E-941B-A3B521457D7C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 8 Jan 2020 13:23:33 -0500 In-Reply-To: Cc: "Richard Backman, Annabelle" , David Waite , "txauth@ietf.org" To: Dick Hardt References: <6DFD1CA6-D334-4FCA-9881-834571A5DE7C@amazon.com> <9C6149E5-144F-442E-862E-D849A9A9FF57@alkaline-solutions.com> <5D7A9B1D-20A4-4F9F-8586-BFA5CCF38B38@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Is it a transaction? (was Framework vs Protocol) 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, 08 Jan 2020 18:24:00 -0000 --Apple-Mail=_9F85D389-A260-4D6E-941B-A3B521457D7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 6, 2020, at 4:33 PM, Dick Hardt wrote: >=20 >=20 > On Mon, Jan 6, 2020 at 8:08 AM Justin Richer > wrote: > > And in all truth, the answer might be =E2=80=9Csomething else = entirely=E2=80=9D. We can=E2=80=99t solve every problem and use case, = and I don=E2=80=99t think it does this work any favors to = over-generalize it at the expense of a set of things we do understand. = Grounding us like that is one of the reasons that I put the = =E2=80=9Ctransactional=E2=80=9D language in the proposed charter text. I = am proposing that we approach not just a certain set of problems but do = so in a particular way, without necessarily presuming the solution. I = think we would all want this new work to be focused on something = tractable. > =20 > I completely agree we don't want to solve every problem and use case, = and we need to scope the problem space in some way. >=20 > As I've thought about the term "transaction", it seems to be a = misnomer, particularly when database semantics are applied, where a = transaction is all or nothing.=20 >=20 > As I understand it, we would like the client to request scoped access = to multiple resources. Not all of the request is required, which is not = aligned with the definition of transaction above.=20 >=20 > Additionally, in the XYZ draft, the transaction handle is used to = refresh tokens. I would consider this a new interaction, as the AS will = be running policy again, and the refresh may be denied.=20 >=20 > I don't have a better suggestion at this time, but "transaction" does = not quite seem right. >=20 As I=E2=80=99ve said before, naming things is hard. I think = =E2=80=9Ctransactional=E2=80=9D has many aspects that fit, and some = connotations that don=E2=80=99t.=20 I stuck to the word =E2=80=9Ctransaction=E2=80=9D because for me it = captured an aspect that I hadn=E2=80=99t seen reified in this work = before: that there is an ongoing process between parties who are = exchanging things, passing information back and forth over time. The RO = and client both provide information to the AS to modify the request over = time, and the AS can respond with what it thinks is needed next. So = it=E2=80=99s like a commercial transaction in some ways: =E2=80=9CI want = to buy that gum=E2=80=9D, =E2=80=9Cthat=E2=80=99ll be $0.50=E2=80=9D, = =E2=80=9Chere=E2=80=99s the money=E2=80=9D, =E2=80=9Chere=E2=80=99s your = change=E2=80=9D, etc. It=E2=80=99s a conversation between parties, but a = specific one in that one party (the client) is trying to get something = (a token) from another party (the AS). This doesn=E2=80=99t mean that I = think this only fits financial APIs =E2=80=94 you=E2=80=99ll notice that = the API didn=E2=80=99t come into the conversation at all here.=20 But in a way the =E2=80=9Ctransactions=E2=80=9D in XYZ are all or = nothing, in the end. You get a token or you don=E2=80=99t, at the end of = things. But more importantly, there=E2=80=99s an explicit =E2=80=9CI=E2=80= =99m starting now=E2=80=9D step with the transaction request, and the = explicit =E2=80=9CI=E2=80=99m continuing something that I already = started=E2=80=9D with the transaction handle. In XYZ, the request = creates something, what I=E2=80=99m calling a transaction, and that = ultimately results in something else, what I=E2=80=99m calling a token. = If something goes amiss, like the user denies the request or the client = asks for more than it=E2=80=99s allowed to, then the transaction stops. = The fact that the client doesn=E2=80=99t get everything it asked for = doesn=E2=80=99t mean the transaction failed, it just means the results = were modified by something within the process.=20 So it=E2=80=99s not just the database sense, and it=E2=80=99s not just = the commerce sense either. Neither is a perfect fit, though, I totally = admit. If we had a better name for it I=E2=80=99d be all for picking = something that=E2=80=99s more descriptive, but nothing I=E2=80=99ve = heard or thought of matches the process better than =E2=80=9Ctransaction=E2= =80=9D for me.=20 =E2=80=94 Justin= --Apple-Mail=_9F85D389-A260-4D6E-941B-A3B521457D7C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 6, 2020, at 4:33 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


On Mon, Jan 6, 2020 at 8:08 AM Justin = Richer <jricher@mit.edu> wrote:
<snip>
And in all truth, the answer might be =E2=80=9Csomething else = entirely=E2=80=9D. We can=E2=80=99t solve every problem and use case, = and I don=E2=80=99t think it does this work any favors to = over-generalize it at the expense of a set of things we do understand. = Grounding us like that is one of the reasons that I put the = =E2=80=9Ctransactional=E2=80=9D language in the proposed charter text. I = am proposing that we approach not just a certain set of problems but do = so in a particular way, without necessarily presuming the solution. I = think we would all want this new work to be focused on something = tractable.
 
I completely agree we don't want to solve every problem and = use case, and we need to scope the problem space in = some way.

As I've thought about the term "transaction", it seems to be = a misnomer, particularly when database semantics are applied, where a = transaction is all or nothing. 

As I understand it, we would like the = client to request scoped access to multiple resources. Not all of = the request is required, which is not aligned with the definition of = transaction above. 

Additionally, in the XYZ draft, the transaction handle is = used to refresh tokens. I would consider this a new interaction, as the = AS will be running policy again, and the refresh may be = denied. 

I = don't have a better suggestion at this time, but "transaction" does not = quite seem right.


As I=E2=80=99ve said before, naming things is = hard. I think =E2=80=9Ctransactional=E2=80=9D has many aspects that fit, = and some connotations that don=E2=80=99t. 

I stuck to the word =E2=80=9Ctransaction=E2=80=9D = because for me it captured an aspect that I hadn=E2=80=99t seen reified = in this work before: that there is an ongoing process between parties = who are exchanging things, passing information back and forth over time. = The RO and client both provide information to the AS to modify the = request over time, and the AS can respond with what it thinks is needed = next. So it=E2=80=99s like a commercial transaction in some ways: =E2=80=9C= I want to buy that gum=E2=80=9D, =E2=80=9Cthat=E2=80=99ll be $0.50=E2=80=9D= , =E2=80=9Chere=E2=80=99s the money=E2=80=9D, =E2=80=9Chere=E2=80=99s = your change=E2=80=9D, etc. It=E2=80=99s a conversation between parties, = but a specific one in that one party (the client) is trying to get = something (a token) from another party (the AS). This doesn=E2=80=99t = mean that I think this only fits financial APIs =E2=80=94 you=E2=80=99ll = notice that the API didn=E2=80=99t come into the conversation at all = here. 

But in a way the = =E2=80=9Ctransactions=E2=80=9D in XYZ are all or nothing, in the end. = You get a token or you don=E2=80=99t, at the end of things. But more = importantly, there=E2=80=99s an explicit =E2=80=9CI=E2=80=99m starting = now=E2=80=9D step with the transaction request, and the explicit = =E2=80=9CI=E2=80=99m continuing something that I already started=E2=80=9D = with the transaction handle. In XYZ, the request creates something, what = I=E2=80=99m calling a transaction, and that ultimately results in = something else, what I=E2=80=99m calling a token. If something goes = amiss, like the user denies the request or the client asks for more than = it=E2=80=99s allowed to, then the transaction stops. The fact that the = client doesn=E2=80=99t get everything it asked for doesn=E2=80=99t mean = the transaction failed, it just means the results were modified by = something within the process. 

So= it=E2=80=99s not just the database sense, and it=E2=80=99s not just the = commerce sense either. Neither is a perfect fit, though, I totally = admit. If we had a better name for it I=E2=80=99d be all for picking = something that=E2=80=99s more descriptive, but nothing I=E2=80=99ve = heard or thought of matches the process better than =E2=80=9Ctransaction=E2= =80=9D for me. 

 =E2=80=94 = Justin
= --Apple-Mail=_9F85D389-A260-4D6E-941B-A3B521457D7C-- From nobody Wed Jan 8 10:34: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 5D0611200B8 for ; Wed, 8 Jan 2020 10:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 apEDl-Zi_-ZG for ; Wed, 8 Jan 2020 10:34:24 -0800 (PST) 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 991441200CC for ; Wed, 8 Jan 2020 10:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578508465; x=1610044465; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FPX381GmUfSZOZtmqqOu84sAL5neEHVjQOS7ON2D+HM=; b=DlaDdJ1iefKFj0Rbl+zhi0FGq84EsuJXKG0Fri+ET1r/QzRnXnNSbzoc mWZHO8ry1vwEIjoIZlY3tZlnk6uZAti/6BILUPNxF93r7ddItZ1AgTld2 hOkf5Ji2AbkPK17Ra83emgG3cW5lMbrVSSfOERcxKWH3MwEerXFb0MGRT k=; IronPort-SDR: JK6fU+uULi77P1pCmtc0ZzBp6fkKcij1jUk6Q9BSdTSjIPJ2EE3J88NzmnMvTQbrPZhWrfskPi Dj9YQ/NcLUjg== X-IronPort-AV: E=Sophos; i="5.69,410,1571702400"; d="scan'208,217"; a="17529403" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1d-9ec21598.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 08 Jan 2020 18:34:08 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1d-9ec21598.us-east-1.amazon.com (Postfix) with ESMTPS id 50192A23EE; Wed, 8 Jan 2020 18:34:05 +0000 (UTC) Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Jan 2020 18:34:05 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Jan 2020 18:34:05 +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.1367.000; Wed, 8 Jan 2020 18:34:05 +0000 From: "Richard Backman, Annabelle" To: Justin Richer CC: David Waite , Dick Hardt , "txauth@ietf.org" Thread-Topic: [UNVERIFIED SENDER] [Txauth] Framework vs Protocol Thread-Index: AQHVxKuwvx7sdbqHo0exP9TrHF7HKafdzwQAgANJEoD//3zeAA== Date: Wed, 8 Jan 2020 18:34:05 +0000 Message-ID: References: <6DFD1CA6-D334-4FCA-9881-834571A5DE7C@amazon.com> <9C6149E5-144F-442E-862E-D849A9A9FF57@alkaline-solutions.com> <5D7A9B1D-20A4-4F9F-8586-BFA5CCF38B38@mit.edu> <2E95304B-66B0-4D28-B56F-EF1B313F4BB9@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.115] Content-Type: multipart/alternative; boundary="_000_D346D42B885B434C924A26F6FCC685F8amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Framework vs Protocol 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, 08 Jan 2020 18:34:28 -0000 --_000_D346D42B885B434C924A26F6FCC685F8amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZS4gSeKAmW0gbm90IG92ZXJseSBjb25jZXJuZWQgYWJvdXQgU1BBcyBmaXR0aW5nIGlu dG8gdGhlIFR4QXV0aCBtb2RlbCwgYXMgSSB0aGluayB3ZSBoYXZlIGEgcHJldHR5IHNvbGlkIHBh dGggZm9yIHRoYXQsIGFzIGlsbHVzdHJhdGVkIGJ5IHRoZSBwdXNoIGZvciBTUEFzIHRvIGFkb3B0 IGF1dGhvcml6YXRpb24gY29kZSBncmFudC4gSSBzdXNwZWN0IGluIG1vc3QgY2FzZXMsIFNQQXMg YW5kIG90aGVyIGNsaWVudHMgdGhhdCBhcmUgc3RpbGwgZG9pbmcgaW1wbGljaXQgZ3JhbnQgYXJl IGRvaW5nIHNvIGJlY2F1c2UgdGhhdOKAmXMgd2hhdCB0aGV5IGJ1aWx0IDMgeWVhcnMgYWdvIGFu ZCB0aGV5IGRvbuKAmXQgaGF2ZSBhIGNvbXBlbGxpbmcgcmVhc29uIHRvIGNoYW5nZS4gSXTigJlz IG5vdCBjbGVhciB0byBtZSB0aGF0IHRoaXMgaXMgdGhlIGNhc2UgZm9yIGFsbCB1c2VzIG9mIGlt cGxpY2l0IGdyYW50IHRvZGF5LCBhbmQgSSB0aGluayBpdOKAmXMgd29ydGggcG9raW5nIGFyb3Vu ZCBpbiB0aGlzIHNwYWNlIGEgYml0IHRvIHVuZGVyc3RhbmQgaWYgdGhlcmUgYXJlIGFueSB1c2Ug Y2FzZXMgbHVya2luZyB0aGVyZSB0aGF0IHdlIHRoaW5rIHNob3VsZCBiZSBjb3ZlcmVkIGJ5IFR4 QXV0aCwgb3IgaWYgd2XigJlyZSBjb21mb3J0YWJsZSBzYXlpbmcgdGhleSBhcmUgdW5zdXBwb3J0 ZWQuDQoNCkRlY2lkaW5nIGhvdyB0byBzdXBwb3J0IHRob3NlIHVzZSBjYXNlcyAoaWYgYW55KSBp cyBhbm90aGVyIG1hdHRlci4gVGhlIGFuc3dlciBzaG91bGRu4oCZdCBiZSDigJxhZGQgYW4gaW1w bGljaXQgc3R5bGUgZmxvdyB0byBUeEF1dGgu4oCdIDotLw0KDQrigJMNCkFubmFiZWxsZSBSaWNo YXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IEp1c3RpbiBSaWNoZXIgPGpyaWNo ZXJAbWl0LmVkdT4NCkRhdGU6IFdlZG5lc2RheSwgSmFudWFyeSA4LCAyMDIwIGF0IDEwOjI0IEFN DQpUbzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbT4N CkNjOiBEYXZpZCBXYWl0ZSA8ZGF2aWRAYWxrYWxpbmUtc29sdXRpb25zLmNvbT4sIERpY2sgSGFy ZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPiwgInR4YXV0aEBpZXRmLm9yZyIgPHR4YXV0aEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbVU5WRVJJRklFRCBTRU5ERVJdIFtUeGF1dGhdIEZyYW1ld29y ayB2cyBQcm90b2NvbA0KDQpJ4oCZbSBkZWZpbml0ZWx5IGluIGxpbmUgd2l0aCB0aGF0IGFwcHJv YWNoLiBTUEHigJlzIGFyZSBhcmd1YWJseSBtdWNoIGJpZ2dlciB0b2RheSB0aGFuIHRoZXkgd2Vy ZSB3aGVuIHRoZSBpbXBsaWNpdCBncmFudCBzdGFydGVkLCBidXQgYXMgYSBjb25zZXF1ZW5jZSB3 ZeKAmXZlIGFsc28gZ290IG11Y2ggYmV0dGVyIHRvb2xpbmcgdG8gbWFuYWdlIHRoZW0uIEkgd291 bGQgcmVjb21tZW5kIHRoYXQgd2UgYXMgYSBncm91cCBkb27igJl0IHRhbGsgYWJvdXQgdGhlbSBp biB0ZXJtcyBvZiDigJx0aGUgaW1wbGljaXQgZ3JhbnTigJ0gYnV0IHJhdGhlciB0aGUgYXNwZWN0 cyBvZiB0aGUgdXNlIGNhc2VzIHdl4oCZcmUgbG9va2luZyB0byBzb2x2ZS4NCg0KIC0gIEp1c3Rp bg0KDQoNCk9uIEphbiA2LCAyMDIwLCBhdCA3OjEzIFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFi ZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdy b3RlOg0KDQpJdOKAmXMgbm90IGFib3V0IGFsaWduaW5nIHdpdGggaW1wbGljaXQgZ3JhbnQgKEkg YWdyZWUgdGhhdCBzaG91bGQgbm90IGJlIGEgZ29hbCksIGl04oCZcyBhYm91dCBlbnN1cmluZyB0 aGF0IHRoZSB1c2UgY2FzZXMgYmVpbmcgc2VydmVkIGJ5IGltcGxpY2l0IGdyYW50IHRvZGF5IGNh biBiZSBtZXQgYnkgVHhBdXRoIG9yIGNhbiBiZSBkaXNtaXNzZWQgYXMgb3V0IG9mIHNjb3BlLCBh bmQgYmVpbmcgaW50ZW50aW9uYWwgYWJvdXQgYW55IGRlY2lzaW9ucyB0b3dhcmQgdGhlIGxhdHRl ci4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpG cm9tOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVk dT4+DQpEYXRlOiBNb25kYXksIEphbnVhcnkgNiwgMjAyMCBhdCA4OjA5IEFNDQpUbzogIlJpY2hh cmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFu bmFAYW1hem9uLmNvbT4+DQpDYzogRGF2aWQgV2FpdGUgPGRhdmlkQGFsa2FsaW5lLXNvbHV0aW9u cy5jb208bWFpbHRvOmRhdmlkQGFsa2FsaW5lLXNvbHV0aW9ucy5jb20+PiwgRGljayBIYXJkdCA8 ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4sICJ0eGF1 dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBpZXRmLm9yZz4iIDx0eGF1dGhAaWV0Zi5vcmc8bWFp bHRvOnR4YXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW1VOVkVSSUZJRUQgU0VOREVSXSBb VHhhdXRoXSBGcmFtZXdvcmsgdnMgUHJvdG9jb2wNCg0KSSBkb27igJl0IHRoaW5rIOKAnGFsaWdu bWVudCB3aXRoIHRoZSBpbXBsaWNpdCBncmFudOKAnSBzaG91bGQgYmUgYSBnb2FsIGhlcmUuIEkg dGhpbmsgYWRkcmVzc2luZyB0aGUgc2FtZSB1c2UgY2FzZXMgYXMgdGhlIGltcGxpY2l0IGdyYW50 IGlzIGdvb2QsIGJ1dCBmb3IgdGhhdCB3ZeKAmXZlIGdvdCBhIGxvdCBiZXR0ZXIgdG9vbHMgdG9k YXkgdGhhbiB3ZSBkaWQgYSBkZWNhZGUgYWdvLCBhbmQgd2UgZG9u4oCZdCBuZWVkIHRvIG1ha2Ug dGhlIHNhbWUgbWlzdGFrZXMgaW4gbmV3IHdvcmsganVzdCBmb3IgdGhlIHNha2Ugb2YgYWxpZ25p bmcgaXQuDQoNClRoZSBzZWxmLWlzc3VlZCBPUCBtb2RlbCBkb2VzIGEgZGVjZW50IGVub3VnaCBq b2Igb2YgdXNpbmcgd2hhdCB0b29scyB3ZXJlIHRoZXJlIGF0IHRoZSB0aW1lIHRvIGdldCBhcm91 bmQgT0lEQ+KAmXMgbGltaXRhdGlvbnMsIGJ1dCBJIHRoaW5rIHRoZXJl4oCZcyBhIG11Y2ggYmV0 dGVyIGFwcHJvYWNoIGF2YWlsYWJsZSB0byB1cyBoZXJlLg0KDQpBbmQgaW4gYWxsIHRydXRoLCB0 aGUgYW5zd2VyIG1pZ2h0IGJlIOKAnHNvbWV0aGluZyBlbHNlIGVudGlyZWx54oCdLiBXZSBjYW7i gJl0IHNvbHZlIGV2ZXJ5IHByb2JsZW0gYW5kIHVzZSBjYXNlLCBhbmQgSSBkb27igJl0IHRoaW5r IGl0IGRvZXMgdGhpcyB3b3JrIGFueSBmYXZvcnMgdG8gb3Zlci1nZW5lcmFsaXplIGl0IGF0IHRo ZSBleHBlbnNlIG9mIGEgc2V0IG9mIHRoaW5ncyB3ZSBkbyB1bmRlcnN0YW5kLiBHcm91bmRpbmcg dXMgbGlrZSB0aGF0IGlzIG9uZSBvZiB0aGUgcmVhc29ucyB0aGF0IEkgcHV0IHRoZSDigJx0cmFu c2FjdGlvbmFs4oCdIGxhbmd1YWdlIGluIHRoZSBwcm9wb3NlZCBjaGFydGVyIHRleHQuIEkgYW0g cHJvcG9zaW5nIHRoYXQgd2UgYXBwcm9hY2ggbm90IGp1c3QgYSBjZXJ0YWluIHNldCBvZiBwcm9i bGVtcyBidXQgZG8gc28gaW4gYSBwYXJ0aWN1bGFyIHdheSwgd2l0aG91dCBuZWNlc3NhcmlseSBw cmVzdW1pbmcgdGhlIHNvbHV0aW9uLiBJIHRoaW5rIHdlIHdvdWxkIGFsbCB3YW50IHRoaXMgbmV3 IHdvcmsgdG8gYmUgZm9jdXNlZCBvbiBzb21ldGhpbmcgdHJhY3RhYmxlLg0KDQog4oCUIEp1c3Rp bg0KDQoNCg0KT24gSmFuIDMsIDIwMjAsIGF0IDE6NTggUE0sIFJpY2hhcmQgQmFja21hbiwgQW5u YWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4g d3JvdGU6DQoNCkkgaGF2ZW7igJl0IHNlZW4gYSBkZXRhaWxlZCBhbmFseXNpcyBvZiBob3cgaW1w bGljaXQgdXNlIGNhc2VzIHdvdWxkIG1hcCBvbnRvIFR4QXV0aCwgc28gd2hpbGUgSSB0aGluayB5 b3UgYXJlIGNvcnJlY3QgSeKAmW0gbm90IHlldCBjb25maWRlbnQgdGhhdCB0aGUgb25seSBjaGFs bGVuZ2VzIGFyZSBtaWdyYXRpb24gcmVsYXRlZCwgYW5kIHRoYXQgdGhlcmUgYXJlbuKAmXQgc3Rp bGwgc29tZSBpbXBvcnRhbnQgZWRnZSBjYXNlcyBsdXJraW5nIGluIHRoZSBpbXBsaWNpdCBzcGFj ZSB0aGF0IGFyZW7igJl0IHdlbGwgc2VydmVkIGJ5IHRoZSBUeEF1dGggYXBwcm9hY2guDQoNCkkg Z2VuZXJhbGx5IGFncmVlIHRoYXQgT0lEQyBzZWxmLWlzc3VlZCBPUCBpcyBjb25mbGF0aW5nIHNl dmVyYWwgZGlmZmVyZW50IHByb2JsZW1zIHRoYXQgd291bGQgYmUgYmV0dGVyIGFkZHJlc3NlZCBv biBhbiBpbmRpdmlkdWFsIGJhc2lzLiBUaG91Z2ggaXQgZG9lcyBkZW1vbnN0cmF0ZSBob3cgVHhB dXRo4oCZcyBkZXBlbmRlbmN5IG9uIGEgdHJhbnNhY3Rpb24gZW5kcG9pbnQgcmVhY2hhYmxlIGJ5 IHRoZSBjbGllbnQgZmF2b3JzIGV4dGVybmFsIGlkZW50aXR5IHNvbHV0aW9ucyBvdmVyIHRob3Nl IHVuZGVyIHRoZSBkaXJlY3QgY29udHJvbCBvZiB0aGUgZW5kIHVzZXIuDQoNCuKAkw0KQW5uYWJl bGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogRGF2aWQgV2FpdGUg PGRhdmlkQGFsa2FsaW5lLXNvbHV0aW9ucy5jb208bWFpbHRvOmRhdmlkQGFsa2FsaW5lLXNvbHV0 aW9ucy5jb20+Pg0KRGF0ZTogRnJpZGF5LCBKYW51YXJ5IDMsIDIwMjAgYXQgMTI6MjcgQU0NClRv OiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0 bzpyaWNoYW5uYUBhbWF6b24uY29tPj4NCkNjOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5l ZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+LCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWls LmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiwgInR4YXV0aEBpZXRmLm9yZzxtYWls dG86dHhhdXRoQGlldGYub3JnPiIgPHR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYu b3JnPj4NClN1YmplY3Q6IFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtUeGF1dGhdIEZyYW1ld29y ayB2cyBQcm90b2NvbA0KDQoNCg0KDQoNCk9uIEphbiAyLCAyMDIwLCBhdCA1OjE4IFBNLCBSaWNo YXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYu b3JnPG1haWx0bzpyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToN ClRoZSBjdXJyZW50IGRvY3VtZW50IHNlZW1zIHRvIGRvIGEgYmV0dGVyIGpvYiBvZiBsYXlpbmcg b3V0IGEgY29yZSBtZXNzYWdlIGFuZCBjb21tdW5pY2F0aW9uIHBhdHRlcm4sIGJ1dCBpdCBkb2Vz buKAmXQgYWxpZ24gd2VsbCB3aXRoIHRoZSBpbXBsaWNpdCBncmFudC4gV2Ugd2lsbCB3YW50IHRv IGRpZyBpbnRvIHBlcnNpc3RlbnQgdXNlIGNhc2VzIGZvciBpbXBsaWNpdCAoZS5nLiwgQnJpYW4g Q2FtcGJlbGzigJlzIHVzZSBjYXNlIGluIHRoaXMgT0F1dGggbWFpbGluZyBsaXN0IHRocmVhZDxo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoL1J1Y1pIS3VSZjZIQ3NX VXlKREswWFJ3dWIzdz4pIHRvIHNlZSBpZiB0aGUgVHhBdXRoIHBhdHRlcm4gY2FuIHNlcnZlIHRo ZW0sIG9yIGlmIHRoZXJlIGFyZSBnYXBzIHRoYXQgbmVlZCB0byBiZSBmaWxsZWQuDQoNCk15IHVu ZGVyc3RhbmRpbmcgaXMgdGhhdCBtb3N0IGNvbXBsaWNhdGlvbnMgYXJlIGR1ZSB0byB0aGUgY29t cGF0aWJpbGl0eSBhbmQgbWlncmF0aW9uIHRoYXQgY29tZXMgZnJvbSB0aGUgV0cgcmVjb21tZW5k aW5nIGFnYWluc3QgZnJvbnQtY2hhbm5lbC9pbXBsaWNpdCBwYXR0ZXJucyBpbiB0aGUgZnJvbnQg Y2hhbm5lbCBmb3IgT0F1dGggMi4gSSBkb27igJl0IHRoaW5rIHRoZXNlIHVzZSBjYXNlcyB3b3Vs ZCBoYXZlIGJlZW4gcHJlY2x1ZGVkIGluIGEgd29ybGQgd2hlcmUgb25seSBjb2RlIGZsb3cgaGFk IGJlZW4gc3RhbmRhcmRpemVkLCBhbmQgd2hlcmUgdGVjaG5vbG9naWVzIHRvIG1ha2UgY29kZSBm bG93IHZpYWJsZSBhdCBpbml0aWFsIE9BdXRoIDIgc3RhbmRhcmRpemF0aW9uIGhhZCBiZWVuIGF2 YWlsYWJsZSAoc3VjaCBhcyBDT1JTKS4gU2luY2Ugd2Ugbm93IGxpdmUgaW4gdGhhdCB3b3JsZCBh bmQgYXJlIHRhbGtpbmcgYWJvdXQgYW4gaW5jb21wYXRpYmxlIHByb3RvY29sLCBJIGRvbuKAmXQg YmVsaWV2ZSB0aGVzZSBzb3J0cyBvZiBjb21wYXRpYmlsaXR5IG9yIG1pZ3JhdGlvbiBjb25zaWRl cmF0aW9ucyBhcHBseS4NCg0KDQpUaGUgb25seSB1c2UgY2FzZSBJIGtub3cgb2YgaW5kaXJlY3Rs eSBwdXNoaW5nIGZvciBpbXBsaWNpdCBpcyBPSURDIHNlbGYtaXNzdWVkIHVzZSBjYXNlLiBJIHdv dWxkIGluc3RlYWQgZGVzY3JpYmUgdGhpcyBhcyBwdXNoaW5nIHRvIHNvbHZlIHNldmVyYWwgbmV3 IHVzZSBjYXNlcyBhdCBvbmNlOg0KDQoxLiBVc2Ugb2YgYSBsb2NhbCAoZS5nLiBub24tZ2xvYmFs bHkgcmVhY2hhYmxlKSBPUA0KMi4gQ29tbXVuaWNhdGlvbiB3aGVuIHRoZSBjbGllbnQgYW5kIHRo ZSBPUCBjYW5ub3QgZXN0YWJsaXNoIGRpcmVjdCBuZXR3b3JrIGNvbW11bmljYXRpb24sIHN1Y2gg YXMgd2hlbiBib3RoIGV4aXN0IHNhbmRib3hlZCBvbiBhIGxvY2FsIGRldmljZQ0KMy4gRGVmaW5p bmcgYW5kIG1hbmRhdGluZyBjbGllbnQgYW5kIE9QIHNlY3VyaXR5IHBvbGljeSB0byBmaXQgaW50 byB0aGUgbW9kZWwgb2YgdGhlIGFib3ZlIHR3byBwb2ludHMsDQoNCkkgcGVyc29uYWxseSBkb27i gJl0IHRoaW5rIHRoZSBtZWNoYW5pY3Mgc2VsZi1pc3N1ZWQgT0lEQyBsZXZlcmFnZXMgKGN1c3Rv bSBVUkwgcmVkaXJlY3RzIGFuZC9vciBsb2NhbGhvc3QgbGlzdGVuZXJzKSBoYXMgYXBwcm9wcmlh dGUgc2VjdXJpdHkgb3IgcHJpdmFjeSBjb25zaWRlcmF0aW9ucy4gVGhlcmUgYXJlIGFjdHVhbGx5 IHplcm8gc2VjdXJpdHkgb3IgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyByZWdhcmRpbmcgc2VsZi1p c3N1ZWQsIHdoaWNoIEkgZmluZCBzb21ld2hhdCBkaXNhcHBvaW50aW5nLg0KDQpJIGFsc28ga25v dyB0aGF0IG9uZSBtb2JpbGUgT1MgdmVuZG9yIGhhcyBleHBsaWNpdGx5IHJlY29tbWVuZGVkIGFn YWluc3QgZGV2ZWxvcGVycyB1c2luZyBjdXN0b20gVVJMIHNjaGVtZXMgdG8gc29sdmUgbmV3IHVz ZSBjYXNlcywgc3Ryb25nbHkgcmVjb21tZW5kaW5nIG1lY2hhbmlzbXMgc3VjaCBhcyBjbGFpbWVk IEhUVFBTIFVSTHMgYmUgdXNlZCBpbnN0ZWFkLiBUaGlzIHZlbmRvciBoYXMgaGFzIGFsc28gZ3Jh ZHVhbGx5IGluY3JlYXNlZCB0aGUgY29tcGxleGl0eSBhbmQgcmVzdHJpY3Rpb25zIGZvciBjdXN0 b20gVVJMIHVzZSBieSBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzLiBJbiBteSBvcGluaW9uLCB0aGVy ZSBpcyByaXNrIGluIG5ldyB1c2Ugb2YgY3VzdG9tIFVSTCBzY2hlbWVzIGZvciBsb2NhbCBJUEMu IEl0IGlzIGxpa2VseSBub3QgYSBjb2luY2lkZW5jZSB0aGF0IGN1c3RvbSBVUkwgc2NoZW1lcyBh cmUgY2hvc2VuIGFzIHRoZXkgYXJlIGhpc3RvcmljYWxseSB0aGUgb25seSBjcm9zcy1wbGF0Zm9y bSBsb2NhbCBJUEMgbWVjaGFuaXNtIHdpdGhvdXQgcHJpdmFjeSBjb250cm9scywgdXNlciBjb25z ZW50LCBhbmQgYW5kIG90aGVyIHVzYWJpbGl0eSByZXN0cmljdGlvbnMgcGxhY2VkIHVwb24gdGhl bS4NCg0KSXQgaXMgYWxzbyB3b3J0aCBtZW50aW9uaW5nIHRoYXQgT0lEQyBzZWxmLWlzc3VlZCBk b2VzIG5vdCBoYXZlIHByb3Zpc2lvbnMgdG8gZ2FpbiBhdXRob3JpemF0aW9uLCB3aGljaCBtaWdo dCBtYWtlIGl0IGRpZmZpY3VsdCB0byBjb25zaWRlciBpdCBpbiBzY29wZSBmb3IgdGhpcyBncm91 cOKAmXMgY2hhcnRlci4NCg0KLURXDQoNCg== --_000_D346D42B885B434C924A26F6FCC685F8amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBhZ3JlZS4gSeKAmW0gbm90IG92ZXJseSBjb25jZXJuZWQgYWJvdXQgU1BBcyBmaXR0aW5nIGlu dG8gdGhlIFR4QXV0aCBtb2RlbCwgYXMgSSB0aGluayB3ZSBoYXZlIGEgcHJldHR5IHNvbGlkIHBh dGggZm9yIHRoYXQsIGFzIGlsbHVzdHJhdGVkIGJ5IHRoZSBwdXNoIGZvciBTUEFzIHRvIGFkb3B0 IGF1dGhvcml6YXRpb24gY29kZSBncmFudC4gSSBzdXNwZWN0IGluIG1vc3QgY2FzZXMsIFNQQXMg YW5kIG90aGVyDQogY2xpZW50cyB0aGF0IGFyZSBzdGlsbCBkb2luZyBpbXBsaWNpdCBncmFudCBh cmUgZG9pbmcgc28gYmVjYXVzZSB0aGF04oCZcyB3aGF0IHRoZXkgYnVpbHQgMyB5ZWFycyBhZ28g YW5kIHRoZXkgZG9u4oCZdCBoYXZlIGEgY29tcGVsbGluZyByZWFzb24gdG8gY2hhbmdlLiBJdOKA mXMgbm90IGNsZWFyIHRvIG1lIHRoYXQgdGhpcyBpcyB0aGUgY2FzZSBmb3INCjxpPmFsbDwvaT4g dXNlcyBvZiBpbXBsaWNpdCBncmFudCB0b2RheSwgYW5kIEkgdGhpbmsgaXTigJlzIHdvcnRoIHBv a2luZyBhcm91bmQgaW4gdGhpcyBzcGFjZSBhIGJpdCB0byB1bmRlcnN0YW5kIGlmIHRoZXJlIGFy ZSBhbnkgdXNlIGNhc2VzIGx1cmtpbmcgdGhlcmUgdGhhdCB3ZSB0aGluaw0KPGk+c2hvdWxkPC9p PiBiZSBjb3ZlcmVkIGJ5IFR4QXV0aCwgb3IgaWYgd2XigJlyZSBjb21mb3J0YWJsZSBzYXlpbmcg dGhleSBhcmUgdW5zdXBwb3J0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlY2lkaW5nIDxp PmhvdzwvaT4gdG8gc3VwcG9ydCB0aG9zZSB1c2UgY2FzZXMgKGlmIGFueSkgaXMgYW5vdGhlciBt YXR0ZXIuIFRoZSBhbnN3ZXIgc2hvdWxkbuKAmXQgYmUg4oCcYWRkIGFuIGltcGxpY2l0IHN0eWxl IGZsb3cgdG8gVHhBdXRoLuKAnSA6LS88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SnVzdGluIFJpY2hl ciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEph bnVhcnkgOCwgMjAyMCBhdCAxMDoyNCBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmljaGFyZCBC YWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7PGJyPg0K PGI+Q2M6IDwvYj5EYXZpZCBXYWl0ZSAmbHQ7ZGF2aWRAYWxrYWxpbmUtc29sdXRpb25zLmNvbSZn dDssIERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0OywgJnF1b3Q7dHhhdXRo QGlldGYub3JnJnF1b3Q7ICZsdDt0eGF1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPlJlOiBbVU5WRVJJRklFRCBTRU5ERVJdIFtUeGF1dGhdIEZyYW1ld29yayB2cyBQcm90b2Nv bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J 4oCZbSBkZWZpbml0ZWx5IGluIGxpbmUgd2l0aCB0aGF0IGFwcHJvYWNoLiBTUEHigJlzIGFyZSBh cmd1YWJseSBtdWNoIGJpZ2dlciB0b2RheSB0aGFuIHRoZXkgd2VyZSB3aGVuIHRoZSBpbXBsaWNp dCBncmFudCBzdGFydGVkLCBidXQgYXMgYSBjb25zZXF1ZW5jZSB3ZeKAmXZlIGFsc28gZ290IG11 Y2ggYmV0dGVyIHRvb2xpbmcgdG8gbWFuYWdlIHRoZW0uIEkgd291bGQgcmVjb21tZW5kIHRoYXQg d2UgYXMgYSBncm91cA0KIGRvbuKAmXQgdGFsayBhYm91dCB0aGVtIGluIHRlcm1zIG9mIOKAnHRo ZSBpbXBsaWNpdCBncmFudOKAnSBidXQgcmF0aGVyIHRoZSBhc3BlY3RzIG9mIHRoZSB1c2UgY2Fz ZXMgd2XigJlyZSBsb29raW5nIHRvIHNvbHZlLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDstICZuYnNwO0p1c3RpbjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSmFuIDYsIDIwMjAsIGF0IDc6 MTMgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmlj aGFubmFAYW1hem9uLmNvbSI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXTigJlzIG5vdCBhYm91 dCBhbGlnbmluZyB3aXRoIGltcGxpY2l0IGdyYW50IChJIGFncmVlIHRoYXQgc2hvdWxkIG5vdCBi ZSBhIGdvYWwpLCBpdOKAmXMgYWJvdXQgZW5zdXJpbmcgdGhhdCB0aGUgdXNlIGNhc2VzIGJlaW5n IHNlcnZlZCBieSBpbXBsaWNpdCBncmFudCB0b2RheSBjYW4gYmUgbWV0IGJ5IFR4QXV0aCBvciBj YW4gYmUgZGlzbWlzc2VkIGFzIG91dCBvZiBzY29wZSwgYW5kIGJlaW5nIGludGVudGlvbmFsDQog YWJvdXQgYW55IGRlY2lzaW9ucyB0b3dhcmQgdGhlIGxhdHRlci48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5BV1MgSWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RnJvbTo8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+SnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNo ZXJAbWl0LmVkdSI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+TW9uZGF5LCBKYW51 YXJ5IDYsIDIwMjAgYXQgODowOSBBTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5h YmVsbGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj5yaWNo YW5uYUBhbWF6b24uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkRhdmlkIFdhaXRlICZsdDs8YSBocmVmPSJt YWlsdG86ZGF2aWRAYWxrYWxpbmUtc29sdXRpb25zLmNvbSI+ZGF2aWRAYWxrYWxpbmUtc29sdXRp b25zLmNvbTwvYT4mZ3Q7LCBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJk dEBnbWFpbC5jb20iPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9 Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmciPnR4YXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyI+dHhhdXRoQGlldGYub3JnPC9hPiZndDs8 YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L2I+UmU6IFtVTlZFUklGSUVEIFNFTkRFUl0gW1R4YXV0aF0gRnJhbWV3b3JrIHZz IFByb3RvY29sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCB0aGluayDigJxh bGlnbm1lbnQgd2l0aCB0aGUgaW1wbGljaXQgZ3JhbnTigJ0gc2hvdWxkIGJlIGEgZ29hbCBoZXJl LiBJIHRoaW5rIGFkZHJlc3NpbmcgdGhlIHNhbWUgdXNlIGNhc2VzIGFzIHRoZSBpbXBsaWNpdCBn cmFudCBpcyBnb29kLCBidXQgZm9yIHRoYXQgd2XigJl2ZSBnb3QgYSBsb3QgYmV0dGVyIHRvb2xz IHRvZGF5IHRoYW4gd2UgZGlkIGEgZGVjYWRlIGFnbywgYW5kIHdlIGRvbuKAmXQgbmVlZCB0bw0K IG1ha2UgdGhlIHNhbWUgbWlzdGFrZXMgaW4gbmV3IHdvcmsganVzdCBmb3IgdGhlIHNha2Ugb2Yg YWxpZ25pbmcgaXQuJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNlbGYtaXNzdWVkIE9QIG1vZGVsIGRv ZXMgYSBkZWNlbnQgZW5vdWdoIGpvYiBvZiB1c2luZyB3aGF0IHRvb2xzIHdlcmUgdGhlcmUgYXQg dGhlIHRpbWUgdG8gZ2V0IGFyb3VuZCBPSURD4oCZcyBsaW1pdGF0aW9ucywgYnV0IEkgdGhpbmsg dGhlcmXigJlzIGEgbXVjaCBiZXR0ZXIgYXBwcm9hY2ggYXZhaWxhYmxlIHRvIHVzIGhlcmUuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBpbiBhbGwgdHJ1dGgsIHRoZSBhbnN3 ZXIgbWlnaHQgYmUg4oCcc29tZXRoaW5nIGVsc2UgZW50aXJlbHnigJ0uIFdlIGNhbuKAmXQgc29s dmUgZXZlcnkgcHJvYmxlbSBhbmQgdXNlIGNhc2UsIGFuZCBJIGRvbuKAmXQgdGhpbmsgaXQgZG9l cyB0aGlzIHdvcmsgYW55IGZhdm9ycyB0byBvdmVyLWdlbmVyYWxpemUgaXQgYXQgdGhlIGV4cGVu c2Ugb2YgYSBzZXQgb2YgdGhpbmdzIHdlIGRvIHVuZGVyc3RhbmQuIEdyb3VuZGluZw0KIHVzIGxp a2UgdGhhdCBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgdGhhdCBJIHB1dCB0aGUg4oCcdHJhbnNhY3Rp b25hbOKAnSBsYW5ndWFnZSBpbiB0aGUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0LiBJIGFtIHByb3Bv c2luZyB0aGF0IHdlIGFwcHJvYWNoIG5vdCBqdXN0IGEgY2VydGFpbiBzZXQgb2YgcHJvYmxlbXMg YnV0IGRvIHNvIGluIGEgcGFydGljdWxhciB3YXksIHdpdGhvdXQgbmVjZXNzYXJpbHkgcHJlc3Vt aW5nIHRoZSBzb2x1dGlvbi4gSSB0aGluayB3ZQ0KIHdvdWxkIGFsbCB3YW50IHRoaXMgbmV3IHdv cmsgdG8gYmUgZm9jdXNlZCBvbiBzb21ldGhpbmcgdHJhY3RhYmxlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBK YW4gMywgMjAyMCwgYXQgMTo1OCBQTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0Ozxh IGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5yaWNoYW5uYUBhbWF6b24uY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBoYXZlbuKAmXQgc2VlbiBhIGRldGFpbGVkIGFuYWx5c2lzIG9mIGhvdyBpbXBs aWNpdCB1c2UgY2FzZXMgd291bGQgbWFwIG9udG8gVHhBdXRoLCBzbyB3aGlsZSBJIHRoaW5rIHlv dSBhcmUgY29ycmVjdCBJ4oCZbSBub3QgeWV0IGNvbmZpZGVudCB0aGF0IHRoZSBvbmx5IGNoYWxs ZW5nZXMgYXJlIG1pZ3JhdGlvbiByZWxhdGVkLCBhbmQgdGhhdCB0aGVyZSBhcmVu4oCZdCBzdGls bCBzb21lIGltcG9ydGFudCBlZGdlIGNhc2VzDQogbHVya2luZyBpbiB0aGUgaW1wbGljaXQgc3Bh Y2UgdGhhdCBhcmVu4oCZdCB3ZWxsIHNlcnZlZCBieSB0aGUgVHhBdXRoIGFwcHJvYWNoLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGdlbmVyYWxseSBhZ3JlZSB0aGF0IE9JREMgc2VsZi1p c3N1ZWQgT1AgaXMgY29uZmxhdGluZyBzZXZlcmFsIGRpZmZlcmVudCBwcm9ibGVtcyB0aGF0IHdv dWxkIGJlIGJldHRlciBhZGRyZXNzZWQgb24gYW4gaW5kaXZpZHVhbCBiYXNpcy4gVGhvdWdoIGl0 IGRvZXMgZGVtb25zdHJhdGUgaG93IFR4QXV0aOKAmXMgZGVwZW5kZW5jeSBvbiBhIHRyYW5zYWN0 aW9uIGVuZHBvaW50IHJlYWNoYWJsZSBieSB0aGUgY2xpZW50DQogZmF2b3JzIGV4dGVybmFsIGlk ZW50aXR5IHNvbHV0aW9ucyBvdmVyIHRob3NlIHVuZGVyIHRoZSBkaXJlY3QgY29udHJvbCBvZiB0 aGUgZW5kIHVzZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+4oCTJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PkZyb206PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkRhdmlkIFdhaXRlICZsdDs8 YSBocmVmPSJtYWlsdG86ZGF2aWRAYWxrYWxpbmUtc29sdXRpb25zLmNvbSI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+ZGF2aWRAYWxrYWxpbmUtc29sdXRpb25zLmNvbTwvc3Bhbj48L2E+Jmd0 Ozxicj4NCjxiPkRhdGU6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvYj5GcmlkYXksIEphbnVhcnkgMywgMjAyMCBhdCAxMjoyNyBBTTxicj4NCjxiPlRv OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1 b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpy aWNoYW5uYUBhbWF6b24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yaWNoYW5uYUBh bWF6b24uY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5KdXN0aW4gUmljaGVyICZsdDs8YSBocmVm PSJtYWlsdG86anJpY2hlckBtaXQuZWR1Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5qcmlj aGVyQG1pdC5lZHU8L3NwYW4+PC9hPiZndDssIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0 bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZGljay5o YXJkdEBnbWFpbC5jb208L3NwYW4+PC9hPiZndDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnR4 YXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dHhhdXRoQGlldGYub3Jn PC9zcGFuPjwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnR4YXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxi cj4NCjxiPlN1YmplY3Q6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvYj5bVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbVHhhdXRoXSBGcmFtZXdvcmsgdnMg UHJvdG9jb2w8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gSmFuIDIsIDIwMjAsIGF0IDU6MTggUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxl ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3Jn Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMu aWV0Zi5vcmc8L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIGN1cnJlbnQgZG9jdW1lbnQgc2VlbXMgdG8gZG8gYSBiZXR0ZXIgam9iIG9mIGxh eWluZyBvdXQgYSBjb3JlIG1lc3NhZ2UgYW5kIGNvbW11bmljYXRpb24gcGF0dGVybiwgYnV0IGl0 IGRvZXNu4oCZdCBhbGlnbiB3ZWxsIHdpdGggdGhlIGltcGxpY2l0IGdyYW50LiBXZSB3aWxsIHdh bnQgdG8gZGlnIGludG8gcGVyc2lzdGVudCB1c2UgY2FzZXMgZm9yIGltcGxpY2l0IChlLmcuLCBC cmlhbiBDYW1wYmVsbOKAmXMNCiB1c2UgY2FzZSBpbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL29hdXRoL1J1Y1pIS3VSZjZIQ3NXVXlKREswWFJ3dWIzdyI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+dGhpcyBPQXV0aCBtYWlsaW5nIGxpc3QgdGhyZWFkPC9zcGFuPjwv YT4pIHRvIHNlZSBpZiB0aGUgVHhBdXRoIHBhdHRlcm4gY2FuIHNlcnZlIHRoZW0sIG9yIGlmDQog dGhlcmUgYXJlIGdhcHMgdGhhdCBuZWVkIHRvIGJlIGZpbGxlZC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15 IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBtb3N0IGNvbXBsaWNhdGlvbnMgYXJlIGR1ZSB0byB0aGUg Y29tcGF0aWJpbGl0eSBhbmQgbWlncmF0aW9uIHRoYXQgY29tZXMgZnJvbSB0aGUgV0cgcmVjb21t ZW5kaW5nIGFnYWluc3QgZnJvbnQtY2hhbm5lbC9pbXBsaWNpdCBwYXR0ZXJucyBpbiB0aGUgZnJv bnQgY2hhbm5lbCBmb3IgT0F1dGggMi4mbmJzcDtJIGRvbuKAmXQgdGhpbmsgdGhlc2UgdXNlIGNh c2VzIHdvdWxkIGhhdmUNCiBiZWVuIHByZWNsdWRlZCBpbiBhIHdvcmxkIHdoZXJlIG9ubHkgY29k ZSBmbG93IGhhZCBiZWVuIHN0YW5kYXJkaXplZCwgYW5kIHdoZXJlIHRlY2hub2xvZ2llcyB0byBt YWtlIGNvZGUgZmxvdyB2aWFibGUgYXQgaW5pdGlhbCBPQXV0aCAyIHN0YW5kYXJkaXphdGlvbiBo YWQgYmVlbiBhdmFpbGFibGUgKHN1Y2ggYXMgQ09SUykuIFNpbmNlIHdlIG5vdyBsaXZlIGluIHRo YXQgd29ybGQgYW5kIGFyZSB0YWxraW5nIGFib3V0IGFuIGluY29tcGF0aWJsZQ0KIHByb3RvY29s LCBJIGRvbuKAmXQgYmVsaWV2ZSB0aGVzZSBzb3J0cyBvZiBjb21wYXRpYmlsaXR5IG9yIG1pZ3Jh dGlvbiBjb25zaWRlcmF0aW9ucyBhcHBseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgb25seSB1c2UgY2FzZSBJIGtub3cgb2YgaW5kaXJlY3RseSBwdXNoaW5nIGZvciBpbXBs aWNpdCBpcyBPSURDIHNlbGYtaXNzdWVkIHVzZSBjYXNlLiBJIHdvdWxkIGluc3RlYWQgZGVzY3Jp YmUgdGhpcyBhcyBwdXNoaW5nIHRvIHNvbHZlIHNldmVyYWwgbmV3IHVzZSBjYXNlcyBhdCBvbmNl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4xLiBVc2Ugb2YgYSBsb2NhbCAoZS5nLiBub24tZ2xvYmFsbHkgcmVhY2hhYmxlKSBPUDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gQ29tbXVuaWNhdGlvbiB3aGVuIHRoZSBjbGllbnQgYW5k IHRoZSBPUCBjYW5ub3QgZXN0YWJsaXNoIGRpcmVjdCBuZXR3b3JrIGNvbW11bmljYXRpb24sIHN1 Y2ggYXMgd2hlbiBib3RoIGV4aXN0IHNhbmRib3hlZCBvbiBhIGxvY2FsIGRldmljZTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+My4gRGVmaW5pbmcgYW5kIG1hbmRhdGluZyBjbGllbnQgYW5kIE9Q IHNlY3VyaXR5IHBvbGljeSB0byBmaXQgaW50byB0aGUgbW9kZWwgb2YgdGhlIGFib3ZlIHR3byBw b2ludHMsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgcGVyc29uYWxseSBkb27igJl0IHRoaW5rIHRoZSBtZWNoYW5pY3Mgc2Vs Zi1pc3N1ZWQgT0lEQyBsZXZlcmFnZXMgKGN1c3RvbSBVUkwgcmVkaXJlY3RzIGFuZC9vciBsb2Nh bGhvc3QgbGlzdGVuZXJzKSBoYXMgYXBwcm9wcmlhdGUgc2VjdXJpdHkgb3IgcHJpdmFjeSBjb25z aWRlcmF0aW9ucy4gVGhlcmUgYXJlIGFjdHVhbGx5IHplcm8gc2VjdXJpdHkgb3IgcHJpdmFjeSBj b25zaWRlcmF0aW9ucyByZWdhcmRpbmcNCiBzZWxmLWlzc3VlZCwgd2hpY2ggSSBmaW5kIHNvbWV3 aGF0IGRpc2FwcG9pbnRpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyBrbm93IHRoYXQgb25lIG1vYmlsZSBPUyB2ZW5kb3Ig aGFzIGV4cGxpY2l0bHkgcmVjb21tZW5kZWQgYWdhaW5zdCBkZXZlbG9wZXJzIHVzaW5nIGN1c3Rv bSBVUkwgc2NoZW1lcyB0byBzb2x2ZSBuZXcgdXNlIGNhc2VzLCBzdHJvbmdseSByZWNvbW1lbmRp bmcgbWVjaGFuaXNtcyBzdWNoIGFzIGNsYWltZWQgSFRUUFMgVVJMcyBiZSB1c2VkIGluc3RlYWQu IFRoaXMgdmVuZG9yIGhhcyBoYXMgYWxzbyBncmFkdWFsbHkNCiBpbmNyZWFzZWQgdGhlIGNvbXBs ZXhpdHkgYW5kIHJlc3RyaWN0aW9ucyBmb3IgY3VzdG9tIFVSTCB1c2UgYnkgYXBwbGljYXRpb24g ZGV2ZWxvcGVycy4gSW4gbXkgb3BpbmlvbiwgdGhlcmUgaXMgcmlzayBpbiBuZXcgdXNlIG9mIGN1 c3RvbSBVUkwgc2NoZW1lcyBmb3IgbG9jYWwgSVBDLiBJdCBpcyBsaWtlbHkgbm90IGEgY29pbmNp ZGVuY2UgdGhhdCBjdXN0b20gVVJMIHNjaGVtZXMgYXJlIGNob3NlbiBhcyB0aGV5IGFyZSBoaXN0 b3JpY2FsbHkNCiB0aGUgb25seSBjcm9zcy1wbGF0Zm9ybSBsb2NhbCBJUEMgbWVjaGFuaXNtIHdp dGhvdXQgcHJpdmFjeSBjb250cm9scywgdXNlciBjb25zZW50LCBhbmQgYW5kIG90aGVyIHVzYWJp bGl0eSByZXN0cmljdGlvbnMgcGxhY2VkIHVwb24gdGhlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgYWxzbyB3b3J0aCBtZW50 aW9uaW5nIHRoYXQgT0lEQyBzZWxmLWlzc3VlZCBkb2VzIG5vdCBoYXZlIHByb3Zpc2lvbnMgdG8g Z2FpbiBhdXRob3JpemF0aW9uLCB3aGljaCBtaWdodCBtYWtlIGl0IGRpZmZpY3VsdCB0byBjb25z aWRlciBpdCBpbiBzY29wZSBmb3IgdGhpcyBncm91cOKAmXMgY2hhcnRlci48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LURXPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_D346D42B885B434C924A26F6FCC685F8amazoncom_-- From nobody Wed Jan 8 10:39: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 8991F120059 for ; Wed, 8 Jan 2020 10:39:29 -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, 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=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 oezE35ReQG56 for ; Wed, 8 Jan 2020 10:39:27 -0800 (PST) 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 2134B120047 for ; Wed, 8 Jan 2020 10:39:27 -0800 (PST) Received: by mail-il1-x142.google.com with SMTP id t8so3521932iln.4 for ; Wed, 08 Jan 2020 10:39:27 -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=WEJTBuvy448+Y2N7+16JTubJX39ZveBXhmvY6Tz5Qs0=; b=qH414fR3tsnFbCHwCoFZRLJ96CFM2wG4W5jdmUR4urHeEFEMY2UrHXayN2WqtTpvzO flYTrp0iJnCH6cW6jFKjnJfGo/E93xFij2gfeJUgkbt9bJBY1Ky5dmb7PCCmakLMwnHC eBrfIMvkEDtkzQlpWR5c5NNSXdABrHBnSgfhs5ZVrABmLMYoZv9IsrQcEWBW8S26hiDp 95F4okUu6FS/EUIrLsX9CrOaRgOp7gkksVpvQp68rP4jmQCxn6+XSrbHps5nrtQC61yg L4F0a1ht50iGrfn1s55pNqwz6YK8A/QAnYiBeBMDlS61bU8AaA7P09HWQuAEtegyrlEx hikg== 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=WEJTBuvy448+Y2N7+16JTubJX39ZveBXhmvY6Tz5Qs0=; b=d/xvktHgKODrs5ufgzfsC2IZ4CuW6kUm+C3XTseI8ogSoO1WwvJPCQw8SIAm1qykrO su9Fj0wXXFB55b1nBLFmtHTycv/Jvkt1P5Bo9GU629og6XbuQRSlg7QhVGJ0Hx1zZBkO lpffUJmZZDO3qS3MvmPnwcY+JhhH5tDogdPjDsF4OcqWZm9KDRRQ/VrZkBEGLga3pvdm JhPELSCkcq6FYjpcGQk0gcvf4N6E4sqpbgPKXrQ6kEJprbXIXhmSqn9DXjyEVvQEa/V5 6gGIs/FHorITyiu6yQKEgLTWkJFMFj0rzn5+h+MZZczztIEbUaoBKO+zf6WxM3sDPPm7 4xxg== X-Gm-Message-State: APjAAAWoGZfVOLXHYhNizIJ3/WmGPWoQ5a4V0YzeN4BkzGf7MevMPOxp xtMDctMRv3htMPt4BKh3MqjMUd6OcOU= X-Google-Smtp-Source: APXvYqyGt0jmNJRviYZTorwYe2caRMohwUnbDf4W7ku58+wBVJYnwzeo/Txm0005F29pRTxmEj9odA== X-Received: by 2002:a92:1090:: with SMTP id 16mr4946108ilq.298.1578508766275; Wed, 08 Jan 2020 10:39:26 -0800 (PST) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id t25sm817293ios.78.2020.01.08.10.39.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2020 10:39:25 -0800 (PST) Received: by mail-io1-f54.google.com with SMTP id c16so4309711ioh.6 for ; Wed, 08 Jan 2020 10:39:25 -0800 (PST) X-Received: by 2002:a6b:ab81:: with SMTP id u123mr4332786ioe.214.1578508765373; Wed, 08 Jan 2020 10:39:25 -0800 (PST) MIME-Version: 1.0 References: <6DFD1CA6-D334-4FCA-9881-834571A5DE7C@amazon.com> <9C6149E5-144F-442E-862E-D849A9A9FF57@alkaline-solutions.com> <5D7A9B1D-20A4-4F9F-8586-BFA5CCF38B38@mit.edu> In-Reply-To: From: Aaron Parecki Date: Wed, 8 Jan 2020 12:39:14 -0600 X-Gmail-Original-Message-ID: Message-ID: To: Justin Richer Cc: Dick Hardt , David Waite , "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Txauth] Is it a transaction? (was Framework vs Protocol) 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, 08 Jan 2020 18:39:29 -0000 This is a very good description of the motivation for using the term, and it would be great to include this description in the abstract or elsewhere in the spec! ---- Aaron Parecki aaronparecki.com On Wed, Jan 8, 2020 at 12:24 PM Justin Richer wrote: > > On Jan 6, 2020, at 4:33 PM, Dick Hardt wrote: > > > On Mon, Jan 6, 2020 at 8:08 AM Justin Richer wrote: >> >> >> And in all truth, the answer might be =E2=80=9Csomething else entirely= =E2=80=9D. We can=E2=80=99t solve every problem and use case, and I don=E2= =80=99t think it does this work any favors to over-generalize it at the exp= ense of a set of things we do understand. Grounding us like that is one of = the reasons that I put the =E2=80=9Ctransactional=E2=80=9D language in the = proposed charter text. I am proposing that we approach not just a certain s= et of problems but do so in a particular way, without necessarily presuming= the solution. I think we would all want this new work to be focused on som= ething tractable. > > > I completely agree we don't want to solve every problem and use case, and= we need to scope the problem space in some way. > > As I've thought about the term "transaction", it seems to be a misnomer, = particularly when database semantics are applied, where a transaction is al= l or nothing. > > As I understand it, we would like the client to request scoped access to = multiple resources. Not all of the request is required, which is not aligne= d with the definition of transaction above. > > Additionally, in the XYZ draft, the transaction handle is used to refresh= tokens. I would consider this a new interaction, as the AS will be running= policy again, and the refresh may be denied. > > I don't have a better suggestion at this time, but "transaction" does not= quite seem right. > > > As I=E2=80=99ve said before, naming things is hard. I think =E2=80=9Ctran= sactional=E2=80=9D has many aspects that fit, and some connotations that do= n=E2=80=99t. > > I stuck to the word =E2=80=9Ctransaction=E2=80=9D because for me it captu= red an aspect that I hadn=E2=80=99t seen reified in this work before: that = there is an ongoing process between parties who are exchanging things, pass= ing information back and forth over time. The RO and client both provide in= formation to the AS to modify the request over time, and the AS can respond= with what it thinks is needed next. So it=E2=80=99s like a commercial tran= saction in some ways: =E2=80=9CI want to buy that gum=E2=80=9D, =E2=80=9Cth= at=E2=80=99ll be $0.50=E2=80=9D, =E2=80=9Chere=E2=80=99s the money=E2=80=9D= , =E2=80=9Chere=E2=80=99s your change=E2=80=9D, etc. It=E2=80=99s a convers= ation between parties, but a specific one in that one party (the client) is= trying to get something (a token) from another party (the AS). This doesn= =E2=80=99t mean that I think this only fits financial APIs =E2=80=94 you=E2= =80=99ll notice that the API didn=E2=80=99t come into the conversation at a= ll here. > > But in a way the =E2=80=9Ctransactions=E2=80=9D in XYZ are all or nothing= , in the end. You get a token or you don=E2=80=99t, at the end of things. B= ut more importantly, there=E2=80=99s an explicit =E2=80=9CI=E2=80=99m start= ing now=E2=80=9D step with the transaction request, and the explicit =E2=80= =9CI=E2=80=99m continuing something that I already started=E2=80=9D with th= e transaction handle. In XYZ, the request creates something, what I=E2=80= =99m calling a transaction, and that ultimately results in something else, = what I=E2=80=99m calling a token. If something goes amiss, like the user de= nies the request or the client asks for more than it=E2=80=99s allowed to, = then the transaction stops. The fact that the client doesn=E2=80=99t get ev= erything it asked for doesn=E2=80=99t mean the transaction failed, it just = means the results were modified by something within the process. > > So it=E2=80=99s not just the database sense, and it=E2=80=99s not just th= e commerce sense either. Neither is a perfect fit, though, I totally admit.= If we had a better name for it I=E2=80=99d be all for picking something th= at=E2=80=99s more descriptive, but nothing I=E2=80=99ve heard or thought of= matches the process better than =E2=80=9Ctransaction=E2=80=9D for me. > > =E2=80=94 Justin > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Wed Jan 8 11: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 C2F1E1200B8 for ; Wed, 8 Jan 2020 11:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.8 X-Spam-Level: X-Spam-Status: No, score=-11.8 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, RCVD_IN_DNSWL_MED=-2.3, 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 7VJ2r4drLNtu for ; Wed, 8 Jan 2020 11:10:40 -0800 (PST) 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 D978E12003E for ; Wed, 8 Jan 2020 11:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578510641; x=1610046641; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TbdrmhDz9Vr5Ol88ouz5dqge8RhF3rMaRA/CV2Js44Y=; b=cnOLDGpaF44Anl/qFO0bCdNp7FLgcnImbZBNMiT6Xo/1PHpDx+zfbUHW 1o5aoybxELjYvVFK5o2qtg5x/eW7VRHl/ByFBKXSIog4w8ZqWVdRBz4UQ Y0buo0EGvO+TS9juJwut2ozFoarEOajsA+mUjSpJAXFln48Qms3bhPSNC E=; IronPort-SDR: b/WEzlymtihlwl0uIpu6aVKvKk5TLCigDPAew68RSSZslikq0pss98paJe/fzHBqQKeEpgrOYJ U5HgOa0De6DA== X-IronPort-AV: E=Sophos;i="5.69,411,1571702400"; d="scan'208";a="18906570" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-57e1d233.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 08 Jan 2020 19:10:20 +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-57e1d233.us-east-1.amazon.com (Postfix) with ESMTPS id 66CE81417DF; Wed, 8 Jan 2020 19:10:19 +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; Wed, 8 Jan 2020 19:10:18 +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.1367.3; Wed, 8 Jan 2020 19:10: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.1367.000; Wed, 8 Jan 2020 19:10:18 +0000 From: "Richard Backman, Annabelle" To: Aaron Parecki , Justin Richer CC: Dick Hardt , David Waite , "txauth@ietf.org" Thread-Topic: [Txauth] Is it a transaction? (was Framework vs Protocol) Thread-Index: AQHVxlDPFqGOU1NMQESaxIDr86LqiafhGTgA//+CkQA= Date: Wed, 8 Jan 2020 19:10:18 +0000 Message-ID: References: <6DFD1CA6-D334-4FCA-9881-834571A5DE7C@amazon.com> <9C6149E5-144F-442E-862E-D849A9A9FF57@alkaline-solutions.com> <5D7A9B1D-20A4-4F9F-8586-BFA5CCF38B38@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.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.109] Content-Type: text/plain; charset="utf-8" Content-ID: <2808401213279E4C913EBD15D3F544B3@amazon.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Is it a transaction? (was Framework vs Protocol) 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, 08 Jan 2020 19:10:43 -0000 VHJhbnNhY3Rpb24gaXMgc3RpbGwgYSBoZWF2aWx5IG92ZXJsb2FkZWQgdGVybSBhbmQgdGhlcmXi gJlzIGEgbG90IG9mIHJvb20gZm9yIGNvbmZ1c2lvbiwgYXMgaWxsdXN0cmF0ZWQgYnkgdGhlIG5h bWluZyBjb252ZXJzYXRpb24uIFRoZSBmYWN0IHRoYXQgUkFSIGhhcyB1c2UgY2FzZXMgZm9yIGF1 dGhvcml6aW5nIGRpc3RpbmN0IChlLmcuLCBmaW5hbmNpYWwpIHRyYW5zYWN0aW9ucyBhcyBvcHBv c2VkIHRvIG1vcmUgdHJhZGl0aW9uYWwgZ2VuZXJhbCBhY2Nlc3MgdG8gYSByZXNvdXJjZSBkb2Vz IG5vdCBoZWxwLiBJIGRvbuKAmXQgaGF2ZSBhIGJldHRlciBhbHRlcm5hdGl2ZSB0aG91Z2guIFRo ZSBvbmUgd29yZCB0aGF0IGNvbWVzIHRvIG1pbmQgdGhhdCBJIHRoaW5rIGJldHRlciBjYXB0dXJl cyB3aGF0IHlvdeKAmXJlIGRlc2NyaWJpbmcgaXMg4oCcc2Vzc2lvbuKAnSwgYnV0IHRoYXTigJlz IGFyZ3VhYmx5IGp1c3QgYXMgb3ZlcmxvYWRlZCBhcyB0cmFuc2FjdGlvbi4g8J+kt/Cfj7vigI3i mYDvuI8NCg0KVGhlIGNvbnZlcnNhdGlvbiBhcm91bmQgaW1wbGljaXQgZ3JhbnQgaGFzIG1lIHRo aW5raW5nIHRob3VnaOKApiBUaGUgdmFsdWUgb2YgVHhBdXRoIGNvbWVzIGZyb20gdGhlIGlzb2xh dGlvbiBvZiB0aGUgY29yZSBwcm90b2NvbCBmcm9tIHRoZSBleHRlcm5hbCBjb21tdW5pY2F0aW9u IGNoYW5uZWxzLiBBIGxvdCBvZiBPQXV0aCAyLjAncyBwcm9ibGVtcyBhcmlzZSBmcm9tIHRpZ2h0 IGNvdXBsaW5nIGJldHdlZW4gdGhlIHByb3RvY29sIGFuZCB0aGUgY29tbXVuaWNhdGlvbiBjaGFu bmVsIGJldHdlZW4gdGhlIHVzZXIgYWdlbnQgYW5kIHRoZSBBUywgd2hpY2ggaXMgaXJvbmljIGNv bnNpZGVyaW5nIHRoZSBVQS9BUyBpbnRlcmFjdGlvbiBpcyBleHBsaWNpdGx5IG91dHNpZGUgdGhl IHNjb3BlIG9mIHRoZSBwcm90b2NvbCEgU2hvdmluZyBhdXRob3JpemF0aW9uIHJlcXVlc3RzIGlu dG8gcmVkaXJlY3QgVVJMcyBjb25zdHJhaW5zIHVzIGluIHRlcm1zIG9mIHJlcXVlc3Qgc3RydWN0 dXJlIGFuZCBzaXplLCBhbmQgZm9yY2VzIHVzIHRvIHByb3RlY3QgcmVxdWVzdHMgYXMgdGhleSBn byB0aHJvdWdoIHVudHJ1c3RlZCBjaGFubmVscy4gTGlrZXdpc2Ugd2l0aCBhdXRob3JpemF0aW9u IHJlc3BvbnNlcy4NCg0KSW4gY29udHJhc3QsIFR4QXV0aCBhbHdheXMgcnVucyBldmVyeXRoaW5n IG92ZXIgdGhlIGNvbm5lY3Rpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCBBUywgYnJpZGdpbmcg aW50byBvdGhlciBjaGFubmVscyBpbiBtaW5pbWFsIHdheXMsIG9ubHkgYXMgbmVlZGVkLiAgVGhp cyBnaXZlcyByaXNlIHRvIHRoZSAiaGFuZGxlIiBhcyB0aGUgbWluaW11bSBwaWVjZSBvZiBpbmZv cm1hdGlvbiBuZWVkZWQgdG8gYmUgdHJhbnNtaXR0ZWQgYWNyb3NzIG90aGVyIGNoYW5uZWxzLCB3 aGljaCBpbiB0dXJuIGxlYWRzIHRvIHRoZSAidHJhbnNhY3Rpb24iIGNvbmNlcHQuIEFsc28sIHNp bmNlIHdlJ3JlIG5vIGxvbmdlciBjb25zdHJhaW5lZCBieSBtb3JlIGxpbWl0ZWQgY2hhbm5lbHMs IHdlIGNhbiBzdGFydCBtYWtpbmcgY29tcGxleCBzdHJ1Y3R1cmVkIHJlcXVlc3RzLCB3aGljaCBl bmFibGVzIGFsbCB0aGUgb3RoZXIgZnVuIHRoaW5ncyBUeEF1dGggc3VwcG9ydHMsIHN1Y2ggYXMg aW5saW5lIGNsaWVudCByZWdpc3RyYXRpb24gYW5kIGtleSBlc3RhYmxpc2htZW50LCByaWNoIGF1 dGhvcml6YXRpb24gcmVxdWVzdHMsIGV0Yy4gQnV0IGFnYWluLCBhbGwgb2YgdGhpcyBjb21lcyBm cm9tIHRoZSBjb25zaXN0ZW50IHVzZSBvZiB0aGUgY2xpZW50LUFTIGNoYW5uZWwsIGFuZCB0aGUg ZGVjb3VwbGluZyBvZiB0aGUgcHJvdG9jb2wgZnJvbSBvdGhlciBjaGFubmVscy4NCg0KSSBkb24n dCBrbm93IGlmIHRoZXJlIGlzIGEgd2F5IHRvIGNhcHR1cmUgdGhpcyBpbiBhIG5hbWUgKGFuZCBk b24ndCByZWFsbHkgd2FudCB0byBnZXQgYmFjayBpbnRvIHRoZSBuYW1pbmcgY29udmVyc2F0aW9u KSwgYnV0IEkgdGhpbmsgaXQncyBhIHVzZWZ1bCBwZXJzcGVjdGl2ZSBmb3IgdGhlICJmcmFtZXdv cmsiIHZzICJwcm90b2NvbCIgZGlzY3Vzc2lvbi4gQSBsb3Qgb2YgT0F1dGggMi4wJ3MgImZyYW1l d29ya25lc3MiIGNvbWVzIGZyb20gaXRzIGNvdXBsaW5nIHdpdGggdmFyaW91cyBjaGFubmVscy4g T0F1dGggMi4wIHBsdXMgRGV2aWNlIEZsb3cgcGx1cyBQQVIgc3RhcnRzIHRvIHJlc2VtYmxlIFNB TUwsIHdpdGggYSB2YXJpZXR5IG9mICJiaW5kaW5ncyIgZm9yIGF1dGhlbnRpY2F0aW9uIHJlcXVl c3RzIGFuZCByZXNwb25zZXMuIFdlIGNhbiBhbmQgc2hvdWxkIGF2b2lkIHRoYXQgd2l0aCBUeEF1 dGggYnkgZW1waGFzaXppbmcgY2hhbm5lbCBkZWNvdXBsaW5nOiBwcm90b2NvbCBtZXNzYWdlcyBv bmx5IGdvIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIEFTLCBhbmQgb3RoZXIgY2hhbm5lbHMg YXJlIG9ubHkgdXNlZCBpbiBhbiAiYXJ0aWZhY3QgYmluZGluZyIgc3R5bGUuDQoNCuKAkyANCkFu bmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KIA0KDQrvu79PbiAxLzgvMjAs IDEwOjM5IEFNLCAiQWFyb24gUGFyZWNraSIgPGFhcm9uQHBhcmVja2kuY29tPiB3cm90ZToNCg0K ICAgIFRoaXMgaXMgYSB2ZXJ5IGdvb2QgZGVzY3JpcHRpb24gb2YgdGhlIG1vdGl2YXRpb24gZm9y IHVzaW5nIHRoZSB0ZXJtLA0KICAgIGFuZCBpdCB3b3VsZCBiZSBncmVhdCB0byBpbmNsdWRlIHRo aXMgZGVzY3JpcHRpb24gaW4gdGhlIGFic3RyYWN0IG9yDQogICAgZWxzZXdoZXJlIGluIHRoZSBz cGVjIQ0KICAgIA0KICAgIC0tLS0NCiAgICBBYXJvbiBQYXJlY2tpDQogICAgYWFyb25wYXJlY2tp LmNvbQ0KICAgIA0KICAgIA0KICAgIE9uIFdlZCwgSmFuIDgsIDIwMjAgYXQgMTI6MjQgUE0gSnVz dGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiB3cm90ZToNCiAgICA+DQogICAgPiBPbiBKYW4g NiwgMjAyMCwgYXQgNDozMyBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+IHdy b3RlOg0KICAgID4NCiAgICA+DQogICAgPiBPbiBNb24sIEphbiA2LCAyMDIwIGF0IDg6MDggQU0g SnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiB3cm90ZToNCiAgICA+Pg0KICAgID4+IDxz bmlwPg0KICAgID4+IEFuZCBpbiBhbGwgdHJ1dGgsIHRoZSBhbnN3ZXIgbWlnaHQgYmUg4oCcc29t ZXRoaW5nIGVsc2UgZW50aXJlbHnigJ0uIFdlIGNhbuKAmXQgc29sdmUgZXZlcnkgcHJvYmxlbSBh bmQgdXNlIGNhc2UsIGFuZCBJIGRvbuKAmXQgdGhpbmsgaXQgZG9lcyB0aGlzIHdvcmsgYW55IGZh dm9ycyB0byBvdmVyLWdlbmVyYWxpemUgaXQgYXQgdGhlIGV4cGVuc2Ugb2YgYSBzZXQgb2YgdGhp bmdzIHdlIGRvIHVuZGVyc3RhbmQuIEdyb3VuZGluZyB1cyBsaWtlIHRoYXQgaXMgb25lIG9mIHRo ZSByZWFzb25zIHRoYXQgSSBwdXQgdGhlIOKAnHRyYW5zYWN0aW9uYWzigJ0gbGFuZ3VhZ2UgaW4g dGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dC4gSSBhbSBwcm9wb3NpbmcgdGhhdCB3ZSBhcHByb2Fj aCBub3QganVzdCBhIGNlcnRhaW4gc2V0IG9mIHByb2JsZW1zIGJ1dCBkbyBzbyBpbiBhIHBhcnRp Y3VsYXIgd2F5LCB3aXRob3V0IG5lY2Vzc2FyaWx5IHByZXN1bWluZyB0aGUgc29sdXRpb24uIEkg dGhpbmsgd2Ugd291bGQgYWxsIHdhbnQgdGhpcyBuZXcgd29yayB0byBiZSBmb2N1c2VkIG9uIHNv bWV0aGluZyB0cmFjdGFibGUuDQogICAgPg0KICAgID4NCiAgICA+IEkgY29tcGxldGVseSBhZ3Jl ZSB3ZSBkb24ndCB3YW50IHRvIHNvbHZlIGV2ZXJ5IHByb2JsZW0gYW5kIHVzZSBjYXNlLCBhbmQg d2UgbmVlZCB0byBzY29wZSB0aGUgcHJvYmxlbSBzcGFjZSBpbiBzb21lIHdheS4NCiAgICA+DQog ICAgPiBBcyBJJ3ZlIHRob3VnaHQgYWJvdXQgdGhlIHRlcm0gInRyYW5zYWN0aW9uIiwgaXQgc2Vl bXMgdG8gYmUgYSBtaXNub21lciwgcGFydGljdWxhcmx5IHdoZW4gZGF0YWJhc2Ugc2VtYW50aWNz IGFyZSBhcHBsaWVkLCB3aGVyZSBhIHRyYW5zYWN0aW9uIGlzIGFsbCBvciBub3RoaW5nLg0KICAg ID4NCiAgICA+IEFzIEkgdW5kZXJzdGFuZCBpdCwgd2Ugd291bGQgbGlrZSB0aGUgY2xpZW50IHRv IHJlcXVlc3Qgc2NvcGVkIGFjY2VzcyB0byBtdWx0aXBsZSByZXNvdXJjZXMuIE5vdCBhbGwgb2Yg dGhlIHJlcXVlc3QgaXMgcmVxdWlyZWQsIHdoaWNoIGlzIG5vdCBhbGlnbmVkIHdpdGggdGhlIGRl ZmluaXRpb24gb2YgdHJhbnNhY3Rpb24gYWJvdmUuDQogICAgPg0KICAgID4gQWRkaXRpb25hbGx5 LCBpbiB0aGUgWFlaIGRyYWZ0LCB0aGUgdHJhbnNhY3Rpb24gaGFuZGxlIGlzIHVzZWQgdG8gcmVm cmVzaCB0b2tlbnMuIEkgd291bGQgY29uc2lkZXIgdGhpcyBhIG5ldyBpbnRlcmFjdGlvbiwgYXMg dGhlIEFTIHdpbGwgYmUgcnVubmluZyBwb2xpY3kgYWdhaW4sIGFuZCB0aGUgcmVmcmVzaCBtYXkg YmUgZGVuaWVkLg0KICAgID4NCiAgICA+IEkgZG9uJ3QgaGF2ZSBhIGJldHRlciBzdWdnZXN0aW9u IGF0IHRoaXMgdGltZSwgYnV0ICJ0cmFuc2FjdGlvbiIgZG9lcyBub3QgcXVpdGUgc2VlbSByaWdo dC4NCiAgICA+DQogICAgPg0KICAgID4gQXMgSeKAmXZlIHNhaWQgYmVmb3JlLCBuYW1pbmcgdGhp bmdzIGlzIGhhcmQuIEkgdGhpbmsg4oCcdHJhbnNhY3Rpb25hbOKAnSBoYXMgbWFueSBhc3BlY3Rz IHRoYXQgZml0LCBhbmQgc29tZSBjb25ub3RhdGlvbnMgdGhhdCBkb27igJl0Lg0KICAgID4NCiAg ICA+IEkgc3R1Y2sgdG8gdGhlIHdvcmQg4oCcdHJhbnNhY3Rpb27igJ0gYmVjYXVzZSBmb3IgbWUg aXQgY2FwdHVyZWQgYW4gYXNwZWN0IHRoYXQgSSBoYWRu4oCZdCBzZWVuIHJlaWZpZWQgaW4gdGhp cyB3b3JrIGJlZm9yZTogdGhhdCB0aGVyZSBpcyBhbiBvbmdvaW5nIHByb2Nlc3MgYmV0d2VlbiBw YXJ0aWVzIHdobyBhcmUgZXhjaGFuZ2luZyB0aGluZ3MsIHBhc3NpbmcgaW5mb3JtYXRpb24gYmFj ayBhbmQgZm9ydGggb3ZlciB0aW1lLiBUaGUgUk8gYW5kIGNsaWVudCBib3RoIHByb3ZpZGUgaW5m b3JtYXRpb24gdG8gdGhlIEFTIHRvIG1vZGlmeSB0aGUgcmVxdWVzdCBvdmVyIHRpbWUsIGFuZCB0 aGUgQVMgY2FuIHJlc3BvbmQgd2l0aCB3aGF0IGl0IHRoaW5rcyBpcyBuZWVkZWQgbmV4dC4gU28g aXTigJlzIGxpa2UgYSBjb21tZXJjaWFsIHRyYW5zYWN0aW9uIGluIHNvbWUgd2F5czog4oCcSSB3 YW50IHRvIGJ1eSB0aGF0IGd1beKAnSwg4oCcdGhhdOKAmWxsIGJlICQwLjUw4oCdLCDigJxoZXJl 4oCZcyB0aGUgbW9uZXnigJ0sIOKAnGhlcmXigJlzIHlvdXIgY2hhbmdl4oCdLCBldGMuIEl04oCZ cyBhIGNvbnZlcnNhdGlvbiBiZXR3ZWVuIHBhcnRpZXMsIGJ1dCBhIHNwZWNpZmljIG9uZSBpbiB0 aGF0IG9uZSBwYXJ0eSAodGhlIGNsaWVudCkgaXMgdHJ5aW5nIHRvIGdldCBzb21ldGhpbmcgKGEg dG9rZW4pIGZyb20gYW5vdGhlciBwYXJ0eSAodGhlIEFTKS4gVGhpcyBkb2VzbuKAmXQgbWVhbiB0 aGF0IEkgdGhpbmsgdGhpcyBvbmx5IGZpdHMgZmluYW5jaWFsIEFQSXMg4oCUIHlvdeKAmWxsIG5v dGljZSB0aGF0IHRoZSBBUEkgZGlkbuKAmXQgY29tZSBpbnRvIHRoZSBjb252ZXJzYXRpb24gYXQg YWxsIGhlcmUuDQogICAgPg0KICAgID4gQnV0IGluIGEgd2F5IHRoZSDigJx0cmFuc2FjdGlvbnPi gJ0gaW4gWFlaIGFyZSBhbGwgb3Igbm90aGluZywgaW4gdGhlIGVuZC4gWW91IGdldCBhIHRva2Vu IG9yIHlvdSBkb27igJl0LCBhdCB0aGUgZW5kIG9mIHRoaW5ncy4gQnV0IG1vcmUgaW1wb3J0YW50 bHksIHRoZXJl4oCZcyBhbiBleHBsaWNpdCDigJxJ4oCZbSBzdGFydGluZyBub3figJ0gc3RlcCB3 aXRoIHRoZSB0cmFuc2FjdGlvbiByZXF1ZXN0LCBhbmQgdGhlIGV4cGxpY2l0IOKAnEnigJltIGNv bnRpbnVpbmcgc29tZXRoaW5nIHRoYXQgSSBhbHJlYWR5IHN0YXJ0ZWTigJ0gd2l0aCB0aGUgdHJh bnNhY3Rpb24gaGFuZGxlLiBJbiBYWVosIHRoZSByZXF1ZXN0IGNyZWF0ZXMgc29tZXRoaW5nLCB3 aGF0IEnigJltIGNhbGxpbmcgYSB0cmFuc2FjdGlvbiwgYW5kIHRoYXQgdWx0aW1hdGVseSByZXN1 bHRzIGluIHNvbWV0aGluZyBlbHNlLCB3aGF0IEnigJltIGNhbGxpbmcgYSB0b2tlbi4gSWYgc29t ZXRoaW5nIGdvZXMgYW1pc3MsIGxpa2UgdGhlIHVzZXIgZGVuaWVzIHRoZSByZXF1ZXN0IG9yIHRo ZSBjbGllbnQgYXNrcyBmb3IgbW9yZSB0aGFuIGl04oCZcyBhbGxvd2VkIHRvLCB0aGVuIHRoZSB0 cmFuc2FjdGlvbiBzdG9wcy4gVGhlIGZhY3QgdGhhdCB0aGUgY2xpZW50IGRvZXNu4oCZdCBnZXQg ZXZlcnl0aGluZyBpdCBhc2tlZCBmb3IgZG9lc27igJl0IG1lYW4gdGhlIHRyYW5zYWN0aW9uIGZh aWxlZCwgaXQganVzdCBtZWFucyB0aGUgcmVzdWx0cyB3ZXJlIG1vZGlmaWVkIGJ5IHNvbWV0aGlu ZyB3aXRoaW4gdGhlIHByb2Nlc3MuDQogICAgPg0KICAgID4gU28gaXTigJlzIG5vdCBqdXN0IHRo ZSBkYXRhYmFzZSBzZW5zZSwgYW5kIGl04oCZcyBub3QganVzdCB0aGUgY29tbWVyY2Ugc2Vuc2Ug ZWl0aGVyLiBOZWl0aGVyIGlzIGEgcGVyZmVjdCBmaXQsIHRob3VnaCwgSSB0b3RhbGx5IGFkbWl0 LiBJZiB3ZSBoYWQgYSBiZXR0ZXIgbmFtZSBmb3IgaXQgSeKAmWQgYmUgYWxsIGZvciBwaWNraW5n IHNvbWV0aGluZyB0aGF04oCZcyBtb3JlIGRlc2NyaXB0aXZlLCBidXQgbm90aGluZyBJ4oCZdmUg aGVhcmQgb3IgdGhvdWdodCBvZiBtYXRjaGVzIHRoZSBwcm9jZXNzIGJldHRlciB0aGFuIOKAnHRy YW5zYWN0aW9u4oCdIGZvciBtZS4NCiAgICA+DQogICAgPiAg4oCUIEp1c3Rpbg0KICAgID4gLS0N CiAgICA+IFR4YXV0aCBtYWlsaW5nIGxpc3QNCiAgICA+IFR4YXV0aEBpZXRmLm9yZw0KICAgID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCiAgICANCg0K From nobody Thu Jan 9 15:27: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 A666E120128 for ; Thu, 9 Jan 2020 15:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 9TNUlshmWu6j for ; Thu, 9 Jan 2020 15:27:02 -0800 (PST) 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 75A5112003E for ; Thu, 9 Jan 2020 15:27:02 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id y4so126433ljj.9 for ; Thu, 09 Jan 2020 15:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DU2pHT9ZGVRUNvC4u/3l+yUXsHkiK0CXz3V0onCig7A=; b=NCdHg+up8pibgEW65Uzkf16SgSQTyBjrTeAlNV6NVhn0vzJKsHJ6woe7aPWM2oXw2u r58y4YBe8nq1cKT+kUQ4q9ofhyT58fKNAdHVIO+DjzKx2Qllpc950rg0saQPPRpmGPo7 Cs4gn0GVE2sdEpThtJlBgD2KNLWbieYjY/qAFnPHIzjQAQWw6w5hcvP4MyiuRgzuvfcf 4VGm9/WP7vstyZ4Xh8lyDp4WGojPLVFWe6317vJ82ZSs0F5ssNX+vBTJdOZ2KTZzNKDu f8IgcpGAGBqKJG47PeX4kXgj7cTzb1ttfTVevWBAixiTk7K5wEJ5Vgex5vtjDkGjHNyu jxWw== 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=DU2pHT9ZGVRUNvC4u/3l+yUXsHkiK0CXz3V0onCig7A=; b=mg/or8xtT81y4HKaQ0Cmm8rsp1WfT9l/V3OMXsjkdKzBssBx7Gu6SaUcUnjbCJaETu n511MDaUPEK+Q3t67UXEP0rsmNt3CYBzSEcwriX8QmRDtsKz76u0xVs2pQWXHM+H++Zo 3AluC7yL+Vleyvv3N3XLG/jDtnfNft/exfZctP5lzdqvatlPfwELH7dvg2Yt8f6g+n39 MCgKbCByryHWpUEDakM/FbGQaEz6hzzxpLPSPvaIy9qiguxh23LOhWlbDHUA8uOlcfFR SQhzhixDvUPbRz4NkBHZi/SlfSITKZS2mKN3ijww+Ux/WLp64iruJF30ds5yC6QyBVh0 mmxg== X-Gm-Message-State: APjAAAX23HDJchiuwfb6gvI25YLgUw6sRFO9X4r4ThEF+fgS00sW4F0s L6xdtM2MtDvEA0LtSVDE5RE4IDBMkBTgbhFB66h94cdIYGzmnVafRivOClH8QJ9ytnyKW0coqfV hz5gxPWeuYXsW9zM= X-Google-Smtp-Source: APXvYqz/c4Nxhsh71GcBXQW2LONO4viuIEP3xQ8dQD1FKrx2ddteib5dQKa1UNIkDvcDXj4TaG1/53phUc3YMWgey6I= X-Received: by 2002:a2e:8197:: with SMTP id e23mr331642ljg.250.1578612420763; Thu, 09 Jan 2020 15:27:00 -0800 (PST) MIME-Version: 1.0 References: <6DFD1CA6-D334-4FCA-9881-834571A5DE7C@amazon.com> In-Reply-To: <6DFD1CA6-D334-4FCA-9881-834571A5DE7C@amazon.com> From: Brian Campbell Date: Thu, 9 Jan 2020 16:26:34 -0700 Message-ID: To: "Richard Backman, Annabelle" Cc: Justin Richer , Dick Hardt , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000093fa6e059bbd5830" Archived-At: Subject: Re: [Txauth] Framework vs Protocol 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, 09 Jan 2020 23:27:05 -0000 --00000000000093fa6e059bbd5830 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 2, 2020 at 5:18 PM Richard Backman, Annabelle wrote: > The current document seems to do a better job of laying out a core messag= e > and communication pattern, but it doesn=E2=80=99t align well with the imp= licit > grant. We will want to dig into persistent use cases for implicit (e.g., > Brian Campbell=E2=80=99s use case in this OAuth mailing list thread > = ) > to see if the TxAuth pattern can serve them, or if there are gaps that ne= ed > to be filled. > I guess takeaway I'd point to from that is less about the implicit grant per se and more to suggest/remind that this space has had variations on front channel pass everything by value and pass by reference in the front channel with backchannel resolution approaches and swings between preferences for one or the other for a long time. The approach in XZY leans heavily towards the latter but both have their benefits and drawbacks. --=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._ --00000000000093fa6e059bbd5830 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 2, 2020 at 5:18 PM Richard Ba= ckman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
<= div class=3D"gmail_quote">

The current document seems to do a better job of lay= ing out a core message and communication pattern, but it doesn=E2=80=99t al= ign well with the implicit grant. We will want to dig into persistent use c= ases for implicit (e.g., Brian Campbell=E2=80=99s use case in this OAuth mailing list thread) to see if the TxAuth pattern can serve = them, or if there are gaps that need to be filled.


I guess takeaway I'd point= to from that is less about the implicit grant per se and more to suggest/r= emind that this space has had variations on front channel pass everything b= y value and pass by reference in the front channel with backchannel resolut= ion approaches and swings between preferences for one or the other for a lo= ng time. The approach in XZY leans heavily towards the latter but both have= their benefits and drawbacks.

<= 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. --00000000000093fa6e059bbd5830-- From nobody Fri Jan 10 09:05: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 904E9120A09 for ; Fri, 10 Jan 2020 09:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.582 X-Spam-Level: X-Spam-Status: No, score=-0.582 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 qAJs8lCUIfpI for ; Fri, 10 Jan 2020 09:05:04 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3AC12091A for ; Fri, 10 Jan 2020 09:05:04 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id m30so2004996lfp.8 for ; Fri, 10 Jan 2020 09:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SWkbcTPish2Hh0L3sfrtjFkY0davFMkKYp4vABUgqaY=; b=jg9s4Y+ng3LBQNUy1frTnXVMP8KpR7cSHCAuJuHz22sXV9UZF28rCEUBlsPxj7OI8v YIp4+kJJH0k4PfR72XPcFQB+ZXhx744l9Nv1Fi1Q3sBKrTWUrOnAvC7KCSHDtd7DDAsA YsVufuVFTcfvljcld1wN0fDYOVqIiNB/r6HqErxIPE5S8T0RneqjEipk/xtTK5nCjRqb ZBSzzrQZJ9yMItBWwloD30T1UaJiX9yXZOgfLSVmU/x8HVCvK5STf3KRi2r6m9/c5wvh D0NLqN4119Wtc1LyUGNAl2essQKKtXY2vaCTfTQbmzKkX942O8HydsLcbdN6JH6qWn7c 0gYA== 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=SWkbcTPish2Hh0L3sfrtjFkY0davFMkKYp4vABUgqaY=; b=gsxHGc8KQ240AMJqbzIOY06tfkGtOfIotl5wdYwlwTgvxPqGVztveRlBMDmMucvkLy tAxBZ0jasfwnuyqr1+guhlnwWmJZ7NzS+tJM+dYpN8vnX46+H7Qu4TqzpHv0ih1aQUcN HvY0Ld+InAYB7USJd99JhNfMDGnaTCq+PLcXaDK3Vwjfswb2AVFoKmoTs4YWo321BLRg ivACPuRjv6J2mvHtQ1iNvFrX7g43xOzs/b/AN4xksvU6EUbxm6TA2pmD4KMDvkcAlVu3 QURjtjMmWc+wlVmKz/mFSVmz38kQfwDWJCSdo5X179uG4DR0TCZeDKnloT5N7dG6mLYG UfCw== X-Gm-Message-State: APjAAAVaKEqb6QZK/B8/qBhvjP9s3pGaS3cEWCeBPTKaMZvQt4JDM1BU f57fPx9Q9sUnTrGeh5KkOjeSTVYD8hEiWrHtwu8iphwid/0= X-Google-Smtp-Source: APXvYqx9aY8YX0j71ahZupNCEMHI/tSnmr8EbTj+OGjVnMFAjvJzPFYYQ9VMjMwvNAkpD5ELDRiONLjri4GY9J+ku3c= X-Received: by 2002:a19:cb54:: with SMTP id b81mr2961351lfg.188.1578675900555; Fri, 10 Jan 2020 09:05:00 -0800 (PST) MIME-Version: 1.0 From: Dick Hardt Date: Fri, 10 Jan 2020 09:04:49 -0800 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000044a6d1059bcc20e8" Archived-At: Subject: [Txauth] alternative charter writeup 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, 10 Jan 2020 17:05:06 -0000 --00000000000044a6d1059bcc20e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey I've written an alternative charter that I hope captures some of the feedback on Justin's charter. I found it easier to rewrite the charter to broaden the marketplace of ideas. Key ideas: - This work supports existing OAuth 2.0, and OpenID Connect use cases. - The client interacts directly with the authorization server. /Dick ---- This group is chartered to develop a delegated identity and authorization protocol. The use cases supported by this protocol will include widely deployed use cases currently supported by OAuth 2.0, and OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the protocol is initiated by redirecting the user's browser to an authorization server, this protocol will be initiated by the client directly interacting with the authorization server. Additionally, the protocol will allow: - fine-grained specification of resource access - the user to approve requests for identity claims and access to multiple resources in one interaction - web, mobile, single-page, and other client applications - taking advantage of optimization features in HTTP2 and HTTP3 The group will define extension points for this protocol to allow for flexibility in areas including: - discovery of the authorization server - cryptographic agility for keys, message signatures, and proof of possession - user interaction mechanisms including web and non-web methods- token presentation mechanisms and key bindings Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt to simplify porting from OAuth 2.0 and OpenID Connect, and strive to reuse existing semantics such as client identifiers, OAuth 2.0 scopes and access tokens, and OpenID Connect ID Tokens and claims. While the initial work will focus on using HTTP for communication between the client and the authorization server, the working group will strive to enable simple mapping to other protocols such as COAP. =E1=90=A7 --00000000000044a6d1059bcc20e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey

I've written an alternative cha= rter that I hope captures some of the feedback on Justin's charter.

I found it easier to rewrite the charter to broaden t= he marketplace of ideas.=C2=A0

Key ideas:

- This work supports existing OAuth 2.0, and OpenID Connec= t use cases.

- The client interacts directly with = the authorization server.=C2=A0

/Dick
----

This group is chartered to develop= a delegated identity and authorization protocol. The use cases supported b= y this protocol will include widely deployed use cases currently supported = by OAuth 2.0, and OpenID Connect. In contrast to OAuth 2.0 and OpenID Conne= ct, where the protocol is initiated by redirecting the user's browser t= o an authorization server, this protocol will be initiated by the client di= rectly interacting with the authorization server.

Additionall= y, the protocol will allow:
- fine-grained specification of resou= rce access
- the user to approve requests for identity claims and= access to multiple resources in one interaction
- web, mobile, s= ingle-page, and other client applications
- taking advantage of o= ptimization features in HTTP2 and HTTP3

The group will define= extension points for this protocol to allow for flexibility in areas inclu= ding:

- discovery of the authorization server
- cry= ptographic agility for keys, message signatures, and proof of possession=C2= =A0
- user interaction mechanisms including web and non-web metho= ds- token presentation mechanisms and key bindings

Although t= he artifacts for this work are not intended or expected to be backwards-com= patible with OAuth 2.0 or OpenID Connect, they will attempt to simplify por= ting from OAuth 2.0 and OpenID Connect, and strive to reuse existing semant= ics such as client identifiers, OAuth 2.0 scopes and access tokens, and Ope= nID Connect ID Tokens and claims.

While the initial work will= focus on using HTTP for communication between the client and the authoriza= tion server, the working group will strive to enable simple mapping to othe= r protocols such as COAP.


3D""=E1=90=A7
--00000000000044a6d1059bcc20e8-- From nobody Fri Jan 10 12:43: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 1091A120116 for ; Fri, 10 Jan 2020 12:43:56 -0800 (PST) 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 AJJ5QCxqm8x7 for ; Fri, 10 Jan 2020 12:43:51 -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 6EFA6120111 for ; Fri, 10 Jan 2020 12:43:51 -0800 (PST) Received: from [192.168.1.16] (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 00AKhmhO012235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2020 15:43:49 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F5D740BE-B503-40D2-B049-21873988550C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 10 Jan 2020 15:43:48 -0500 In-Reply-To: Cc: txauth@ietf.org To: Dick Hardt References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 10 Jan 2020 20:43:56 -0000 --Apple-Mail=_F5D740BE-B503-40D2-B049-21873988550C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Dick. I=E2=80=99ve been working on an updated charter based on = everyone=E2=80=99s feedback, and I was aiming to have out today anyway, = so this timing is helpful. So here=E2=80=99s my take on a new charter, = incorporating some of your points below: This group is chartered to develop a delegation protocol for identity, = authorization, and API access. This protocol will allow an authorizing = party to delegate access to client software through an authorization = server. The use cases supported by this protocol will include widely = deployed use cases currently supported by OAuth 2.0 and OpenID Connect.=20= The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will be = initiated by the client interacting directly with the authorization = server (in contrast with OAuth 2 which is initiated by the client = redirecting the user=E2=80=99s browser). The client will involve the = authorizing party as necessary through interaction mechanisms indicated = by the protocol.=20 Additionally, the delegation process will allow for: - Fine-grained specification of resource access - Approval of identity claims and multiple resources in a single = interaction - Delegation between multiple users - Web, mobile, single-page, and other types of client 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 providing user, software, organization, and other = pieces of information used in authorization decisions - Token presentation mechanisms and key bindings 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 porting from OAuth 2.0 and OpenID Connect to the new = protocol where possible. While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3, and = will strive to enable simple mapping to other protocols such as COAP. > On Jan 10, 2020, at 12:04 PM, Dick Hardt wrote: >=20 > Hey >=20 > I've written an alternative charter that I hope captures some of the = feedback on Justin's charter. >=20 > I found it easier to rewrite the charter to broaden the marketplace of = ideas.=20 >=20 > Key ideas: >=20 > - This work supports existing OAuth 2.0, and OpenID Connect use cases. >=20 > - The client interacts directly with the authorization server.=20 >=20 > /Dick >=20 > ---- >=20 > This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the = protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server. >=20 > Additionally, the protocol will allow: > - fine-grained specification of resource access > - the user to approve requests for identity claims and access to = multiple resources in one interaction > - web, mobile, single-page, and other client applications > - taking advantage of optimization features in HTTP2 and HTTP3 >=20 > The group will define extension points for this protocol to allow for = flexibility in areas including: >=20 > - discovery of the authorization server > - cryptographic agility for keys, message signatures, and proof of = possession=20 > - user interaction mechanisms including web and non-web methods- token = presentation mechanisms and key bindings >=20 > Although the artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 or OpenID Connect, they will = attempt to simplify porting from OAuth 2.0 and OpenID Connect, and = strive to reuse existing semantics such as client identifiers, OAuth 2.0 = scopes and access tokens, and OpenID Connect ID Tokens and claims. >=20 > While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = strive to enable simple mapping to other protocols such as COAP. >=20 >=20 > =E1=90=A7 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_F5D740BE-B503-40D2-B049-21873988550C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, Dick. I=E2=80=99ve been working on an updated charter = based on everyone=E2=80=99s feedback, and I was aiming to have out today = anyway, so this timing is helpful. So here=E2=80=99s my take on a new = charter, incorporating some of your points below:

This group is chartered to = develop a delegation protocol for identity, authorization, and API = access. This protocol will allow an authorizing party to delegate access = to client software through an authorization server. The use cases = supported by this protocol will include widely deployed use cases = currently supported by OAuth 2.0 and OpenID Connect. 

The delegation process = will be acted upon by multiple parties in the protocol, each performing = a specific role. The protocol will be initiated by the client = interacting directly with the authorization server (in contrast with = OAuth 2 which is initiated by the client redirecting the user=E2=80=99s = browser). The client will involve the authorizing party as necessary = through interaction mechanisms indicated by the = protocol. 

Additionally, the delegation process will allow = for:

- = Fine-grained specification of resource access
- = Approval of identity claims and multiple resources in a single = interaction
- Delegation between multiple = users
- Web, mobile, single-page, and other types = of client 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 providing user, software, organization, and = other pieces of information used in authorization decisions
- Token presentation mechanisms and key bindings

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 porting from OAuth 2.0 and = OpenID Connect to the new protocol where possible.

While the initial work will focus on using HTTP for = communication between the client and the authorization server, the = working group will seek to take advantage of optimization features of = HTTP2 and HTTP3, and will strive to enable simple mapping to other = protocols such as COAP.

On Jan 10, 2020, at 12:04 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

Hey

I've written an alternative charter = that I hope captures some of the feedback on Justin's charter.

I found it easier to = rewrite the charter to broaden the marketplace of ideas. 

Key ideas:

- This work supports = existing OAuth 2.0, and OpenID Connect use cases.
- The client interacts directly with = the authorization server. 

/Dick

----

This group is chartered to develop a = delegated identity and authorization protocol. The use cases supported = by this protocol will include widely deployed use cases currently = supported by OAuth 2.0, and OpenID Connect. In contrast to OAuth 2.0 and = OpenID Connect, where the protocol is initiated by redirecting the = user's browser to an authorization server, this protocol will be = initiated by the client directly interacting with the authorization = server.

Additionally, the protocol = will allow:
- fine-grained specification of = resource access
- the user to approve requests for = identity claims and access to multiple resources in one = interaction
- web, mobile, single-page, and other = client applications
- taking advantage of = optimization features in HTTP2 and HTTP3

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

- discovery of the authorization server
- = cryptographic agility for keys, message signatures, and proof of = possession 
- user interaction mechanisms = including web and non-web methods- token presentation mechanisms and key = bindings

Although the artifacts for = this work are not intended or expected to be backwards-compatible with = OAuth 2.0 or OpenID Connect, they will attempt to simplify porting from = OAuth 2.0 and OpenID Connect, and strive to reuse existing semantics = such as client identifiers, OAuth 2.0 scopes and access tokens, and = OpenID Connect ID Tokens and claims.

While the initial work will focus on using HTTP for = communication between the client and the authorization server, the = working group will strive to enable simple mapping to other protocols = such as COAP.


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

= --Apple-Mail=_F5D740BE-B503-40D2-B049-21873988550C-- From nobody Fri Jan 10 18:56: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 2B69612002E for ; Fri, 10 Jan 2020 18:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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] 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 87J7n_423B7l for ; Fri, 10 Jan 2020 18:56:29 -0800 (PST) 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 AF607120018 for ; Fri, 10 Jan 2020 18:56:28 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id u1so4127918ljk.7 for ; Fri, 10 Jan 2020 18:56:28 -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=itI5XUApbOsazEdEJjSwdSwTqig7Jz3uhgMOXIsXiB4=; b=Y6eJWZ5ohImxkCFTshwAvQVAeQRLlBYGY5lwpxwxvUYtKjIsiUmDp4fHrrcFZvOVuh BcHl8OjGUPpPG7TR8zvYHMiaxr7lrrY7cssQS78Xpc/+0KKqWlJh1/R0mcolb65tGsI9 794HQVPV2b/WRGbVlJ0LXAvKOuIeYDW3GYE1UYEl9r/a2l2xnobsHsxm1DxCTFyvw4gf aj9qyw0wjXQmNegEZquA8iQiKAkNpZK4iPZvJHu5DDyT750SVzx00ArJwOPcvjQylS7v yK7bsO1NqER23dGF428jfXmvw5S6wyiclN5e6OexERZRq28i9GyuDwOj+mhHB2Bz732p pceg== 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=itI5XUApbOsazEdEJjSwdSwTqig7Jz3uhgMOXIsXiB4=; b=eyoWoWAYHPQZY4aLI86Gq11JJhlZDI7kk65cCkCdZBShPpZ7JerlZguMWgv6QtlNXF dtvAZlXoxMhGvgt14Rs8vkSakuyLs7t6iZL8/p39cgMvhv2btDXNs59PdYqlqr0qyXbw XdVxPAH0OKsr1FLqdjBeycgcLlE5DAWXmcF07WbIcrTHfBGSuTEJTepC1CBfT5it1sGQ dg058S6NJegnJXrLt5/vZ6fglZ9r2ktrf8YoxQYMHjxJcB+VvKnEsnu/HyNU0mJax6Jg cRpTgi6wUVcx3w5PDkgiNCW2UEL43mtHAxdg02EYB0A18MZtNV4rpoLTIsW9lGObvrc9 VhfQ== X-Gm-Message-State: APjAAAW6mYDg3sfWx3Wo1wwYrHDTJmJddveC1hFmTZ92vJsvRhjSgTcz 7uVbRyF9eN5moDXlzHU25SCRu2eQ2QhZqgteCQrU96Bv X-Google-Smtp-Source: APXvYqzPGKG+vqWxyiJ8kIMunUAoUx+HhOMF3SqGm/MQSkxuBu1xLGPoHvKoLPtnuXLeaMnnN5uz8iyOhsGdJckA0ko= X-Received: by 2002:a2e:7505:: with SMTP id q5mr4543614ljc.7.1578711386871; Fri, 10 Jan 2020 18:56:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 10 Jan 2020 18:56:15 -0800 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000006adda7059bd46345" Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 11 Jan 2020 02:56:32 -0000 --0000000000006adda7059bd46345 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This looks even better! Thanks Justin. What do others think of the proposed charter now? =E1=90=A7 On Fri, Jan 10, 2020 at 12:43 PM Justin Richer wrote: > Thanks, Dick. I=E2=80=99ve been working on an updated charter based on ev= eryone=E2=80=99s > feedback, and I was aiming to have out today anyway, so this timing is > helpful. So here=E2=80=99s my take on a new charter, incorporating some o= f your > points below: > > This group is chartered to develop a delegation protocol for identity, > authorization, and API access. This protocol will allow an authorizing > party to delegate access to client software through an authorization > server. The use cases supported by this protocol will include widely > deployed use cases currently supported by OAuth 2.0 and OpenID Connect. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will be initiated > by the client interacting directly with the authorization server (in > contrast with OAuth 2 which is initiated by the client redirecting the > user=E2=80=99s browser). The client will involve the authorizing party as= necessary > through interaction mechanisms indicated by the protocol. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of resource access > - Approval of identity claims and multiple resources in a single > interaction > - Delegation between multiple users > - Web, mobile, single-page, and other types of client 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 providing user, software, organization, and other pieces > of information used in authorization decisions > - Token presentation mechanisms and key bindings > > 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 porting from OAuth 2.0 and OpenID Connect to the > new protocol where possible. > > While the initial work will focus on using HTTP for communication between > the client and the authorization server, the working group will seek to > take advantage of optimization features of HTTP2 and HTTP3, and will stri= ve > to enable simple mapping to other protocols such as COAP. > > On Jan 10, 2020, at 12:04 PM, Dick Hardt wrote: > > Hey > > I've written an alternative charter that I hope captures some of the > feedback on Justin's charter. > > I found it easier to rewrite the charter to broaden the marketplace of > ideas. > > Key ideas: > > - This work supports existing OAuth 2.0, and OpenID Connect use cases. > > - The client interacts directly with the authorization server. > > /Dick > > ---- > > This group is chartered to develop a delegated identity and authorization > protocol. The use cases supported by this protocol will include widely > deployed use cases currently supported by OAuth 2.0, and OpenID Connect. = In > contrast to OAuth 2.0 and OpenID Connect, where the protocol is initiated > by redirecting the user's browser to an authorization server, this protoc= ol > will be initiated by the client directly interacting with the authorizati= on > server. > > Additionally, the protocol will allow: > - fine-grained specification of resource access > - the user to approve requests for identity claims and access to multiple > resources in one interaction > - web, mobile, single-page, and other client applications > - taking advantage of optimization features in HTTP2 and HTTP3 > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - discovery of the authorization server > - cryptographic agility for keys, message signatures, and proof of > possession > - user interaction mechanisms including web and non-web methods- token > presentation mechanisms and key bindings > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt = to > simplify porting from OAuth 2.0 and OpenID Connect, and strive to reuse > existing semantics such as client identifiers, OAuth 2.0 scopes and acces= s > tokens, and OpenID Connect ID Tokens and claims. > > While the initial work will focus on using HTTP for communication between > the client and the authorization server, the working group will strive to > enable simple mapping to other protocols such as COAP. > > > =E1=90=A7 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --0000000000006adda7059bd46345 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This looks even better! Thanks Justin.

= What do others think of the proposed charter now?=C2=A0
3D""=E1=90=A7

On Fri, Jan 10, 2020 at 12:43 PM Justin Richer <jricher@mit.edu> wrote:
Thanks, Dick. I=E2=80=99ve been working on an updated charter bas= ed on everyone=E2=80=99s feedback, and I was aiming to have out today anywa= y, so this timing is helpful. So here=E2=80=99s my take on a new charter, i= ncorporating some of your points below:

This group is charter= ed to develop a delegation protocol for identity, authorization, and API ac= cess. This protocol will allow an authorizing party to delegate access to c= lient software through an authorization server. The use cases supported by = this protocol will include widely deployed use cases currently supported by= OAuth 2.0 and OpenID Connect.=C2=A0

The delegatio= n process will be acted upon by multiple parties in the protocol, each perf= orming a specific role. The protocol will be initiated by the client intera= cting directly with the authorization server (in contrast with OAuth 2 whic= h is initiated by the client redirecting the user=E2=80=99s browser). The c= lient will involve the authorizing party as necessary through interaction m= echanisms indicated by the protocol.=C2=A0

Additio= nally, the delegation process will allow for:

- Fi= ne-grained specification of resource access
- Approval of identit= y claims and multiple resources in a single interaction
- Delegat= ion between multiple users
- Web, mobile, single-page, and other = types of client applications

The group will define= extension points for this protocol to allow for flexibility in areas inclu= ding:

- Cryptographic agility for keys, message si= gnatures, and proof of possession=C2=A0
- User interaction mechan= isms including web and non-web methods
- Mechanisms for providing= user, software, organization, and other pieces of information used in auth= orization decisions
- Token presentation mechanisms and key bindi= ngs

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
- Query of token rights by resource servers
Although the artifacts for this work are not intended or expec= ted to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group = will=C2=A0attempt to simplify porting from OAuth 2.0 and OpenID Connect to = the new protocol where possible.

While the initial work will focus o= n using HTTP for communication between the client and the authorization ser= ver, the working group will seek to take advantage of optimization features= of HTTP2 and HTTP3, and will strive to=C2=A0enable simple mapping to other= protocols such as COAP.

On Jan 10, 2020, at 12:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey

I've= written an alternative charter that I hope captures some of the feedback o= n Justin's charter.

I found it easier to rewri= te the charter to broaden the marketplace of ideas.=C2=A0

Key ideas:

- This work supports existing O= Auth 2.0, and OpenID Connect use cases.

- The clie= nt interacts directly with the authorization server.=C2=A0

/Dick

----

This gr= oup is chartered to develop a delegated identity and authorization protocol= . The use cases supported by this protocol will include widely deployed use= cases currently supported by OAuth 2.0, and OpenID Connect. In contrast to= OAuth 2.0 and OpenID Connect, where the protocol is initiated by redirecti= ng the user's browser to an authorization server, this protocol will be= initiated by the client directly interacting with the authorization server= .

Additionally, the protocol will allow:
- fine-gra= ined specification of resource access
- the user to approve reque= sts for identity claims and access to multiple resources in one interaction=
- web, mobile, single-page, and other client applications
<= div>- taking advantage of optimization features in HTTP2 and HTTP3

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

- discovery of the authoriza= tion server
- cryptographic agility for keys, message signatures,= and proof of possession=C2=A0
- user interaction mechanisms incl= uding web and non-web methods- token presentation mechanisms and key bindin= gs

Although the artifacts for this work are not intended or e= xpected to be backwards-compatible with OAuth 2.0 or OpenID Connect, they w= ill attempt to simplify porting from OAuth 2.0 and OpenID Connect, and stri= ve to reuse existing semantics such as client identifiers, OAuth 2.0 scopes= and access tokens, and OpenID Connect ID Tokens and claims.

= While the initial work will focus on using HTTP for communication between t= he client and the authorization server, the working group will strive to en= able simple mapping to other protocols such as COAP.


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

--0000000000006adda7059bd46345-- From nobody Fri Jan 10 23:11: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 71ED7120124 for ; Fri, 10 Jan 2020 23:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 lwnURMmWWgPh for ; Fri, 10 Jan 2020 23:11:22 -0800 (PST) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0: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 85EAE12004F for ; Fri, 10 Jan 2020 23:11:22 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id 19so4272293otz.3 for ; Fri, 10 Jan 2020 23:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2MGFImrdPk0dmKaAx3eM6313Vr7zEqickd7p9vRR5Ig=; b=Gbvp837lqHcc/+/9VxGF7g0VVDWmE3xCEJm7rEqPQOhTzabg/Al9drO3KYSBucVvvo rtRsLailAVdQXwN8WekOawSzbyFUYejIKvjnzigxh1vKuWiEr1p/hmHt9bJBdo5u8Rs5 ssuSNtXPjBkhU2dYiCr4BDmU5VyyKTmhoRweA= 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=2MGFImrdPk0dmKaAx3eM6313Vr7zEqickd7p9vRR5Ig=; b=rYj5iZ2q5pL29ksLLUZcTfSBfr6cAxPuWhvvLhHmg3LXVHtzVL5hh5Nut5eb6HKFa5 OVXS55HJyIQVvAbe/sUBbWjG2cJwpBM/N4A2UQ0afKnIsZIpiWFFHIPvS1MJrlyQaMHG RewmjcSkvHnXKtBz/qJRaHshTe9oHowMzssqS19xnjzj6EMJEC4ywcujGtD+F0xwHu7/ rbytjI48WJlf5M7LLySmslyZShFgkWI05d/qIk++eQSnK9dxsGRBk1qDGAeO88QtBaK4 DwTLUKjypYf/LXYe3VSdm2s6mSgz0C4iU9EmWEIzce9hV4ggJ7WwAnDYC7cnBdJtuJaF 3SUw== X-Gm-Message-State: APjAAAXu40i5+WdlXerDz4udm00/tQSe5g5aQDOD8wbsnp4oGzWMgxpm SsGsruIRV6sdxsFGKQIfQKaSPU0YHRO1ioLK0bTX5w== X-Google-Smtp-Source: APXvYqwRjeX/REwlQMMFE3MSC2r6AhpzRfLY0go2UyXoGHWlP8znWG9EQHJcpCDTCdoMOmT/5jZD+EaYtCpTM+6S7rY= X-Received: by 2002:a9d:7cd9:: with SMTP id r25mr5495341otn.326.1578726681564; Fri, 10 Jan 2020 23:11:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Hope-Bailie Date: Sat, 11 Jan 2020 09:11:10 +0200 Message-ID: To: Dick Hardt Cc: Justin Richer , txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000000d6be9059bd7f3d4" Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 11 Jan 2020 07:11:26 -0000 --0000000000000d6be9059bd7f3d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Sat, Jan 11, 2020 at 04:56 Dick Hardt wrote: > This looks even better! Thanks Justin. > > What do others think of the proposed charter now? > =E1=90=A7 > > On Fri, Jan 10, 2020 at 12:43 PM Justin Richer wrote: > >> Thanks, Dick. I=E2=80=99ve been working on an updated charter based on e= veryone=E2=80=99s >> feedback, and I was aiming to have out today anyway, so this timing is >> helpful. So here=E2=80=99s my take on a new charter, incorporating some = of your >> points below: >> >> This group is chartered to develop a delegation protocol for identity, >> authorization, and API access. This protocol will allow an authorizing >> party to delegate access to client software through an authorization >> server. The use cases supported by this protocol will include widely >> deployed use cases currently supported by OAuth 2.0 and OpenID Connect. >> >> The delegation process will be acted upon by multiple parties in the >> protocol, each performing a specific role. The protocol will be initiate= d >> by the client interacting directly with the authorization server (in >> contrast with OAuth 2 which is initiated by the client redirecting the >> user=E2=80=99s browser). The client will involve the authorizing party a= s necessary >> through interaction mechanisms indicated by the protocol. >> >> Additionally, the delegation process will allow for: >> >> - Fine-grained specification of resource access >> - Approval of identity claims and multiple resources in a single >> interaction >> - Delegation between multiple users >> - Web, mobile, single-page, and other types of client 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 providing user, software, organization, and other piece= s >> of information used in authorization decisions >> - Token presentation mechanisms and key bindings >> >> 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 porting from OAuth 2.0 and OpenID Connect to th= e >> new protocol where possible. >> >> While the initial work will focus on using HTTP for communication betwee= n >> the client and the authorization server, the working group will seek to >> take advantage of optimization features of HTTP2 and HTTP3, and will str= ive >> to enable simple mapping to other protocols such as COAP. >> >> On Jan 10, 2020, at 12:04 PM, Dick Hardt wrote: >> >> Hey >> >> I've written an alternative charter that I hope captures some of the >> feedback on Justin's charter. >> >> I found it easier to rewrite the charter to broaden the marketplace of >> ideas. >> >> Key ideas: >> >> - This work supports existing OAuth 2.0, and OpenID Connect use cases. >> >> - The client interacts directly with the authorization server. >> >> /Dick >> >> ---- >> >> This group is chartered to develop a delegated identity and authorizatio= n >> protocol.. The use cases supported by this protocol will include widely >> deployed use cases currently supported by OAuth 2.0, and OpenID Connect.= In >> contrast to OAuth 2.0 and OpenID Connect, where the protocol is initiate= d >> by redirecting the user's browser to an authorization server, this proto= col >> will be initiated by the client directly interacting with the authorizat= ion >> server.. >> >> >> Additionally, the protocol will allow: >> - fine-grained specification of resource access >> - the user to approve requests for identity claims and access to multipl= e >> resources in one interaction >> - web, mobile, single-page, and other client applications >> - taking advantage of optimization features in HTTP2 and HTTP3 >> >> The group will define extension points for this protocol to allow for >> flexibility in areas including: >> >> - discovery of the authorization server >> - cryptographic agility for keys, message signatures, and proof of >> possession >> - user interaction mechanisms including web and non-web methods- token >> presentation mechanisms and key bindings >> >> Although the artifacts for this work are not intended or expected to be >> backwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt= to >> simplify porting from OAuth 2.0 and OpenID Connect, and strive to reuse >> existing semantics such as client identifiers, OAuth 2.0 scopes and acce= ss >> tokens, and OpenID Connect ID Tokens and claims. >> >> While the initial work will focus on using HTTP for communication betwee= n >> the client and the authorization server, the working group will strive t= o >> enable simple mapping to other protocols such as COAP. >> >> >> =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 Sent from a mobile device, please excuse any typos --0000000000000d6be9059bd7f3d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Sat, Jan 11,= 2020 at 04:56 Dick Hardt <dick.= hardt@gmail.com> wrote:
T= his looks even better! Thanks Justin.

What do others thi= nk of the proposed charter now?=C2=A0
3D""=E1=90=A7

On Fri, Jan 10, 2020= at 12:43 PM Justin Richer <jricher@mit.edu> wrote:
Thanks, Dick. I=E2=80=99ve been working on an u= pdated charter based on everyone=E2=80=99s feedback, and I was aiming to ha= ve out today anyway, so this timing is helpful. So here=E2=80=99s my take o= n a new charter, incorporating some of your points below:

Thi= s group is chartered to develop a delegation protocol for identity, authori= zation, and API access. This protocol will allow an authorizing party to de= legate access to client software through an authorization server. The use c= ases supported by this protocol will include widely deployed use cases curr= ently supported by OAuth 2.0 and OpenID Connect.=C2=A0

=
The delegation process will be acted upon by multiple parties in the p= rotocol, each performing a specific role. The protocol will be initiated by= the client interacting directly with the authorization server (in contrast= with OAuth 2 which is initiated by the client redirecting the user=E2=80= =99s browser). The client will involve the authorizing party as necessary t= hrough interaction mechanisms indicated by the protocol.=C2=A0
Additionally, the delegation process will allow for:

- Fine-grained specification of resource access
-= Approval of identity claims and multiple resources in a single interaction=
- Delegation between multiple users
- Web, mobile, sin= gle-page, and other types of client applications

T= he group will define extension points for this protocol to allow for flexib= ility in areas including:

- Cryptographic agility = for keys, message signatures, and proof of possession=C2=A0
- Use= r interaction mechanisms including web and non-web methods
- Mech= anisms for providing user, software, organization, and other pieces of info= rmation used in authorization decisions
- Token presentation mech= anisms and key bindings

Additionally, the group wi= ll 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 n= ot intended or expected to be backwards-compatible with OAuth 2.0 or OpenID= Connect, the group will=C2=A0attempt to simplify porting from OAuth 2.0 an= d OpenID Connect to the new protocol where possible.

While the initi= al work will focus on using HTTP for communication between the client and t= he authorization server, the working group will seek to take advantage of o= ptimization features of HTTP2 and HTTP3, and will strive to=C2=A0enable sim= ple mapping to other protocols such as COAP.

On Jan 10, 2020, at 12:04 PM, Dick Hardt <dick.hardt@gmail.co= m> wrote:

<= div>
Hey

= I've written an alternative charter that I hope captures some of the fe= edback on Justin's charter.

I found it easier = to rewrite the charter to broaden the marketplace of ideas.=C2=A0

Key ideas:

- This work supports ex= isting OAuth 2.0, and OpenID Connect use cases.

- = The client interacts directly with the authorization server.=C2=A0

/Dick

<= /div>
=
----

This group is chartered to develop a delegated identit= y and authorization protocol.. The use cases supported by this protocol wil= l include widely deployed use cases currently supported by OAuth 2.0, and O= penID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the proto= col is initiated by redirecting the user's browser to an authorization = server, this protocol will be initiated by the client directly interacting = with the authorization server..
<= /div>
=
Additionally, the protocol will allow:
- fine-grained specifica= tion of resource access
- the user to approve requests for identi= ty claims and access to multiple resources in one interaction
- w= eb, mobile, single-page, and other client applications
- taking a= dvantage of optimization features in HTTP2 and HTTP3

The grou= p will define extension points for this protocol to allow for flexibility i= n areas including:

- discovery of the authorization server
- cryptographic agility for keys, message signatures, and proof of = possession=C2=A0
- user interaction mechanisms including web and = non-web methods- token presentation mechanisms and key bindings
<= br>Although the artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt to= simplify porting from OAuth 2.0 and OpenID Connect, and strive to reuse ex= isting semantics such as client identifiers, OAuth 2.0 scopes and access to= kens, and OpenID Connect ID Tokens and claims.

While the init= ial work will focus on using HTTP for communication between the client and = the authorization server, the working group will strive to enable simple ma= pping to other protocols such as COAP.


=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
--
Sent from a mobile device, please excuse= any typos
--0000000000000d6be9059bd7f3d4-- From nobody Sat Jan 11 13:08: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 AA7D712004E for ; Sat, 11 Jan 2020 13:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=0.852, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZjNUWbEZDo0E for ; Sat, 11 Jan 2020 13:08:19 -0800 (PST) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F4C12001A for ; Sat, 11 Jan 2020 13:08:18 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id p9so5544238wmc.2 for ; Sat, 11 Jan 2020 13:08:18 -0800 (PST) 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=zWrUt9WJAeLJEJv5ZDTnEHIRkmxS1Lw4VkC7OV1ukyc=; b=LqOn+4m4fLLCDd4yaL7WfH3likvFZN1qrEH9z6C4djT4D669Cgp1EAuqYhfMWnjvHu 4suM+ib/VqcAblug3VSe3HQgSndhF7EwfoJyS+U9UhuLyrWUcWdzSydCtq18bq42QuGk yEjlm9+qTufL0iBPsOjEAEyxxPgG+T4OxO3uDl1VKfq0JG//Ye4f1B+aYI9S6uoyGjCs k2QxsSOs5FNGtJhfQCjZcekpCGbGzl5P1te6sS1/ZG1P6px/lbqLy4MdPepaRLQSppjC /t96Cgh7oE6ZSqFG4O8iJZKoFqSZ2+tJdA2BABp1loXurzwvjejHAV0IWC+YfBMA/sJJ +Kgg== 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=zWrUt9WJAeLJEJv5ZDTnEHIRkmxS1Lw4VkC7OV1ukyc=; b=dH9ExF5X9s5q02oMFPx0avc1xyPkDcVBF+BPm2ct6g26PKNjrse8PD3lG6VcFVdVO8 Jm3jU8SF14UYoMNpxJFtJFgrdPt+WiQPEN7whLbV9ch8Gt3LZF8rn7a60eq8avbpaRhl 1lnFdmNOV5fGb2F+Rfyh5/h1AizUXPeZYTVxpq07W6WRHxIHvJq46FmCQnVZw6Epo9CH Ge251uDqcsavEsE28u3oPbbptL1yDOVIRmwg/JHe2Xwyt7QgoXy75GvukjaBwKlpukxS NbxaApUPvt/JXp/DLj2tArsLpakaWmbiJTCkZEIw88DdixI9MKP16TJcvR0u7pFwnSYv 2/5w== X-Gm-Message-State: APjAAAUIffbBpheh/5szu7EXVJAZa9cvymuVxBQQUi/NTdHnnOa6GtOE qoAC8nHK2TjhntAD63Kbo+c= X-Google-Smtp-Source: APXvYqw/zSbk3LreYKAuVX0o+HKbBU0/C9OEtTRdayDf+if3MoYrmyenrZmHCMXgiIZdlaW/BTrM4Q== X-Received: by 2002:a1c:dc85:: with SMTP id t127mr11503621wmg.16.1578776896963; Sat, 11 Jan 2020 13:08:16 -0800 (PST) Received: from [10.0.0.144] (bzq-79-180-23-198.red.bezeqint.net. [79.180.23.198]) by smtp.gmail.com with ESMTPSA id q14sm7906611wmj.14.2020.01.11.13.08.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Jan 2020 13:08:16 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.20.0.191208 Date: Sat, 11 Jan 2020 23:08:15 +0200 From: Yaron Sheffer To: Adrian Hope-Bailie , Dick Hardt CC: , Justin Richer Message-ID: <734FDFDE-59C4-41CA-AFE0-3F8204B24C8F@gmail.com> Thread-Topic: [Txauth] alternative charter writeup References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3661628895_183676716" Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 11 Jan 2020 21:08:21 -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_3661628895_183676716 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Same here. =20 From: Txauth on behalf of Adrian Hope-Bailie Date: Saturday, January 11, 2020 at 09:11 To: Dick Hardt Cc: , Justin Richer Subject: Re: [Txauth] alternative charter writeup =20 +1 =20 On Sat, Jan 11, 2020 at 04:56 Dick Hardt wrote: This looks even better! Thanks Justin. =20 What do others think of the proposed charter now?=20 =E1=90=A7 =20 On Fri, Jan 10, 2020 at 12:43 PM Justin Richer wrote: Thanks, Dick. I=E2=80=99ve been working on an updated charter based on everyone=E2=80= =99s feedback, and I was aiming to have out today anyway, so this timing is he= lpful. So here=E2=80=99s my take on a new charter, incorporating some of your poin= ts below: =20 This group is chartered to develop a delegation protocol for identity, auth= orization, and API access. This protocol will allow an authorizing party to = delegate access to client software through an authorization server. The use = cases supported by this protocol will include widely deployed use cases curr= ently supported by OAuth 2.0 and OpenID Connect.=20 =20 The delegation process will be acted upon by multiple parties in the protoc= ol, each performing a specific role. The protocol will be initiated by the c= lient interacting directly with the authorization server (in contrast with O= Auth 2 which is initiated by the client redirecting the user=E2=80=99s browser). T= he client will involve the authorizing party as necessary through interactio= n mechanisms indicated by the protocol.=20 =20 Additionally, the delegation process will allow for: =20 - Fine-grained specification of resource access - Approval of identity claims and multiple resources in a single interactio= n - Delegation between multiple users - Web, mobile, single-page, and other types of client applications =20 The group will define extension points for this protocol to allow for flexi= bility in areas including: =20 - Cryptographic agility for keys, message signatures, and proof of possessi= on=20 - User interaction mechanisms including web and non-web methods - Mechanisms for providing user, software, organization, and other pieces o= f information used in authorization decisions - Token presentation mechanisms and key bindings =20 Additionally, the group will provide mechanisms for management of the proto= col 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 bac= kwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt t= o simplify porting from OAuth 2.0 and OpenID Connect to the new protocol whe= re possible. While the initial work will focus on using HTTP for communication between t= he client and the authorization server, the working group will seek to take = advantage of optimization features of HTTP2 and HTTP3, and will strive to en= able simple mapping to other protocols such as COAP. =20 On Jan 10, 2020, at 12:04 PM, Dick Hardt wrote: =20 Hey =20 I've written an alternative charter that I hope captures some of the feedba= ck on Justin's charter. =20 I found it easier to rewrite the charter to broaden the marketplace of idea= s.=20 =20 Key ideas: =20 - This work supports existing OAuth 2.0, and OpenID Connect use cases. =20 - The client interacts directly with the authorization server.=20 =20 /Dick =20 ---- =20 This group is chartered to develop a delegated identity and authorization p= rotocol.. The use cases supported by this protocol will include widely deplo= yed use cases currently supported by OAuth 2.0, and OpenID Connect. In contr= ast to OAuth 2.0 and OpenID Connect, where the protocol is initiated by redi= recting the user's browser to an authorization server, this protocol will be= initiated by the client directly interacting with the authorization server.= . Additionally, the protocol will allow: - fine-grained specification of resource access - the user to approve requests for identity claims and access to multiple r= esources in one interaction - web, mobile, single-page, and other client applications - taking advantage of optimization features in HTTP2 and HTTP3 The group will define extension points for this protocol to allow for flexi= bility in areas including: - discovery of the authorization server - cryptographic agility for keys, message signatures, and proof of possessi= on=20 - user interaction mechanisms including web and non-web methods- token pres= entation mechanisms and key bindings Although the artifacts for this work are not intended or expected to be bac= kwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt to sim= plify porting from OAuth 2.0 and OpenID Connect, and strive to reuse existin= g semantics such as client identifiers, OAuth 2.0 scopes and access tokens, = and OpenID Connect ID Tokens and claims. While the initial work will focus on using HTTP for communication between t= he client and the authorization server, the working group will strive to ena= ble simple mapping to other protocols such as COAP. =20 =20 =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 --=20 Sent from a mobile device, please excuse any typos -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3661628895_183676716 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Same here.

 

From: Txauth <txauth-bounces@ietf.org> on behalf of Adrian = Hope-Bailie <adrian@hopebailie.com>
Date: Saturday, January = 11, 2020 at 09:11
To: Dick Hardt <dick.hardt@gmail.com>
<= b>Cc: <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
= Subject: Re: [Txauth] alternative charter writeup

 

+1

 =

On Sat, Jan 11, 2020 at 04= :56 Dick Hardt <dick.hardt@gmail.co= m> wrote:

This looks even better! Thanks Justin.

 

What do others think of the proposed charter now? =

3D"Image=E1=90=A7

 

On Fri, Jan 10, 2020 at 12:43 = PM Justin Richer <jriche= r@mit.edu> wrote:

Thanks, Dick. I=E2=80=99ve be= en working on an updated charter based on everyone=E2=80=99s feedback, and I was a= iming to have out today anyway, so this timing is helpful. So here=E2=80=99s my ta= ke on a new charter, incorporating some of your points below:

=

 

This group is charter= ed to develop a delegation protocol for identity, authorization, and API acc= ess. This protocol will allow an authorizing party to delegate access to cli= ent software through an authorization server. The use cases supported by thi= s protocol will include widely deployed use cases currently supported by OAu= th 2.0 and OpenID Connect. 

 

The delegation process w= ill be acted upon by multiple parties in the protocol, each performing a spe= cific role. The protocol will be initiated by the client interacting directl= y with the authorization server (in contrast with OAuth 2 which is initiated= by the client redirecting the user=E2=80=99s browser). The client will involve th= e authorizing party as necessary through interaction mechanisms indicated by= the protocol. 

 =

Additionally, the delegation process= will allow for:

 

- Fine-grained specification of resource= access

- Approval of identity c= laims and multiple resources in a single interaction

- Delegation between multiple users

- Web, mobile, single-page, and other types of clie= nt applications

 

The group will define extension points fo= r this protocol to allow for flexibility in areas including:

<= /div>

 

- Cryptographic agility for keys, message signatures, and proof of posse= ssion 

- User interaction m= echanisms including web and non-web methods

- Mechanisms for providing user, software, organization, and oth= er pieces of information used in authorization decisions

- Token presentation mechanisms and key bindings

 

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

 

- Discovery of t= he authorization server

- Revoca= tion 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 O= Auth 2.0 or OpenID Connect, the group will attempt to simplify porting = from OAuth 2.0 and OpenID Connect to the new protocol where possible.
While the initial work will focus on using HTTP for communication between t= he client and the authorization server, the working group will seek to take = advantage of optimization features of HTTP2 and HTTP3, and will strive to&nb= sp;enable simple mapping to other protocols such as COAP.

 

On Jan 10, 2020, at 12:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:=

 

<= /div>

Hey

<= o:p> 

I've written an alternativ= e charter that I hope captures some of the feedback on Justin's charter.

 

I found it easier to rewrite the charter to broaden the mark= etplace of ideas. 

&nb= sp;

Key ideas:

 

- T= his work supports existing OAuth 2.0, and OpenID Connect use cases.

 

- The client interacts directly with the authorization server.&nb= sp;

 

<= div>

/Dick

 

<= p class=3DMsoNormal>----

 

This group is chartered to develop a del= egated identity and authorization protocol.. The use cases supported by this= protocol will include widely deployed use cases currently supported by OAut= h 2.0, and OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, wher= e the protocol is initiated by redirecting the user's browser to an authoriz= ation server, this protocol will be initiated by the client directly interac= ting with the authorization server..

<= /blockquote>


Additional= ly, the protocol will allow:

- f= ine-grained specification of resource access

- the user to approve requests for identity claims and access t= o multiple resources in one interaction

- web, mobile, single-page, and other client applications=

- taking advantage of optimization feature= s in HTTP2 and HTTP3


The gro= up will define extension points for this protocol to allow for flexibility i= n areas including:


- discove= ry of the authorization server

-= cryptographic agility for keys, message signatures, and proof of possession=  

- user interaction mechan= isms including web and non-web methods- token presentation mechanisms and ke= y bindings


Although the arti= facts for this work are not intended or expected to be backwards-compatible = with OAuth 2.0 or OpenID Connect, they will attempt to simplify porting from= OAuth 2.0 and OpenID Connect, and strive to reuse existing semantics such a= s client identifiers, OAuth 2.0 scopes and access tokens, and OpenID Connect= ID Tokens and claims.


While= the initial work will focus on using HTTP for communication between the cli= ent and the authorization server, the working group will strive to enable si= mple mapping to other protocols such as COAP.

 

 =

3D"Imag==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

=

--

Sen= t from a mobile device, please excuse any typos

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

--B_3661628895_183676716-- From nobody Sun Jan 12 23:59: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 D9E5912008C for ; Sun, 12 Jan 2020 23:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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] 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 TEXogzLLYFlf for ; Sun, 12 Jan 2020 23:59:28 -0800 (PST) Received: from esa10.hc1106-67.c3s2.iphmx.com (esa10.hc1106-67.c3s2.iphmx.com [139.138.36.51]) (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 9CFDE120013 for ; Sun, 12 Jan 2020 23:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=swissre.com; i=@swissre.com; q=dns/txt; s=srprod19; t=1578902368; x=1610438368; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wU4Ncqm9JCPIIjSPsW32YGIM0BW9OZpzLrLFteEWt54=; b=rBaUV/XS2jmi0oVW19oYnWwAqKcoF6J/H+LX65PLOIa/l4LrMDzk0B74 i0zyxt6CQZZGB9QvYoNIT8mKkepl0/t0VauaKfl5T54/tX84kx+5IcxP3 I0EwS4+z4wIxTW9RHAinRIuH2UUmi96oPqc1bCt+z/KcY1gMv/1Z2vjs7 jFEnTFPmT/ZVFBKCTQJ/NnmxsnWFZsGBRCDQpBdjEi4fsYnpHYXn6vska pReS3j7VqjskIcRmNVmiVc48D44nRCrWcuaqLgWK6/EDMVZNhsXpzY3Oz F+m1MrTWE6YPB7Jg7ugtjLICVR3WhePjO1GJj9zQ435xWm789zCZopTuO g==; IronPort-SDR: o1qKRJCuW4Kw7HNLck2wC4IZtjUXmARukTqg6WZyRePPCYd0ycFx/+HedSFkNhRg9vKmv3YHk4 NLp/zdBI3LuacC6SdzSWdR2RfMoP5ObGeVHeh7GpOizALNuaH+9QfgOsv0baf/UaKDA+7v2DYf xoHTQXiuFqAUP2E/7hyspYmaUovd8CBhAsBwHFBbi25Nwdx40bCeY2annFvcZwToIXcHhgBj+F VauC1odHj+h7ZlPP+e7zA/EpVs/7lnTxCUX2R9rENZbVZQW1Vq+n8mJ3agfCoLdQgc/VDYUrkk Elc= X-Amp-Result: SKIPPED(no attachment in message) Received: from edge.swissre.com ([193.246.239.102]) by esa10.hc1106-67.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 13 Jan 2020 07:59:23 +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.1473.3; Mon, 13 Jan 2020 08:59:22 +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.1473.3; Mon, 13 Jan 2020 08:59: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.1473.003; Mon, 13 Jan 2020 08:59:21 +0100 From: Lee McGovern To: Adrian Hope-Bailie CC: "txauth@ietf.org" Thread-Topic: [Txauth] alternative charter writeup Thread-Index: AQHVyLnStX57bneKs0yBwXIVno8lVafoPPKg Date: Mon, 13 Jan 2020 07:59:20 +0000 Message-ID: <8735c94a16d64c008e650347de113e55@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-01-13T07:59:18.8679500Z; 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.10] Content-Type: multipart/alternative; boundary="_000_8735c94a16d64c008e650347de113e55CHRP5009corpgwpnetcom_" MIME-Version: 1.0 X-GBS-PROC: 2hIY42bPeOGjeRR/kd6oj+vt5sWR79bF5EgE/Z3n6TM= Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 13 Jan 2020 07:59:31 -0000 --_000_8735c94a16d64c008e650347de113e55CHRP5009corpgwpnetcom_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 IldlYiwgbW9iaWxlLCBzaW5nbGUtcGFnZSwgYW5kIG90aGVyIHR5cGVzIG9mIGNsaWVudCBhcHBs aWNhdGlvbnMiDQoNClNob3VsZCBkZXZpY2UgKGFzIGluIGRldmljZSBmbG93KSBiZSBleHBsaWNp dGx5IG1lbnRpb25lZCBoZXJlPw0KDQpGcm9tOiBBZHJpYW4gSG9wZS1CYWlsaWUgPGFkcmlhbkBo b3BlYmFpbGllLmNvbT4NClNlbnQ6IFNhbXN0YWcsIDExLiBKYW51YXIgMjAyMCAwODoxMQ0KVG86 IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPg0KQ2M6IEp1c3RpbiBSaWNoZXIgPGpy aWNoZXJAbWl0LmVkdT47IHR4YXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUeGF1dGhdIGFs dGVybmF0aXZlIGNoYXJ0ZXIgd3JpdGV1cA0KDQorMQ0KDQpPbiBTYXQsIEphbiAxMSwgMjAyMCBh dCAwNDo1NiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJk dEBnbWFpbC5jb20+PiB3cm90ZToNClRoaXMgbG9va3MgZXZlbiBiZXR0ZXIhIFRoYW5rcyBKdXN0 aW4uDQoNCldoYXQgZG8gb3RoZXJzIHRoaW5rIG9mIHRoZSBwcm9wb3NlZCBjaGFydGVyIG5vdz8N CltodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RF Qm5iV0ZwYkM1amIyMCUzRCZ0eXBlPXplcm9jb250ZW50Jmd1aWQ9YzI1NDJhNzMtOWIzNi00MmYx LWIwOTEtYjA3Y2VhZGUxOGVlXeGQpw0KDQpPbiBGcmksIEphbiAxMCwgMjAyMCBhdCAxMjo0MyBQ TSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+ IHdyb3RlOg0KVGhhbmtzLCBEaWNrLiBJ4oCZdmUgYmVlbiB3b3JraW5nIG9uIGFuIHVwZGF0ZWQg Y2hhcnRlciBiYXNlZCBvbiBldmVyeW9uZeKAmXMgZmVlZGJhY2ssIGFuZCBJIHdhcyBhaW1pbmcg dG8gaGF2ZSBvdXQgdG9kYXkgYW55d2F5LCBzbyB0aGlzIHRpbWluZyBpcyBoZWxwZnVsLiBTbyBo ZXJl4oCZcyBteSB0YWtlIG9uIGEgbmV3IGNoYXJ0ZXIsIGluY29ycG9yYXRpbmcgc29tZSBvZiB5 b3VyIHBvaW50cyBiZWxvdzoNCg0KVGhpcyBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBh IGRlbGVnYXRpb24gcHJvdG9jb2wgZm9yIGlkZW50aXR5LCBhdXRob3JpemF0aW9uLCBhbmQgQVBJ IGFjY2Vzcy4gVGhpcyBwcm90b2NvbCB3aWxsIGFsbG93IGFuIGF1dGhvcml6aW5nIHBhcnR5IHRv IGRlbGVnYXRlIGFjY2VzcyB0byBjbGllbnQgc29mdHdhcmUgdGhyb3VnaCBhbiBhdXRob3JpemF0 aW9uIHNlcnZlci4gVGhlIHVzZSBjYXNlcyBzdXBwb3J0ZWQgYnkgdGhpcyBwcm90b2NvbCB3aWxs IGluY2x1ZGUgd2lkZWx5IGRlcGxveWVkIHVzZSBjYXNlcyBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5 IE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3QuDQoNClRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mg d2lsbCBiZSBhY3RlZCB1cG9uIGJ5IG11bHRpcGxlIHBhcnRpZXMgaW4gdGhlIHByb3RvY29sLCBl YWNoIHBlcmZvcm1pbmcgYSBzcGVjaWZpYyByb2xlLiBUaGUgcHJvdG9jb2wgd2lsbCBiZSBpbml0 aWF0ZWQgYnkgdGhlIGNsaWVudCBpbnRlcmFjdGluZyBkaXJlY3RseSB3aXRoIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciAoaW4gY29udHJhc3Qgd2l0aCBPQXV0aCAyIHdoaWNoIGlzIGluaXRpYXRl ZCBieSB0aGUgY2xpZW50IHJlZGlyZWN0aW5nIHRoZSB1c2Vy4oCZcyBicm93c2VyKS4gVGhlIGNs aWVudCB3aWxsIGludm9sdmUgdGhlIGF1dGhvcml6aW5nIHBhcnR5IGFzIG5lY2Vzc2FyeSB0aHJv dWdoIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5kaWNhdGVkIGJ5IHRoZSBwcm90b2NvbC4NCg0K QWRkaXRpb25hbGx5LCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYWxsb3cgZm9yOg0KDQot IEZpbmUtZ3JhaW5lZCBzcGVjaWZpY2F0aW9uIG9mIHJlc291cmNlIGFjY2Vzcw0KLSBBcHByb3Zh bCBvZiBpZGVudGl0eSBjbGFpbXMgYW5kIG11bHRpcGxlIHJlc291cmNlcyBpbiBhIHNpbmdsZSBp bnRlcmFjdGlvbg0KLSBEZWxlZ2F0aW9uIGJldHdlZW4gbXVsdGlwbGUgdXNlcnMNCi0gV2ViLCBt b2JpbGUsIHNpbmdsZS1wYWdlLCBhbmQgb3RoZXIgdHlwZXMgb2YgY2xpZW50IGFwcGxpY2F0aW9u cw0KDQpUaGUgZ3JvdXAgd2lsbCBkZWZpbmUgZXh0ZW5zaW9uIHBvaW50cyBmb3IgdGhpcyBwcm90 b2NvbCB0byBhbGxvdyBmb3IgZmxleGliaWxpdHkgaW4gYXJlYXMgaW5jbHVkaW5nOg0KDQotIENy eXB0b2dyYXBoaWMgYWdpbGl0eSBmb3Iga2V5cywgbWVzc2FnZSBzaWduYXR1cmVzLCBhbmQgcHJv b2Ygb2YgcG9zc2Vzc2lvbg0KLSBVc2VyIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5jbHVkaW5n IHdlYiBhbmQgbm9uLXdlYiBtZXRob2RzDQotIE1lY2hhbmlzbXMgZm9yIHByb3ZpZGluZyB1c2Vy LCBzb2Z0d2FyZSwgb3JnYW5pemF0aW9uLCBhbmQgb3RoZXIgcGllY2VzIG9mIGluZm9ybWF0aW9u IHVzZWQgaW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbnMNCi0gVG9rZW4gcHJlc2VudGF0aW9uIG1l Y2hhbmlzbXMgYW5kIGtleSBiaW5kaW5ncw0KDQpBZGRpdGlvbmFsbHksIHRoZSBncm91cCB3aWxs IHByb3ZpZGUgbWVjaGFuaXNtcyBmb3IgbWFuYWdlbWVudCBvZiB0aGUgcHJvdG9jb2wgbGlmZWN5 Y2xlIGluY2x1ZGluZzoNCg0KLSBEaXNjb3Zlcnkgb2YgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy DQotIFJldm9jYXRpb24gb2YgYWN0aXZlIHRva2Vucw0KLSBRdWVyeSBvZiB0b2tlbiByaWdodHMg YnkgcmVzb3VyY2Ugc2VydmVycw0KDQpBbHRob3VnaCB0aGUgYXJ0aWZhY3RzIGZvciB0aGlzIHdv cmsgYXJlIG5vdCBpbnRlbmRlZCBvciBleHBlY3RlZCB0byBiZSBiYWNrd2FyZHMtY29tcGF0aWJs ZSB3aXRoIE9BdXRoIDIuMCBvciBPcGVuSUQgQ29ubmVjdCwgdGhlIGdyb3VwIHdpbGwgYXR0ZW1w dCB0byBzaW1wbGlmeSBwb3J0aW5nIGZyb20gT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCB0 byB0aGUgbmV3IHByb3RvY29sIHdoZXJlIHBvc3NpYmxlLg0KDQpXaGlsZSB0aGUgaW5pdGlhbCB3 b3JrIHdpbGwgZm9jdXMgb24gdXNpbmcgSFRUUCBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRo ZSBjbGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlIHdvcmtpbmcgZ3JvdXAg d2lsbCBzZWVrIHRvIHRha2UgYWR2YW50YWdlIG9mIG9wdGltaXphdGlvbiBmZWF0dXJlcyBvZiBI VFRQMiBhbmQgSFRUUDMsIGFuZCB3aWxsIHN0cml2ZSB0byBlbmFibGUgc2ltcGxlIG1hcHBpbmcg dG8gb3RoZXIgcHJvdG9jb2xzIHN1Y2ggYXMgQ09BUC4NCg0KT24gSmFuIDEwLCAyMDIwLCBhdCAx MjowNCBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFy ZHRAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhleQ0KDQpJJ3ZlIHdyaXR0ZW4gYW4gYWx0ZXJuYXRp dmUgY2hhcnRlciB0aGF0IEkgaG9wZSBjYXB0dXJlcyBzb21lIG9mIHRoZSBmZWVkYmFjayBvbiBK dXN0aW4ncyBjaGFydGVyLg0KDQpJIGZvdW5kIGl0IGVhc2llciB0byByZXdyaXRlIHRoZSBjaGFy dGVyIHRvIGJyb2FkZW4gdGhlIG1hcmtldHBsYWNlIG9mIGlkZWFzLg0KDQpLZXkgaWRlYXM6DQoN Ci0gVGhpcyB3b3JrIHN1cHBvcnRzIGV4aXN0aW5nIE9BdXRoIDIuMCwgYW5kIE9wZW5JRCBDb25u ZWN0IHVzZSBjYXNlcy4NCg0KLSBUaGUgY2xpZW50IGludGVyYWN0cyBkaXJlY3RseSB3aXRoIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlci4NCg0KL0RpY2sNCg0KLS0tLQ0KDQpUaGlzIGdyb3VwIGlz IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGEgZGVsZWdhdGVkIGlkZW50aXR5IGFuZCBhdXRob3JpemF0 aW9uIHByb3RvY29sLi4gVGhlIHVzZSBjYXNlcyBzdXBwb3J0ZWQgYnkgdGhpcyBwcm90b2NvbCB3 aWxsIGluY2x1ZGUgd2lkZWx5IGRlcGxveWVkIHVzZSBjYXNlcyBjdXJyZW50bHkgc3VwcG9ydGVk IGJ5IE9BdXRoIDIuMCwgYW5kIE9wZW5JRCBDb25uZWN0LiBJbiBjb250cmFzdCB0byBPQXV0aCAy LjAgYW5kIE9wZW5JRCBDb25uZWN0LCB3aGVyZSB0aGUgcHJvdG9jb2wgaXMgaW5pdGlhdGVkIGJ5 IHJlZGlyZWN0aW5nIHRoZSB1c2VyJ3MgYnJvd3NlciB0byBhbiBhdXRob3JpemF0aW9uIHNlcnZl ciwgdGhpcyBwcm90b2NvbCB3aWxsIGJlIGluaXRpYXRlZCBieSB0aGUgY2xpZW50IGRpcmVjdGx5 IGludGVyYWN0aW5nIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLi4NCg0KQWRkaXRpb25h bGx5LCB0aGUgcHJvdG9jb2wgd2lsbCBhbGxvdzoNCi0gZmluZS1ncmFpbmVkIHNwZWNpZmljYXRp b24gb2YgcmVzb3VyY2UgYWNjZXNzDQotIHRoZSB1c2VyIHRvIGFwcHJvdmUgcmVxdWVzdHMgZm9y IGlkZW50aXR5IGNsYWltcyBhbmQgYWNjZXNzIHRvIG11bHRpcGxlIHJlc291cmNlcyBpbiBvbmUg aW50ZXJhY3Rpb24NCi0gd2ViLCBtb2JpbGUsIHNpbmdsZS1wYWdlLCBhbmQgb3RoZXIgY2xpZW50 IGFwcGxpY2F0aW9ucw0KLSB0YWtpbmcgYWR2YW50YWdlIG9mIG9wdGltaXphdGlvbiBmZWF0dXJl cyBpbiBIVFRQMiBhbmQgSFRUUDMNCg0KVGhlIGdyb3VwIHdpbGwgZGVmaW5lIGV4dGVuc2lvbiBw b2ludHMgZm9yIHRoaXMgcHJvdG9jb2wgdG8gYWxsb3cgZm9yIGZsZXhpYmlsaXR5IGluIGFyZWFz IGluY2x1ZGluZzoNCg0KLSBkaXNjb3Zlcnkgb2YgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyDQot IGNyeXB0b2dyYXBoaWMgYWdpbGl0eSBmb3Iga2V5cywgbWVzc2FnZSBzaWduYXR1cmVzLCBhbmQg cHJvb2Ygb2YgcG9zc2Vzc2lvbg0KLSB1c2VyIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5jbHVk aW5nIHdlYiBhbmQgbm9uLXdlYiBtZXRob2RzLSB0b2tlbiBwcmVzZW50YXRpb24gbWVjaGFuaXNt cyBhbmQga2V5IGJpbmRpbmdzDQoNCkFsdGhvdWdoIHRoZSBhcnRpZmFjdHMgZm9yIHRoaXMgd29y ayBhcmUgbm90IGludGVuZGVkIG9yIGV4cGVjdGVkIHRvIGJlIGJhY2t3YXJkcy1jb21wYXRpYmxl IHdpdGggT0F1dGggMi4wIG9yIE9wZW5JRCBDb25uZWN0LCB0aGV5IHdpbGwgYXR0ZW1wdCB0byBz aW1wbGlmeSBwb3J0aW5nIGZyb20gT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCwgYW5kIHN0 cml2ZSB0byByZXVzZSBleGlzdGluZyBzZW1hbnRpY3Mgc3VjaCBhcyBjbGllbnQgaWRlbnRpZmll cnMsIE9BdXRoIDIuMCBzY29wZXMgYW5kIGFjY2VzcyB0b2tlbnMsIGFuZCBPcGVuSUQgQ29ubmVj dCBJRCBUb2tlbnMgYW5kIGNsYWltcy4NCg0KV2hpbGUgdGhlIGluaXRpYWwgd29yayB3aWxsIGZv Y3VzIG9uIHVzaW5nIEhUVFAgZm9yIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFu ZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgc3RyaXZl IHRvIGVuYWJsZSBzaW1wbGUgbWFwcGluZyB0byBvdGhlciBwcm90b2NvbHMgc3VjaCBhcyBDT0FQ Lg0KDQoNCltodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVv WVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZ0eXBlPXplcm9jb250ZW50Jmd1aWQ9NDEwMGYxMWMtMTVj YS00ZDQ1LWJiZDItYzAyOTk2NTgyMWZiXeGQpw0KLS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4 YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCg0KLS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4 YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCi0tDQpTZW50IGZyb20gYSBtb2JpbGUgZGV2aWNl LCBwbGVhc2UgZXhjdXNlIGFueSB0eXBvcw0KCgpUaGlzIGUtbWFpbCwgaW5jbHVkaW5nIGF0dGFj aG1lbnRzLCBpcyBpbnRlbmRlZCBmb3IgdGhlIHBlcnNvbihzKSBvciBjb21wYW55IG5hbWVkIGFu ZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIGxlZ2FsbHkgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbi4KClVuYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIHVzZSBvZiB0aGlz IGluZm9ybWF0aW9uIG1heSBiZSB1bmxhd2Z1bCBhbmQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpBbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGUtbWFpbCBt ZXNzYWdlcyBhcmUgc3RvcmVkIGluIHRoZSBTd2lzcyBSZSBFbGVjdHJvbmljIE1lc3NhZ2UgUmVw b3NpdG9yeS4KSWYgeW91IGRvIG5vdCB3aXNoIHRoZSByZXRlbnRpb24gb2YgcG90ZW50aWFsbHkg cHJpdmF0ZSBlLW1haWxzIGJ5IFN3aXNzIFJlLCB3ZSBzdHJvbmdseSBhZHZpc2UgeW91IG5vdCB0 byB1c2UgdGhlIFN3aXNzIFJlIGUtbWFpbCBhY2NvdW50IGZvciBhbnkgcHJpdmF0ZSwgbm9uLWJ1 c2luZXNzIHJlbGF0ZWQgY29tbXVuaWNhdGlvbnMuCg== --_000_8735c94a16d64c008e650347de113e55CHRP5009corpgwpnetcom_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow Y207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUtQ0giIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPiZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+V2ViLCBtb2JpbGUsIHNpbmdsZS1w YWdlLCBhbmQgb3RoZXIgdHlwZXMgb2YgY2xpZW50IGFwcGxpY2F0aW9ucyZxdW90OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+U2hvdWxkIGRldmljZSAoYXMgaW4gZGV2aWNlIGZsb3cpIGJlIGV4cGxpY2l0 bHkgbWVudGlvbmVkIGhlcmU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEFk cmlhbiBIb3BlLUJhaWxpZSAmbHQ7YWRyaWFuQGhvcGViYWlsaWUuY29tJmd0Ow0KPGJyPg0KPGI+ U2VudDo8L2I+IFNhbXN0YWcsIDExLiBKYW51YXIgMjAyMCAwODoxMTxicj4NCjxiPlRvOjwvYj4g RGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBK dXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7OyB0eGF1dGhAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUeGF1dGhdIGFsdGVybmF0aXZlIGNoYXJ0ZXIgd3JpdGV1 cDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzE8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgSmFuIDExLCAyMDIwIGF0IDA0OjU2IERpY2sgSGFyZHQg Jmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+ZGljay5oYXJkdEBnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGxvb2tzIGV2ZW4gYmV0dGVyISBUaGFu a3MgSnVzdGluLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2hhdCBkbyBvdGhlcnMgdGhpbmsgb2YgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgbm93PyZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJodHRwczovL21haWxmb29n YWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZh bXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD1jMjU0MmE3My05YjM2LTQyZjEtYjA5MS1iMDdj ZWFkZTE4ZWUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDEwLCAyMDIw IGF0IDEyOjQzIFBNIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1p dC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsIERpY2suIEnigJl2ZSBiZWVuIHdvcmtpbmcgb24g YW4gdXBkYXRlZCBjaGFydGVyIGJhc2VkIG9uIGV2ZXJ5b25l4oCZcyBmZWVkYmFjaywgYW5kIEkg d2FzIGFpbWluZyB0byBoYXZlIG91dCB0b2RheSBhbnl3YXksIHNvIHRoaXMgdGltaW5nIGlzIGhl bHBmdWwuIFNvIGhlcmXigJlzIG15IHRha2Ugb24gYSBuZXcgY2hhcnRlciwgaW5jb3Jwb3JhdGlu ZyBzb21lIG9mIHlvdXIgcG9pbnRzIGJlbG93OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBk ZWxlZ2F0aW9uIHByb3RvY29sIGZvciBpZGVudGl0eSwgYXV0aG9yaXphdGlvbiwgYW5kIEFQSSBh Y2Nlc3MuIFRoaXMgcHJvdG9jb2wgd2lsbCBhbGxvdyBhbiBhdXRob3JpemluZyBwYXJ0eSB0byBk ZWxlZ2F0ZSBhY2Nlc3MgdG8gY2xpZW50IHNvZnR3YXJlIHRocm91Z2ggYW4gYXV0aG9yaXphdGlv biBzZXJ2ZXIuIFRoZSB1c2UgY2FzZXMgc3VwcG9ydGVkDQogYnkgdGhpcyBwcm90b2NvbCB3aWxs IGluY2x1ZGUgd2lkZWx5IGRlcGxveWVkIHVzZSBjYXNlcyBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5 IE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3QuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mg d2lsbCBiZSBhY3RlZCB1cG9uIGJ5IG11bHRpcGxlIHBhcnRpZXMgaW4gdGhlIHByb3RvY29sLCBl YWNoIHBlcmZvcm1pbmcgYSBzcGVjaWZpYyByb2xlLiBUaGUgcHJvdG9jb2wgd2lsbCBiZSBpbml0 aWF0ZWQgYnkgdGhlIGNsaWVudCBpbnRlcmFjdGluZyBkaXJlY3RseSB3aXRoIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciAoaW4gY29udHJhc3Qgd2l0aCBPQXV0aCAyIHdoaWNoDQogaXMgaW5pdGlh dGVkIGJ5IHRoZSBjbGllbnQgcmVkaXJlY3RpbmcgdGhlIHVzZXLigJlzIGJyb3dzZXIpLiBUaGUg Y2xpZW50IHdpbGwgaW52b2x2ZSB0aGUgYXV0aG9yaXppbmcgcGFydHkgYXMgbmVjZXNzYXJ5IHRo cm91Z2ggaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmRpY2F0ZWQgYnkgdGhlIHByb3RvY29sLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BZGRpdGlvbmFsbHksIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mgd2lsbCBhbGxvdyBmb3I6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gRmlu ZS1ncmFpbmVkIHNwZWNpZmljYXRpb24gb2YgcmVzb3VyY2UgYWNjZXNzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEFwcHJvdmFsIG9mIGlkZW50 aXR5IGNsYWltcyBhbmQgbXVsdGlwbGUgcmVzb3VyY2VzIGluIGEgc2luZ2xlIGludGVyYWN0aW9u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIERl bGVnYXRpb24gYmV0d2VlbiBtdWx0aXBsZSB1c2VyczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBXZWIsIG1vYmlsZSwgc2luZ2xlLXBhZ2UsIGFu ZCBvdGhlciB0eXBlcyBvZiBjbGllbnQgYXBwbGljYXRpb25zPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBncm91cCB3aWxsIGRlZmluZSBl eHRlbnNpb24gcG9pbnRzIGZvciB0aGlzIHByb3RvY29sIHRvIGFsbG93IGZvciBmbGV4aWJpbGl0 eSBpbiBhcmVhcyBpbmNsdWRpbmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0gQ3J5cHRvZ3JhcGhpYyBhZ2lsaXR5IGZvciBrZXlzLCBtZXNz YWdlIHNpZ25hdHVyZXMsIGFuZCBwcm9vZiBvZiBwb3NzZXNzaW9uJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFVzZXIgaW50ZXJhY3Rp b24gbWVjaGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFuZCBub24td2ViIG1ldGhvZHM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gTWVjaGFuaXNtcyBm b3IgcHJvdmlkaW5nIHVzZXIsIHNvZnR3YXJlLCBvcmdhbml6YXRpb24sIGFuZCBvdGhlciBwaWVj ZXMgb2YgaW5mb3JtYXRpb24gdXNlZCBpbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBUb2tlbiBwcmVz ZW50YXRpb24gbWVjaGFuaXNtcyBhbmQga2V5IGJpbmRpbmdzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFkZGl0aW9uYWxseSwgdGhlIGdyb3Vw IHdpbGwgcHJvdmlkZSBtZWNoYW5pc21zIGZvciBtYW5hZ2VtZW50IG9mIHRoZSBwcm90b2NvbCBs aWZlY3ljbGUgaW5jbHVkaW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tIERpc2NvdmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXI8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gUmV2 b2NhdGlvbiBvZiBhY3RpdmUgdG9rZW5zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFF1ZXJ5IG9mIHRva2VuIHJpZ2h0cyBieSByZXNvdXJjZSBz ZXJ2ZXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFsdGhvdWdoIHRoZSBhcnRpZmFjdHMgZm9yIHRoaXMgd29yayBhcmUgbm90IGludGVuZGVk IG9yIGV4cGVjdGVkIHRvIGJlIGJhY2t3YXJkcy1jb21wYXRpYmxlIHdpdGggT0F1dGggMi4wIG9y IE9wZW5JRCBDb25uZWN0LCB0aGUgZ3JvdXAgd2lsbCZuYnNwO2F0dGVtcHQgdG8gc2ltcGxpZnkg cG9ydGluZyBmcm9tIE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3QgdG8gdGhlIG5ldyBwcm90 b2NvbCB3aGVyZSBwb3NzaWJsZS48YnI+DQo8YnI+DQpXaGlsZSB0aGUgaW5pdGlhbCB3b3JrIHdp bGwgZm9jdXMgb24gdXNpbmcgSFRUUCBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBjbGll bnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBz ZWVrIHRvIHRha2UgYWR2YW50YWdlIG9mIG9wdGltaXphdGlvbiBmZWF0dXJlcyBvZiBIVFRQMiBh bmQgSFRUUDMsIGFuZCB3aWxsIHN0cml2ZSB0byZuYnNwO2VuYWJsZSBzaW1wbGUgbWFwcGluZyB0 byBvdGhlciBwcm90b2NvbHMNCiBzdWNoIGFzIENPQVAuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gSmFuIDEwLCAyMDIwLCBhdCAxMjowNCBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJk dEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhleTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSd2ZSB3cml0dGVuIGFuIGFsdGVybmF0aXZlIGNoYXJ0ZXIgdGhhdCBJIGhvcGUgY2FwdHVyZXMg c29tZSBvZiB0aGUgZmVlZGJhY2sgb24gSnVzdGluJ3MgY2hhcnRlci48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBmb3VuZCBpdCBlYXNpZXIg dG8gcmV3cml0ZSB0aGUgY2hhcnRlciB0byBicm9hZGVuIHRoZSBtYXJrZXRwbGFjZSBvZiBpZGVh cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+S2V5IGlkZWFzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tIFRoaXMgd29yayBzdXBwb3J0cyBleGlzdGluZyBPQXV0aCAyLjAsIGFu ZCBPcGVuSUQgQ29ubmVjdCB1c2UgY2FzZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gVGhlIGNsaWVudCBpbnRlcmFjdHMgZGlyZWN0bHkg d2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9EaWNrPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tLS08bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg Z3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBkZWxlZ2F0ZWQgaWRlbnRpdHkgYW5kIGF1 dGhvcml6YXRpb24gcHJvdG9jb2wuLiBUaGUgdXNlIGNhc2VzIHN1cHBvcnRlZCBieSB0aGlzIHBy b3RvY29sIHdpbGwgaW5jbHVkZSB3aWRlbHkgZGVwbG95ZWQgdXNlIGNhc2VzIGN1cnJlbnRseSBz dXBwb3J0ZWQgYnkgT0F1dGggMi4wLCBhbmQgT3BlbklEIENvbm5lY3QuIEluIGNvbnRyYXN0IHRv IE9BdXRoDQogMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCwgd2hlcmUgdGhlIHByb3RvY29sIGlzIGlu aXRpYXRlZCBieSByZWRpcmVjdGluZyB0aGUgdXNlcidzIGJyb3dzZXIgdG8gYW4gYXV0aG9yaXph dGlvbiBzZXJ2ZXIsIHRoaXMgcHJvdG9jb2wgd2lsbCBiZSBpbml0aWF0ZWQgYnkgdGhlIGNsaWVu dCBkaXJlY3RseSBpbnRlcmFjdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpBZGRpdGlvbmFsbHksIHRoZSBwcm90 b2NvbCB3aWxsIGFsbG93OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LSBmaW5lLWdyYWluZWQgc3BlY2lmaWNhdGlvbiBvZiByZXNvdXJjZSBhY2Nl c3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g dGhlIHVzZXIgdG8gYXBwcm92ZSByZXF1ZXN0cyBmb3IgaWRlbnRpdHkgY2xhaW1zIGFuZCBhY2Nl c3MgdG8gbXVsdGlwbGUgcmVzb3VyY2VzIGluIG9uZSBpbnRlcmFjdGlvbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSB3ZWIsIG1vYmlsZSwgc2lu Z2xlLXBhZ2UsIGFuZCBvdGhlciBjbGllbnQgYXBwbGljYXRpb25zPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHRha2luZyBhZHZhbnRhZ2Ugb2Yg b3B0aW1pemF0aW9uIGZlYXR1cmVzIGluIEhUVFAyIGFuZCBIVFRQMzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhlIGdyb3VwIHdpbGwg ZGVmaW5lIGV4dGVuc2lvbiBwb2ludHMgZm9yIHRoaXMgcHJvdG9jb2wgdG8gYWxsb3cgZm9yIGZs ZXhpYmlsaXR5IGluIGFyZWFzIGluY2x1ZGluZzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi0gZGlzY292ZXJ5IG9mIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LSBjcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3NhZ2Ugc2lnbmF0 dXJlcywgYW5kIHByb29mIG9mIHBvc3Nlc3Npb24mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gdXNlciBpbnRlcmFjdGlvbiBtZWNoYW5p c21zIGluY2x1ZGluZyB3ZWIgYW5kIG5vbi13ZWIgbWV0aG9kcy0gdG9rZW4gcHJlc2VudGF0aW9u IG1lY2hhbmlzbXMgYW5kIGtleSBiaW5kaW5nczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQWx0aG91Z2ggdGhlIGFydGlmYWN0cyBmb3Ig dGhpcyB3b3JrIGFyZSBub3QgaW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8gYmUgYmFja3dhcmRzLWNv bXBhdGlibGUgd2l0aCBPQXV0aCAyLjAgb3IgT3BlbklEIENvbm5lY3QsIHRoZXkgd2lsbCBhdHRl bXB0IHRvIHNpbXBsaWZ5IHBvcnRpbmcgZnJvbSBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0 LCBhbmQgc3RyaXZlIHRvIHJldXNlIGV4aXN0aW5nIHNlbWFudGljcyBzdWNoIGFzIGNsaWVudCBp ZGVudGlmaWVycywNCiBPQXV0aCAyLjAgc2NvcGVzIGFuZCBhY2Nlc3MgdG9rZW5zLCBhbmQgT3Bl bklEIENvbm5lY3QgSUQgVG9rZW5zIGFuZCBjbGFpbXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpXaGlsZSB0aGUgaW5pdGlhbCB3b3Jr IHdpbGwgZm9jdXMgb24gdXNpbmcgSFRUUCBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBj bGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlIHdvcmtpbmcgZ3JvdXAgd2ls bCBzdHJpdmUgdG8gZW5hYmxlIHNpbXBsZSBtYXBwaW5nIHRvIG90aGVyIHByb3RvY29scyBzdWNo IGFzIENPQVAuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI2 IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9Z WEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPTQxMDBm MTFjLTE1Y2EtNGQ0NS1iYmQyLWMwMjk5NjU4MjFmYiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0 ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tLSA8YnI+DQpUeGF1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlR4YXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlR4YXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0KVHhhdXRoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5UeGF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW50IGZyb20gYSBtb2Jp bGUgZGV2aWNlLCBwbGVhc2UgZXhjdXNlIGFueSB0eXBvczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxicj48ZGl2PlRoaXMgZS1tYWlsLCBpbmNsdWRpbmcgYXR0YWNobWVudHMsIGlz IGludGVuZGVkIGZvciB0aGUgcGVyc29uKHMpIG9yIGNvbXBhbnkgbmFtZWQgYW5kIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBhbmQvb3IgbGVnYWxseSBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLjwv ZGl2PlVuYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIHVzZSBvZiB0aGlzIGluZm9y bWF0aW9uIG1heSBiZSB1bmxhd2Z1bCBhbmQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIG5v dGlmeSB0aGUgc2VuZGVyLjxicj5BbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGUtbWFpbCBtZXNz YWdlcyBhcmUgc3RvcmVkIGluIHRoZSBTd2lzcyBSZSBFbGVjdHJvbmljIE1lc3NhZ2UgUmVwb3Np dG9yeS48YnI+SWYgeW91IGRvIG5vdCB3aXNoIHRoZSByZXRlbnRpb24gb2YgcG90ZW50aWFsbHkg cHJpdmF0ZSBlLW1haWxzIGJ5IFN3aXNzIFJlLCB3ZSBzdHJvbmdseSBhZHZpc2UgeW91IG5vdCB0 byB1c2UgdGhlIFN3aXNzIFJlIGUtbWFpbCBhY2NvdW50IGZvciBhbnkgcHJpdmF0ZSwgbm9uLWJ1 c2luZXNzIHJlbGF0ZWQgY29tbXVuaWNhdGlvbnMuPC9ib2R5Pg0KPC9odG1sPg0K --_000_8735c94a16d64c008e650347de113e55CHRP5009corpgwpnetcom_-- From nobody Mon Jan 13 09:29: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 C7D9612094A for ; Mon, 13 Jan 2020 09:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 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] 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 1wAEQ5SouXVe for ; Mon, 13 Jan 2020 09:29:54 -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 DF1DD12094B for ; Mon, 13 Jan 2020 09:29:53 -0800 (PST) Received: from [192.168.3.142] (c-24-60-137-1.hsd1.ma.comcast.net [24.60.137.1]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00DHTm5J023766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jan 2020 12:29:49 -0500 From: Justin Richer Message-Id: <1DFB3EDF-29BD-41F2-B9A9-5F602C772173@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_3CC903F8-99B7-4B1C-BEE5-42DE7A815717" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 13 Jan 2020 12:29:47 -0500 In-Reply-To: <8735c94a16d64c008e650347de113e55@CHRP5009.corp.gwpnet.com> Cc: Adrian Hope-Bailie , "txauth@ietf.org" To: Lee McGovern References: <8735c94a16d64c008e650347de113e55@CHRP5009.corp.gwpnet.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 13 Jan 2020 17:29:57 -0000 --Apple-Mail=_3CC903F8-99B7-4B1C-BEE5-42DE7A815717 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think it should be I struggled on how to capture that. The key element = here is that there=E2=80=99s one device doing the request and another = doing the interaction. This pattern is also used in CIBA and some UMA = style flows, so it=E2=80=99s not just about the nature of the client but = also about the nature of the users involved.=20 So for now that=E2=80=99s firmly in =E2=80=9Cand other=E2=80=9D but = I=E2=80=99m open to suggestion! =E2=80=94 Justin > On Jan 13, 2020, at 2:59 AM, Lee McGovern = wrote: >=20 > "Web, mobile, single-page, and other types of client applications" > =20 > Should device (as in device flow) be explicitly mentioned here? > =20 > From: Adrian Hope-Bailie =20 > Sent: Samstag, 11. Januar 2020 08:11 > To: Dick Hardt > Cc: Justin Richer ; txauth@ietf.org > Subject: Re: [Txauth] alternative charter writeup > =20 > +1 > =20 > On Sat, Jan 11, 2020 at 04:56 Dick Hardt > wrote: > This looks even better! Thanks Justin. > =20 > What do others think of the proposed charter now?=20 > =E1=90=A7 > =20 > On Fri, Jan 10, 2020 at 12:43 PM Justin Richer > wrote: > Thanks, Dick. I=E2=80=99ve been working on an updated charter based on = everyone=E2=80=99s feedback, and I was aiming to have out today anyway, = so this timing is helpful. So here=E2=80=99s my take on a new charter, = incorporating some of your points below: > =20 > This group is chartered to develop a delegation protocol for identity, = authorization, and API access. This protocol will allow an authorizing = party to delegate access to client software through an authorization = server. The use cases supported by this protocol will include widely = deployed use cases currently supported by OAuth 2.0 and OpenID Connect.=20= > =20 > The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will be = initiated by the client interacting directly with the authorization = server (in contrast with OAuth 2 which is initiated by the client = redirecting the user=E2=80=99s browser). The client will involve the = authorizing party as necessary through interaction mechanisms indicated = by the protocol.=20 > =20 > Additionally, the delegation process will allow for: > =20 > - Fine-grained specification of resource access > - Approval of identity claims and multiple resources in a single = interaction > - Delegation between multiple users > - Web, mobile, single-page, and other types of client 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 providing user, software, organization, and other = pieces of information used in authorization decisions > - Token presentation mechanisms and key bindings > =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 porting from OAuth 2.0 and OpenID Connect to the new = protocol where possible. >=20 > While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3, and = will strive to enable simple mapping to other protocols such as COAP. > =20 > On Jan 10, 2020, at 12:04 PM, Dick Hardt > wrote: > =20 > Hey > =20 > I've written an alternative charter that I hope captures some of the = feedback on Justin's charter. > =20 > I found it easier to rewrite the charter to broaden the marketplace of = ideas.=20 > =20 > Key ideas: > =20 > - This work supports existing OAuth 2.0, and OpenID Connect use cases. > =20 > - The client interacts directly with the authorization server.=20 > =20 > /Dick > =20 > ---- > =20 > This group is chartered to develop a delegated identity and = authorization protocol.. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the = protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server.. >=20 > Additionally, the protocol will allow: > - fine-grained specification of resource access > - the user to approve requests for identity claims and access to = multiple resources in one interaction > - web, mobile, single-page, and other client applications > - taking advantage of optimization features in HTTP2 and HTTP3 >=20 > The group will define extension points for this protocol to allow for = flexibility in areas including: >=20 > - discovery of the authorization server > - cryptographic agility for keys, message signatures, and proof of = possession=20 > - user interaction mechanisms including web and non-web methods- token = presentation mechanisms and key bindings >=20 > Although the artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 or OpenID Connect, they will = attempt to simplify porting from OAuth 2.0 and OpenID Connect, and = strive to reuse existing semantics such as client identifiers, OAuth 2.0 = scopes and access tokens, and OpenID Connect ID Tokens and claims. >=20 > While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = strive to enable simple mapping to other protocols such as COAP. > =20 > =20 > =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 = > --=20 > Sent from a mobile device, please excuse any typos >=20 > This e-mail, including attachments, is intended for the person(s) or = company named and may contain confidential and/or legally privileged = information. > Unauthorized disclosure, copying or use of this information may be = unlawful and is prohibited. If you are not the intended recipient, = please delete this message and notify the sender. > All incoming and outgoing e-mail messages are stored in the Swiss Re = Electronic Message Repository. > If you do not wish the retention of potentially private e-mails by = Swiss Re, we strongly advise you not to use the Swiss Re e-mail account = for any private, non-business related communications. --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_3CC903F8-99B7-4B1C-BEE5-42DE7A815717 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think it should be I struggled on how to capture that. The key element = here is that there=E2=80=99s one device doing the request and another = doing the interaction. This pattern is also used in CIBA and some UMA = style flows, so it=E2=80=99s not just about the nature of the client but = also about the nature of the users involved. 

So for now that=E2=80=99s firmly in = =E2=80=9Cand other=E2=80=9D but I=E2=80=99m open to suggestion!

 =E2=80= =94 Justin

On Jan 13, 2020, at 2:59 AM, Lee McGovern = <Lee_McGovern@swissre.com> wrote:

"Web, = mobile, single-page, and other types of client applications"
 
Should = device (as in device flow) be explicitly mentioned here?
 
From: Adrian Hope-Bailie <adrian@hopebailie.com> 
Sent: Samstag, 11. Januar 2020 = 08:11
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Justin Richer <jricher@mit.edu>; txauth@ietf.org
Subject: Re: [Txauth] alternative = charter writeup
 
+1
 
On Sat, Jan 11, 2020 at 04:56 Dick Hardt <dick.hardt@gmail.com> = wrote:
This looks even better! Thanks Justin.
 
What do others think of the proposed = charter now? 
=E1=90=A7
 
On Fri, Jan 10, 2020 at 12:43 PM Justin = Richer <jricher@mit.edu> wrote:
Thanks, Dick. I=E2=80=99ve been working = on an updated charter based on everyone=E2=80=99s feedback, and I was = aiming to have out today anyway, so this timing is helpful. So here=E2=80=99= s my take on a new charter, incorporating some of your points below:
 
This group is chartered to = develop a delegation protocol for identity, authorization, and API = access. This protocol will allow an authorizing party to delegate access = to client software through an authorization server. The use cases = supported by this protocol will include widely deployed use cases = currently supported by OAuth 2.0 and OpenID Connect. 
 
The delegation process will be acted = upon by multiple parties in the protocol, each performing a specific = role. The protocol will be initiated by the client interacting directly = with the authorization server (in contrast with OAuth 2 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client will involve the authorizing party as necessary through = interaction mechanisms indicated by the protocol. 
 
Additionally, the delegation process = will allow for:
 
- Fine-grained specification of resource access
- Approval of identity claims and multiple resources in a = single interaction
- Delegation between multiple users
- Web, mobile, single-page, and other types of client = 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 providing user, = software, organization, and other pieces of information used in = authorization decisions
- Token presentation = mechanisms and key bindings
 
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 porting from = OAuth 2.0 and OpenID Connect to the new protocol where possible.

While the initial work will focus on using = HTTP for communication between the client and the authorization server, = the working group will seek to take advantage of optimization features = of HTTP2 and HTTP3, and will strive to enable simple mapping to = other protocols such as COAP.
 
<= div class=3D"">
On Jan 10, 2020, at 12:04 = PM, Dick Hardt <dick.hardt@gmail.com> wrote:
 
<= /div>
Hey
 
I've written an alternative charter = that I hope captures some of the feedback on Justin's charter.
 
I found it easier to rewrite the = charter to broaden the marketplace of ideas. 
 
Key ideas:
 
- This work supports existing OAuth = 2.0, and OpenID Connect use cases.
 
- The client interacts directly with the authorization = server. 
 
/Dick
 
----
 
This group is chartered to develop a delegated identity and = authorization protocol.. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the = protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server..

Additionally,= the protocol will allow:
- fine-grained = specification of resource access
- the user to approve = requests for identity claims and access to multiple resources in one = interaction
- web, mobile, single-page, and other = client applications
- taking advantage of optimization = features in HTTP2 and HTTP3

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

- discovery of the = authorization server
- cryptographic agility for keys, = message signatures, and proof of possession 
- user interaction mechanisms including web and non-web = methods- token presentation mechanisms and key bindings

Although the artifacts for this work are not = intended or expected to be backwards-compatible with OAuth 2.0 or OpenID = Connect, they will attempt to simplify porting from OAuth 2.0 and OpenID = Connect, and strive to reuse existing semantics such as client = identifiers, OAuth 2.0 scopes and access tokens, and OpenID Connect ID = Tokens and claims.

While the initial work = will focus on using HTTP for communication between the client and the = authorization server, the working group will strive to enable simple = mapping to other protocols such as COAP.
 
 
=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
-- 
Sent from a mobile device, please excuse any typos

This e-mail, including attachments, = is intended for the person(s) or company named and may contain = confidential and/or legally privileged information.
Unauthorized disclosure, copying = or use of this information may be unlawful and is prohibited. If you are = not the intended recipient, please delete this message and notify the = sender.
All incoming = and outgoing e-mail messages are stored in the Swiss Re Electronic = Message Repository.
If you do not wish the retention of potentially private = e-mails by Swiss Re, we strongly advise you not to use the Swiss Re = e-mail account for any private, non-business related communications. = -- 
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
= --Apple-Mail=_3CC903F8-99B7-4B1C-BEE5-42DE7A815717-- From nobody Mon Jan 13 09:53: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 5B50C120963 for ; Mon, 13 Jan 2020 09:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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] 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 rEI262s9nFdQ for ; Mon, 13 Jan 2020 09:53:13 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240C0120962 for ; Mon, 13 Jan 2020 09:53:13 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id y19so7523361lfl.9 for ; Mon, 13 Jan 2020 09:53:13 -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=4YFQ0cQaSphpVQmm3ZaeD5zzq/jTQAMoNdCZPzwsL/w=; b=eX/fRBvxcpvzJPW7YrfFglSX3rKNvJk1Anb6zB/72UjNWQmMcLmohhwBJVZaJ8yzp8 QG/2c662EoEXh+YHYjw0O6ar/zdknDSZJcaYgm9lk1ESbd6dVnpC3ASR3ngA1e2mpW8D jpfGWU4tMfiuxnC7NvKoOi3D+7zXMcFJj0S4ns5UZ7nIyXD6GbKqbexL8ImKNXaiIhwn K7OOXpBNv/SxM9FL5/Ap8W0eLxAcnCOIoSSeUBUAGwnB7cgmu4LjKRHrfxAF6Sl8/3Y3 +UpannxMoLzIbBW+IU4fyyzxikD0cBO4wS/gLZV3vhwSLrjv+dGFlcR7B2sqh7kSSO9+ Rccw== 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=4YFQ0cQaSphpVQmm3ZaeD5zzq/jTQAMoNdCZPzwsL/w=; b=ne4fVkAPJPhwh9G0OUeLIYkpSkcPIlpkd8+AHfPA13tjz8vtloF9jiesm1Doj3eQZS Q+vOK9mkzYzEkh815wtP342qRzQ5DQ8dFPe+fJly267QjDsZnPM1LHv8wlNqv1A2kbZO ldGzMvT7ZCNN1a9TDiC29/Qw7rzYaH7hUZ69Rxpi7mfRfAD1SBjQvK2IPI4pkjnj8gzc fzTPW1LapYrVK1T8WU8AJfPCZM/x2H1M75vWvK5Zv5K4Wdaf3HJY0MT3haQR0ZUFIrm/ msn9oF5+x+fxdRgFlZmrROIVfbelaLG3e7d/JM25SeEFIS7jJYiYT/H90+YcuI4UPGF7 uuHQ== X-Gm-Message-State: APjAAAXKp9J3FhoMnylatucoItIfrP+lluDs+kdRdPT4SK4znQjfeJfH nItv73GGOBQ9d0er40j88JdcuNryuNsZNwlyM5I= X-Google-Smtp-Source: APXvYqzHMMabIp/bDzJRWoRgTM/sGid44DpHcsD0aDRghoXjnOiywAwdtRS5I8wRyBWS5GRNMIueIWoo8LWXVrE/CwI= X-Received: by 2002:a19:cb54:: with SMTP id b81mr10315068lfg.188.1578937991250; Mon, 13 Jan 2020 09:53:11 -0800 (PST) MIME-Version: 1.0 References: <8735c94a16d64c008e650347de113e55@CHRP5009.corp.gwpnet.com> <1DFB3EDF-29BD-41F2-B9A9-5F602C772173@mit.edu> In-Reply-To: <1DFB3EDF-29BD-41F2-B9A9-5F602C772173@mit.edu> From: Dick Hardt Date: Mon, 13 Jan 2020 09:53:00 -0800 Message-ID: To: Justin Richer Cc: Adrian Hope-Bailie , Lee McGovern , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000017489a059c092638" Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 13 Jan 2020 17:53:16 -0000 --00000000000017489a059c092638 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable UX constrained devices? On Mon, Jan 13, 2020 at 9:30 AM Justin Richer wrote: > I think it should be I struggled on how to capture that. The key element > here is that there=E2=80=99s one device doing the request and another doi= ng the > interaction. This pattern is also used in CIBA and some UMA style flows, = so > it=E2=80=99s not just about the nature of the client but also about the n= ature of > the users involved. > > So for now that=E2=80=99s firmly in =E2=80=9Cand other=E2=80=9D but I=E2= =80=99m open to suggestion! > > > =E2=80=94 Justin > > On Jan 13, 2020, at 2:59 AM, Lee McGovern > wrote: > > "Web, mobile, single-page, and other types of client applications" > > Should device (as in device flow) be explicitly mentioned here? > > *From:* Adrian Hope-Bailie > *Sent:* Samstag, 11. Januar 2020 08:11 > *To:* Dick Hardt > *Cc:* Justin Richer ; txauth@ietf.org > *Subject:* Re: [Txauth] alternative charter writeup > > +1 > > On Sat, Jan 11, 2020 at 04:56 Dick Hardt wrote: > > This looks even better! Thanks Justin. > > What do others think of the proposed charter now? > =E1=90=A7 > > On Fri, Jan 10, 2020 at 12:43 PM Justin Richer wrote: > > Thanks, Dick. I=E2=80=99ve been working on an updated charter based on ev= eryone=E2=80=99s > feedback, and I was aiming to have out today anyway, so this timing is > helpful. So here=E2=80=99s my take on a new charter, incorporating some o= f your > points below: > > > This group is chartered to develop a delegation protocol for identity, > authorization, and API access. This protocol will allow an authorizing > party to delegate access to client software through an authorization > server. The use cases supported by this protocol will include widely > deployed use cases currently supported by OAuth 2.0 and OpenID Connect. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will be initiated > by the client interacting directly with the authorization server (in > contrast with OAuth 2 which is initiated by the client redirecting the > user=E2=80=99s browser). The client will involve the authorizing party as= necessary > through interaction mechanisms indicated by the protocol. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of resource access > - Approval of identity claims and multiple resources in a single > interaction > - Delegation between multiple users > - Web, mobile, single-page, and other types of client 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 providing user, software, organization, and other pieces > of information used in authorization decisions > - Token presentation mechanisms and key bindings > > 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 porting from OAuth 2.0 and OpenID Connect to the > new protocol where possible. > > While the initial work will focus on using HTTP for communication between > the client and the authorization server, the working group will seek to > take advantage of optimization features of HTTP2 and HTTP3, and will stri= ve > to enable simple mapping to other protocols such as COAP. > > > On Jan 10, 2020, at 12:04 PM, Dick Hardt wrote: > > > Hey > > I've written an alternative charter that I hope captures some of the > feedback on Justin's charter. > > I found it easier to rewrite the charter to broaden the marketplace of > ideas. > > Key ideas: > > - This work supports existing OAuth 2.0, and OpenID Connect use cases. > > - The client interacts directly with the authorization server. > > /Dick > > > ---- > > This group is chartered to develop a delegated identity and authorization > protocol.. The use cases supported by this protocol will include widely > deployed use cases currently supported by OAuth 2.0, and OpenID Connect. = In > contrast to OAuth 2.0 and OpenID Connect, where the protocol is initiated > by redirecting the user's browser to an authorization server, this protoc= ol > will be initiated by the client directly interacting with the authorizati= on > server.. > > > Additionally, the protocol will allow: > - fine-grained specification of resource access > - the user to approve requests for identity claims and access to multiple > resources in one interaction > - web, mobile, single-page, and other client applications > - taking advantage of optimization features in HTTP2 and HTTP3 > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - discovery of the authorization server > - cryptographic agility for keys, message signatures, and proof of > possession > - user interaction mechanisms including web and non-web methods- token > presentation mechanisms and key bindings > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt = to > simplify porting from OAuth 2.0 and OpenID Connect, and strive to reuse > existing semantics such as client identifiers, OAuth 2.0 scopes and acces= s > tokens, and OpenID Connect ID Tokens and claims. > > While the initial work will focus on using HTTP for communication between > the client and the authorization server, the working group will strive to > enable simple mapping to other protocols such as COAP. > > > =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 > > -- > Sent from a mobile device, please excuse any typos > > This e-mail, including attachments, is intended for the person(s) or > company named and may contain confidential and/or legally privileged > information. > Unauthorized disclosure, copying or use of this information may be > unlawful and is prohibited. If you are not the intended recipient, please > delete this message and notify the sender. > All incoming and outgoing e-mail messages are stored in the Swiss Re > Electronic Message Repository. > If you do not wish the retention of potentially private e-mails by Swiss > Re, we strongly advise you not to use the Swiss Re e-mail account for any > private, non-business related communications. -- > 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 > --00000000000017489a059c092638 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
UX constrained devices?

On Mon, Jan 13, 20= 20 at 9:30 AM Justin Richer <jricher@= mit.edu> wrote:
I think it should be= I struggled on how to capture that. The key element here is that there=E2= =80=99s one device doing the request and another doing the interaction. Thi= s pattern is also used in CIBA and some UMA style flows, so it=E2=80=99s no= t just about the nature of the client but also about the nature of the user= s involved.=C2=A0

So for now that=E2=80=99s firmly in = =E2=80=9Cand other=E2=80=9D but I=E2=80=99m open to suggestion!
=

<= div>
=C2=A0=E2=80=94 Justin

On Jan 13, 2020, at 2:59 AM, Lee McGovern <Lee_McGovern@swissre.com>= wrote:

&= quot;Web, mobile, single-page, and other types = of client applications"
=C2=A0
= Should device (as in device flow) be explicitly mentioned here?
=C2=A0
From:= =C2=A0Adrian Hope-Bailie <adrian@hopebailie.com>=C2=A0<= br>Sent:=C2=A0Samstag, 11. Januar 2020 08:11
To:<= /b>=C2=A0Dick Hardt <dick.hardt@gmail.com>
Cc:=C2=A0<= /span>Justin Richer <jricher@mit.edu>; txauth@ietf.org
Subject:=C2=A0Re: [Txauth] = alternative charter writeup
=C2= =A0
+1
=C2=A0
On Sat, = Jan 11, 2020 at 04:56 Dick Hardt <dick.h= ardt@gmail.com> wrote:
This looks even better! Thanks Justin.
=
=C2=A0
What do other= s think of the proposed charter now?=C2=A0
<= div>
=E1=90=A7
=C2=A0
On Fri, Jan 10, 2020 at 12:43 PM Justin Richer <= jricher@mit.edu> wrote:
Thanks, Dick. I=E2= =80=99ve been working on an updated charter based on everyone=E2=80=99s fee= dback, and I was aiming to have out today anyway, so this timing is helpful= . So here=E2=80=99s my take on a new charter, incorporating some of your po= ints below:
=C2=A0
= This group is chartered to develop a delegation protocol for identity, auth= orization, and API access. This protocol will allow an authorizing party to= delegate access to client software through an authorization server. The us= e cases supported by this protocol will include widely deployed use cases c= urrently supported by OAuth 2.0 and OpenID Connect.=C2=A0
=C2=A0
The d= elegation process will be acted upon by multiple parties in the protocol, e= ach performing a specific role. The protocol will be initiated by the clien= t interacting directly with the authorization server (in contrast with OAut= h 2 which is initiated by the client redirecting the user=E2=80=99s browser= ). The client will involve the authorizing party as necessary through inter= action mechanisms indicated by the protocol.=C2=A0
=C2=A0
Additionally= , the delegation process will allow for:
=C2=A0
- Fine-grained specifi= cation of resource access
- Approva= l of identity claims and multiple resources in a single interaction<= u>
- Delegation between multiple users=
- Web, mobile, single-page, and other typ= es of client applications
= =C2=A0
The group will define extension poi= nts for this protocol to allow for flexibility in areas including:
=C2=A0
- Cryptographic agility for keys, message signatures, and proof of poss= ession=C2=A0
- User interaction mec= hanisms including web and non-web methods
- Mechanisms for providing user, software, organization, and other p= ieces of information used in authorization decisions
- Token presentation mechanisms and key bindings
=C2=A0
Additionally, the group will provide mechanisms for management of the p= rotocol lifecycle including:
=C2=A0
- Discovery of the authorization s= erver
- Revocation of active tokens=
- Query of token rights by resourc= e servers
=C2=A0
Although the artifacts for this work are not intended= or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, t= he group will=C2=A0attempt to simplify porting from OAuth 2.0 and OpenID Co= nnect to the new protocol where possible.

While the initial work wil= l focus on using HTTP for communication between the client and the authoriz= ation server, the working group will seek to take advantage of optimization= features of HTTP2 and HTTP3, and will strive to=C2=A0enable simple mapping= to other protocols such as COAP.
= =C2=A0
=
On Jan 10, 2020, at 12:04 PM, Dick Hardt &l= t;dick.hardt@gmail.com> wrote:
=C2=A0
=
= Hey
=C2=A0
=
I've written an alternative charter that I hope captures some= of the feedback on Justin's charter.
=C2=A0
I found it easier to = rewrite the charter to broaden the marketplace of ideas.=C2=A0
=C2=A0
= Key ideas:
=C2=A0
- This work supports existing OAuth 2.0, and OpenID = Connect use cases.
=C2=A0=
- The client interacts directly with the aut= horization server.=C2=A0
=C2= =A0
/Dick
=C2=A0
= ----
=C2=A0
This group is chartered to develop a delegated identity and auth= orization protocol.. The use cases supported by this protocol will include = widely deployed use cases currently supported by OAuth 2.0, and OpenID Conn= ect. In contrast to OAuth 2.0 and OpenID Connect, where the protocol is ini= tiated by redirecting the user's browser to an authorization server, th= is protocol will be initiated by the client directly interacting with the a= uthorization server..

Additionally, the protocol will allow:
- fine-grained specification of resource access=
- the user to approve requests for id= entity claims and access to multiple resources in one interaction=
- web, mobile, single-page, and other client= applications
- taking advantage of= optimization features in HTTP2 and HTTP3

The group will define extension points for this protocol to allo= w for flexibility in areas including:

- discovery of the authorization server
- cryptographic agility for keys, message signatures, and proof= of possession=C2=A0
- user interac= tion mechanisms including web and non-web methods- token presentation mecha= nisms and key bindings

Although= the artifacts for this work are not intended or expected to be backwards-c= ompatible with OAuth 2.0 or OpenID Connect, they will attempt to simplify p= orting from OAuth 2.0 and OpenID Connect, and strive to reuse existing sema= ntics such as client identifiers, OAuth 2.0 scopes and access tokens, and O= penID Connect ID Tokens and claims.

While the initial work will focus on using HTTP for communication betw= een the client and the authorization server, the working group will strive = to enable simple mapping to other protocols such as COAP.
=C2=A0
=C2= =A0
=C2=A0
--=C2= =A0
Sent from a mobile device, ple= ase excuse any typos

This e-mail, including attachments, is intended for the p= erson(s) or company named and may contain confidential and/or legally privi= leged information.Unauthorized disclosure, copying or use of this information may be u= nlawful and is prohibited. If you are not the intended recipient, please de= lete this message and notify the sender.
All incoming and outgoing= e-mail messages are stored in the Swiss Re Electronic Message Repository.<= /span>
If you do not wish the retention of potentially private e-mails by= Swiss Re, we strongly advise you not to use the Swiss Re e-mail account fo= r any private, non-business related communications. --=C2=A0
Txauth mailing list
Txauth@ie= tf.org
https://www= .ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000017489a059c092638-- From nobody Mon Jan 13 15:38: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 09A03120041 for ; Mon, 13 Jan 2020 15:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 RBMniIn7ol24 for ; Mon, 13 Jan 2020 15:38:10 -0800 (PST) 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 6511F12001B for ; Mon, 13 Jan 2020 15:38:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578958691; x=1610494691; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FoEEQUhfwr7dgFY/qYU3yRU1rNqqJZ4aIhZWzQ6xmOM=; b=jtCWdXkPxk3wXSJbGqe1B5wxonCMe9FO1KhUOwS4q+ZBBy2JmCXHf7uR A93esOOFjqeHjKxaF6Amq7iteMUN819tLKRtlt18/j67W15Z8+u1D9b7N o/GJ3WLdRMjYG+iWO4UTWSPo8P24q/OxBFtYvwFVyv1NCycDGULSqw7iQ M=; IronPort-SDR: R1s8h6HaFFxyF2DH7Z092RbSY6Jvi4XqHV3G6Osqylao2j2LSu5ylreJsIXFEqMSJGoc7nsDAg H/HvgTZpI/cg== X-IronPort-AV: E=Sophos; i="5.69,430,1571702400"; d="scan'208,217"; a="18505429" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1a-807d4a99.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 13 Jan 2020 23:37:58 +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-807d4a99.us-east-1.amazon.com (Postfix) with ESMTPS id 38FCFA1C3D; Mon, 13 Jan 2020 23:37:56 +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; Mon, 13 Jan 2020 23:37:56 +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.1367.3; Mon, 13 Jan 2020 23:37:56 +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.1367.000; Mon, 13 Jan 2020 23:37:56 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt , Justin Richer CC: "txauth@ietf.org" Thread-Topic: [Txauth] alternative charter writeup Thread-Index: AQHVx9g9cyOj1MRzqU6+3+Goa7VakafkXaAAgABoEICAA/l4gA== Date: Mon, 13 Jan 2020 23:37:56 +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.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.115] Content-Type: multipart/alternative; boundary="_000_B758A8F2211F463784AE3FD6974C546Famazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 13 Jan 2020 23:38:16 -0000 --_000_B758A8F2211F463784AE3FD6974C546Famazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hpbGUgSSBhZ3JlZSB3aXRoIHRoZSBnb2FscyBzdGF0ZWQgaW4gdGhpcyBjaGFydGVyLCBpZiBJ IHJlYWQgdGhpcyBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBzb21lb25lIHdobyBoYXNu4oCZdCBi ZWVuIG91ciBtZWV0aW5ncyBvciBsaXN0ZW5lZCB0byBKdXN0aW7igJlzIHByZXNlbnRhdGlvbnMs IEnigJltIGhhcmQgcHJlc3NlZCB0byBzZWUgd2hhdCB0aGUgcG9pbnQgb2YgdGhpcyBncm91cCBp cywgcmVsYXRpdmUgdG8gdGhlIE9BdXRoIFdHLiBJ4oCZZCBleHBlY3QgdGhpcyBjaGFydGVyIHRv IHByb3ZpZGUgYXQgbGVhc3QgYSBjdXJzb3J5IGV4cGxhbmF0aW9uIG9mIHdoYXQgcHJvYmxlbSBp dCBpcyB0cnlpbmcgdG8gc29sdmUuIEluIHRoaXMgY2FzZSwgdGhlIHByb2JsZW0gc2hvdWxkIGJl IHBhcnRpYWxseSBkZWZpbmVkIGluIHJlbGF0aW9uIHRvIE9BdXRoLiBXaGF0IHdpbGwgdGhpcyBX RyBkbyB0aGF0IHRoZSBPQXV0aCBXRyBoYXNu4oCZdCBhbHJlYWR5IGRvbmUgb3IgaXNu4oCZdCBh bHJlYWR5IGRvaW5nPw0KDQpIb3cgYWJvdXQgYWRkaW5nIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xs b3dpbmcgdG8gcGFyYWdyYXBoIDI6DQoNClRoZSBwcm90b2NvbCB3aWxsIG1pdGlnYXRlIG1hbnkg b2YgdGhlIHNlY3VyaXR5IGNvbmNlcm5zIGFuZCB0ZWNobmljYWwgY2hhbGxlbmdlcyBvZiBPQXV0 aCAyLjAgYnkgY29tbXVuaWNhdGluZyBvdmVyIHNlY3VyZSBjaGFubmVscyBiZXR3ZWVuIHRoZSBj bGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgYW5kIG1pbmltaXppbmcgdGhlIGFt b3VudCBvZiBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBvdmVyIHVudHJ1c3RlZCBjaGFubmVscy4N Cg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9t OiBUeGF1dGggPHR4YXV0aC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRGljayBIYXJk dCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpEYXRlOiBGcmlkYXksIEphbnVhcnkgMTAsIDIwMjAg YXQgNjo1NyBQTQ0KVG86IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4NCkNjOiAidHhh dXRoQGlldGYub3JnIiA8dHhhdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUeGF1dGhdIGFs dGVybmF0aXZlIGNoYXJ0ZXIgd3JpdGV1cA0KDQpUaGlzIGxvb2tzIGV2ZW4gYmV0dGVyISBUaGFu a3MgSnVzdGluLg0KDQpXaGF0IGRvIG90aGVycyB0aGluayBvZiB0aGUgcHJvcG9zZWQgY2hhcnRl ciBub3c/DQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1 b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlkPWMyNTQyYTczLTli MzYtNDJmMS1iMDkxLWIwN2NlYWRlMThlZV3hkKcNCg0KT24gRnJpLCBKYW4gMTAsIDIwMjAgYXQg MTI6NDMgUE0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1p dC5lZHU+PiB3cm90ZToNClRoYW5rcywgRGljay4gSeKAmXZlIGJlZW4gd29ya2luZyBvbiBhbiB1 cGRhdGVkIGNoYXJ0ZXIgYmFzZWQgb24gZXZlcnlvbmXigJlzIGZlZWRiYWNrLCBhbmQgSSB3YXMg YWltaW5nIHRvIGhhdmUgb3V0IHRvZGF5IGFueXdheSwgc28gdGhpcyB0aW1pbmcgaXMgaGVscGZ1 bC4gU28gaGVyZeKAmXMgbXkgdGFrZSBvbiBhIG5ldyBjaGFydGVyLCBpbmNvcnBvcmF0aW5nIHNv bWUgb2YgeW91ciBwb2ludHMgYmVsb3c6DQoNClRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRl dmVsb3AgYSBkZWxlZ2F0aW9uIHByb3RvY29sIGZvciBpZGVudGl0eSwgYXV0aG9yaXphdGlvbiwg YW5kIEFQSSBhY2Nlc3MuIFRoaXMgcHJvdG9jb2wgd2lsbCBhbGxvdyBhbiBhdXRob3JpemluZyBw YXJ0eSB0byBkZWxlZ2F0ZSBhY2Nlc3MgdG8gY2xpZW50IHNvZnR3YXJlIHRocm91Z2ggYW4gYXV0 aG9yaXphdGlvbiBzZXJ2ZXIuIFRoZSB1c2UgY2FzZXMgc3VwcG9ydGVkIGJ5IHRoaXMgcHJvdG9j b2wgd2lsbCBpbmNsdWRlIHdpZGVseSBkZXBsb3llZCB1c2UgY2FzZXMgY3VycmVudGx5IHN1cHBv cnRlZCBieSBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0Lg0KDQpUaGUgZGVsZWdhdGlvbiBw cm9jZXNzIHdpbGwgYmUgYWN0ZWQgdXBvbiBieSBtdWx0aXBsZSBwYXJ0aWVzIGluIHRoZSBwcm90 b2NvbCwgZWFjaCBwZXJmb3JtaW5nIGEgc3BlY2lmaWMgcm9sZS4gVGhlIHByb3RvY29sIHdpbGwg YmUgaW5pdGlhdGVkIGJ5IHRoZSBjbGllbnQgaW50ZXJhY3RpbmcgZGlyZWN0bHkgd2l0aCB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgKGluIGNvbnRyYXN0IHdpdGggT0F1dGggMiB3aGljaCBpcyBp bml0aWF0ZWQgYnkgdGhlIGNsaWVudCByZWRpcmVjdGluZyB0aGUgdXNlcuKAmXMgYnJvd3Nlciku IFRoZSBjbGllbnQgd2lsbCBpbnZvbHZlIHRoZSBhdXRob3JpemluZyBwYXJ0eSBhcyBuZWNlc3Nh cnkgdGhyb3VnaCBpbnRlcmFjdGlvbiBtZWNoYW5pc21zIGluZGljYXRlZCBieSB0aGUgcHJvdG9j b2wuDQoNCkFkZGl0aW9uYWxseSwgdGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGFsbG93IGZv cjoNCg0KLSBGaW5lLWdyYWluZWQgc3BlY2lmaWNhdGlvbiBvZiByZXNvdXJjZSBhY2Nlc3MNCi0g QXBwcm92YWwgb2YgaWRlbnRpdHkgY2xhaW1zIGFuZCBtdWx0aXBsZSByZXNvdXJjZXMgaW4gYSBz aW5nbGUgaW50ZXJhY3Rpb24NCi0gRGVsZWdhdGlvbiBiZXR3ZWVuIG11bHRpcGxlIHVzZXJzDQot IFdlYiwgbW9iaWxlLCBzaW5nbGUtcGFnZSwgYW5kIG90aGVyIHR5cGVzIG9mIGNsaWVudCBhcHBs aWNhdGlvbnMNCg0KVGhlIGdyb3VwIHdpbGwgZGVmaW5lIGV4dGVuc2lvbiBwb2ludHMgZm9yIHRo aXMgcHJvdG9jb2wgdG8gYWxsb3cgZm9yIGZsZXhpYmlsaXR5IGluIGFyZWFzIGluY2x1ZGluZzoN Cg0KLSBDcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3NhZ2Ugc2lnbmF0dXJlcywg YW5kIHByb29mIG9mIHBvc3Nlc3Npb24NCi0gVXNlciBpbnRlcmFjdGlvbiBtZWNoYW5pc21zIGlu Y2x1ZGluZyB3ZWIgYW5kIG5vbi13ZWIgbWV0aG9kcw0KLSBNZWNoYW5pc21zIGZvciBwcm92aWRp bmcgdXNlciwgc29mdHdhcmUsIG9yZ2FuaXphdGlvbiwgYW5kIG90aGVyIHBpZWNlcyBvZiBpbmZv cm1hdGlvbiB1c2VkIGluIGF1dGhvcml6YXRpb24gZGVjaXNpb25zDQotIFRva2VuIHByZXNlbnRh dGlvbiBtZWNoYW5pc21zIGFuZCBrZXkgYmluZGluZ3MNCg0KQWRkaXRpb25hbGx5LCB0aGUgZ3Jv dXAgd2lsbCBwcm92aWRlIG1lY2hhbmlzbXMgZm9yIG1hbmFnZW1lbnQgb2YgdGhlIHByb3RvY29s IGxpZmVjeWNsZSBpbmNsdWRpbmc6DQoNCi0gRGlzY292ZXJ5IG9mIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlcg0KLSBSZXZvY2F0aW9uIG9mIGFjdGl2ZSB0b2tlbnMNCi0gUXVlcnkgb2YgdG9rZW4g cmlnaHRzIGJ5IHJlc291cmNlIHNlcnZlcnMNCg0KQWx0aG91Z2ggdGhlIGFydGlmYWN0cyBmb3Ig dGhpcyB3b3JrIGFyZSBub3QgaW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8gYmUgYmFja3dhcmRzLWNv bXBhdGlibGUgd2l0aCBPQXV0aCAyLjAgb3IgT3BlbklEIENvbm5lY3QsIHRoZSBncm91cCB3aWxs IGF0dGVtcHQgdG8gc2ltcGxpZnkgcG9ydGluZyBmcm9tIE9BdXRoIDIuMCBhbmQgT3BlbklEIENv bm5lY3QgdG8gdGhlIG5ldyBwcm90b2NvbCB3aGVyZSBwb3NzaWJsZS4NCg0KV2hpbGUgdGhlIGlu aXRpYWwgd29yayB3aWxsIGZvY3VzIG9uIHVzaW5nIEhUVFAgZm9yIGNvbW11bmljYXRpb24gYmV0 d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRoZSB3b3JraW5n IGdyb3VwIHdpbGwgc2VlayB0byB0YWtlIGFkdmFudGFnZSBvZiBvcHRpbWl6YXRpb24gZmVhdHVy ZXMgb2YgSFRUUDIgYW5kIEhUVFAzLCBhbmQgd2lsbCBzdHJpdmUgdG8gZW5hYmxlIHNpbXBsZSBt YXBwaW5nIHRvIG90aGVyIHByb3RvY29scyBzdWNoIGFzIENPQVAuDQoNCk9uIEphbiAxMCwgMjAy MCwgYXQgMTI6MDQgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpk aWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIZXkNCg0KSSd2ZSB3cml0dGVuIGFuIGFs dGVybmF0aXZlIGNoYXJ0ZXIgdGhhdCBJIGhvcGUgY2FwdHVyZXMgc29tZSBvZiB0aGUgZmVlZGJh Y2sgb24gSnVzdGluJ3MgY2hhcnRlci4NCg0KSSBmb3VuZCBpdCBlYXNpZXIgdG8gcmV3cml0ZSB0 aGUgY2hhcnRlciB0byBicm9hZGVuIHRoZSBtYXJrZXRwbGFjZSBvZiBpZGVhcy4NCg0KS2V5IGlk ZWFzOg0KDQotIFRoaXMgd29yayBzdXBwb3J0cyBleGlzdGluZyBPQXV0aCAyLjAsIGFuZCBPcGVu SUQgQ29ubmVjdCB1c2UgY2FzZXMuDQoNCi0gVGhlIGNsaWVudCBpbnRlcmFjdHMgZGlyZWN0bHkg d2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuDQoNCi9EaWNrDQoNCi0tLS0NCg0KVGhpcyBn cm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBhIGRlbGVnYXRlZCBpZGVudGl0eSBhbmQgYXV0 aG9yaXphdGlvbiBwcm90b2NvbC4uIFRoZSB1c2UgY2FzZXMgc3VwcG9ydGVkIGJ5IHRoaXMgcHJv dG9jb2wgd2lsbCBpbmNsdWRlIHdpZGVseSBkZXBsb3llZCB1c2UgY2FzZXMgY3VycmVudGx5IHN1 cHBvcnRlZCBieSBPQXV0aCAyLjAsIGFuZCBPcGVuSUQgQ29ubmVjdC4gSW4gY29udHJhc3QgdG8g T0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCwgd2hlcmUgdGhlIHByb3RvY29sIGlzIGluaXRp YXRlZCBieSByZWRpcmVjdGluZyB0aGUgdXNlcidzIGJyb3dzZXIgdG8gYW4gYXV0aG9yaXphdGlv biBzZXJ2ZXIsIHRoaXMgcHJvdG9jb2wgd2lsbCBiZSBpbml0aWF0ZWQgYnkgdGhlIGNsaWVudCBk aXJlY3RseSBpbnRlcmFjdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4uDQoNCkFk ZGl0aW9uYWxseSwgdGhlIHByb3RvY29sIHdpbGwgYWxsb3c6DQotIGZpbmUtZ3JhaW5lZCBzcGVj aWZpY2F0aW9uIG9mIHJlc291cmNlIGFjY2Vzcw0KLSB0aGUgdXNlciB0byBhcHByb3ZlIHJlcXVl c3RzIGZvciBpZGVudGl0eSBjbGFpbXMgYW5kIGFjY2VzcyB0byBtdWx0aXBsZSByZXNvdXJjZXMg aW4gb25lIGludGVyYWN0aW9uDQotIHdlYiwgbW9iaWxlLCBzaW5nbGUtcGFnZSwgYW5kIG90aGVy IGNsaWVudCBhcHBsaWNhdGlvbnMNCi0gdGFraW5nIGFkdmFudGFnZSBvZiBvcHRpbWl6YXRpb24g ZmVhdHVyZXMgaW4gSFRUUDIgYW5kIEhUVFAzDQoNClRoZSBncm91cCB3aWxsIGRlZmluZSBleHRl bnNpb24gcG9pbnRzIGZvciB0aGlzIHByb3RvY29sIHRvIGFsbG93IGZvciBmbGV4aWJpbGl0eSBp biBhcmVhcyBpbmNsdWRpbmc6DQoNCi0gZGlzY292ZXJ5IG9mIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlcg0KLSBjcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3NhZ2Ugc2lnbmF0dXJl cywgYW5kIHByb29mIG9mIHBvc3Nlc3Npb24NCi0gdXNlciBpbnRlcmFjdGlvbiBtZWNoYW5pc21z IGluY2x1ZGluZyB3ZWIgYW5kIG5vbi13ZWIgbWV0aG9kcy0gdG9rZW4gcHJlc2VudGF0aW9uIG1l Y2hhbmlzbXMgYW5kIGtleSBiaW5kaW5ncw0KDQpBbHRob3VnaCB0aGUgYXJ0aWZhY3RzIGZvciB0 aGlzIHdvcmsgYXJlIG5vdCBpbnRlbmRlZCBvciBleHBlY3RlZCB0byBiZSBiYWNrd2FyZHMtY29t cGF0aWJsZSB3aXRoIE9BdXRoIDIuMCBvciBPcGVuSUQgQ29ubmVjdCwgdGhleSB3aWxsIGF0dGVt cHQgdG8gc2ltcGxpZnkgcG9ydGluZyBmcm9tIE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3Qs IGFuZCBzdHJpdmUgdG8gcmV1c2UgZXhpc3Rpbmcgc2VtYW50aWNzIHN1Y2ggYXMgY2xpZW50IGlk ZW50aWZpZXJzLCBPQXV0aCAyLjAgc2NvcGVzIGFuZCBhY2Nlc3MgdG9rZW5zLCBhbmQgT3BlbklE IENvbm5lY3QgSUQgVG9rZW5zIGFuZCBjbGFpbXMuDQoNCldoaWxlIHRoZSBpbml0aWFsIHdvcmsg d2lsbCBmb2N1cyBvbiB1c2luZyBIVFRQIGZvciBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIGNs aWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCB0aGUgd29ya2luZyBncm91cCB3aWxs IHN0cml2ZSB0byBlbmFibGUgc2ltcGxlIG1hcHBpbmcgdG8gb3RoZXIgcHJvdG9jb2xzIHN1Y2gg YXMgQ09BUC4NCg0KDQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFa R2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlkPTQxMDBm MTFjLTE1Y2EtNGQ0NS1iYmQyLWMwMjk5NjU4MjFmYl3hkKcNCi0tDQpUeGF1dGggbWFpbGluZyBs aXN0DQpUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQoNCg== --_000_B758A8F2211F463784AE3FD6974C546Famazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <5EB000B8357772468FF63AF3FD09790E@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJFdXBoZW1pYSBVQ0FTIjsNCglwYW5vc2UtMToyIDEx IDUgMyA0IDEgMiAyIDEgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hp bGUgSSBhZ3JlZSB3aXRoIHRoZSBnb2FscyBzdGF0ZWQgaW4gdGhpcyBjaGFydGVyLCBpZiBJIHJl YWQgdGhpcyBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBzb21lb25lIHdobyBoYXNu4oCZdCBiZWVu IG91ciBtZWV0aW5ncyBvciBsaXN0ZW5lZCB0byBKdXN0aW7igJlzIHByZXNlbnRhdGlvbnMsIEni gJltIGhhcmQgcHJlc3NlZCB0byBzZWUgd2hhdCB0aGUgcG9pbnQgb2YgdGhpcyBncm91cCBpcywg cmVsYXRpdmUgdG8NCiB0aGUgT0F1dGggV0cuIEnigJlkIGV4cGVjdCB0aGlzIGNoYXJ0ZXIgdG8g cHJvdmlkZSBhdCBsZWFzdCBhIGN1cnNvcnkgZXhwbGFuYXRpb24gb2Ygd2hhdCBwcm9ibGVtIGl0 IGlzIHRyeWluZyB0byBzb2x2ZS4gSW4gdGhpcyBjYXNlLCB0aGUgcHJvYmxlbSBzaG91bGQgYmUg cGFydGlhbGx5IGRlZmluZWQgaW4gcmVsYXRpb24gdG8gT0F1dGguIFdoYXQgd2lsbCB0aGlzIFdH IGRvIHRoYXQgdGhlIE9BdXRoIFdHIGhhc27igJl0IGFscmVhZHkgZG9uZSBvcg0KIGlzbuKAmXQg YWxyZWFkeSBkb2luZz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IGFib3V0IGFkZGluZyBz b21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nIHRvIHBhcmFncmFwaCAyOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIHByb3RvY29sIHdpbGwgbWl0 aWdhdGUgbWFueSBvZiB0aGUgc2VjdXJpdHkgY29uY2VybnMgYW5kIHRlY2huaWNhbCBjaGFsbGVu Z2VzIG9mIE9BdXRoIDIuMCBieSBjb21tdW5pY2F0aW5nIG92ZXIgc2VjdXJlIGNoYW5uZWxzIGJl dHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBhbmQgbWluaW1p emluZyB0aGUgYW1vdW50IG9mDQogaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgb3ZlciB1bnRydXN0 ZWQgY2hhbm5lbHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBS aWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlR4YXV0aCAmbHQ7dHhhdXRoLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdt YWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBKYW51YXJ5IDEwLCAyMDIwIGF0 IDY6NTcgUE08YnI+DQo8Yj5UbzogPC9iPkp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVk dSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3R4YXV0aEBpZXRmLm9yZyZxdW90OyAmbHQ7dHhh dXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1R4YXV0aF0gYWx0ZXJu YXRpdmUgY2hhcnRlciB3cml0ZXVwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGxvb2tzIGV2ZW4gYmV0dGVyISBUaGFua3Mg SnVzdGluLiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldo YXQgZG8gb3RoZXJzIHRoaW5rIG9mIHRoZSBwcm9wb3NlZCBjaGFydGVyIG5vdz8mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGltZyBpZD0iX3gwMDAwX2kxMDI2IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNv bS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9j b250ZW50JmFtcDtndWlkPWMyNTQyYTczLTliMzYtNDJmMS1iMDkxLWIwN2NlYWRlMThlZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtFdXBoZW1pYSBVQ0FT JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDEwLCAyMDIwIGF0IDEy OjQzIFBNIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUi PmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcywgRGljay4gSeKA mXZlIGJlZW4gd29ya2luZyBvbiBhbiB1cGRhdGVkIGNoYXJ0ZXIgYmFzZWQgb24gZXZlcnlvbmXi gJlzIGZlZWRiYWNrLCBhbmQgSSB3YXMgYWltaW5nIHRvIGhhdmUgb3V0IHRvZGF5IGFueXdheSwg c28gdGhpcyB0aW1pbmcgaXMgaGVscGZ1bC4gU28gaGVyZeKAmXMgbXkgdGFrZSBvbiBhIG5ldyBj aGFydGVyLCBpbmNvcnBvcmF0aW5nIHNvbWUgb2YgeW91ciBwb2ludHMgYmVsb3c6DQo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGdyb3VwIGlzIGNo YXJ0ZXJlZCB0byBkZXZlbG9wIGEgZGVsZWdhdGlvbiBwcm90b2NvbCBmb3IgaWRlbnRpdHksIGF1 dGhvcml6YXRpb24sIGFuZCBBUEkgYWNjZXNzLiBUaGlzIHByb3RvY29sIHdpbGwgYWxsb3cgYW4g YXV0aG9yaXppbmcgcGFydHkgdG8gZGVsZWdhdGUgYWNjZXNzIHRvIGNsaWVudCBzb2Z0d2FyZSB0 aHJvdWdoIGFuIGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGUgdXNlIGNhc2VzIHN1cHBvcnRlZA0K IGJ5IHRoaXMgcHJvdG9jb2wgd2lsbCBpbmNsdWRlIHdpZGVseSBkZXBsb3llZCB1c2UgY2FzZXMg Y3VycmVudGx5IHN1cHBvcnRlZCBieSBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0LiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYmUgYWN0ZWQgdXBvbiBieSBtdWx0aXBsZSBwYXJ0 aWVzIGluIHRoZSBwcm90b2NvbCwgZWFjaCBwZXJmb3JtaW5nIGEgc3BlY2lmaWMgcm9sZS4gVGhl IHByb3RvY29sIHdpbGwgYmUgaW5pdGlhdGVkIGJ5IHRoZSBjbGllbnQgaW50ZXJhY3RpbmcgZGly ZWN0bHkgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgKGluIGNvbnRyYXN0IHdpdGggT0F1 dGggMiB3aGljaA0KIGlzIGluaXRpYXRlZCBieSB0aGUgY2xpZW50IHJlZGlyZWN0aW5nIHRoZSB1 c2Vy4oCZcyBicm93c2VyKS4gVGhlIGNsaWVudCB3aWxsIGludm9sdmUgdGhlIGF1dGhvcml6aW5n IHBhcnR5IGFzIG5lY2Vzc2FyeSB0aHJvdWdoIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5kaWNh dGVkIGJ5IHRoZSBwcm90b2NvbC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWRkaXRpb25hbGx5LCB0aGUgZGVsZWdhdGlvbiBwcm9j ZXNzIHdpbGwgYWxsb3cgZm9yOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tIEZpbmUtZ3JhaW5lZCBzcGVjaWZpY2F0aW9uIG9mIHJlc291cmNl IGFjY2VzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSBBcHByb3ZhbCBvZiBpZGVudGl0eSBjbGFpbXMgYW5kIG11bHRpcGxlIHJlc291cmNlcyBp biBhIHNpbmdsZSBpbnRlcmFjdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LSBEZWxlZ2F0aW9uIGJldHdlZW4gbXVsdGlwbGUgdXNlcnM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gV2ViLCBt b2JpbGUsIHNpbmdsZS1wYWdlLCBhbmQgb3RoZXIgdHlwZXMgb2YgY2xpZW50IGFwcGxpY2F0aW9u czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgZ3JvdXAgd2lsbCBkZWZpbmUgZXh0ZW5zaW9uIHBvaW50cyBmb3IgdGhpcyBwcm90b2NvbCB0 byBhbGxvdyBmb3IgZmxleGliaWxpdHkgaW4gYXJlYXMgaW5jbHVkaW5nOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIENyeXB0b2dyYXBoaWMg YWdpbGl0eSBmb3Iga2V5cywgbWVzc2FnZSBzaWduYXR1cmVzLCBhbmQgcHJvb2Ygb2YgcG9zc2Vz c2lvbiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LSBVc2VyIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5jbHVkaW5nIHdlYiBhbmQgbm9u LXdlYiBtZXRob2RzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tIE1lY2hhbmlzbXMgZm9yIHByb3ZpZGluZyB1c2VyLCBzb2Z0d2FyZSwgb3JnYW5p emF0aW9uLCBhbmQgb3RoZXIgcGllY2VzIG9mIGluZm9ybWF0aW9uIHVzZWQgaW4gYXV0aG9yaXph dGlvbiBkZWNpc2lvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0gVG9rZW4gcHJlc2VudGF0aW9uIG1lY2hhbmlzbXMgYW5kIGtleSBiaW5kaW5n czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B ZGRpdGlvbmFsbHksIHRoZSBncm91cCB3aWxsIHByb3ZpZGUgbWVjaGFuaXNtcyBmb3IgbWFuYWdl bWVudCBvZiB0aGUgcHJvdG9jb2wgbGlmZWN5Y2xlIGluY2x1ZGluZzo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBEaXNjb3Zlcnkgb2YgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tIFJldm9jYXRpb24gb2YgYWN0aXZlIHRva2VuczxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBRdWVyeSBvZiB0b2tl biByaWdodHMgYnkgcmVzb3VyY2Ugc2VydmVyczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHRob3VnaCB0aGUgYXJ0aWZhY3RzIGZvciB0aGlz IHdvcmsgYXJlIG5vdCBpbnRlbmRlZCBvciBleHBlY3RlZCB0byBiZSBiYWNrd2FyZHMtY29tcGF0 aWJsZSB3aXRoIE9BdXRoIDIuMCBvciBPcGVuSUQgQ29ubmVjdCwgdGhlIGdyb3VwIHdpbGwmbmJz cDthdHRlbXB0IHRvIHNpbXBsaWZ5IHBvcnRpbmcgZnJvbSBPQXV0aCAyLjAgYW5kIE9wZW5JRCBD b25uZWN0IHRvIHRoZSBuZXcgcHJvdG9jb2wgd2hlcmUgcG9zc2libGUuPGJyPg0KPGJyPg0KV2hp bGUgdGhlIGluaXRpYWwgd29yayB3aWxsIGZvY3VzIG9uIHVzaW5nIEhUVFAgZm9yIGNvbW11bmlj YXRpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRo ZSB3b3JraW5nIGdyb3VwIHdpbGwgc2VlayB0byB0YWtlIGFkdmFudGFnZSBvZiBvcHRpbWl6YXRp b24gZmVhdHVyZXMgb2YgSFRUUDIgYW5kIEhUVFAzLCBhbmQgd2lsbCBzdHJpdmUgdG8mbmJzcDtl bmFibGUgc2ltcGxlIG1hcHBpbmcgdG8gb3RoZXIgcHJvdG9jb2xzDQogc3VjaCBhcyBDT0FQLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSmFuIDEwLCAyMDIwLCBhdCAxMjowNCBQTSwg RGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhleSA8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkndmUgd3JpdHRlbiBhbiBhbHRlcm5hdGl2 ZSBjaGFydGVyIHRoYXQgSSBob3BlIGNhcHR1cmVzIHNvbWUgb2YgdGhlIGZlZWRiYWNrIG9uIEp1 c3RpbidzIGNoYXJ0ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgZm91bmQgaXQgZWFzaWVyIHRvIHJld3JpdGUgdGhlIGNoYXJ0ZXIgdG8g YnJvYWRlbiB0aGUgbWFya2V0cGxhY2Ugb2YgaWRlYXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktleSBpZGVhczo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBUaGlzIHdvcmsg c3VwcG9ydHMgZXhpc3RpbmcgT0F1dGggMi4wLCBhbmQgT3BlbklEIENvbm5lY3QgdXNlIGNhc2Vz LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t IFRoZSBjbGllbnQgaW50ZXJhY3RzIGRpcmVjdGx5IHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4vRGljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tLS0tPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGEgZGVsZWdhdGVkIGlkZW50 aXR5IGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29sLi4gVGhlIHVzZSBjYXNlcyBzdXBwb3J0ZWQg YnkgdGhpcyBwcm90b2NvbCB3aWxsIGluY2x1ZGUgd2lkZWx5IGRlcGxveWVkIHVzZSBjYXNlcyBj dXJyZW50bHkgc3VwcG9ydGVkIGJ5IE9BdXRoIDIuMCwgYW5kIE9wZW5JRCBDb25uZWN0LiBJbiBj b250cmFzdCB0byBPQXV0aA0KIDIuMCBhbmQgT3BlbklEIENvbm5lY3QsIHdoZXJlIHRoZSBwcm90 b2NvbCBpcyBpbml0aWF0ZWQgYnkgcmVkaXJlY3RpbmcgdGhlIHVzZXIncyBicm93c2VyIHRvIGFu IGF1dGhvcml6YXRpb24gc2VydmVyLCB0aGlzIHByb3RvY29sIHdpbGwgYmUgaW5pdGlhdGVkIGJ5 IHRoZSBjbGllbnQgZGlyZWN0bHkgaW50ZXJhY3Rpbmcgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KQWRkaXRpb25hbGx5LCB0aGUgcHJvdG9jb2wgd2lsbCBhbGxvdzo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gZmluZS1ncmFpbmVk IHNwZWNpZmljYXRpb24gb2YgcmVzb3VyY2UgYWNjZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHRoZSB1c2VyIHRvIGFwcHJvdmUgcmVxdWVz dHMgZm9yIGlkZW50aXR5IGNsYWltcyBhbmQgYWNjZXNzIHRvIG11bHRpcGxlIHJlc291cmNlcyBp biBvbmUgaW50ZXJhY3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0gd2ViLCBtb2JpbGUsIHNpbmdsZS1wYWdlLCBhbmQgb3RoZXIgY2xpZW50 IGFwcGxpY2F0aW9uczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LSB0YWtpbmcgYWR2YW50YWdlIG9mIG9wdGltaXphdGlvbiBmZWF0dXJlcyBpbiBI VFRQMiBhbmQgSFRUUDM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NClRoZSBncm91cCB3aWxsIGRlZmluZSBleHRlbnNpb24gcG9pbnRzIGZv ciB0aGlzIHByb3RvY29sIHRvIGFsbG93IGZvciBmbGV4aWJpbGl0eSBpbiBhcmVhcyBpbmNsdWRp bmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQotIGRpc2NvdmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXI8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gY3J5cHRvZ3JhcGhpYyBh Z2lsaXR5IGZvciBrZXlzLCBtZXNzYWdlIHNpZ25hdHVyZXMsIGFuZCBwcm9vZiBvZiBwb3NzZXNz aW9uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tIHVzZXIgaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFuZCBub24t d2ViIG1ldGhvZHMtIHRva2VuIHByZXNlbnRhdGlvbiBtZWNoYW5pc21zIGFuZCBrZXkgYmluZGlu Z3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCkFsdGhvdWdoIHRoZSBhcnRpZmFjdHMgZm9yIHRoaXMgd29yayBhcmUgbm90IGludGVuZGVk IG9yIGV4cGVjdGVkIHRvIGJlIGJhY2t3YXJkcy1jb21wYXRpYmxlIHdpdGggT0F1dGggMi4wIG9y IE9wZW5JRCBDb25uZWN0LCB0aGV5IHdpbGwgYXR0ZW1wdCB0byBzaW1wbGlmeSBwb3J0aW5nIGZy b20gT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCwgYW5kIHN0cml2ZSB0byByZXVzZSBleGlz dGluZyBzZW1hbnRpY3Mgc3VjaCBhcyBjbGllbnQgaWRlbnRpZmllcnMsDQogT0F1dGggMi4wIHNj b3BlcyBhbmQgYWNjZXNzIHRva2VucywgYW5kIE9wZW5JRCBDb25uZWN0IElEIFRva2VucyBhbmQg Y2xhaW1zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KV2hpbGUgdGhlIGluaXRpYWwgd29yayB3aWxsIGZvY3VzIG9uIHVzaW5nIEhUVFAg Zm9yIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgc3RyaXZlIHRvIGVuYWJsZSBzaW1wbGUg bWFwcGluZyB0byBvdGhlciBwcm90b2NvbHMgc3VjaCBhcyBDT0FQLjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJodHRwczovL21haWxmb29nYWUu YXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7 dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD00MTAwZjExYy0xNWNhLTRkNDUtYmJkMi1jMDI5OTY1 ODIxZmIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7RXVw aGVtaWEgVUNBUyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRlIj7hkKc8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NClR4YXV0aCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+VHhhdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B758A8F2211F463784AE3FD6974C546Famazoncom_-- From nobody Mon Jan 13 16:34: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 ACE42120020 for ; Mon, 13 Jan 2020 16:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 gbHKQTC6g60s for ; Mon, 13 Jan 2020 16:34:32 -0800 (PST) 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 D291712001B for ; Mon, 13 Jan 2020 16:34:31 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id y6so12296779lji.0 for ; Mon, 13 Jan 2020 16:34:31 -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=gEtU58Nlo5pQTUTJudX/cyOw3kUuVE7TmQJXKhOrK1k=; b=c77ef+8zv7rbxh/EFtrJxspCxHh1W0nGwqz0JhfJfByqOhpz3RgHusFBl8hNxDlQpT ayhSqFy3owca61Iw2+9KZMkHBBrieRETS9YLs7bWM3yjH/9SQy3sP7jXykYk1i7VO8cd ABcPwV2r9ZwnxbCn+wQ+qWl2b6Nv3fw6isJMwDh+J4m/HKwQCc6EPfD9cnILIWQcUi6f c31Nqs6pGtbtK36MlK2lCzoeBv6ND09NydvAyv+yTdY0JHJhMekbfUbvAe9Cg2vjq6L5 Ld5WS4yJ6/me4tbhaX7wfkkHkND9yjl4ru0x7XM7jOzzIYAf7PFllxcCgyU4JV9h6DRI 4WYw== 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=gEtU58Nlo5pQTUTJudX/cyOw3kUuVE7TmQJXKhOrK1k=; b=DzpBY9Pulh2OZCaozf5JfymKGzwAMnBCwWW+EuqTBmfbsR5xvg+/wb2JJ40pCnbwMp gL3ZQBeo1NVATlf3Ja1Xl/PxhiWjnD/3r4GiSJ8wK1RoLs7W+avOvKwyXCXw/PhhqR1e Hdnc7XhevBshvWLqkUFUoe+0qlnS/vvl5HLhDxcKpL8k7V3OKAStsw6F5S5sroUHzr1f 1eIWQ8YNTXKhmmfbnLomFv3bA+w97rXZgwtXoSRB2I+4EeRYemJT/STvF10Lgpou2td8 2Otot2aaVwBL0zw4qW7yV592Qkdu1GcBJLqgoLBDv+U0iz8XpEQE9cVOwZ3GjGWHQZWN 7ejg== X-Gm-Message-State: APjAAAUDxqSUyu1maIq+e9LY7FvCpTaOqAQgeHBuawrYaau3ptTM3dgR si4ZOXuqYYbWiGTFrhZL03qA2UbDQe0vjXVLIxQ= X-Google-Smtp-Source: APXvYqxm3eE7t13u5enoot5iHJCQjpR+EgULCWe1r5eJOjSZOdWEZDcDA2ktmx8ibwt91bKi35qNObNDlRbgTJAaiPc= X-Received: by 2002:a2e:a404:: with SMTP id p4mr12826748ljn.234.1578962070015; Mon, 13 Jan 2020 16:34:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Mon, 13 Jan 2020 16:34:18 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: Justin Richer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004c1ded059c0ec1d5" Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 14 Jan 2020 00:34:35 -0000 --0000000000004c1ded059c0ec1d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree, some more "why" would help a broader audience understand the motivations. How about this change to the first paragraph? This group is chartered to develop a delegated identity and authorization protocol. The use cases supported by this protocol will include widely deployed use cases currently supported by OAuth 2.0, and OpenID Connect, an extension of OAuth 2.0. In contrast to OAuth 2.0, where the protocol is initiated by redirecting the user's browser to an authorization server, this protocol will be initiated by the client directly interacting with the authorization server, which will mitigate many of the security concerns and technical challenges of OAuth 2.0. On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle < richanna@amazon.com> wrote: > While I agree with the goals stated in this charter, if I read this from > the perspective of someone who hasn=E2=80=99t been our meetings or listen= ed to > Justin=E2=80=99s presentations, I=E2=80=99m hard pressed to see what the = point of this > group is, relative to the OAuth WG. I=E2=80=99d expect this charter to pr= ovide at > least a cursory explanation of what problem it is trying to solve. In thi= s > case, the problem should be partially defined in relation to OAuth. What > will this WG do that the OAuth WG hasn=E2=80=99t already done or isn=E2= =80=99t already > doing? > > > > How about adding something like the following to paragraph 2: > > > > The protocol will mitigate many of the security concerns and technical > challenges of OAuth 2.0 by communicating over secure channels between the > client and the authorization server, and minimizing the amount of > information transmitted over untrusted channels. > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Friday, January 10, 2020 at 6:57 PM > *To: *Justin Richer > *Cc: *"txauth@ietf.org" > *Subject: *Re: [Txauth] alternative charter writeup > > > > This looks even better! Thanks Justin. > > > > What do others think of the proposed charter now? > > =E1=90=A7 > > > > On Fri, Jan 10, 2020 at 12:43 PM Justin Richer wrote: > > Thanks, Dick. I=E2=80=99ve been working on an updated charter based on ev= eryone=E2=80=99s > feedback, and I was aiming to have out today anyway, so this timing is > helpful. So here=E2=80=99s my take on a new charter, incorporating some o= f your > points below: > > > > This group is chartered to develop a delegation protocol for identity, > authorization, and API access. This protocol will allow an authorizing > party to delegate access to client software through an authorization > server. The use cases supported by this protocol will include widely > deployed use cases currently supported by OAuth 2.0 and OpenID Connect. > > > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will be initiated > by the client interacting directly with the authorization server (in > contrast with OAuth 2 which is initiated by the client redirecting the > user=E2=80=99s browser). The client will involve the authorizing party as= necessary > through interaction mechanisms indicated by the protocol. > > > > Additionally, the delegation process will allow for: > > > > - Fine-grained specification of resource access > > - Approval of identity claims and multiple resources in a single > interaction > > - Delegation between multiple users > > - Web, mobile, single-page, and other types of client 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 providing user, software, organization, and other pieces > of information used in authorization decisions > > - Token presentation mechanisms and key bindings > > > > 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 porting from OAuth 2.0 and OpenID Connect to the > new protocol where possible. > > While the initial work will focus on using HTTP for communication between > the client and the authorization server, the working group will seek to > take advantage of optimization features of HTTP2 and HTTP3, and will stri= ve > to enable simple mapping to other protocols such as COAP. > > > > On Jan 10, 2020, at 12:04 PM, Dick Hardt wrote: > > > > Hey > > > > I've written an alternative charter that I hope captures some of the > feedback on Justin's charter. > > > > I found it easier to rewrite the charter to broaden the marketplace of > ideas. > > > > Key ideas: > > > > - This work supports existing OAuth 2.0, and OpenID Connect use cases. > > > > - The client interacts directly with the authorization server. > > > > /Dick > > > > ---- > > > > This group is chartered to develop a delegated identity and authorization > protocol.. The use cases supported by this protocol will include widely > deployed use cases currently supported by OAuth 2.0, and OpenID Connect. = In > contrast to OAuth 2.0 and OpenID Connect, where the protocol is initiated > by redirecting the user's browser to an authorization server, this protoc= ol > will be initiated by the client directly interacting with the authorizati= on > server.. > > > Additionally, the protocol will allow: > > - fine-grained specification of resource access > > - the user to approve requests for identity claims and access to multiple > resources in one interaction > > - web, mobile, single-page, and other client applications > > - taking advantage of optimization features in HTTP2 and HTTP3 > > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > > - discovery of the authorization server > > - cryptographic agility for keys, message signatures, and proof of > possession > > - user interaction mechanisms including web and non-web methods- token > presentation mechanisms and key bindings > > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt = to > simplify porting from OAuth 2.0 and OpenID Connect, and strive to reuse > existing semantics such as client identifiers, OAuth 2.0 scopes and acces= s > tokens, and OpenID Connect ID Tokens and claims. > > > While the initial work will focus on using HTTP for communication between > the client and the authorization server, the working group will strive to > enable simple mapping to other protocols such as COAP. > > > > > > =E1=90=A7 > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > --0000000000004c1ded059c0ec1d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree, some more "why" would help a broad= er audience understand the motivations. How about this change to the first = paragraph?

This group is c= hartered to develop a delegated identity and authorization protocol. The us= e cases supported by this protocol will include widely deployed use cases c= urrently supported by OAuth 2.0, and OpenID Connect, an extension of OAuth = 2.0. In contrast to OAuth 2.0, where the protocol is initiated by redirecti= ng the user's browser to an authorization server, this protocol will be= initiated by the client directly interacting with the authorization server= , which will mitigate many of the security concerns and technical challenge= s of OAuth 2.0.


On Mon, Jan 13, 2020 at= 3:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

While I agree with the goals stated in this charter,= if I read this from the perspective of someone who hasn=E2=80=99t been our= meetings or listened to Justin=E2=80=99s presentations, I=E2=80=99m hard p= ressed to see what the point of this group is, relative to the OAuth WG. I=E2=80=99d expect this charter to provide at least a cursor= y explanation of what problem it is trying to solve. In this case, the prob= lem should be partially defined in relation to OAuth. What will this WG do = that the OAuth WG hasn=E2=80=99t already done or isn=E2=80=99t already doing?

=C2=A0

How about adding something like the following to par= agraph 2:

=C2=A0

The protocol will mitiga= te many of the security concerns and technical challenges of OAuth 2.0 by c= ommunicating over secure channels between the client and the authorization = server, and minimizing the amount of information transmitted over untrusted channels.

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Bac= kman

AWS Identity

=C2=A0

=C2=A0

From: = Txauth <txauth-bounces@ietf.org<= /a>> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Friday, January 10, 2020 at 6:57 PM
To: Justin Richer <jricher@mit.edu>
Cc: "txaut= h@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] alternative charter writeup

=C2=A0

This looks even better! Thanks Justin.

=C2=A0

What do others think of the proposed charter now?=C2= =A0

=E1=90=A7

=C2=A0

On Fri, Jan 10, 2020 at 12:43 PM Justin Richer <<= a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>= wrote:

Thanks, Dick. I=E2=80=99ve been working on an update= d charter based on everyone=E2=80=99s feedback, and I was aiming to have ou= t today anyway, so this timing is helpful. So here=E2=80=99s my take on a n= ew charter, incorporating some of your points below:

=C2=A0

This group is chartered to develop a delegation prot= ocol for identity, authorization, and API access. This protocol will allow = an authorizing party to delegate access to client software through an autho= rization server. The use cases supported by this protocol will include widely deployed use cases currently supporte= d by OAuth 2.0 and OpenID Connect.=C2=A0

=C2=A0

The delegation process will be acted upon by multipl= e parties in the protocol, each performing a specific role. The protocol wi= ll be initiated by the client interacting directly with the authorization s= erver (in contrast with OAuth 2 which is initiated by the client redirecting the user=E2=80=99s browser). The cl= ient will involve the authorizing party as necessary through interaction me= chanisms indicated by the protocol.=C2=A0

=C2=A0

Additionally, the delegation process will allow for:=

=C2=A0

- Fine-grained specification of resource access

- Approval of identity claims and multiple resources= in a single interaction

- Delegation between multiple users

- Web, mobile, single-page, and other types of clien= t applications

=C2=A0

The group will define extension points for this prot= ocol to allow for flexibility in areas including:

=C2=A0

- Cryptographic agility for keys, message signatures= , and proof of possession=C2=A0

- User interaction mechanisms including web and non-= web methods

- Mechanisms for providing user, software, organizat= ion, and other pieces of information used in authorization decisions=

- Token presentation mechanisms and key bindings<= /u>

=C2=A0

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

=C2=A0

- Discovery of the authorization server

- Revocation of active tokens

- Query of token rights by resource servers

=C2=A0

Although the artifacts for this work are not intende= d or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, = the group will=C2=A0attempt to simplify porting from OAuth 2.0 and OpenID C= onnect to the new protocol where possible.

While the initial work will focus on using HTTP for communication between t= he client and the authorization server, the working group will seek to take= advantage of optimization features of HTTP2 and HTTP3, and will strive to= =C2=A0enable simple mapping to other protocols such as COAP.

=C2=A0

On Jan 10, 2020, at 12:04 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

Hey

=C2=A0

I've written an alternative charter that I hope = captures some of the feedback on Justin's charter.

=C2=A0

I found it easier to rewrite the charter to broaden = the marketplace of ideas.=C2=A0

=C2=A0

Key ideas:

=C2=A0

- This work supports existing OAuth 2.0, and OpenID = Connect use cases.

=C2=A0

- The client interacts directly with the authorizati= on server.=C2=A0

=C2=A0

/Dick

=C2=A0

----

=C2=A0

This group is chartered to develop a delegated ident= ity and authorization protocol.. The use cases supported by this protocol w= ill include widely deployed use cases currently supported by OAuth 2.0, and= OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the protocol is initiated by redirecting the= user's browser to an authorization server, this protocol will be initi= ated by the client directly interacting with the authorization server..<= /u>


Additionally, the protocol will allow:

- fine-grained specification of resource access

- the user to approve requests for identity claims a= nd access to multiple resources in one interaction

- web, mobile, single-page, and other client applica= tions

- taking advantage of optimization features in HTTP2= and HTTP3


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


- discovery of the authorization server

- cryptographic agility for keys, message signatures= , and proof of possession=C2=A0

- user interaction mechanisms including web and non-= web methods- token presentation mechanisms and key bindings


Although the artifacts for this work are not intended or expected to be bac= kwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt to si= mplify porting from OAuth 2.0 and OpenID Connect, and strive to reuse exist= ing semantics such as client identifiers, OAuth 2.0 scopes and access tokens, and OpenID Connect ID Tokens and claim= s.


While the initial work will focus on using HTTP for communication between t= he client and the authorization server, the working group will strive to en= able simple mapping to other protocols such as COAP.

=C2=A0

=C2=A0

=E1=90=A7

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

=C2=A0

--0000000000004c1ded059c0ec1d5-- From nobody Mon Jan 13 17:55: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 7432C120026 for ; Mon, 13 Jan 2020 17:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.496 X-Spam-Level: X-Spam-Status: No, score=-14.496 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 4QE2nq855CYr for ; Mon, 13 Jan 2020 17:55:00 -0800 (PST) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.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 19B6912001B for ; Mon, 13 Jan 2020 17:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578966900; x=1610502900; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tZDfIqrHGVyY3jCcQ4VpTteLOkGm4fc6xOrtdWmcSIY=; b=jnlekazij877n/AHuIONPaPyveJ7xzqDx18KqCs0eJIqINT79l0DZAdb HvIV7DTOltfZdQYq6xD98kmOI2MZT4V8xUBhfZADKsg+pgMFcmBuqWlH+ AV58vHD4cKEpYPtnLFJRAiMGPczlkGUai6BjpaGX18JNBAbje2cJQuuwq M=; IronPort-SDR: uhm9uaViiodSxKKQM1r3+vsrCFIwo8hUzqGB0xNcPoXFWgqTNeX1t78qYbbdFV9UH+LVoG5IWt PrNWQB9SlgcQ== X-IronPort-AV: E=Sophos; i="5.69,431,1571702400"; d="scan'208,217"; a="12301219" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1d-38ae4ad2.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 14 Jan 2020 01:54:58 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1d-38ae4ad2.us-east-1.amazon.com (Postfix) with ESMTPS id 16BB0A28B5; Tue, 14 Jan 2020 01:54:58 +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, 14 Jan 2020 01:54:57 +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.1367.3; Tue, 14 Jan 2020 01:54:57 +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.1367.000; Tue, 14 Jan 2020 01:54:57 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt CC: Justin Richer , "txauth@ietf.org" Thread-Topic: [Txauth] alternative charter writeup Thread-Index: AQHVx9g9cyOj1MRzqU6+3+Goa7VakafkXaAAgABoEICAA/l4gIAAld0A//+QawA= Date: Tue, 14 Jan 2020 01:54:57 +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.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.95] Content-Type: multipart/alternative; boundary="_000_A6D90193D3FC4BDB8F4C55A30ED252EEamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 14 Jan 2020 01:55:04 -0000 --_000_A6D90193D3FC4BDB8F4C55A30ED252EEamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXTigJlzIG5vdCBqdXN0IGFib3V0IHRoZSBpbml0aWFsIGNvbW11bmljYXRpb24sIHRob3VnaC4g SSB0aGUga2V5IHRoaW5nIHRvIGVtcGhhc2l6ZSBpcyB0aGUgZGVjb3VwbGluZyB0aGUgcHJvdG9j b2wgZnJvbSBkZWxlZ2F0aW9uIGNoYW5uZWxzLCB3aGljaCBhZGRyZXNzZXMgdGhlIGFmb3JlbWVu dGlvbmVkIHNlY3VyaXR5L2NvbXBsZXhpdHkgaXNzdWVzIGFuZCBhbHNvIHByb3ZpZGVzIGEgcGF0 aCB0byBzdXBwb3J0IGZ1dHVyZSBkZWxlZ2F0aW9uIGNoYW5uZWwgdHlwZXMgd2l0aG91dCBzaWdu aWZpY2FudCBjaGFuZ2VzIHRvIHRoZSBwcm90b2NvbCAodW5saWtlIE9BdXRoIDIuMCwgd2hlcmUg ZXh0ZW5zaW9ucyBsaWtlIERldmljZSBGbG93IGFuZCBQQVIgaW50cm9kdWNlIHN1YnN0YW50aWFs IGNoYW5nZXMgdG8gdGhlIGNvcmUgcHJvdG9jb2wgZmxvdyBvbiBib3RoIGNsaWVudCBhbmQgQVMp LiBTaW5jZSB0aGUgcHJvdG9jb2wgaXNu4oCZdCBhc3N1bWluZyBhIHBhcnRpY3VsYXIgZnJvbnQg Y2hhbm5lbCwgaXTigJlzIGVhc2llciB0byBhZGQgc3VwcG9ydCBmb3IgYSBuZXcgb25lLg0KDQpQ cm9wb3NhbCwgYWx0ZXJlZCBmcm9tIERpY2vigJlzIHN1Z2dlc3Rpb246DQpUaGlzIGdyb3VwIGlz IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGEgZGVsZWdhdGVkIGlkZW50aXR5IGFuZCBhdXRob3JpemF0 aW9uIHByb3RvY29sLiBUaGUgdXNlIGNhc2VzIHN1cHBvcnRlZCBieSB0aGlzIHByb3RvY29sIHdp bGwgaW5jbHVkZSB3aWRlbHkgZGVwbG95ZWQgdXNlIGNhc2VzIGN1cnJlbnRseSBzdXBwb3J0ZWQg YnkgT0F1dGggMi4wLCBhbmQgT3BlbklEIENvbm5lY3QsIGFuIGV4dGVuc2lvbiBvZiBPQXV0aCAy LjAuIFRoaXMgcHJvdG9jb2wgd2lsbCBiZSBkZWNvdXBsZWQgZnJvbSBkZWxlZ2F0aW9uIGNoYW5u ZWxzIHN1Y2ggYXMgYW4gZW5kIHVzZXLigJlzIHdlYiBicm93c2VyIGFuZCBvcGVyYXRlIHByaW1h cmlseSB0aHJvdWdoIGEgY2hhbm5lbCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciwgYXZvaWRpbmcgbWFueSBvZiB0aGUgc2VjdXJpdHkgY29uY2VybnMgYW5k IHRlY2huaWNhbCBjaGFsbGVuZ2VzIG9mIE9BdXRoIDIuMCBhbmQgcHJvdmlkaW5nIGEgbm9uLWlu dmFzaXZlIHBhdGggZm9yIGFkZGluZyBzdXBwb3J0IGZvciBmdXR1cmUgdHlwZXMgb2YgY2xpZW50 cyBhbmQgZGVsZWdhdGlvbiBjaGFubmVscy4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNr bWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWls LmNvbT4NCkRhdGU6IE1vbmRheSwgSmFudWFyeSAxMywgMjAyMCBhdCA0OjM1IFBNDQpUbzogIlJp Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbT4NCkNjOiBKdXN0 aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+LCAidHhhdXRoQGlldGYub3JnIiA8dHhhdXRoQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtUeGF1dGhdIGFsdGVybmF0aXZlIGNoYXJ0ZXIgd3JpdGV1 cA0KDQpJIGFncmVlLCBzb21lIG1vcmUgIndoeSIgd291bGQgaGVscCBhIGJyb2FkZXIgYXVkaWVu Y2UgdW5kZXJzdGFuZCB0aGUgbW90aXZhdGlvbnMuIEhvdyBhYm91dCB0aGlzIGNoYW5nZSB0byB0 aGUgZmlyc3QgcGFyYWdyYXBoPw0KDQpUaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9w IGEgZGVsZWdhdGVkIGlkZW50aXR5IGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29sLiBUaGUgdXNl IGNhc2VzIHN1cHBvcnRlZCBieSB0aGlzIHByb3RvY29sIHdpbGwgaW5jbHVkZSB3aWRlbHkgZGVw bG95ZWQgdXNlIGNhc2VzIGN1cnJlbnRseSBzdXBwb3J0ZWQgYnkgT0F1dGggMi4wLCBhbmQgT3Bl bklEIENvbm5lY3QsIGFuIGV4dGVuc2lvbiBvZiBPQXV0aCAyLjAuIEluIGNvbnRyYXN0IHRvIE9B dXRoIDIuMCwgd2hlcmUgdGhlIHByb3RvY29sIGlzIGluaXRpYXRlZCBieSByZWRpcmVjdGluZyB0 aGUgdXNlcidzIGJyb3dzZXIgdG8gYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRoaXMgcHJvdG9j b2wgd2lsbCBiZSBpbml0aWF0ZWQgYnkgdGhlIGNsaWVudCBkaXJlY3RseSBpbnRlcmFjdGluZyB3 aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgd2hpY2ggd2lsbCBtaXRpZ2F0ZSBtYW55IG9m IHRoZSBzZWN1cml0eSBjb25jZXJucyBhbmQgdGVjaG5pY2FsIGNoYWxsZW5nZXMgb2YgT0F1dGgg Mi4wLg0KDQoNCk9uIE1vbiwgSmFuIDEzLCAyMDIwIGF0IDM6MzggUE0gUmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5j b20+PiB3cm90ZToNCldoaWxlIEkgYWdyZWUgd2l0aCB0aGUgZ29hbHMgc3RhdGVkIGluIHRoaXMg Y2hhcnRlciwgaWYgSSByZWFkIHRoaXMgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2Ygc29tZW9uZSB3 aG8gaGFzbuKAmXQgYmVlbiBvdXIgbWVldGluZ3Mgb3IgbGlzdGVuZWQgdG8gSnVzdGlu4oCZcyBw cmVzZW50YXRpb25zLCBJ4oCZbSBoYXJkIHByZXNzZWQgdG8gc2VlIHdoYXQgdGhlIHBvaW50IG9m IHRoaXMgZ3JvdXAgaXMsIHJlbGF0aXZlIHRvIHRoZSBPQXV0aCBXRy4gSeKAmWQgZXhwZWN0IHRo aXMgY2hhcnRlciB0byBwcm92aWRlIGF0IGxlYXN0IGEgY3Vyc29yeSBleHBsYW5hdGlvbiBvZiB3 aGF0IHByb2JsZW0gaXQgaXMgdHJ5aW5nIHRvIHNvbHZlLiBJbiB0aGlzIGNhc2UsIHRoZSBwcm9i bGVtIHNob3VsZCBiZSBwYXJ0aWFsbHkgZGVmaW5lZCBpbiByZWxhdGlvbiB0byBPQXV0aC4gV2hh dCB3aWxsIHRoaXMgV0cgZG8gdGhhdCB0aGUgT0F1dGggV0cgaGFzbuKAmXQgYWxyZWFkeSBkb25l IG9yIGlzbuKAmXQgYWxyZWFkeSBkb2luZz8NCg0KSG93IGFib3V0IGFkZGluZyBzb21ldGhpbmcg bGlrZSB0aGUgZm9sbG93aW5nIHRvIHBhcmFncmFwaCAyOg0KDQpUaGUgcHJvdG9jb2wgd2lsbCBt aXRpZ2F0ZSBtYW55IG9mIHRoZSBzZWN1cml0eSBjb25jZXJucyBhbmQgdGVjaG5pY2FsIGNoYWxs ZW5nZXMgb2YgT0F1dGggMi4wIGJ5IGNvbW11bmljYXRpbmcgb3ZlciBzZWN1cmUgY2hhbm5lbHMg YmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGFuZCBtaW5p bWl6aW5nIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgb3ZlciB1bnRydXN0 ZWQgY2hhbm5lbHMuDQoNCuKAkw0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50 aXR5DQoNCg0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHhh dXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8ZGljay5oYXJk dEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkRhdGU6IEZyaWRheSwg SmFudWFyeSAxMCwgMjAyMCBhdCA2OjU3IFBNDQpUbzogSnVzdGluIFJpY2hlciA8anJpY2hlckBt aXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+Pg0KQ2M6ICJ0eGF1dGhAaWV0Zi5vcmc8bWFp bHRvOnR4YXV0aEBpZXRmLm9yZz4iIDx0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBpZXRm Lm9yZz4+DQpTdWJqZWN0OiBSZTogW1R4YXV0aF0gYWx0ZXJuYXRpdmUgY2hhcnRlciB3cml0ZXVw DQoNClRoaXMgbG9va3MgZXZlbiBiZXR0ZXIhIFRoYW5rcyBKdXN0aW4uDQoNCldoYXQgZG8gb3Ro ZXJzIHRoaW5rIG9mIHRoZSBwcm9wb3NlZCBjaGFydGVyIG5vdz8NCltodHRwczovL21haWxmb29n YWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZ0 eXBlPXplcm9jb250ZW50Jmd1aWQ9YzI1NDJhNzMtOWIzNi00MmYxLWIwOTEtYjA3Y2VhZGUxOGVl XeGQpw0KDQpPbiBGcmksIEphbiAxMCwgMjAyMCBhdCAxMjo0MyBQTSBKdXN0aW4gUmljaGVyIDxq cmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KVGhhbmtzLCBE aWNrLiBJ4oCZdmUgYmVlbiB3b3JraW5nIG9uIGFuIHVwZGF0ZWQgY2hhcnRlciBiYXNlZCBvbiBl dmVyeW9uZeKAmXMgZmVlZGJhY2ssIGFuZCBJIHdhcyBhaW1pbmcgdG8gaGF2ZSBvdXQgdG9kYXkg YW55d2F5LCBzbyB0aGlzIHRpbWluZyBpcyBoZWxwZnVsLiBTbyBoZXJl4oCZcyBteSB0YWtlIG9u IGEgbmV3IGNoYXJ0ZXIsIGluY29ycG9yYXRpbmcgc29tZSBvZiB5b3VyIHBvaW50cyBiZWxvdzoN Cg0KVGhpcyBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBhIGRlbGVnYXRpb24gcHJvdG9j b2wgZm9yIGlkZW50aXR5LCBhdXRob3JpemF0aW9uLCBhbmQgQVBJIGFjY2Vzcy4gVGhpcyBwcm90 b2NvbCB3aWxsIGFsbG93IGFuIGF1dGhvcml6aW5nIHBhcnR5IHRvIGRlbGVnYXRlIGFjY2VzcyB0 byBjbGllbnQgc29mdHdhcmUgdGhyb3VnaCBhbiBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhlIHVz ZSBjYXNlcyBzdXBwb3J0ZWQgYnkgdGhpcyBwcm90b2NvbCB3aWxsIGluY2x1ZGUgd2lkZWx5IGRl cGxveWVkIHVzZSBjYXNlcyBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5IE9BdXRoIDIuMCBhbmQgT3Bl bklEIENvbm5lY3QuDQoNClRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mgd2lsbCBiZSBhY3RlZCB1cG9u IGJ5IG11bHRpcGxlIHBhcnRpZXMgaW4gdGhlIHByb3RvY29sLCBlYWNoIHBlcmZvcm1pbmcgYSBz cGVjaWZpYyByb2xlLiBUaGUgcHJvdG9jb2wgd2lsbCBiZSBpbml0aWF0ZWQgYnkgdGhlIGNsaWVu dCBpbnRlcmFjdGluZyBkaXJlY3RseSB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciAoaW4g Y29udHJhc3Qgd2l0aCBPQXV0aCAyIHdoaWNoIGlzIGluaXRpYXRlZCBieSB0aGUgY2xpZW50IHJl ZGlyZWN0aW5nIHRoZSB1c2Vy4oCZcyBicm93c2VyKS4gVGhlIGNsaWVudCB3aWxsIGludm9sdmUg dGhlIGF1dGhvcml6aW5nIHBhcnR5IGFzIG5lY2Vzc2FyeSB0aHJvdWdoIGludGVyYWN0aW9uIG1l Y2hhbmlzbXMgaW5kaWNhdGVkIGJ5IHRoZSBwcm90b2NvbC4NCg0KQWRkaXRpb25hbGx5LCB0aGUg ZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYWxsb3cgZm9yOg0KDQotIEZpbmUtZ3JhaW5lZCBzcGVj aWZpY2F0aW9uIG9mIHJlc291cmNlIGFjY2Vzcw0KLSBBcHByb3ZhbCBvZiBpZGVudGl0eSBjbGFp bXMgYW5kIG11bHRpcGxlIHJlc291cmNlcyBpbiBhIHNpbmdsZSBpbnRlcmFjdGlvbg0KLSBEZWxl Z2F0aW9uIGJldHdlZW4gbXVsdGlwbGUgdXNlcnMNCi0gV2ViLCBtb2JpbGUsIHNpbmdsZS1wYWdl LCBhbmQgb3RoZXIgdHlwZXMgb2YgY2xpZW50IGFwcGxpY2F0aW9ucw0KDQpUaGUgZ3JvdXAgd2ls bCBkZWZpbmUgZXh0ZW5zaW9uIHBvaW50cyBmb3IgdGhpcyBwcm90b2NvbCB0byBhbGxvdyBmb3Ig ZmxleGliaWxpdHkgaW4gYXJlYXMgaW5jbHVkaW5nOg0KDQotIENyeXB0b2dyYXBoaWMgYWdpbGl0 eSBmb3Iga2V5cywgbWVzc2FnZSBzaWduYXR1cmVzLCBhbmQgcHJvb2Ygb2YgcG9zc2Vzc2lvbg0K LSBVc2VyIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5jbHVkaW5nIHdlYiBhbmQgbm9uLXdlYiBt ZXRob2RzDQotIE1lY2hhbmlzbXMgZm9yIHByb3ZpZGluZyB1c2VyLCBzb2Z0d2FyZSwgb3JnYW5p emF0aW9uLCBhbmQgb3RoZXIgcGllY2VzIG9mIGluZm9ybWF0aW9uIHVzZWQgaW4gYXV0aG9yaXph dGlvbiBkZWNpc2lvbnMNCi0gVG9rZW4gcHJlc2VudGF0aW9uIG1lY2hhbmlzbXMgYW5kIGtleSBi aW5kaW5ncw0KDQpBZGRpdGlvbmFsbHksIHRoZSBncm91cCB3aWxsIHByb3ZpZGUgbWVjaGFuaXNt cyBmb3IgbWFuYWdlbWVudCBvZiB0aGUgcHJvdG9jb2wgbGlmZWN5Y2xlIGluY2x1ZGluZzoNCg0K LSBEaXNjb3Zlcnkgb2YgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyDQotIFJldm9jYXRpb24gb2Yg YWN0aXZlIHRva2Vucw0KLSBRdWVyeSBvZiB0b2tlbiByaWdodHMgYnkgcmVzb3VyY2Ugc2VydmVy cw0KDQpBbHRob3VnaCB0aGUgYXJ0aWZhY3RzIGZvciB0aGlzIHdvcmsgYXJlIG5vdCBpbnRlbmRl ZCBvciBleHBlY3RlZCB0byBiZSBiYWNrd2FyZHMtY29tcGF0aWJsZSB3aXRoIE9BdXRoIDIuMCBv ciBPcGVuSUQgQ29ubmVjdCwgdGhlIGdyb3VwIHdpbGwgYXR0ZW1wdCB0byBzaW1wbGlmeSBwb3J0 aW5nIGZyb20gT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCB0byB0aGUgbmV3IHByb3RvY29s IHdoZXJlIHBvc3NpYmxlLg0KDQpXaGlsZSB0aGUgaW5pdGlhbCB3b3JrIHdpbGwgZm9jdXMgb24g dXNpbmcgSFRUUCBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciwgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBzZWVrIHRvIHRha2Ug YWR2YW50YWdlIG9mIG9wdGltaXphdGlvbiBmZWF0dXJlcyBvZiBIVFRQMiBhbmQgSFRUUDMsIGFu ZCB3aWxsIHN0cml2ZSB0byBlbmFibGUgc2ltcGxlIG1hcHBpbmcgdG8gb3RoZXIgcHJvdG9jb2xz IHN1Y2ggYXMgQ09BUC4NCg0KT24gSmFuIDEwLCAyMDIwLCBhdCAxMjowNCBQTSwgRGljayBIYXJk dCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3Jv dGU6DQoNCkhleQ0KDQpJJ3ZlIHdyaXR0ZW4gYW4gYWx0ZXJuYXRpdmUgY2hhcnRlciB0aGF0IEkg aG9wZSBjYXB0dXJlcyBzb21lIG9mIHRoZSBmZWVkYmFjayBvbiBKdXN0aW4ncyBjaGFydGVyLg0K DQpJIGZvdW5kIGl0IGVhc2llciB0byByZXdyaXRlIHRoZSBjaGFydGVyIHRvIGJyb2FkZW4gdGhl IG1hcmtldHBsYWNlIG9mIGlkZWFzLg0KDQpLZXkgaWRlYXM6DQoNCi0gVGhpcyB3b3JrIHN1cHBv cnRzIGV4aXN0aW5nIE9BdXRoIDIuMCwgYW5kIE9wZW5JRCBDb25uZWN0IHVzZSBjYXNlcy4NCg0K LSBUaGUgY2xpZW50IGludGVyYWN0cyBkaXJlY3RseSB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlci4NCg0KL0RpY2sNCg0KLS0tLQ0KDQpUaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZl bG9wIGEgZGVsZWdhdGVkIGlkZW50aXR5IGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29sLi4gVGhl IHVzZSBjYXNlcyBzdXBwb3J0ZWQgYnkgdGhpcyBwcm90b2NvbCB3aWxsIGluY2x1ZGUgd2lkZWx5 IGRlcGxveWVkIHVzZSBjYXNlcyBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5IE9BdXRoIDIuMCwgYW5k IE9wZW5JRCBDb25uZWN0LiBJbiBjb250cmFzdCB0byBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25u ZWN0LCB3aGVyZSB0aGUgcHJvdG9jb2wgaXMgaW5pdGlhdGVkIGJ5IHJlZGlyZWN0aW5nIHRoZSB1 c2VyJ3MgYnJvd3NlciB0byBhbiBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhpcyBwcm90b2NvbCB3 aWxsIGJlIGluaXRpYXRlZCBieSB0aGUgY2xpZW50IGRpcmVjdGx5IGludGVyYWN0aW5nIHdpdGgg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyLi4NCg0KQWRkaXRpb25hbGx5LCB0aGUgcHJvdG9jb2wg d2lsbCBhbGxvdzoNCi0gZmluZS1ncmFpbmVkIHNwZWNpZmljYXRpb24gb2YgcmVzb3VyY2UgYWNj ZXNzDQotIHRoZSB1c2VyIHRvIGFwcHJvdmUgcmVxdWVzdHMgZm9yIGlkZW50aXR5IGNsYWltcyBh bmQgYWNjZXNzIHRvIG11bHRpcGxlIHJlc291cmNlcyBpbiBvbmUgaW50ZXJhY3Rpb24NCi0gd2Vi LCBtb2JpbGUsIHNpbmdsZS1wYWdlLCBhbmQgb3RoZXIgY2xpZW50IGFwcGxpY2F0aW9ucw0KLSB0 YWtpbmcgYWR2YW50YWdlIG9mIG9wdGltaXphdGlvbiBmZWF0dXJlcyBpbiBIVFRQMiBhbmQgSFRU UDMNCg0KVGhlIGdyb3VwIHdpbGwgZGVmaW5lIGV4dGVuc2lvbiBwb2ludHMgZm9yIHRoaXMgcHJv dG9jb2wgdG8gYWxsb3cgZm9yIGZsZXhpYmlsaXR5IGluIGFyZWFzIGluY2x1ZGluZzoNCg0KLSBk aXNjb3Zlcnkgb2YgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyDQotIGNyeXB0b2dyYXBoaWMgYWdp bGl0eSBmb3Iga2V5cywgbWVzc2FnZSBzaWduYXR1cmVzLCBhbmQgcHJvb2Ygb2YgcG9zc2Vzc2lv bg0KLSB1c2VyIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5jbHVkaW5nIHdlYiBhbmQgbm9uLXdl YiBtZXRob2RzLSB0b2tlbiBwcmVzZW50YXRpb24gbWVjaGFuaXNtcyBhbmQga2V5IGJpbmRpbmdz DQoNCkFsdGhvdWdoIHRoZSBhcnRpZmFjdHMgZm9yIHRoaXMgd29yayBhcmUgbm90IGludGVuZGVk IG9yIGV4cGVjdGVkIHRvIGJlIGJhY2t3YXJkcy1jb21wYXRpYmxlIHdpdGggT0F1dGggMi4wIG9y IE9wZW5JRCBDb25uZWN0LCB0aGV5IHdpbGwgYXR0ZW1wdCB0byBzaW1wbGlmeSBwb3J0aW5nIGZy b20gT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCwgYW5kIHN0cml2ZSB0byByZXVzZSBleGlz dGluZyBzZW1hbnRpY3Mgc3VjaCBhcyBjbGllbnQgaWRlbnRpZmllcnMsIE9BdXRoIDIuMCBzY29w ZXMgYW5kIGFjY2VzcyB0b2tlbnMsIGFuZCBPcGVuSUQgQ29ubmVjdCBJRCBUb2tlbnMgYW5kIGNs YWltcy4NCg0KV2hpbGUgdGhlIGluaXRpYWwgd29yayB3aWxsIGZvY3VzIG9uIHVzaW5nIEhUVFAg Zm9yIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgc3RyaXZlIHRvIGVuYWJsZSBzaW1wbGUg bWFwcGluZyB0byBvdGhlciBwcm90b2NvbHMgc3VjaCBhcyBDT0FQLg0KDQoNCltodHRwczovL21h aWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIy MCUzRCZ0eXBlPXplcm9jb250ZW50Jmd1aWQ9NDEwMGYxMWMtMTVjYS00ZDQ1LWJiZDItYzAyOTk2 NTgyMWZiXeGQpw0KLS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4YXV0aEBpZXRmLm9yZzxtYWls dG86VHhhdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90eGF1dGgNCg0K --_000_A6D90193D3FC4BDB8F4C55A30ED252EEamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <17A3D0329B21874F97BEC5CC8BB1824C@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAy IDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQg MiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkV1cGhlbWlhIFVDQVMiOw0K CXBhbm9zZS0xOjIgMTEgNSAzIDQgMSAyIDIgMSA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlz dFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3NTI1NTE0NzI7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjc1MjAxMDk1MCA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo5MjczNDM2NDg7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjkxNjM3NTc0MCA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXTigJlzIG5v dCBqdXN0IGFib3V0IHRoZSBpbml0aWFsIGNvbW11bmljYXRpb24sIHRob3VnaC4gSSB0aGUga2V5 IHRoaW5nIHRvIGVtcGhhc2l6ZSBpcyB0aGUgZGVjb3VwbGluZyB0aGUgcHJvdG9jb2wgZnJvbSBk ZWxlZ2F0aW9uIGNoYW5uZWxzLCB3aGljaCBhZGRyZXNzZXMgdGhlIGFmb3JlbWVudGlvbmVkIHNl Y3VyaXR5L2NvbXBsZXhpdHkgaXNzdWVzIGFuZCBhbHNvIHByb3ZpZGVzIGEgcGF0aCB0byBzdXBw b3J0DQogZnV0dXJlIGRlbGVnYXRpb24gY2hhbm5lbCB0eXBlcyB3aXRob3V0IHNpZ25pZmljYW50 IGNoYW5nZXMgdG8gdGhlIHByb3RvY29sICh1bmxpa2UgT0F1dGggMi4wLCB3aGVyZSBleHRlbnNp b25zIGxpa2UgRGV2aWNlIEZsb3cgYW5kIFBBUiBpbnRyb2R1Y2Ugc3Vic3RhbnRpYWwgY2hhbmdl cyB0byB0aGUgY29yZSBwcm90b2NvbCBmbG93IG9uIGJvdGggY2xpZW50IGFuZCBBUykuIFNpbmNl IHRoZSBwcm90b2NvbCBpc27igJl0IGFzc3VtaW5nIGEgcGFydGljdWxhcg0KIGZyb250IGNoYW5u ZWwsIGl04oCZcyBlYXNpZXIgdG8gYWRkIHN1cHBvcnQgZm9yIGEgbmV3IG9uZS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UHJvcG9zYWwsIGFsdGVyZWQgZnJvbSBEaWNr4oCZcyBzdWdnZXN0aW9u OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPlRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBkZWxlZ2F0ZWQgaWRl bnRpdHkgYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2wuIFRoZSB1c2UgY2FzZXMgc3VwcG9ydGVk IGJ5IHRoaXMgcHJvdG9jb2wgd2lsbCBpbmNsdWRlIHdpZGVseSBkZXBsb3llZCB1c2UgY2FzZXMg Y3VycmVudGx5IHN1cHBvcnRlZCBieSBPQXV0aCAyLjAsIGFuZCBPcGVuSUQgQ29ubmVjdCwNCiBh biBleHRlbnNpb24gb2YgT0F1dGggMi4wLiBUaGlzIHByb3RvY29sIHdpbGwgYmUgZGVjb3VwbGVk IGZyb20gZGVsZWdhdGlvbiBjaGFubmVscyBzdWNoIGFzIGFuIGVuZCB1c2Vy4oCZcyB3ZWIgYnJv d3NlciBhbmQgb3BlcmF0ZSBwcmltYXJpbHkgdGhyb3VnaCBhIGNoYW5uZWwgYmV0d2VlbiB0aGUg Y2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGF2b2lkaW5nIG1hbnkgb2YgdGhl IHNlY3VyaXR5IGNvbmNlcm5zIGFuZCB0ZWNobmljYWwNCiBjaGFsbGVuZ2VzIG9mIE9BdXRoIDIu MCBhbmQgcHJvdmlkaW5nIGEgbm9uLWludmFzaXZlIHBhdGggZm9yIGFkZGluZyBzdXBwb3J0IGZv ciBmdXR1cmUgdHlwZXMgb2YgY2xpZW50cyBhbmQgZGVsZWdhdGlvbiBjaGFubmVscy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFi ZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkRpY2sgSGFyZHQgJmx0O2Rp Y2suaGFyZHRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEphbnVhcnkg MTMsIDIwMjAgYXQgNDozNSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6 IDwvYj5KdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7LCAmcXVvdDt0eGF1dGhA aWV0Zi5vcmcmcXVvdDsgJmx0O3R4YXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8 L2I+UmU6IFtUeGF1dGhdIGFsdGVybmF0aXZlIGNoYXJ0ZXIgd3JpdGV1cDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg YWdyZWUsIHNvbWUgbW9yZSAmcXVvdDt3aHkmcXVvdDsgd291bGQgaGVscCBhIGJyb2FkZXIgYXVk aWVuY2UgdW5kZXJzdGFuZCB0aGUgbW90aXZhdGlvbnMuIEhvdyBhYm91dCB0aGlzIGNoYW5nZSB0 byB0aGUgZmlyc3QgcGFyYWdyYXBoPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGEg ZGVsZWdhdGVkIGlkZW50aXR5IGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29sLiBUaGUgdXNlIGNh c2VzIHN1cHBvcnRlZCBieSB0aGlzIHByb3RvY29sIHdpbGwgaW5jbHVkZSB3aWRlbHkgZGVwbG95 ZWQgdXNlIGNhc2VzIGN1cnJlbnRseSBzdXBwb3J0ZWQgYnkgT0F1dGggMi4wLCBhbmQgT3BlbklE IENvbm5lY3QsIGFuIGV4dGVuc2lvbiBvZiBPQXV0aA0KIDIuMC4gSW4gY29udHJhc3QgdG8gT0F1 dGggMi4wLCB3aGVyZSB0aGUgcHJvdG9jb2wgaXMgaW5pdGlhdGVkIGJ5IHJlZGlyZWN0aW5nIHRo ZSB1c2VyJ3MgYnJvd3NlciB0byBhbiBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhpcyBwcm90b2Nv bCB3aWxsIGJlIGluaXRpYXRlZCBieSB0aGUgY2xpZW50IGRpcmVjdGx5IGludGVyYWN0aW5nIHdp dGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCB3aGljaCB3aWxsIG1pdGlnYXRlIG1hbnkgb2Yg dGhlIHNlY3VyaXR5DQogY29uY2VybnMgYW5kIHRlY2huaWNhbCBjaGFsbGVuZ2VzIG9mIE9BdXRo IDIuMC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBNb24sIEphbiAxMywgMjAyMCBhdCAzOjM4IFBNIFJpY2hhcmQgQmFja21hbiwgQW5u YWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSI+cmljaGFubmFA YW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoaWxlIEkgYWdyZWUg d2l0aCB0aGUgZ29hbHMgc3RhdGVkIGluIHRoaXMgY2hhcnRlciwgaWYgSSByZWFkIHRoaXMgZnJv bSB0aGUgcGVyc3BlY3RpdmUgb2Ygc29tZW9uZSB3aG8gaGFzbuKAmXQgYmVlbiBvdXIgbWVldGlu Z3Mgb3IgbGlzdGVuZWQgdG8gSnVzdGlu4oCZcyBwcmVzZW50YXRpb25zLCBJ4oCZbSBoYXJkDQog cHJlc3NlZCB0byBzZWUgd2hhdCB0aGUgcG9pbnQgb2YgdGhpcyBncm91cCBpcywgcmVsYXRpdmUg dG8gdGhlIE9BdXRoIFdHLiBJ4oCZZCBleHBlY3QgdGhpcyBjaGFydGVyIHRvIHByb3ZpZGUgYXQg bGVhc3QgYSBjdXJzb3J5IGV4cGxhbmF0aW9uIG9mIHdoYXQgcHJvYmxlbSBpdCBpcyB0cnlpbmcg dG8gc29sdmUuIEluIHRoaXMgY2FzZSwgdGhlIHByb2JsZW0gc2hvdWxkIGJlIHBhcnRpYWxseSBk ZWZpbmVkIGluIHJlbGF0aW9uIHRvIE9BdXRoLiBXaGF0DQogd2lsbCB0aGlzIFdHIGRvIHRoYXQg dGhlIE9BdXRoIFdHIGhhc27igJl0IGFscmVhZHkgZG9uZSBvciBpc27igJl0IGFscmVhZHkgZG9p bmc/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3cgYWJvdXQgYWRkaW5nIHNvbWV0aGlu ZyBsaWtlIHRoZSBmb2xsb3dpbmcgdG8gcGFyYWdyYXBoIDI6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KVGhlIHByb3RvY29sIHdpbGwgbWl0aWdhdGUgbWFu eSBvZiB0aGUgc2VjdXJpdHkgY29uY2VybnMgYW5kIHRlY2huaWNhbCBjaGFsbGVuZ2VzIG9mIE9B dXRoIDIuMCBieSBjb21tdW5pY2F0aW5nIG92ZXIgc2VjdXJlIGNoYW5uZWxzIGJldHdlZW4gdGhl IGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBhbmQgbWluaW1pemluZyB0aGUg YW1vdW50IG9mIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIG92ZXIgdW50cnVzdGVkIGNoYW5uZWxz LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij7igJMmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgUmljaGFy ZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UeGF1dGggJmx0OzxhIGhyZWY9 Im1haWx0bzp0eGF1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnR4YXV0aC1i b3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIERpY2sgSGFyZHQgJmx0OzxhIGhy ZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFy ZHRAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBKYW51YXJ5IDEw LCAyMDIwIGF0IDY6NTcgUE08YnI+DQo8Yj5UbzogPC9iPkp1c3RpbiBSaWNoZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5l ZHU8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnR4YXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1dGhAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1R4YXV0aF0gYWx0ZXJuYXRp dmUgY2hhcnRlciB3cml0ZXVwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBsb29rcyBldmVuIGJldHRlciEgVGhhbmtz IEp1c3Rpbi4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPldoYXQgZG8gb3RoZXJzIHRoaW5rIG9mIHRoZSBwcm9wb3NlZCBjaGFydGVyIG5vdz8mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48aW1nIGJvcmRlcj0iMCIgaWQ9ImdtYWlsLW1fLTQyODI5NTI0OTc4NjMwNzE5MzRf eDAwNWZfeDAwMDBfaTEwMjYiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/ c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9emVyb2NvbnRl bnQmYW1wO2d1aWQ9YzI1NDJhNzMtOWIzNi00MmYxLWIwOTEtYjA3Y2VhZGUxOGVlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0V1cGhlbWlhIFVDQVMmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgSmFuIDEwLCAyMDIwIGF0IDEy OjQzIFBNIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUi IHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MsIERpY2suIEnigJl2 ZSBiZWVuIHdvcmtpbmcgb24gYW4gdXBkYXRlZCBjaGFydGVyIGJhc2VkIG9uIGV2ZXJ5b25l4oCZ cyBmZWVkYmFjaywgYW5kIEkgd2FzIGFpbWluZyB0byBoYXZlIG91dCB0b2RheSBhbnl3YXksIHNv IHRoaXMgdGltaW5nIGlzIGhlbHBmdWwuIFNvIGhlcmXigJlzIG15IHRha2Ugb24gYQ0KIG5ldyBj aGFydGVyLCBpbmNvcnBvcmF0aW5nIHNvbWUgb2YgeW91ciBwb2ludHMgYmVsb3c6IDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxv cCBhIGRlbGVnYXRpb24gcHJvdG9jb2wgZm9yIGlkZW50aXR5LCBhdXRob3JpemF0aW9uLCBhbmQg QVBJIGFjY2Vzcy4gVGhpcyBwcm90b2NvbCB3aWxsIGFsbG93IGFuIGF1dGhvcml6aW5nIHBhcnR5 IHRvIGRlbGVnYXRlIGFjY2VzcyB0byBjbGllbnQNCiBzb2Z0d2FyZSB0aHJvdWdoIGFuIGF1dGhv cml6YXRpb24gc2VydmVyLiBUaGUgdXNlIGNhc2VzIHN1cHBvcnRlZCBieSB0aGlzIHByb3RvY29s IHdpbGwgaW5jbHVkZSB3aWRlbHkgZGVwbG95ZWQgdXNlIGNhc2VzIGN1cnJlbnRseSBzdXBwb3J0 ZWQgYnkgT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBkZWxlZ2F0aW9u IHByb2Nlc3Mgd2lsbCBiZSBhY3RlZCB1cG9uIGJ5IG11bHRpcGxlIHBhcnRpZXMgaW4gdGhlIHBy b3RvY29sLCBlYWNoIHBlcmZvcm1pbmcgYSBzcGVjaWZpYyByb2xlLiBUaGUgcHJvdG9jb2wgd2ls bCBiZSBpbml0aWF0ZWQgYnkgdGhlIGNsaWVudCBpbnRlcmFjdGluZyBkaXJlY3RseQ0KIHdpdGgg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChpbiBjb250cmFzdCB3aXRoIE9BdXRoIDIgd2hpY2gg aXMgaW5pdGlhdGVkIGJ5IHRoZSBjbGllbnQgcmVkaXJlY3RpbmcgdGhlIHVzZXLigJlzIGJyb3dz ZXIpLiBUaGUgY2xpZW50IHdpbGwgaW52b2x2ZSB0aGUgYXV0aG9yaXppbmcgcGFydHkgYXMgbmVj ZXNzYXJ5IHRocm91Z2ggaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmRpY2F0ZWQgYnkgdGhlIHBy b3RvY29sLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+QWRkaXRpb25hbGx5LCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwg YWxsb3cgZm9yOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+LSBGaW5lLWdyYWluZWQgc3BlY2lmaWNhdGlvbiBvZiByZXNvdXJjZSBhY2Nl c3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ LSBBcHByb3ZhbCBvZiBpZGVudGl0eSBjbGFpbXMgYW5kIG11bHRpcGxlIHJlc291cmNlcyBpbiBh IHNpbmdsZSBpbnRlcmFjdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4tIERlbGVnYXRpb24gYmV0d2VlbiBtdWx0aXBsZSB1c2VyczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIFdlYiwg bW9iaWxlLCBzaW5nbGUtcGFnZSwgYW5kIG90aGVyIHR5cGVzIG9mIGNsaWVudCBhcHBsaWNhdGlv bnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlRoZSBncm91cCB3aWxsIGRlZmluZSBleHRlbnNpb24gcG9pbnRzIGZvciB0aGlzIHByb3Rv Y29sIHRvIGFsbG93IGZvciBmbGV4aWJpbGl0eSBpbiBhcmVhcyBpbmNsdWRpbmc6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIENyeXB0 b2dyYXBoaWMgYWdpbGl0eSBmb3Iga2V5cywgbWVzc2FnZSBzaWduYXR1cmVzLCBhbmQgcHJvb2Yg b2YgcG9zc2Vzc2lvbiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4tIFVzZXIgaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcg d2ViIGFuZCBub24td2ViIG1ldGhvZHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+LSBNZWNoYW5pc21zIGZvciBwcm92aWRpbmcgdXNlciwgc29m dHdhcmUsIG9yZ2FuaXphdGlvbiwgYW5kIG90aGVyIHBpZWNlcyBvZiBpbmZvcm1hdGlvbiB1c2Vk IGluIGF1dGhvcml6YXRpb24gZGVjaXNpb25zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gVG9rZW4gcHJlc2VudGF0aW9uIG1lY2hhbmlzbXMg YW5kIGtleSBiaW5kaW5nczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+QWRkaXRpb25hbGx5LCB0aGUgZ3JvdXAgd2lsbCBwcm92aWRlIG1l Y2hhbmlzbXMgZm9yIG1hbmFnZW1lbnQgb2YgdGhlIHByb3RvY29sIGxpZmVjeWNsZSBpbmNsdWRp bmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4tIERpc2NvdmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXI8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBSZXZvY2F0aW9uIG9m IGFjdGl2ZSB0b2tlbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+LSBRdWVyeSBvZiB0b2tlbiByaWdodHMgYnkgcmVzb3VyY2Ugc2VydmVyczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ QWx0aG91Z2ggdGhlIGFydGlmYWN0cyBmb3IgdGhpcyB3b3JrIGFyZSBub3QgaW50ZW5kZWQgb3Ig ZXhwZWN0ZWQgdG8gYmUgYmFja3dhcmRzLWNvbXBhdGlibGUgd2l0aCBPQXV0aCAyLjAgb3IgT3Bl bklEIENvbm5lY3QsIHRoZSBncm91cCB3aWxsJm5ic3A7YXR0ZW1wdCB0byBzaW1wbGlmeSBwb3J0 aW5nIGZyb20gT0F1dGgNCiAyLjAgYW5kIE9wZW5JRCBDb25uZWN0IHRvIHRoZSBuZXcgcHJvdG9j b2wgd2hlcmUgcG9zc2libGUuPGJyPg0KPGJyPg0KV2hpbGUgdGhlIGluaXRpYWwgd29yayB3aWxs IGZvY3VzIG9uIHVzaW5nIEhUVFAgZm9yIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgY2xpZW50 IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgc2Vl ayB0byB0YWtlIGFkdmFudGFnZSBvZiBvcHRpbWl6YXRpb24gZmVhdHVyZXMgb2YgSFRUUDIgYW5k IEhUVFAzLCBhbmQgd2lsbCBzdHJpdmUgdG8mbmJzcDtlbmFibGUgc2ltcGxlIG1hcHBpbmcgdG8g b3RoZXIgcHJvdG9jb2xzDQogc3VjaCBhcyBDT0FQLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIEphbiAxMCwgMjAyMCwgYXQgMTI6MDQgUE0sIERpY2sgSGFyZHQgJmx0OzxhIGhy ZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFy ZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SGV5DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JJ3ZlIHdyaXR0ZW4gYW4gYWx0ZXJuYXRpdmUgY2hhcnRlciB0 aGF0IEkgaG9wZSBjYXB0dXJlcyBzb21lIG9mIHRoZSBmZWVkYmFjayBvbiBKdXN0aW4ncyBjaGFy dGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SSBmb3VuZCBpdCBlYXNpZXIgdG8gcmV3cml0ZSB0aGUgY2hhcnRlciB0byBicm9hZGVu IHRoZSBtYXJrZXRwbGFjZSBvZiBpZGVhcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPktleSBpZGVhczo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gVGhpcyB3b3Jr IHN1cHBvcnRzIGV4aXN0aW5nIE9BdXRoIDIuMCwgYW5kIE9wZW5JRCBDb25uZWN0IHVzZSBjYXNl cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPi0gVGhlIGNsaWVudCBpbnRlcmFjdHMgZGlyZWN0bHkgd2l0aCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4vRGljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0tLTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3Ag YSBkZWxlZ2F0ZWQgaWRlbnRpdHkgYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2wuLiBUaGUgdXNl IGNhc2VzIHN1cHBvcnRlZCBieSB0aGlzIHByb3RvY29sIHdpbGwgaW5jbHVkZSB3aWRlbHkgZGVw bG95ZWQgdXNlIGNhc2VzIGN1cnJlbnRseSBzdXBwb3J0ZWQNCiBieSBPQXV0aCAyLjAsIGFuZCBP cGVuSUQgQ29ubmVjdC4gSW4gY29udHJhc3QgdG8gT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVj dCwgd2hlcmUgdGhlIHByb3RvY29sIGlzIGluaXRpYXRlZCBieSByZWRpcmVjdGluZyB0aGUgdXNl cidzIGJyb3dzZXIgdG8gYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRoaXMgcHJvdG9jb2wgd2ls bCBiZSBpbml0aWF0ZWQgYnkgdGhlIGNsaWVudCBkaXJlY3RseSBpbnRlcmFjdGluZyB3aXRoIHRo ZSBhdXRob3JpemF0aW9uDQogc2VydmVyLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KQWRkaXRpb25hbGx5LCB0aGUgcHJvdG9jb2wg d2lsbCBhbGxvdzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+LSBmaW5lLWdyYWluZWQgc3BlY2lmaWNhdGlvbiBvZiByZXNvdXJjZSBhY2Nlc3M8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSB0 aGUgdXNlciB0byBhcHByb3ZlIHJlcXVlc3RzIGZvciBpZGVudGl0eSBjbGFpbXMgYW5kIGFjY2Vz cyB0byBtdWx0aXBsZSByZXNvdXJjZXMgaW4gb25lIGludGVyYWN0aW9uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gd2ViLCBtb2JpbGUsIHNp bmdsZS1wYWdlLCBhbmQgb3RoZXIgY2xpZW50IGFwcGxpY2F0aW9uczxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIHRha2luZyBhZHZhbnRhZ2Ug b2Ygb3B0aW1pemF0aW9uIGZlYXR1cmVzIGluIEhUVFAyIGFuZCBIVFRQMzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpUaGUgZ3JvdXAg d2lsbCBkZWZpbmUgZXh0ZW5zaW9uIHBvaW50cyBmb3IgdGhpcyBwcm90b2NvbCB0byBhbGxvdyBm b3IgZmxleGliaWxpdHkgaW4gYXJlYXMgaW5jbHVkaW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQotIGRpc2NvdmVyeSBvZiB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+LSBjcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3Nh Z2Ugc2lnbmF0dXJlcywgYW5kIHByb29mIG9mIHBvc3Nlc3Npb24mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSB1c2VyIGludGVyYWN0 aW9uIG1lY2hhbmlzbXMgaW5jbHVkaW5nIHdlYiBhbmQgbm9uLXdlYiBtZXRob2RzLSB0b2tlbiBw cmVzZW50YXRpb24gbWVjaGFuaXNtcyBhbmQga2V5IGJpbmRpbmdzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCkFsdGhvdWdoIHRoZSBh cnRpZmFjdHMgZm9yIHRoaXMgd29yayBhcmUgbm90IGludGVuZGVkIG9yIGV4cGVjdGVkIHRvIGJl IGJhY2t3YXJkcy1jb21wYXRpYmxlIHdpdGggT0F1dGggMi4wIG9yIE9wZW5JRCBDb25uZWN0LCB0 aGV5IHdpbGwgYXR0ZW1wdCB0byBzaW1wbGlmeSBwb3J0aW5nIGZyb20gT0F1dGggMi4wIGFuZCBP cGVuSUQgQ29ubmVjdCwgYW5kIHN0cml2ZSB0byByZXVzZSBleGlzdGluZyBzZW1hbnRpY3Mgc3Vj aCBhcyBjbGllbnQgaWRlbnRpZmllcnMsDQogT0F1dGggMi4wIHNjb3BlcyBhbmQgYWNjZXNzIHRv a2VucywgYW5kIE9wZW5JRCBDb25uZWN0IElEIFRva2VucyBhbmQgY2xhaW1zLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpXaGlsZSB0 aGUgaW5pdGlhbCB3b3JrIHdpbGwgZm9jdXMgb24gdXNpbmcgSFRUUCBmb3IgY29tbXVuaWNhdGlv biBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlIHdv cmtpbmcgZ3JvdXAgd2lsbCBzdHJpdmUgdG8gZW5hYmxlIHNpbXBsZSBtYXBwaW5nIHRvIG90aGVy IHByb3RvY29scyBzdWNoIGFzIENPQVAuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpbWcgYm9yZGVy PSIwIiBpZD0iZ21haWwtbV8tNDI4Mjk1MjQ5Nzg2MzA3MTkzNF94MDA1Zl94MDAwMF9pMTAyNSIg c3JjPSJodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhK a2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD00MTAwZjEx Yy0xNWNhLTRkNDUtYmJkMi1jMDI5OTY1ODIxZmIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7RXVwaGVtaWEgVUNBUyZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndoaXRlIj7hkKc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+LS0NCjxicj4NClR4YXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86VHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VHhhdXRoQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRo IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 eGF1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A6D90193D3FC4BDB8F4C55A30ED252EEamazoncom_-- From nobody Mon Jan 13 18:24: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 107D612006F for ; Mon, 13 Jan 2020 18:24:17 -0800 (PST) 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 E-FgydSAqh8d for ; Mon, 13 Jan 2020 18:24:14 -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 34C2B12006B for ; Mon, 13 Jan 2020 18:24:14 -0800 (PST) Received: from [192.168.1.16] (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 00E2OAmR031876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jan 2020 21:24:11 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C5E6E472-C1EC-4726-81FE-F7BA80925015" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 13 Jan 2020 21:24:10 -0500 In-Reply-To: Cc: Dick Hardt , "txauth@ietf.org" To: "Richard Backman, Annabelle" References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 14 Jan 2020 02:24:17 -0000 --Apple-Mail=_C5E6E472-C1EC-4726-81FE-F7BA80925015 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I can get behind this kind of addition. I like Annabelle=E2=80=99s = framing of it in terms of decoupling, and some explanation of why = we=E2=80=99re doing it in relation to OAuth 2=E2=80=99s approach. One of = the key things, to me, is that we=E2=80=99re making a break from OAuth = 2=E2=80=99s core architecture but doing so for very specific reasons.=20 =E2=80=94 Justin > On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle = wrote: >=20 > It=E2=80=99s not just about the initial communication, though. I the = key thing to emphasize is the decoupling the protocol from delegation = channels, which addresses the aforementioned security/complexity issues = and also provides a path to support future delegation channel types = without significant changes to the protocol (unlike OAuth 2.0, where = extensions like Device Flow and PAR introduce substantial changes to the = core protocol flow on both client and AS). Since the protocol isn=E2=80=99= t assuming a particular front channel, it=E2=80=99s easier to add = support for a new one. > =20 > Proposal, altered from Dick=E2=80=99s suggestion: > This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. This protocol will be = decoupled from delegation channels such as an end user=E2=80=99s web = browser and operate primarily through a channel between the client and = the authorization server, avoiding many of the security concerns and = technical challenges of OAuth 2.0 and providing a non-invasive path for = adding support for future types of clients and delegation channels. > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: Dick Hardt > Date: Monday, January 13, 2020 at 4:35 PM > To: "Richard Backman, Annabelle" > Cc: Justin Richer , "txauth@ietf.org" = > Subject: Re: [Txauth] alternative charter writeup > =20 > I agree, some more "why" would help a broader audience understand the = motivations. How about this change to the first paragraph? > =20 > This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. In contrast to OAuth 2.0, = where the protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server, which will mitigate = many of the security concerns and technical challenges of OAuth 2.0. > =20 > =20 > On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle = > wrote: >> While I agree with the goals stated in this charter, if I read this = from the perspective of someone who hasn=E2=80=99t been our meetings or = listened to Justin=E2=80=99s presentations, I=E2=80=99m hard pressed to = see what the point of this group is, relative to the OAuth WG. I=E2=80=99d= expect this charter to provide at least a cursory explanation of what = problem it is trying to solve. In this case, the problem should be = partially defined in relation to OAuth. What will this WG do that the = OAuth WG hasn=E2=80=99t already done or isn=E2=80=99t already doing? >> =20 >> How about adding something like the following to paragraph 2: >> =20 >> The protocol will mitigate many of the security concerns and = technical challenges of OAuth 2.0 by communicating over secure channels = between the client and the authorization server, and minimizing the = amount of information transmitted over untrusted channels. >> =20 >> =E2=80=93=20 >> Annabelle Richard Backman >> AWS Identity >> =20 >> =20 >> From: Txauth > on behalf of Dick Hardt = > >> Date: Friday, January 10, 2020 at 6:57 PM >> To: Justin Richer > >> Cc: "txauth@ietf.org " > >> Subject: Re: [Txauth] alternative charter writeup >> =20 >> This looks even better! Thanks Justin. >> =20 >> What do others think of the proposed charter now?=20 >> =E1=90=A7 >> =20 >> On Fri, Jan 10, 2020 at 12:43 PM Justin Richer > wrote: >>> Thanks, Dick. I=E2=80=99ve been working on an updated charter based = on everyone=E2=80=99s feedback, and I was aiming to have out today = anyway, so this timing is helpful. So here=E2=80=99s my take on a new = charter, incorporating some of your points below:=20 >>> =20 >>>> This group is chartered to develop a delegation protocol for = identity, authorization, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0 and = OpenID Connect.=20 >>>> =20 >>>> The delegation process will be acted upon by multiple parties in = the protocol, each performing a specific role. The protocol will be = initiated by the client interacting directly with the authorization = server (in contrast with OAuth 2 which is initiated by the client = redirecting the user=E2=80=99s browser). The client will involve the = authorizing party as necessary through interaction mechanisms indicated = by the protocol.=20 >>>> =20 >>>> Additionally, the delegation process will allow for: >>>> =20 >>>> - Fine-grained specification of resource access >>>> - Approval of identity claims and multiple resources in a single = interaction >>>> - Delegation between multiple users >>>> - Web, mobile, single-page, and other types of client 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 providing user, software, organization, and other = pieces of information used in authorization decisions >>>> - Token presentation mechanisms and key bindings >>>> =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 porting from OAuth 2.0 and OpenID Connect to = the new protocol where possible. >>>>=20 >>>> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3, and = will strive to enable simple mapping to other protocols such as COAP. >>>> =20 >>>> On Jan 10, 2020, at 12:04 PM, Dick Hardt > wrote: >>>> =20 >>>> Hey >>>> =20 >>>> I've written an alternative charter that I hope captures some of = the feedback on Justin's charter. >>>> =20 >>>> I found it easier to rewrite the charter to broaden the marketplace = of ideas.=20 >>>> =20 >>>> Key ideas: >>>> =20 >>>> - This work supports existing OAuth 2.0, and OpenID Connect use = cases. >>>> =20 >>>> - The client interacts directly with the authorization server.=20 >>>> =20 >>>> /Dick >>>> =20 >>>> ---- >>>> =20 >>>> This group is chartered to develop a delegated identity and = authorization protocol.. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the = protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server.. >>>>=20 >>>> Additionally, the protocol will allow: >>>> - fine-grained specification of resource access >>>> - the user to approve requests for identity claims and access to = multiple resources in one interaction >>>> - web, mobile, single-page, and other client applications >>>> - taking advantage of optimization features in HTTP2 and HTTP3 >>>>=20 >>>> The group will define extension points for this protocol to allow = for flexibility in areas including: >>>>=20 >>>> - discovery of the authorization server >>>> - cryptographic agility for keys, message signatures, and proof of = possession=20 >>>> - user interaction mechanisms including web and non-web methods- = token presentation mechanisms and key bindings >>>>=20 >>>> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, they will = attempt to simplify porting from OAuth 2.0 and OpenID Connect, and = strive to reuse existing semantics such as client identifiers, OAuth 2.0 = scopes and access tokens, and OpenID Connect ID Tokens and claims. >>>>=20 >>>> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = strive to enable simple mapping to other protocols such as COAP. >>>> =20 >>>> =20 >>>> =E1=90=A7 >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_C5E6E472-C1EC-4726-81FE-F7BA80925015 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = can get behind this kind of addition. I like Annabelle=E2=80=99s framing = of it in terms of decoupling, and some explanation of why we=E2=80=99re = doing it in relation to OAuth 2=E2=80=99s approach. One of the key = things, to me, is that we=E2=80=99re making a break from OAuth 2=E2=80=99s= core architecture but doing so for very specific reasons. 

 =E2=80=94 = Justin

On Jan 13, 2020, at 8:54 PM, Richard Backman, = Annabelle <richanna@amazon.com> wrote:

It=E2=80=99= s not just about the initial communication, though. I the key thing to = emphasize is the decoupling the protocol from delegation channels, which = addresses the aforementioned security/complexity issues and also = provides a path to support future delegation channel types without = significant changes to the protocol (unlike OAuth 2.0, where extensions = like Device Flow and PAR introduce substantial changes to the core = protocol flow on both client and AS). Since the protocol isn=E2=80=99t = assuming a particular front channel, it=E2=80=99s easier to add support = for a new one.
 
Proposal, altered from Dick=E2=80=99s suggestion:
This = group is chartered to develop a delegated identity and authorization = protocol. The use cases supported by this protocol will include widely = deployed use cases currently supported by OAuth 2.0, and OpenID Connect, = an extension of OAuth 2.0. This protocol will be decoupled from = delegation channels such as an end user=E2=80=99s web browser and = operate primarily through a channel between the client and the = authorization server, avoiding many of the security concerns and = technical challenges of OAuth 2.0 and providing a non-invasive path for = adding support for future types of clients and delegation channels.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: Dick Hardt <dick.hardt@gmail.com>
Date: Monday, January 13, = 2020 at 4:35 PM
To: "Richard Backman, = Annabelle" <richanna@amazon.com>
Cc: Justin Richer <jricher@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] = alternative charter writeup
 
I agree, some more "why" would help a = broader audience understand the motivations. How about this change to = the first paragraph?
 
This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. In contrast to OAuth 2.0, = where the protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server, which will mitigate = many of the security concerns and technical challenges of OAuth 2.0.
 
 
On Mon, = Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle <richanna@amazon.com> = wrote:
While I agree with the = goals stated in this charter, if I read this from the perspective of = someone who hasn=E2=80=99t been our meetings or listened to Justin=E2=80=99= s presentations, I=E2=80=99m hard pressed to see what the point of this = group is, relative to the OAuth WG. I=E2=80=99d expect this charter to = provide at least a cursory explanation of what problem it is trying to = solve. In this case, the problem should be partially defined in relation = to OAuth. What will this WG do that the OAuth WG hasn=E2=80=99t already = done or isn=E2=80=99t already doing?
 
How about adding something like the = following to paragraph 2:
 
The protocol will mitigate many of the security concerns and = technical challenges of OAuth 2.0 by communicating over secure channels = between the client and the authorization server, and minimizing the = amount of information transmitted over untrusted channels.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.com>
Date: Friday, January 10, = 2020 at 6:57 PM
To: Justin Richer <jricher@mit.edu>Cc: "txauth@ietf.org" = <txauth@ietf.org>Subject: Re: [Txauth] = alternative charter writeup
 
This looks even better! Thanks Justin.
 
What do others think of the proposed = charter now? 
=E1=90=A7
 
On Fri, = Jan 10, 2020 at 12:43 PM Justin Richer <jricher@mit.edu> = wrote:
Thanks, Dick. I=E2=80=99ve been working on an updated charter = based on everyone=E2=80=99s feedback, and I was aiming to have out today = anyway, so this timing is helpful. So here=E2=80=99s my take on a new = charter, incorporating some of your points below: 
 
This group is chartered to = develop a delegation protocol for identity, authorization, and API = access. This protocol will allow an authorizing party to delegate access = to client software through an authorization server. The use cases = supported by this protocol will include widely deployed use cases = currently supported by OAuth 2.0 and OpenID Connect. 
 
The delegation process will be acted = upon by multiple parties in the protocol, each performing a specific = role. The protocol will be initiated by the client interacting directly = with the authorization server (in contrast with OAuth 2 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client will involve the authorizing party as necessary through = interaction mechanisms indicated by the protocol. 
 
Additionally, the delegation process = will allow for:
 
- Fine-grained specification of resource access
- Approval of identity claims and multiple resources in a = single interaction
- Delegation between multiple users
- Web, mobile, single-page, and other types of client = 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 providing user, = software, organization, and other pieces of information used in = authorization decisions
- Token presentation = mechanisms and key bindings
 
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 porting from = OAuth 2.0 and OpenID Connect to the new protocol where possible.

While the initial work will focus on using = HTTP for communication between the client and the authorization server, = the working group will seek to take advantage of optimization features = of HTTP2 and HTTP3, and will strive to enable simple mapping to = other protocols such as COAP.
 
On Jan 10, 2020, at 12:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
 
Hey
 
I've written an alternative charter that I hope captures some = of the feedback on Justin's charter.
 
I found it easier to rewrite the charter to broaden the = marketplace of ideas. 
 
Key ideas:
 
- This work supports existing OAuth 2.0, and OpenID Connect = use cases.
 
- The client interacts directly with the authorization = server. 
 
/Dick
 
----
 
This group is chartered to develop a delegated identity and = authorization protocol.. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the = protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server..

Additionally, the protocol will allow:
- fine-grained specification of resource access
- the user to approve requests for identity claims and access = to multiple resources in one interaction
- web, mobile, single-page, and other client applications
- taking advantage of optimization features in HTTP2 and = HTTP3

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

- discovery of the = authorization server
- cryptographic agility for keys, = message signatures, and proof of possession 
- user interaction mechanisms including web and non-web = methods- token presentation mechanisms and key bindings

Although the artifacts for this work are not = intended or expected to be backwards-compatible with OAuth 2.0 or OpenID = Connect, they will attempt to simplify porting from OAuth 2.0 and OpenID = Connect, and strive to reuse existing semantics such as client = identifiers, OAuth 2.0 scopes and access tokens, and OpenID Connect ID = Tokens and claims.

While the initial work = will focus on using HTTP for communication between the client and the = authorization server, the working group will strive to enable simple = mapping to other protocols such as COAP.
 
 
=E1=90=A7
-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_C5E6E472-C1EC-4726-81FE-F7BA80925015-- From nobody Mon Jan 13 21: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 9FE8812001E for ; Mon, 13 Jan 2020 21:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 ZAd5t0f26L8J for ; Mon, 13 Jan 2020 21:12:15 -0800 (PST) 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 37DE8120019 for ; Mon, 13 Jan 2020 21:12:15 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id u71so12735550lje.11 for ; Mon, 13 Jan 2020 21:12:15 -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=v27LKMQVdZKsrqbffCKz4yydqPin74pdpClZJlCwe6o=; b=KKNrF1RrMBmQxAdKvJP5Dk7NF3IbUctjN59ypmiOHzesDuXSnjh2cWFBGhpGTFeROT w2Jc09qiAkdt8fi37jO6BCp+m0qG6WTO4PXgnWaUDHLk5FMb9BP8jZo1mCfBwE8Ae79l DMH2MZe97jRTOEaOUIyxLrUzDZAfN6ZPbeZUJrOQPZ4f2qNObyaAOk5CWCZI7y+6k6tm dc1yOLOLLB7hA1FxvcjB8Psc3G4COv/87o0xm3+ptqmt/il+/qcQyzU6W1wpIaZ2OhuR 3vp8qv649gg5O6E5kEi16ewYsi8x6vzuWdq7cq8gaPlWopea0dmDZic0RpGsAmgz65hd lahw== 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=v27LKMQVdZKsrqbffCKz4yydqPin74pdpClZJlCwe6o=; b=hbjZfy0cJtlWvniSC1ouDNsyW0XQFO20A0hTXnMOahn2yapOv9seKJqDGqac8u3UOt /oo/NdzOZeWR1UNCqt7JQRGVupRe76kQ4cB9sySUuICK58SvSAuSOUU09NlBGXnaNYWL 7sh75S1LhieiX2ioZGG2AA8pxmGEEoGidUm5yFq9suBjTXCWGBooajz7KfDscVeXjfXL 65fN4HPboy06l/VBk+jeqF4VZCe50wT6VI98c3VbEWaSBRd/oxrMFWVuTRXwwQt26l6r uXamO6+Y5KhUOAZr+IeFuF+96xw4yzwrxqQ3R4HHY1rbMsgr93krSsG3K7nXM2qaiTHp Z+ag== X-Gm-Message-State: APjAAAVcEJvQdgESQP388tCfiyNwHfTB+wU5z6XrypdssI8khRg74jHU W6Dz43OTjgo/3HxWsARQPLoCLm9x+XkK4GFlDVU= X-Google-Smtp-Source: APXvYqw2RChq0EbC6qCJztrND4z9ko0L+W+7U3ZP1qQBliq8juL+PpLuT8cqCv2mVr2ol6CjOgz9C19OuVrxiyGFLYI= X-Received: by 2002:a2e:9ad8:: with SMTP id p24mr13635521ljj.148.1578978733384; Mon, 13 Jan 2020 21:12:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Mon, 13 Jan 2020 21:12:02 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000082e838059c12a26f" Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 14 Jan 2020 05:12:18 -0000 --00000000000082e838059c12a26f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sounds good to me. On Mon, Jan 13, 2020 at 6:24 PM Justin Richer wrote: > I can get behind this kind of addition. I like Annabelle=E2=80=99s framin= g of it > in terms of decoupling, and some explanation of why we=E2=80=99re doing i= t in > relation to OAuth 2=E2=80=99s approach. One of the key things, to me, is = that we=E2=80=99re > making a break from OAuth 2=E2=80=99s core architecture but doing so for = very > specific reasons. > > =E2=80=94 Justin > > On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > It=E2=80=99s not just about the initial communication, though. I the key = thing to > emphasize is the decoupling the protocol from delegation channels, which > addresses the aforementioned security/complexity issues and also provides= a > path to support future delegation channel types without significant chang= es > to the protocol (unlike OAuth 2.0, where extensions like Device Flow and > PAR introduce substantial changes to the core protocol flow on both clien= t > and AS). Since the protocol isn=E2=80=99t assuming a particular front cha= nnel, it=E2=80=99s > easier to add support for a new one. > > Proposal, altered from Dick=E2=80=99s suggestion: > This group is chartered to develop a delegated identity and authorization > protocol. The use cases supported by this protocol will include widely > deployed use cases currently supported by OAuth 2.0, and OpenID Connect, = an > extension of OAuth 2.0. This protocol will be decoupled from delegation > channels such as an end user=E2=80=99s web browser and operate primarily = through a > channel between the client and the authorization server, avoiding many of > the security concerns and technical challenges of OAuth 2.0 and providing= a > non-invasive path for adding support for future types of clients and > delegation channels. > > =E2=80=93 > Annabelle Richard Backman > AWS Identity > > > *From: *Dick Hardt > *Date: *Monday, January 13, 2020 at 4:35 PM > *To: *"Richard Backman, Annabelle" > *Cc: *Justin Richer , "txauth@ietf.org" > *Subject: *Re: [Txauth] alternative charter writeup > > I agree, some more "why" would help a broader audience understand the > motivations. How about this change to the first paragraph? > > This group is chartered to develop a delegated identity and authorization > protocol. The use cases supported by this protocol will include widely > deployed use cases currently supported by OAuth 2.0, and OpenID Connect, = an > extension of OAuth 2.0. In contrast to OAuth 2.0, where the protocol is > initiated by redirecting the user's browser to an authorization server, > this protocol will be initiated by the client directly interacting with t= he > authorization server, which will mitigate many of the security concerns a= nd > technical challenges of OAuth 2.0. > > > On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > While I agree with the goals stated in this charter, if I read this from > the perspective of someone who hasn=E2=80=99t been our meetings or listen= ed to > Justin=E2=80=99s presentations, I=E2=80=99m hard pressed to see what the = point of this > group is, relative to the OAuth WG. I=E2=80=99d expect this charter to pr= ovide at > least a cursory explanation of what problem it is trying to solve. In thi= s > case, the problem should be partially defined in relation to OAuth. What > will this WG do that the OAuth WG hasn=E2=80=99t already done or isn=E2= =80=99t already > doing? > > How about adding something like the following to paragraph 2: > > The protocol will mitigate many of the security concerns and technical > challenges of OAuth 2.0 by communicating over secure channels between the > client and the authorization server, and minimizing the amount of > information transmitted over untrusted channels. > > =E2=80=93 > Annabelle Richard Backman > AWS Identity > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Friday, January 10, 2020 at 6:57 PM > *To: *Justin Richer > *Cc: *"txauth@ietf.org" > *Subject: *Re: [Txauth] alternative charter writeup > > This looks even better! Thanks Justin. > > What do others think of the proposed charter now? > =E1=90=A7 > > On Fri, Jan 10, 2020 at 12:43 PM Justin Richer wrote: > > Thanks, Dick. I=E2=80=99ve been working on an updated charter based on ev= eryone=E2=80=99s > feedback, and I was aiming to have out today anyway, so this timing is > helpful. So here=E2=80=99s my take on a new charter, incorporating some o= f your > points below: > > > This group is chartered to develop a delegation protocol for identity, > authorization, and API access. This protocol will allow an authorizing > party to delegate access to client software through an authorization > server. The use cases supported by this protocol will include widely > deployed use cases currently supported by OAuth 2.0 and OpenID Connect. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will be initiated > by the client interacting directly with the authorization server (in > contrast with OAuth 2 which is initiated by the client redirecting the > user=E2=80=99s browser). The client will involve the authorizing party as= necessary > through interaction mechanisms indicated by the protocol. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of resource access > - Approval of identity claims and multiple resources in a single > interaction > - Delegation between multiple users > - Web, mobile, single-page, and other types of client 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 providing user, software, organization, and other pieces > of information used in authorization decisions > - Token presentation mechanisms and key bindings > > 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 porting from OAuth 2.0 and OpenID Connect to the > new protocol where possible. > > While the initial work will focus on using HTTP for communication between > the client and the authorization server, the working group will seek to > take advantage of optimization features of HTTP2 and HTTP3, and will stri= ve > to enable simple mapping to other protocols such as COAP. > > > On Jan 10, 2020, at 12:04 PM, Dick Hardt wrote: > > Hey > > I've written an alternative charter that I hope captures some of the > feedback on Justin's charter. > > I found it easier to rewrite the charter to broaden the marketplace of > ideas. > > Key ideas: > > - This work supports existing OAuth 2.0, and OpenID Connect use cases. > > - The client interacts directly with the authorization server. > > /Dick > > ---- > > This group is chartered to develop a delegated identity and authorization > protocol.. The use cases supported by this protocol will include widely > deployed use cases currently supported by OAuth 2.0, and OpenID Connect. = In > contrast to OAuth 2.0 and OpenID Connect, where the protocol is initiated > by redirecting the user's browser to an authorization server, this protoc= ol > will be initiated by the client directly interacting with the authorizati= on > server.. > > Additionally, the protocol will allow: > - fine-grained specification of resource access > - the user to approve requests for identity claims and access to multiple > resources in one interaction > - web, mobile, single-page, and other client applications > - taking advantage of optimization features in HTTP2 and HTTP3 > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - discovery of the authorization server > - cryptographic agility for keys, message signatures, and proof of > possession > - user interaction mechanisms including web and non-web methods- token > presentation mechanisms and key bindings > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt = to > simplify porting from OAuth 2.0 and OpenID Connect, and strive to reuse > existing semantics such as client identifiers, OAuth 2.0 scopes and acces= s > tokens, and OpenID Connect ID Tokens and claims. > > While the initial work will focus on using HTTP for communication between > the client and the authorization server, the working group will strive to > enable simple mapping to other protocols such as COAP. > > > =E1=90=A7 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --00000000000082e838059c12a26f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sounds good to me.

On Mon, Jan 13, 2020 at 6:24 PM Justin Richer= <jricher@mit.edu> wrote:
<= /div>
I can get behind this kind of addition. I like An= nabelle=E2=80=99s framing of it in terms of decoupling, and some explanatio= n of why we=E2=80=99re doing it in relation to OAuth 2=E2=80=99s approach. = One of the key things, to me, is that we=E2=80=99re making a break from OAu= th 2=E2=80=99s core architecture but doing so for very specific reasons.=C2= =A0
<= div>
=C2=A0=E2=80=94 Justin

On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle <richanna@amazon.com= > wrote:

It=E2=80=99s not j= ust about the initial communication, though. I the key thing to emphasize i= s the decoupling the protocol from delegation channels, which addresses the= aforementioned security/complexity issues and also provides a path to supp= ort future delegation channel types without significant changes to the prot= ocol (unlike OAuth 2.0, where extensions like Device Flow and PAR introduce= substantial changes to the core protocol flow on both client and AS). Sinc= e the protocol isn=E2=80=99t assuming a particular front channel, it=E2=80= =99s easier to add support for a new one.
<= /u>=C2=A0
Proposal, altered from Dick=E2=80=99s sugge= stion:
This group is chartered to develo= p a delegated identity and authorization protocol. The use cases supported = by this protocol will include widely deployed use cases currently supported= by OAuth 2.0, and OpenID Connect, an extension of OAuth 2.0. This protocol= will be decoupled from delegation channels such as an end user=E2=80=99s w= eb browser and operate primarily through a channel between the client and t= he authorization server, avoiding many of the security concerns and technic= al challenges of OAuth 2.0 and providing a non-invasive path for adding sup= port for future types of clients and delegation channels.
=C2=A0
=E2=80=93=C2=A0
Annabelle Richard Backman
=
AWS Identity<= /div>
=C2=A0
=C2=A0
From:=C2=A0Dick Hardt <dick.hardt@gmail.com>
Date:=C2=A0= Monday, January 13, 2020 at 4:35 PM
To:=C2=A0"R= ichard Backman, Annabelle" <richanna@amazon.com>
Cc:=C2=A0<= /b>Justin Richer <j= richer@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
Subject:=C2=A0Re: [Txauth] alternative charter writeup
=
=C2=A0
I agree,= some more "why" would help a broader audience understand the mot= ivations. How about this change to the first paragraph?
=
=C2=A0
This gr= oup is chartered to develop a delegated identity and authorization protocol= . The use cases supported by this protocol will include widely deployed use= cases currently supported by OAuth 2.0, and OpenID Connect, an extension o= f OAuth 2.0. In contrast to OAuth 2.0, where the protocol is initiated by r= edirecting the user's browser to an authorization server, this protocol= will be initiated by the client directly interacting with the authorizatio= n server, which will mitigate many of the security concerns and technical c= hallenges of OAuth 2.0.
=C2= =A0
=C2=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:
While = I agree with the goals stated in this charter, if I read this from the pers= pective of someone who hasn=E2=80=99t been our meetings or listened to Just= in=E2=80=99s presentations, I=E2=80=99m hard pressed to see what the point = of this group is, relative to the OAuth WG. I=E2=80=99d expect this charter= to provide at least a cursory explanation of what problem it is trying to = solve. In this case, the problem should be partially defined in relation to= OAuth. What will this WG do that the OAuth WG hasn=E2=80=99t already done = or isn=E2=80=99t already doing?
=C2=A0<= u>
How about adding something like the following to para= graph 2:
=C2=A0
The protocol will mitigate many of the security concerns and technica= l challenges of OAuth 2.0 by communicating over secure channels between the= client and the authorization server, and minimizing the amount of informat= ion transmitted over untrusted channels.
=C2= =A0
=E2=80= =93=C2=A0
Annabelle Richard Backman
AWS Identity
= =C2=A0
=C2=A0
= From:=C2=A0Txauth &l= t;txauth-bounces@ietf.org> on beh= alf of Dick Hardt <dick.hardt@gmail.com<= /a>>
Date:=C2=A0Friday, January 10, 2020 at 6:57 = PM
To:=C2=A0Justin Richer <jricher@mit.edu>
Cc:=C2=A0"txauth@ietf.org" <txauth@ietf.org>
Subject:=C2=A0Re: [Txauth]= alternative charter writeup
=C2=A0
This looks even better! Tha= nks Justin.
=C2=A0
What do others think of the proposed charter now?=C2=A0
=E1=90=A7
=C2=A0=
On Fri, Jan 10, 2020 at 12:43 PM Justin Ri= cher <jricher@mit.edu> wrote:
Thanks, Dick. I= =E2=80=99ve been working on an updated charter based on everyone=E2=80=99s = feedback, and I was aiming to have out today anyway, so this timing is help= ful. So here=E2=80=99s my take on a new charter, incorporating some of your= points below:=C2=A0
=C2=A0<= u>
This group is chartered to develop a delegation pr= otocol for identity, authorization, and API access. This protocol will allo= w an authorizing party to delegate access to client software through an aut= horization server. The use cases supported by this protocol will include wi= dely deployed use cases currently supported by OAuth 2.0 and OpenID Connect= .=C2=A0
=C2=A0
<= /div>
The delegation process will be acted upon by multiple p= arties in the protocol, each performing a specific role. The protocol will = be initiated by the client interacting directly with the authorization serv= er (in contrast with OAuth 2 which is initiated by the client redirecting t= he user=E2=80=99s browser). The client will involve the authorizing party a= s necessary through interaction mechanisms indicated by the protocol.=C2=A0=
=C2=A0
Additionally, the delegation process will allow for:=
=C2=A0
- Fine-grained specification of resource access
- Approval of identity claims and multiple resources in a s= ingle interaction
- Delegation betw= een multiple users
- Web, mobile, s= ingle-page, and other types of client applications
=C2=A0
The group wi= ll define extension points for this protocol to allow for flexibility in ar= eas including:
=C2=A0=
- Cryptographic agility for keys, message signat= ures, and proof of possession=C2=A0
- User interaction mechanisms including web and non-web methods<= /u>
- Mechanisms for providing user, software, or= ganization, and other pieces of information used in authorization decisions=
- Token presentation mechanisms an= d key bindings
=C2=A0=
Additionally, the group will provide mechanisms = for management of the protocol lifecycle including:
=C2=A0
- Discovery= of the authorization server
- Revo= cation of active tokens
- Query of = token rights by resource servers
= =C2=A0
Although the artifacts for t= his work are not intended or expected to be backwards-compatible with OAuth= 2.0 or OpenID Connect, the group will=C2=A0attempt to simplify porting fro= m OAuth 2.0 and OpenID Connect to the new protocol where possible.

W= hile the initial work will focus on using HTTP for communication between th= e client and the authorization server, the working group will seek to take = advantage of optimization features of HTTP2 and HTTP3, and will strive to= =C2=A0enable simple mapping to other protocols such as COAP.<= /div>
=C2=A0
=
On Jan 10, 2020, at 12:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
=C2=A0
Hey
=C2=A0
I'= ve written an alternative charter that I hope captures some of the feedback= on Justin's charter.
=C2=A0=
I found it easier to rewrite the char= ter to broaden the marketplace of ideas.=C2=A0
=C2=A0
Key ideas:
=C2=A0
- This work supports existing OAuth 2.0, and OpenID Connect use case= s.
=C2=A0
=
- The client interacts directly with the authorization serve= r.=C2=A0
=C2=A0
=
/Dick
=C2=A0
----
=C2=A0
This group is chartered t= o develop a delegated identity and authorization protocol.. The use cases s= upported by this protocol will include widely deployed use cases currently = supported by OAuth 2.0, and OpenID Connect. In contrast to OAuth 2.0 and Op= enID Connect, where the protocol is initiated by redirecting the user's= browser to an authorization server, this protocol will be initiated by the= client directly interacting with the authorization server..<= /div>

Additionally, the protocol will allow:=
- fine-grained specification of resource = access
- the user to approve reques= ts for identity claims and access to multiple resources in one interaction<= u>
- web, mobile, single-page, and oth= er client applications
- taking adv= antage of optimization features in HTTP2 and HTTP3

The group will define extension points for this protoco= l to allow for flexibility in areas including:

- discovery of the authorization server
=
- cryptographic agility for keys, message signatures, = and proof of possession=C2=A0
- use= r interaction mechanisms including web and non-web methods- token presentat= ion mechanisms and key bindings
Although the artifacts for this work are not intended or expected to be ba= ckwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt to s= implify porting from OAuth 2.0 and OpenID Connect, and strive to reuse exis= ting semantics such as client identifiers, OAuth 2.0 scopes and access toke= ns, and OpenID Connect ID Tokens and claims.
=

While the initial work will focus on using HTTP for communica= tion between the client and the authorization server, the working group wil= l strive to enable simple mapping to other protocols such as COAP.
=C2=A0
= =C2=A0
=E1=90=A7
--=C2=A0
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--00000000000082e838059c12a26f-- From nobody Thu Jan 16 07:45: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 0EDF4120862 for ; Thu, 16 Jan 2020 07:45:51 -0800 (PST) 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 ZRV7FAIGb0JH for ; Thu, 16 Jan 2020 07:45:45 -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 4B9361208AF for ; Thu, 16 Jan 2020 07:45:34 -0800 (PST) Received: from [192.168.1.16] (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 00GFjASh008836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 10:45:12 -0500 From: Justin Richer Message-Id: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_76A24BD8-D79C-4197-88C2-85B8F7FAE62D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 16 Jan 2020 10:45:10 -0500 In-Reply-To: Cc: "Richard Backman, Annabelle" , Benjamin Kaduk , "rdd@cert.org" , Dick Hardt To: "txauth@ietf.org" References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 15:45:51 -0000 --Apple-Mail=_76A24BD8-D79C-4197-88C2-85B8F7FAE62D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here=E2=80=99s my updated text incorporating the feedback so far: This group is chartered to develop a delegation protocol for identity, = authorization, and API access. This protocol will allow an authorizing = party to delegate access to client software through an authorization = server. The use cases supported by this protocol will include widely = deployed use cases currently supported by OAuth 2.0 and OpenID Connect = (an extension of OAuth 2.0) as well as new use cases not enabled by = OAuth 2.0. 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 which is initiated by = the client redirecting the user=E2=80=99s browser). The client will = involve the authorizing party as necessary through interaction = mechanisms indicated by the protocol. This decoupling avoids many of the = security concerns and technical challenges of OAuth 2.0 as well as = providing a non-invasive path for supporting future types of clients and = interaction channels. Additionally, the delegation process will allow for: - Fine-grained specification of resource access - Approval of identity claims and multiple resources in a single = interaction - Delegation between multiple users - Web, mobile, single-page, interaction-constrained, and other types of = client 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 providing user, software, organization, and other = pieces of information used in authorization decisions - Token presentation mechanisms and key bindings 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 porting from OAuth 2.0 and OpenID Connect to the new = protocol where possible. While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3 where = possible, and will strive to enable simple mapping to other protocols = such as COAP. It=E2=80=99s definitely a lot, but I think we=E2=80=99ve got a good = handle on what we=E2=80=99re working on, and what the boundaries are. I = think this is both too much of an effort and too much of a break to do = this in the OAuth WG, where there=E2=80=99s already still plenty of work = to be done. We=E2=80=99re leaning a lot on lessons learned from the = OAuth 2 world and its extensions, including OIDC and UMA2. We=E2=80=99ve = got the attention of a lot of the right people to start this as well. So to the AD=E2=80=99s: Ben and Roman =E2=80=94 what=E2=80=99s the next = step? This should be a new working group and like to get it started so = that we can have our first meeting in Vancouver. =E2=80=94 Justin > On Jan 14, 2020, at 12:12 AM, Dick Hardt wrote: >=20 > Sounds good to me. >=20 > On Mon, Jan 13, 2020 at 6:24 PM Justin Richer > wrote: > I can get behind this kind of addition. I like Annabelle=E2=80=99s = framing of it in terms of decoupling, and some explanation of why = we=E2=80=99re doing it in relation to OAuth 2=E2=80=99s approach. One of = the key things, to me, is that we=E2=80=99re making a break from OAuth = 2=E2=80=99s core architecture but doing so for very specific reasons.=20 >=20 > =E2=80=94 Justin >=20 >> On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle = > wrote: >>=20 >> It=E2=80=99s not just about the initial communication, though. I the = key thing to emphasize is the decoupling the protocol from delegation = channels, which addresses the aforementioned security/complexity issues = and also provides a path to support future delegation channel types = without significant changes to the protocol (unlike OAuth 2.0, where = extensions like Device Flow and PAR introduce substantial changes to the = core protocol flow on both client and AS). Since the protocol isn=E2=80=99= t assuming a particular front channel, it=E2=80=99s easier to add = support for a new one. >> =20 >> Proposal, altered from Dick=E2=80=99s suggestion: >> This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. This protocol will be = decoupled from delegation channels such as an end user=E2=80=99s web = browser and operate primarily through a channel between the client and = the authorization server, avoiding many of the security concerns and = technical challenges of OAuth 2.0 and providing a non-invasive path for = adding support for future types of clients and delegation channels. >> =20 >> =E2=80=93=20 >> Annabelle Richard Backman >> AWS Identity >> =20 >> =20 >> From: Dick Hardt > >> Date: Monday, January 13, 2020 at 4:35 PM >> To: "Richard Backman, Annabelle" > >> Cc: Justin Richer >, = "txauth@ietf.org " > >> Subject: Re: [Txauth] alternative charter writeup >> =20 >> I agree, some more "why" would help a broader audience understand the = motivations. How about this change to the first paragraph? >> =20 >> This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. In contrast to OAuth 2.0, = where the protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server, which will mitigate = many of the security concerns and technical challenges of OAuth 2.0. >> =20 >> =20 >> On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle = > wrote: >>> While I agree with the goals stated in this charter, if I read this = from the perspective of someone who hasn=E2=80=99t been our meetings or = listened to Justin=E2=80=99s presentations, I=E2=80=99m hard pressed to = see what the point of this group is, relative to the OAuth WG. I=E2=80=99d= expect this charter to provide at least a cursory explanation of what = problem it is trying to solve. In this case, the problem should be = partially defined in relation to OAuth. What will this WG do that the = OAuth WG hasn=E2=80=99t already done or isn=E2=80=99t already doing? >>> =20 >>> How about adding something like the following to paragraph 2: >>> =20 >>> The protocol will mitigate many of the security concerns and = technical challenges of OAuth 2.0 by communicating over secure channels = between the client and the authorization server, and minimizing the = amount of information transmitted over untrusted channels. >>> =20 >>> =E2=80=93=20 >>> Annabelle Richard Backman >>> AWS Identity >>> =20 >>> =20 >>> From: Txauth > on behalf of Dick Hardt = > >>> Date: Friday, January 10, 2020 at 6:57 PM >>> To: Justin Richer > >>> Cc: "txauth@ietf.org " > >>> Subject: Re: [Txauth] alternative charter writeup >>> =20 >>> This looks even better! Thanks Justin. >>> =20 >>> What do others think of the proposed charter now?=20 >>> =E1=90=A7 >>> =20 >>> On Fri, Jan 10, 2020 at 12:43 PM Justin Richer > wrote: >>>> Thanks, Dick. I=E2=80=99ve been working on an updated charter based = on everyone=E2=80=99s feedback, and I was aiming to have out today = anyway, so this timing is helpful. So here=E2=80=99s my take on a new = charter, incorporating some of your points below:=20 >>>> =20 >>>>> This group is chartered to develop a delegation protocol for = identity, authorization, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0 and = OpenID Connect.=20 >>>>> =20 >>>>> The delegation process will be acted upon by multiple parties in = the protocol, each performing a specific role. The protocol will be = initiated by the client interacting directly with the authorization = server (in contrast with OAuth 2 which is initiated by the client = redirecting the user=E2=80=99s browser). The client will involve the = authorizing party as necessary through interaction mechanisms indicated = by the protocol.=20 >>>>> =20 >>>>> Additionally, the delegation process will allow for: >>>>> =20 >>>>> - Fine-grained specification of resource access >>>>> - Approval of identity claims and multiple resources in a single = interaction >>>>> - Delegation between multiple users >>>>> - Web, mobile, single-page, and other types of client 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 providing user, software, organization, and other = pieces of information used in authorization decisions >>>>> - Token presentation mechanisms and key bindings >>>>> =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 porting from OAuth 2.0 and OpenID Connect to = the new protocol where possible. >>>>>=20 >>>>> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3, and = will strive to enable simple mapping to other protocols such as COAP. >>>>> =20 >>>>> On Jan 10, 2020, at 12:04 PM, Dick Hardt > wrote: >>>>> =20 >>>>> Hey >>>>> =20 >>>>> I've written an alternative charter that I hope captures some of = the feedback on Justin's charter. >>>>> =20 >>>>> I found it easier to rewrite the charter to broaden the = marketplace of ideas.=20 >>>>> =20 >>>>> Key ideas: >>>>> =20 >>>>> - This work supports existing OAuth 2.0, and OpenID Connect use = cases. >>>>> =20 >>>>> - The client interacts directly with the authorization server.=20 >>>>> =20 >>>>> /Dick >>>>> =20 >>>>> ---- >>>>> =20 >>>>> This group is chartered to develop a delegated identity and = authorization protocol.. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the = protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server.. >>>>>=20 >>>>> Additionally, the protocol will allow: >>>>> - fine-grained specification of resource access >>>>> - the user to approve requests for identity claims and access to = multiple resources in one interaction >>>>> - web, mobile, single-page, and other client applications >>>>> - taking advantage of optimization features in HTTP2 and HTTP3 >>>>>=20 >>>>> The group will define extension points for this protocol to allow = for flexibility in areas including: >>>>>=20 >>>>> - discovery of the authorization server >>>>> - cryptographic agility for keys, message signatures, and proof of = possession=20 >>>>> - user interaction mechanisms including web and non-web methods- = token presentation mechanisms and key bindings >>>>>=20 >>>>> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, they will = attempt to simplify porting from OAuth 2.0 and OpenID Connect, and = strive to reuse existing semantics such as client identifiers, OAuth 2.0 = scopes and access tokens, and OpenID Connect ID Tokens and claims. >>>>>=20 >>>>> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = strive to enable simple mapping to other protocols such as COAP. >>>>> =20 >>>>> =20 >>>>> =E1=90=A7 >>>>> --=20 >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_76A24BD8-D79C-4197-88C2-85B8F7FAE62D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Here=E2=80=99s my updated text incorporating the feedback so = far:


This group is = chartered to develop a delegation protocol for identity, authorization, = and API access. This protocol will allow an authorizing party to = delegate access to client software through an authorization server. The = use cases supported by this protocol will include widely deployed use = cases currently supported by OAuth 2.0 and OpenID Connect (an extension = of OAuth 2.0) as well as new use cases not enabled by OAuth = 2.0.

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 which is initiated by the client = redirecting the user=E2=80=99s browser). The client will involve the = authorizing party as necessary through interaction mechanisms indicated = by the protocol. This decoupling avoids many of the security concerns = and technical challenges of OAuth 2.0 as well as providing a = non-invasive path for supporting future types of clients and interaction = channels.

Additionally, the = delegation process will allow for:

- = Fine-grained specification of resource access
- Approval of identity claims and multiple = resources in a single interaction
- Delegation between multiple users
- Web, mobile, single-page, = interaction-constrained, and other types of client = 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 providing user, software, = organization, and other pieces of information used in authorization = decisions
- Token = presentation mechanisms and key bindings

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 porting from OAuth 2.0 and OpenID Connect = to the new protocol where possible.

While the initial work will focus on using HTTP for = communication between the client and the authorization server, the = working group will seek to take advantage of optimization features of = HTTP2 and HTTP3 where possible, and will strive to enable simple = mapping to other protocols such as COAP.


It=E2=80=99s definitely a lot, but I think we=E2=80=99= ve got a good handle on what we=E2=80=99re working on, and what the = boundaries are. I think this is both too much of an effort and too much = of a break to do this in the OAuth WG, where there=E2=80=99s already = still plenty of work to be done. We=E2=80=99re leaning a lot on lessons = learned from the OAuth 2 world and its extensions, including OIDC and = UMA2. We=E2=80=99ve got the attention of a lot of the right people to = start this as well.

So to the = AD=E2=80=99s: Ben and Roman =E2=80=94 what=E2=80=99s the next step? This = should be a new working group and like to get it started so that we can = have our first meeting in Vancouver.

 =E2=80=94 Justin

On Jan = 14, 2020, at 12:12 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

Sounds good to me.

On Mon, Jan 13, 2020 at 6:24 PM Justin Richer = <jricher@mit.edu> = wrote:
I = can get behind this kind of addition. I like Annabelle=E2=80=99s framing = of it in terms of decoupling, and some explanation of why we=E2=80=99re = doing it in relation to OAuth 2=E2=80=99s approach. One of the key = things, to me, is that we=E2=80=99re making a break from OAuth 2=E2=80=99s= core architecture but doing so for very specific = reasons. 

 =E2=80= =94 Justin

On Jan 13, 2020, at 8:54 PM, = Richard Backman, Annabelle <richanna@amazon.com> wrote:

It=E2=80= =99s not just about the initial communication, though. I the key thing = to emphasize is the decoupling the protocol from delegation channels, = which addresses the aforementioned security/complexity issues and also = provides a path to support future delegation channel types without = significant changes to the protocol (unlike OAuth 2.0, where extensions = like Device Flow and PAR introduce substantial changes to the core = protocol flow on both client and AS). Since the protocol isn=E2=80=99t = assuming a particular front channel, it=E2=80=99s easier to add support = for a new one.
 
Proposal, altered from Dick=E2=80=99s suggestion:
This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. This protocol will be = decoupled from delegation channels such as an end user=E2=80=99s web = browser and operate primarily through a channel between the client and = the authorization server, avoiding many of the security concerns and = technical challenges of OAuth 2.0 and providing a non-invasive path for = adding support for future types of clients and delegation channels.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: Dick Hardt <dick.hardt@gmail.com>
Date: Monday, January 13, = 2020 at 4:35 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: Justin Richer <jricher@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] = alternative charter writeup
 
I = agree, some more "why" would help a broader audience understand the = motivations. How about this change to the first paragraph?
 
This = group is chartered to develop a delegated identity and authorization = protocol. The use cases supported by this protocol will include widely = deployed use cases currently supported by OAuth 2.0, and OpenID Connect, = an extension of OAuth 2.0. In contrast to OAuth 2.0, where the protocol = is initiated by redirecting the user's browser to an authorization = server, this protocol will be initiated by the client directly = interacting with the authorization server, which will mitigate many of = the security concerns and technical challenges of OAuth 2.0.
 
 
On = Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:
While = I agree with the goals stated in this charter, if I read this from the = perspective of someone who hasn=E2=80=99t been our meetings or listened = to Justin=E2=80=99s presentations, I=E2=80=99m hard pressed to see what = the point of this group is, relative to the OAuth WG. I=E2=80=99d expect = this charter to provide at least a cursory explanation of what problem = it is trying to solve. In this case, the problem should be partially = defined in relation to OAuth. What will this WG do that the OAuth WG = hasn=E2=80=99t already done or isn=E2=80=99t already doing?
 
How = about adding something like the following to paragraph 2:
 
The = protocol will mitigate many of the security concerns and technical = challenges of OAuth 2.0 by communicating over secure channels between = the client and the authorization server, and minimizing the amount of = information transmitted over untrusted channels.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.com>
Date: Friday, January 10, = 2020 at 6:57 PM
To: Justin Richer <jricher@mit.edu>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] = alternative charter writeup
 
This = looks even better! Thanks Justin.
 
What = do others think of the proposed charter now? 
=E1=90=A7
 
On = Fri, Jan 10, 2020 at 12:43 PM Justin Richer <jricher@mit.edu> wrote:
Thanks,= Dick. I=E2=80=99ve been working on an updated charter based on = everyone=E2=80=99s feedback, and I was aiming to have out today anyway, = so this timing is helpful. So here=E2=80=99s my take on a new charter, = incorporating some of your points below: 
 
This = group is chartered to develop a delegation protocol for identity, = authorization, and API access. This protocol will allow an authorizing = party to delegate access to client software through an authorization = server. The use cases supported by this protocol will include widely = deployed use cases currently supported by OAuth 2.0 and OpenID = Connect. 
 
The = delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will be = initiated by the client interacting directly with the authorization = server (in contrast with OAuth 2 which is initiated by the client = redirecting the user=E2=80=99s browser). The client will involve the = authorizing party as necessary through interaction mechanisms indicated = by the protocol. 
 
Additionally, the delegation process will allow for:
 
- = Fine-grained specification of resource access
- = Approval of identity claims and multiple resources in a single = interaction
- = Delegation between multiple users
- = Web, mobile, single-page, and other types of client 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 providing user, software, organization, and other pieces = of information used in authorization decisions
- = Token presentation mechanisms and key bindings
 
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 porting from OAuth 2.0 and = OpenID Connect to the new protocol where possible.

While the initial work will focus on using HTTP for = communication between the client and the authorization server, the = working group will seek to take advantage of optimization features of = HTTP2 and HTTP3, and will strive to enable simple mapping to other = protocols such as COAP.
 
On = Jan 10, 2020, at 12:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
 
Hey
 
I've = written an alternative charter that I hope captures some of the feedback = on Justin's charter.
 
I = found it easier to rewrite the charter to broaden the marketplace of = ideas. 
 
Key = ideas:
 
- = This work supports existing OAuth 2.0, and OpenID Connect use cases.
 
- The = client interacts directly with the authorization server. 
 
/Dick
 
----
 
This = group is chartered to develop a delegated identity and authorization = protocol.. The use cases supported by this protocol will include widely = deployed use cases currently supported by OAuth 2.0, and OpenID Connect. = In contrast to OAuth 2.0 and OpenID Connect, where the protocol is = initiated by redirecting the user's browser to an authorization server, = this protocol will be initiated by the client directly interacting with = the authorization server..

Additionally, the protocol will allow:
- = fine-grained specification of resource access
- the = user to approve requests for identity claims and access to multiple = resources in one interaction
- = web, mobile, single-page, and other client applications
- = taking advantage of optimization features in HTTP2 and HTTP3

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

- discovery of the authorization server
- = cryptographic agility for keys, message signatures, and proof of = possession 
- = user interaction mechanisms including web and non-web methods- token = presentation mechanisms and key bindings

Although the artifacts for this work are not intended or = expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, = they will attempt to simplify porting from OAuth 2.0 and OpenID Connect, = and strive to reuse existing semantics such as client identifiers, OAuth = 2.0 scopes and access tokens, and OpenID Connect ID Tokens and claims.

While the initial work will focus on using HTTP for = communication between the client and the authorization server, the = working group will strive to enable simple mapping to other protocols = such as COAP.
 
 
=E1=90=A7


= --Apple-Mail=_76A24BD8-D79C-4197-88C2-85B8F7FAE62D-- From nobody Thu Jan 16 08:15: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 C9D1F120867 for ; Thu, 16 Jan 2020 08:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 A5JgqJZOgfAV for ; Thu, 16 Jan 2020 08:15:16 -0800 (PST) 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 374A91209A2 for ; Thu, 16 Jan 2020 08:15:12 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id w15so19789781wru.4 for ; Thu, 16 Jan 2020 08:15:12 -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=7y0K/oOUKqko4a2siFuPq06RYykf3FztAcFLAV3638M=; b=y6OmWbnxjG5fkY8FwUuZW2hW6Sr/VC/mzGcWe7TFIleOA1mCpMsn3lz3f6+V9kzi/N Aq5Vt3vX5+FSXhN5c1K3vyYLup/5kzlOp0cZqoWNum93LQKoHXkOEpXMDeC2KeXCSBIB UE9QN1/vnlP7pUJhhO5erkw0tai8+WQzqubwU37Iv5h/8DpUxerx5LzoJKtVxfVvXrc2 sCPNwjr/nicerhp93ZBx82+uR+1mn/UCoqOzTVUVtwcBm+eN333CrVg+UZHEwrUkZ7v/ VYP8riFiGDlm3qLCmtDbYfkzZbq421byzVdtuIIwPV+vp8bYshkptwckJVxAbeJRktZj 6s1A== 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=7y0K/oOUKqko4a2siFuPq06RYykf3FztAcFLAV3638M=; b=hSDsmaxzaSzutMwU0D/E9Niv/kGf5XEka1pWmFyFs4Z843EeQZ1YgPHZU0uMaoEtrj tm4LhQaZHEauhuwRqsbs/Jokl1qTiD2PJiUp67tR8n4+ZaGbIwVC4dV3ANtGfjOJ5LdC xMHAHZmvTI83Pe2QJuLh1gt0Jf2uiMGbbsL8BJyN53jqPNwT3fBvbJ3osd5w0Or5psmo weT9KjPagJH9vADd6kSkZSdPTztyjkjJpkKHrhvrjZikXSYrCOWQeje0oU/Zd+QigFa5 gZ5LYzzAo2Q2pFpVbYwOB2DFt5neL/f9r6GrRV749Oa8W8OH7zNN8lJHCIigvMAIf1xz GTOA== X-Gm-Message-State: APjAAAUgPV7ZkFnSmiEjBv1GMkDt5k7xO2t3c5cCjhvnEAWp+0PGQfVA 0b/J7P4Bx7iaS2+T5nAA2TM0vA== X-Google-Smtp-Source: APXvYqxPoYhgUhtY138KhPmR91s8MKxbeHQ+8OvGGq13+CPIKZFwE6mjXxlh7ZEEia2wA78lU+8pBA== X-Received: by 2002:adf:f10a:: with SMTP id r10mr4141518wro.202.1579191310655; Thu, 16 Jan 2020 08:15:10 -0800 (PST) Received: from [172.17.103.27] ([193.242.134.240]) by smtp.gmail.com with ESMTPSA id h17sm30660930wrs.18.2020.01.16.08.15.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2020 08:15:09 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-9BFB0201-140B-463C-8E25-57DF749EC03B; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Thu, 16 Jan 2020 17:15:08 +0100 Message-Id: <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> Cc: "txauth@ietf.org" , "rdd@cert.org" , "Richard Backman, Annabelle" , Benjamin Kaduk , Dick Hardt In-Reply-To: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> To: Justin Richer X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 16:15:26 -0000 --Apple-Mail-9BFB0201-140B-463C-8E25-57DF749EC03B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 16.01.2020 um 16:45 schrieb Justin Richer : >=20 > - Approval of identity claims and multiple resources in a single interacti= on This sounds a bit incomplete to me. I assume the user would approve =E2=80=9E= the attestation of identity claims=E2=80=9C. I furthermore think the user wo= uld approve =E2=80=9Eaccess to multiple APIs=E2=80=9C. I would prefer API ov= er resource because it is more universal. For example, the protocol could al= so be used to create resources.= --Apple-Mail-9BFB0201-140B-463C-8E25-57DF749EC03B Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBTYw ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDGCA8cwggPDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0 aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAesw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTE2MTYxNTA4WjAv BgkqhkiG9w0BCQQxIgQgajuNj7CMBadZE5vqiwqWrhlzHHbKhMv3r5rUnGJIpp4wgb0GCSsGAQQB gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQA/JMIN qi1X9aC7FxZQIrkmGaehcG9tcQn5RpX6vyxf4GOmRu7nZlji3K8Q8gaVFiN6nkjxiLmriMUy1etG MvItp1ItDBphzWvHlhrf63tvOqvL2u80duWfsfrECz4DKKZ1joEswUh5SN2NAPiagcEzkC1N86pe kx6eji057WgbNWOTMnMnWD2++wDvXrqJOlz3HE3SzoUomMf4DvCwNOBC3A4uaWPuZlckzIXXQ2Gu HNEDmzM1dg2GUa9rbTiYvM9GjR/WnurKA7nS78eY0WG1KkOHEM9Uwo8dxdxnkW+JsNfpJEBQfU1S 0Kbb1Q1fOLgoUGxqFJfo/U0e4hXOEuIqAAAAAAAA --Apple-Mail-9BFB0201-140B-463C-8E25-57DF749EC03B-- From nobody Thu Jan 16 08:43: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 104DB1209A1 for ; Thu, 16 Jan 2020 08:43:19 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 L46i1NskeJ1M for ; Thu, 16 Jan 2020 08:43:14 -0800 (PST) Received: from gateway30.websitewelcome.com (gateway30.websitewelcome.com [192.185.160.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8217E12004C for ; Thu, 16 Jan 2020 08:43:14 -0800 (PST) Received: from cm11.websitewelcome.com (cm11.websitewelcome.com [100.42.49.5]) by gateway30.websitewelcome.com (Postfix) with ESMTP id 029CB5942C for ; Thu, 16 Jan 2020 10:43:14 -0600 (CST) Received: from box5207.bluehost.com ([162.241.224.194]) by cmsmtp with SMTP id s8EjiUOZjiJ43s8EjikF35; Thu, 16 Jan 2020 10:43:13 -0600 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:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=98zMSOrvwHJWyrnL3d4U5ewNkUHzYqbGg4+0u/WwXNc=; b=AixLagYwwMjOXwdND8d2G3cema gOWuj01MssgauKWoI044aEzja6qTaIHU26oaOZ1atTR1FTcIvPN6p5fGDkQb1SXWofAMbEVOEs4Z7 cWnIG7NT1Ve7/md76b+KVx/wy; Received: from [192.54.222.147] (port=21892 helo=[10.189.93.86]) by box5207.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1is8Ej-001bWa-GX; Thu, 16 Jan 2020 09:43:13 -0700 User-Agent: Microsoft-MacOutlook/10.10.12.200112 Date: Thu, 16 Jan 2020 11:43:11 -0500 From: Thomas Hardjono To: Justin Richer , "txauth@ietf.org" CC: Thomas Hardjono Message-ID: <40DEDA03-58E1-46EE-A46E-15D448283762@hardjono.net> Thread-Topic: [Txauth] alternative charter writeup References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> In-Reply-To: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> 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: 192.54.222.147 X-Source-L: No X-Exim-ID: 1is8Ej-001bWa-GX X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.189.93.86]) [192.54.222.147]:21892 X-Source-Auth: ietf-txauth@hardjono.net X-Email-Count: 2 X-Source-Cap: aGFyZGpvbm87aGFyZGpvbm87Ym94NTIwNy5ibHVlaG9zdC5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 16:43:19 -0000 Looks good, but I have a clarification question: >>> - Delegation between multiple users What does this mean exactly? Is it the "multi-hop" delegation (Alice to Bob to Charlize to ...) Or does it only the "1-hop" delegation concurrently (Alice to Bob; Alice to= Charlize; Alice to...) -- thomas -- =EF=BB=BF-----Original Message----- From: Txauth on behalf of Justin Richer Date: Thursday, January 16, 2020 at 10:46 AM To: "txauth@ietf.org" Cc: "rdd@cert.org" , "Richard Backman, Annabelle" , Benjamin Kaduk , Dick Hardt Subject: Re: [Txauth] alternative charter writeup Here=E2=80=99s my updated text incorporating the feedback so far: This group is chartered to develop a delegation protocol for identity, auth= orization, and API access. This protocol will allow an authorizing party to = delegate access to client software through an authorization server. The use = cases supported by this protocol will include widely deployed use cases curr= ently supported by OAuth 2.0 and OpenID Connect (an extension of OAuth 2.0) = as well as new use cases not enabled by OAuth 2.0. 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 which is initiated by the client redirecting the user=E2= =80=99s browser). The client will involve the authorizing party as necessary thr= ough interaction mechanisms indicated by the protocol. This decoupling avoid= s many of the security concerns and technical challenges of OAuth 2.0 as wel= l as providing a non-invasive path for supporting future types of clients an= d interaction channels. Additionally, the delegation process will allow for: - Fine-grained specification of resource access - Approval of identity claims and multiple resources in a single interactio= n - Delegation between multiple users - Web, mobile, single-page, interaction-constrained, and other types of cli= ent 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 providing user, software, organization, and other pieces o= f information used in authorization decisions - Token presentation mechanisms and key bindings 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 porting from OAuth 2.0 and OpenID Connect to the new protocol whe= re possible. While the initial work will focus on using HTTP for communication between t= he client and the authorization server, the working group will seek to take = advantage of optimization features of HTTP2 and HTTP3 where possible, and wi= ll strive to enable simple mapping to other protocols such as COAP. It=E2=80=99s definitely a lot, but I think we=E2=80=99ve got a good handle on what we=E2=80= =99re working on, and what the boundaries are. I think this is both too much o= f an effort and too much of a break to do this in the OAuth WG, where there=E2= =80=99s already still plenty of work to be done. We=E2=80=99re leaning a lot on lesson= s learned from the OAuth 2 world and its extensions, including OIDC and UMA2= . We=E2=80=99ve got the attention of a lot of the right people to start this as we= ll. So to the AD=E2=80=99s: Ben and Roman =E2=80=94 what=E2=80=99s the next step? This should be = a new working group and like to get it started so that we can have our first= meeting in Vancouver. =E2=80=94 Justin On Jan 14, 2020, at 12:12 AM, Dick Hardt wrote: Sounds good to me. On Mon, Jan 13, 2020 at 6:24 PM Justin Richer wrote: I can get behind this kind of addition. I like Annabelle=E2=80=99s framing of it = in terms of decoupling, and some explanation of why we=E2=80=99re doing it in rela= tion to OAuth 2=E2=80=99s approach. One of the key things, to me, is that we=E2=80=99re = making a break from OAuth 2=E2=80=99s core architecture but doing so for very spec= ific reasons.=20 =E2=80=94 Justin On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle wrote: It=E2=80=99s not just about the initial communication, though. I the key thing to= emphasize is the decoupling the protocol from delegation channels, which ad= dresses the aforementioned security/complexity issues and also provides a pa= th to support future delegation channel types without significant changes to= the protocol (unlike OAuth 2.0, where extensions like Device Flow and PAR i= ntroduce substantial changes to the core protocol flow on both client and AS= ). Since the protocol isn=E2=80=99t assuming a particular front channel, it=E2=80=99s ea= sier to add support for a new one. =20 Proposal, altered from Dick=E2=80=99s suggestion: This group is chartered to develop a delegated identity and authorization p= rotocol. The use cases supported by this protocol will include widely deploy= ed use cases currently supported by OAuth 2.0, and OpenID Connect, an extens= ion of OAuth 2.0. This protocol will be decoupled from delegation channels s= uch as an end user=E2=80=99s web browser and operate primarily through a channel b= etween the client and the authorization server, avoiding many of the securit= y concerns and technical challenges of OAuth 2.0 and providing a non-invasiv= e path for adding support for future types of clients and delegation channel= s. =20 =E2=80=93=20 Annabelle Richard Backman AWS Identity =20 =20 From: Dick Hardt Date: Monday, January 13, 2020 at 4:35 PM To: "Richard Backman, Annabelle" Cc: Justin Richer , "txauth@ietf.org" Subject: Re: [Txauth] alternative charter writeup =20 I agree, some more "why" would help a broader audience understand the motiv= ations. How about this change to the first paragraph? =20 This group is chartered to develop a delegated identity and authorization p= rotocol. The use cases supported by this protocol will include widely deploy= ed use cases currently supported by OAuth 2.0, and OpenID Connect, an extens= ion of OAuth 2.0. In contrast to OAuth 2.0, where the protocol is initiated = by redirecting the user's browser to an authorization server, this protocol = will be initiated by the client directly interacting with the authorization = server, which will mitigate many of the security concerns and technical chal= lenges of OAuth 2.0. =20 =20 On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle wrote: While I agree with the goals stated in this charter, if I read this from th= e perspective of someone who hasn=E2=80=99t been our meetings or listened to Justi= n=E2=80=99s presentations, I=E2=80=99m hard pressed to see what the point of this group = is, relative to the OAuth WG. I=E2=80=99d expect this charter to provide at least = a cursory explanation of what problem it is trying to solve. In this case, t= he problem should be partially defined in relation to OAuth. What will this = WG do that the OAuth WG hasn=E2=80=99t already done or isn=E2=80=99t already doing? =20 How about adding something like the following to paragraph 2: =20 The protocol will mitigate many of the security concerns and technical chal= lenges of OAuth 2.0 by communicating over secure channels between the client= and the authorization server, and minimizing the amount of information tran= smitted over untrusted channels. =20 =E2=80=93=20 Annabelle Richard Backman AWS Identity =20 =20 From: Txauth on behalf of Dick Hardt Date: Friday, January 10, 2020 at 6:57 PM To: Justin Richer Cc: "txauth@ietf.org" Subject: Re: [Txauth] alternative charter writeup =20 This looks even better! Thanks Justin. =20 What do others think of the proposed charter now?=20 =E1=90=A7 =20 On Fri, Jan 10, 2020 at 12:43 PM Justin Richer wrote: Thanks, Dick. I=E2=80=99ve been working on an updated charter based on everyone=E2=80= =99s feedback, and I was aiming to have out today anyway, so this timing is he= lpful. So here=E2=80=99s my take on a new charter, incorporating some of your poin= ts below:=20 =20 This group is chartered to develop a delegation protocol for identity, auth= orization, and API access. This protocol will allow an authorizing party to = delegate access to client software through an authorization server. The use = cases supported by this protocol will include widely deployed use cases curr= ently supported by OAuth 2.0 and OpenID Connect.=20 =20 The delegation process will be acted upon by multiple parties in the protoc= ol, each performing a specific role. The protocol will be initiated by the c= lient interacting directly with the authorization server (in contrast with O= Auth 2 which is initiated by the client redirecting the user=E2=80=99s browser). T= he client will involve the authorizing party as necessary through interactio= n mechanisms indicated by the protocol.=20 =20 Additionally, the delegation process will allow for: =20 - Fine-grained specification of resource access - Approval of identity claims and multiple resources in a single interactio= n - Delegation between multiple users - Web, mobile, single-page, and other types of client applications =20 The group will define extension points for this protocol to allow for flexi= bility in areas including: =20 - Cryptographic agility for keys, message signatures, and proof of possessi= on=20 - User interaction mechanisms including web and non-web methods - Mechanisms for providing user, software, organization, and other pieces o= f information used in authorization decisions - Token presentation mechanisms and key bindings =20 Additionally, the group will provide mechanisms for management of the proto= col 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 bac= kwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt t= o simplify porting from OAuth 2.0 and OpenID Connect to the new protocol whe= re possible. While the initial work will focus on using HTTP for communication between t= he client and the authorization server, the working group will seek to take = advantage of optimization features of HTTP2 and HTTP3, and will strive to en= able simple mapping to other protocols such as COAP. =20 On Jan 10, 2020, at 12:04 PM, Dick Hardt wrote: =20 Hey =20 I've written an alternative charter that I hope captures some of the feedba= ck on Justin's charter. =20 I found it easier to rewrite the charter to broaden the marketplace of idea= s.=20 =20 Key ideas: =20 - This work supports existing OAuth 2.0, and OpenID Connect use cases. =20 - The client interacts directly with the authorization server.=20 =20 /Dick =20 ---- =20 This group is chartered to develop a delegated identity and authorization p= rotocol.. The use cases supported by this protocol will include widely deplo= yed use cases currently supported by OAuth 2.0, and OpenID Connect. In contr= ast to OAuth 2.0 and OpenID Connect, where the protocol is initiated by redi= recting the user's browser to an authorization server, this protocol will be= initiated by the client directly interacting with the authorization server.= . Additionally, the protocol will allow: - fine-grained specification of resource access - the user to approve requests for identity claims and access to multiple r= esources in one interaction - web, mobile, single-page, and other client applications - taking advantage of optimization features in HTTP2 and HTTP3 The group will define extension points for this protocol to allow for flexi= bility in areas including: - discovery of the authorization server - cryptographic agility for keys, message signatures, and proof of possessi= on=20 - user interaction mechanisms including web and non-web methods- token pres= entation mechanisms and key bindings Although the artifacts for this work are not intended or expected to be bac= kwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt to sim= plify porting from OAuth 2.0 and OpenID Connect, and strive to reuse existin= g semantics such as client identifiers, OAuth 2.0 scopes and access tokens, = and OpenID Connect ID Tokens and claims. While the initial work will focus on using HTTP for communication between t= he client and the authorization server, the working group will strive to ena= ble simple mapping to other protocols such as COAP. =20 =20 =E1=90=A7 --=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 Thu Jan 16 08:51: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 4887F120AED for ; Thu, 16 Jan 2020 08:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[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 vkJOeHlEb-WH for ; Thu, 16 Jan 2020 08:51:37 -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 79389120ADB for ; Thu, 16 Jan 2020 08:51:37 -0800 (PST) Received: from [192.168.1.16] (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 00GGpIBf000500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 11:51:19 -0500 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: <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> Date: Thu, 16 Jan 2020 11:51:18 -0500 Cc: "txauth@ietf.org" , "rdd@cert.org" , "Richard Backman, Annabelle" , Benjamin Kaduk , Dick Hardt Content-Transfer-Encoding: quoted-printable Message-Id: References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 16:51:43 -0000 On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt = wrote: >=20 >=20 >=20 >> Am 16.01.2020 um 16:45 schrieb Justin Richer : >>=20 >> - Approval of identity claims and multiple resources in a single = interaction >=20 > This sounds a bit incomplete to me. I assume the user would approve = =E2=80=9Ethe attestation of identity claims=E2=80=9C. I furthermore = think the user would approve =E2=80=9Eaccess to multiple APIs=E2=80=9C. = I would prefer API over resource because it is more universal. For = example, the protocol could also be used to create resources. Point taken, but this isn=E2=80=99t meant to be an exhaustive list of = what it can do, merely the list of things we=E2=80=99re positive we want = it to do. I also prefer =E2=80=9CAPI=E2=80=9D over =E2=80=9Cresource=E2=80= =9D, but concede that =E2=80=9Cresource=E2=80=9D can be a writeable = thing too. Even then I=E2=80=99m happy to tweak the language here.=20 =E2=80=94 Justin= From nobody Thu Jan 16 08: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 364D2120AF1 for ; Thu, 16 Jan 2020 08:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[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 UpWg12Cv1psr for ; Thu, 16 Jan 2020 08:53:47 -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 D569F120AFC for ; Thu, 16 Jan 2020 08:53:46 -0800 (PST) Received: from [192.168.1.16] (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 00GGrQpc001405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 11:53:28 -0500 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: <40DEDA03-58E1-46EE-A46E-15D448283762@hardjono.net> Date: Thu, 16 Jan 2020 11:53:25 -0500 Cc: "txauth@ietf.org" , Thomas Hardjono Content-Transfer-Encoding: quoted-printable Message-Id: <5F952C70-8EE2-440A-9334-5FBC19CE2A5E@mit.edu> References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <40DEDA03-58E1-46EE-A46E-15D448283762@hardjono.net> To: Thomas Hardjono X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 16:53:52 -0000 On Jan 16, 2020, at 11:43 AM, Thomas Hardjono = wrote: >=20 >=20 > Looks good, but I have a clarification question: >=20 >>>> - Delegation between multiple users >=20 > What does this mean exactly? >=20 > Is it the "multi-hop" delegation (Alice to Bob to Charlize to ...) >=20 > Or does it only the "1-hop" delegation concurrently (Alice to Bob; = Alice to Charlize; Alice to=E2=80=A6) My thinking was that at the very least we want to allow the person = running the client software and the person doing the authorization to be = different people. This is the UMA use case (Alice to bob) and the CIBA = use case (agent getting someone to log in). I think chaining can follow = that, where Bob can then let Charlie do something. This is also along = the lines of the token exchange model of OAuth 2, with continuously = down-scoped access. What I think is very much out of scope is cross-domain policy = processing.=20 =E2=80=94 Justin >=20 > -- thomas -- >=20 >=20 >=20 > =EF=BB=BF-----Original Message----- > From: Txauth on behalf of Justin Richer = > Date: Thursday, January 16, 2020 at 10:46 AM > To: "txauth@ietf.org" > Cc: "rdd@cert.org" , "Richard Backman, Annabelle" = , Benjamin Kaduk , Dick Hardt = > Subject: Re: [Txauth] alternative charter writeup >=20 > Here=E2=80=99s my updated text incorporating the feedback so far: >=20 >=20 > This group is chartered to develop a delegation protocol for identity, = authorization, and API access. This protocol will allow an authorizing = party to delegate access to client software through an authorization = server. The use cases supported by this protocol will include widely = deployed use cases currently supported by OAuth 2.0 and OpenID Connect = (an extension of OAuth 2.0) as well as new use cases not enabled by = OAuth 2.0. >=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 which is initiated by = the client redirecting the user=E2=80=99s browser). The client will = involve the authorizing party as necessary through interaction = mechanisms indicated by the protocol. This decoupling avoids many of the = security concerns and technical challenges of OAuth 2.0 as well as = providing a non-invasive path for supporting future types of clients and = interaction channels. >=20 >=20 > Additionally, the delegation process will allow for: >=20 >=20 > - Fine-grained specification of resource access >=20 > - Approval of identity claims and multiple resources in a single = interaction >=20 > - Delegation between multiple users >=20 > - Web, mobile, single-page, interaction-constrained, and other types = of client applications >=20 >=20 > The group will define extension points for this protocol to allow for = flexibility in areas including: >=20 >=20 > - Cryptographic agility for keys, message signatures, and proof of = possession=20 >=20 > - User interaction mechanisms including web and non-web methods >=20 > - Mechanisms for providing user, software, organization, and other = pieces of information used in authorization decisions >=20 > - Token presentation mechanisms and key bindings >=20 >=20 > Additionally, the group will provide mechanisms for management of the = protocol lifecycle including: >=20 >=20 > - Discovery of the authorization server >=20 > - Revocation of active tokens >=20 > - Query of token rights by resource servers >=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 porting from OAuth 2.0 and OpenID Connect to the new = protocol where possible. >=20 >=20 > While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3 where = possible, and will strive to enable simple mapping to other protocols = such as COAP. >=20 >=20 >=20 >=20 >=20 > It=E2=80=99s definitely a lot, but I think we=E2=80=99ve got a good = handle on what we=E2=80=99re working on, and what the boundaries are. I = think this is both too much of an effort and too much of a break to do = this in the OAuth WG, where there=E2=80=99s already still plenty of work = to be done. We=E2=80=99re leaning a lot on lessons learned from the = OAuth 2 world and its extensions, including OIDC and UMA2. We=E2=80=99ve = got the attention of a lot of the right people to start this as well. >=20 > So to the AD=E2=80=99s: Ben and Roman =E2=80=94 what=E2=80=99s the = next step? This should be a new working group and like to get it started = so that we can have our first meeting in Vancouver. >=20 > =E2=80=94 Justin >=20 >=20 > On Jan 14, 2020, at 12:12 AM, Dick Hardt wrote: >=20 > Sounds good to me. >=20 > On Mon, Jan 13, 2020 at 6:24 PM Justin Richer wrote: >=20 >=20 > I can get behind this kind of addition. I like Annabelle=E2=80=99s = framing of it in terms of decoupling, and some explanation of why = we=E2=80=99re doing it in relation to OAuth 2=E2=80=99s approach. One of = the key things, to me, is that we=E2=80=99re making a break from OAuth = 2=E2=80=99s core architecture but doing so for very specific reasons.=20 >=20 > =E2=80=94 Justin >=20 >=20 > On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle = wrote: >=20 > It=E2=80=99s not just about the initial communication, though. I the = key thing to emphasize is the decoupling the protocol from delegation = channels, which addresses the aforementioned security/complexity issues = and also provides a path to support future delegation channel types = without significant changes to the protocol (unlike OAuth 2.0, where = extensions like Device Flow and PAR introduce substantial changes to the = core protocol flow on both client and AS). Since the protocol isn=E2=80=99= t assuming a particular front channel, it=E2=80=99s easier to add = support for a new one. >=20 > Proposal, altered from Dick=E2=80=99s suggestion: > This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. This protocol will be = decoupled from delegation channels such as an end user=E2=80=99s web = browser and operate primarily through a channel between the client and = the authorization server, avoiding many of the security concerns and = technical challenges of OAuth 2.0 and providing a non-invasive path for = adding support for future types of clients and delegation channels. >=20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity >=20 >=20 >=20 > From: Dick Hardt > Date: Monday, January 13, 2020 at 4:35 PM > To: "Richard Backman, Annabelle" > Cc: Justin Richer , "txauth@ietf.org" = > Subject: Re: [Txauth] alternative charter writeup >=20 >=20 >=20 > I agree, some more "why" would help a broader audience understand the = motivations. How about this change to the first paragraph? >=20 >=20 >=20 > This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. In contrast to OAuth 2.0, = where the protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server, which will mitigate = many of the security concerns and technical challenges of OAuth 2.0. >=20 >=20 >=20 >=20 >=20 > On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle = wrote: >=20 >=20 > While I agree with the goals stated in this charter, if I read this = from the perspective of someone who hasn=E2=80=99t been our meetings or = listened to Justin=E2=80=99s presentations, I=E2=80=99m hard pressed to = see what the point of this group is, relative to the OAuth WG. I=E2=80=99d= expect this charter to provide at least a cursory explanation of what = problem it is trying to solve. In this case, the problem should be = partially defined in relation to OAuth. What will this WG do that the = OAuth WG hasn=E2=80=99t already done or isn=E2=80=99t already doing? >=20 > How about adding something like the following to paragraph 2: >=20 > The protocol will mitigate many of the security concerns and technical = challenges of OAuth 2.0 by communicating over secure channels between = the client and the authorization server, and minimizing the amount of = information transmitted over untrusted channels. >=20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity >=20 >=20 >=20 > From: Txauth on behalf of Dick Hardt = > Date: Friday, January 10, 2020 at 6:57 PM > To: Justin Richer > Cc: "txauth@ietf.org" > Subject: Re: [Txauth] alternative charter writeup >=20 >=20 >=20 > This looks even better! Thanks Justin. >=20 >=20 > What do others think of the proposed charter now?=20 >=20 >=20 > =E1=90=A7 >=20 >=20 > On Fri, Jan 10, 2020 at 12:43 PM Justin Richer = wrote: >=20 >=20 > Thanks, Dick. I=E2=80=99ve been working on an updated charter based on = everyone=E2=80=99s feedback, and I was aiming to have out today anyway, = so this timing is helpful. So here=E2=80=99s my take on a new charter, = incorporating some of your points below:=20 >=20 >=20 >=20 > This group is chartered to develop a delegation protocol for identity, = authorization, and API access. This protocol will allow an authorizing = party to delegate access to client software through an authorization = server. The use cases supported by this protocol will include widely = deployed use cases currently supported by OAuth 2.0 and OpenID Connect.=20= >=20 >=20 >=20 > The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will be = initiated by the client interacting directly with the authorization = server (in contrast with OAuth 2 which is initiated by the client = redirecting the user=E2=80=99s browser). The client will involve the = authorizing party as necessary through interaction mechanisms indicated = by the protocol.=20 >=20 >=20 >=20 > Additionally, the delegation process will allow for: >=20 >=20 >=20 > - Fine-grained specification of resource access >=20 > - Approval of identity claims and multiple resources in a single = interaction >=20 > - Delegation between multiple users >=20 > - Web, mobile, single-page, and other types of client applications >=20 >=20 >=20 > The group will define extension points for this protocol to allow for = flexibility in areas including: >=20 >=20 >=20 > - Cryptographic agility for keys, message signatures, and proof of = possession=20 >=20 > - User interaction mechanisms including web and non-web methods >=20 > - Mechanisms for providing user, software, organization, and other = pieces of information used in authorization decisions >=20 > - Token presentation mechanisms and key bindings >=20 >=20 >=20 > Additionally, the group will provide mechanisms for management of the = protocol lifecycle including: >=20 >=20 >=20 > - Discovery of the authorization server >=20 > - Revocation of active tokens >=20 > - Query of token rights by resource servers >=20 >=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 porting from OAuth 2.0 and OpenID Connect to the new = protocol where possible. >=20 > While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3, and = will strive to enable simple mapping to other protocols such as COAP. >=20 >=20 >=20 >=20 >=20 > On Jan 10, 2020, at 12:04 PM, Dick Hardt wrote: >=20 >=20 > Hey >=20 >=20 > I've written an alternative charter that I hope captures some of the = feedback on Justin's charter. >=20 >=20 >=20 > I found it easier to rewrite the charter to broaden the marketplace of = ideas.=20 >=20 >=20 >=20 > Key ideas: >=20 >=20 >=20 > - This work supports existing OAuth 2.0, and OpenID Connect use cases. >=20 >=20 >=20 > - The client interacts directly with the authorization server.=20 >=20 >=20 >=20 > /Dick >=20 >=20 >=20 > ---- >=20 >=20 > This group is chartered to develop a delegated identity and = authorization protocol.. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the = protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server.. >=20 >=20 > Additionally, the protocol will allow: >=20 > - fine-grained specification of resource access >=20 > - the user to approve requests for identity claims and access to = multiple resources in one interaction >=20 > - web, mobile, single-page, and other client applications >=20 > - taking advantage of optimization features in HTTP2 and HTTP3 >=20 >=20 > The group will define extension points for this protocol to allow for = flexibility in areas including: >=20 >=20 > - discovery of the authorization server >=20 > - cryptographic agility for keys, message signatures, and proof of = possession=20 >=20 > - user interaction mechanisms including web and non-web methods- token = presentation mechanisms and key bindings >=20 >=20 > Although the artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 or OpenID Connect, they will = attempt to simplify porting from OAuth 2.0 and OpenID Connect, and = strive to reuse existing semantics such as client identifiers, OAuth 2.0 = scopes and access tokens, and OpenID Connect ID Tokens and claims. >=20 >=20 > While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = strive to enable simple mapping to other protocols such as COAP. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =E1=90=A7 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=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 From nobody Thu Jan 16 11:12: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 79DF2120963 for ; Thu, 16 Jan 2020 11:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.8 X-Spam-Level: X-Spam-Status: No, score=-11.8 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, RCVD_IN_DNSWL_MED=-2.3, 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 0MXZNAX8RgfP for ; Thu, 16 Jan 2020 11:12:47 -0800 (PST) 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 CB81D1208CD for ; Thu, 16 Jan 2020 11:12:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579201968; x=1610737968; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OT/2SA/43tPURQ4dJO0TdIBYsnTsnJy9bQVR3joB+IE=; b=UL4LdEm8zHoK6aQ/Pqnx/32J62iViw6gev5A10sSi81NnoqjXWIggvIZ pOeSb2sMgSVxaqefuMyl8ApQe6Mh8hiK+LtD8/mYFauilj1sAx+7dflil 9QOhYX9X4Omb/CLppHARb7JPqbrzVN4vTb9hMbII9VWn+ALWEoCN66shm o=; IronPort-SDR: pO7rGafAlubgdanSjvIjEoU9RINhrJg1o5u2mHJkVjWGEHwE9Ud2zAsQhN/y8Gn8bV/5kBAIZ8 C9QTWMfYFwyQ== X-IronPort-AV: E=Sophos;i="5.70,327,1574121600"; d="scan'208";a="20530068" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1d-474bcd9f.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 16 Jan 2020 19:12:34 +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-474bcd9f.us-east-1.amazon.com (Postfix) with ESMTPS id D5FABA226C; Thu, 16 Jan 2020 19:12:33 +0000 (UTC) Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 16 Jan 2020 19:12:33 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 16 Jan 2020 19:12:33 +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.1367.000; Thu, 16 Jan 2020 19:12:33 +0000 From: "Richard Backman, Annabelle" To: Justin Richer , Torsten Lodderstedt CC: "txauth@ietf.org" , "rdd@cert.org" , Benjamin Kaduk , Dick Hardt Thread-Topic: [Txauth] alternative charter writeup Thread-Index: AQHVx9g9cyOj1MRzqU6+3+Goa7VakafkXaAAgABoEICAA/l4gIAAld0A//+QawCAAI5HAIAALucAgAPVjwCAAAhfAIAAChsA//+hWgA= Date: Thu, 16 Jan 2020 19:12:33 +0000 Message-ID: References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.8] Content-Type: text/plain; charset="utf-8" Content-ID: <90D18082EFF5B94293A0E2C52367CB0F@amazon.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 19:12:49 -0000 VGhlIG9ubHkgcmVhc29uIEkgY2FuIHRoaW5rIG9mIHRvIHNpbmdsZSBvdXQgaWRlbnRpdHkgd2l0 aGluIHRoZSBjaGFydGVyIGlzIGlmIHRoZXJlIGlzIHNvbWUgd29yayBvciBmZWF0dXJlIHRoYXQg aXMgd2l0aGluIHNjb3BlIGZvciB0aGUgd29ya2luZyBncm91cCwgYnV0IG9ubHkgZm9yIGlkZW50 aXR5IGNsYWltcyAoZS5nLiwgcmV0dXJuaW5nIGlkZW50aXR5IGNsYWltcyBmcm9tIHRoZSB0cmFu c2FjdGlvbiBlbmRwb2ludCkuIFJlcGVhdGluZyBhIHF1ZXN0aW9uIEkgcG9zZWQgZWFybGllciwg d2hhdCBpcyBpdCBhYm91dCBpZGVudGl0eSBjbGFpbXMgdGhhdCBtYWtlIHRoZW0gd29ydGh5IG9m IHNwZWNpYWwgY29uc2lkZXJhdGlvbj8NCg0K4oCTIA0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21h bg0KQVdTIElkZW50aXR5DQogDQoNCu+7v09uIDEvMTYvMjAsIDg6NTEgQU0sICJKdXN0aW4gUmlj aGVyIiA8anJpY2hlckBtaXQuZWR1PiB3cm90ZToNCg0KICAgIE9uIEphbiAxNiwgMjAyMCwgYXQg MTE6MTUgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiB3 cm90ZToNCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+PiBBbSAxNi4wMS4yMDIwIHVtIDE2 OjQ1IHNjaHJpZWIgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PjoNCiAgICA+PiANCiAg ICA+PiAtIEFwcHJvdmFsIG9mIGlkZW50aXR5IGNsYWltcyBhbmQgbXVsdGlwbGUgcmVzb3VyY2Vz IGluIGEgc2luZ2xlIGludGVyYWN0aW9uDQogICAgPiANCiAgICA+IFRoaXMgc291bmRzIGEgYml0 IGluY29tcGxldGUgdG8gbWUuIEkgYXNzdW1lIHRoZSB1c2VyIHdvdWxkIGFwcHJvdmUg4oCedGhl IGF0dGVzdGF0aW9uIG9mIGlkZW50aXR5IGNsYWltc+KAnC4gSSBmdXJ0aGVybW9yZSB0aGluayB0 aGUgdXNlciB3b3VsZCBhcHByb3ZlIOKAnmFjY2VzcyB0byBtdWx0aXBsZSBBUElz4oCcLiBJIHdv dWxkIHByZWZlciBBUEkgb3ZlciByZXNvdXJjZSBiZWNhdXNlIGl0IGlzIG1vcmUgdW5pdmVyc2Fs LiBGb3IgZXhhbXBsZSwgdGhlIHByb3RvY29sIGNvdWxkIGFsc28gYmUgdXNlZCB0byBjcmVhdGUg cmVzb3VyY2VzLg0KICAgIA0KICAgIFBvaW50IHRha2VuLCBidXQgdGhpcyBpc27igJl0IG1lYW50 IHRvIGJlIGFuIGV4aGF1c3RpdmUgbGlzdCBvZiB3aGF0IGl0IGNhbiBkbywgbWVyZWx5IHRoZSBs aXN0IG9mIHRoaW5ncyB3ZeKAmXJlIHBvc2l0aXZlIHdlIHdhbnQgaXQgdG8gZG8uIEkgYWxzbyBw cmVmZXIg4oCcQVBJ4oCdIG92ZXIg4oCccmVzb3VyY2XigJ0sIGJ1dCBjb25jZWRlIHRoYXQg4oCc cmVzb3VyY2XigJ0gY2FuIGJlIGEgd3JpdGVhYmxlIHRoaW5nIHRvby4gRXZlbiB0aGVuIEnigJlt IGhhcHB5IHRvIHR3ZWFrIHRoZSBsYW5ndWFnZSBoZXJlLiANCiAgICANCiAgICAg4oCUIEp1c3Rp bg0KDQo= From nobody Thu Jan 16 12:58: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 287FE12008D for ; Thu, 16 Jan 2020 12:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[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 D5bfnlcF7dWk for ; Thu, 16 Jan 2020 12:58:31 -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 2CC9F120026 for ; Thu, 16 Jan 2020 12:58:30 -0800 (PST) Received: from [192.168.1.16] (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 00GKwQp7020150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 15:58:27 -0500 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, 16 Jan 2020 15:58:26 -0500 Cc: Torsten Lodderstedt , "txauth@ietf.org" , Dick Hardt Content-Transfer-Encoding: quoted-printable Message-Id: <5A7FEF06-954E-47B1-B3CE-AD5DE2329B52@mit.edu> References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> To: "Richard Backman, Annabelle" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 20:58:33 -0000 I think that=E2=80=99s exactly the reason =E2=80=94 the case of getting = information about the user directly from the TX endpoint is well = established. People don=E2=80=99t want to make another round trip just = to figure out who=E2=80=99s there, when a lot of time that=E2=80=99s the = first thing they care about, and then the=E2=80=99d make the = determination of whether to follow other APIs after that.=20 So if I can send you a very basic set of authn info from the callback, = like an identifier and VoT style login information, then you can figure = out if you need to know more about that user or not. But these basic = claims do get elevated to the same level as other returned artifacts = from the transaction, like the access tokens. =E2=80=94 Justin > On Jan 16, 2020, at 2:12 PM, Richard Backman, Annabelle = wrote: >=20 > The only reason I can think of to single out identity within the = charter is if there is some work or feature that is within scope for the = working group, but only for identity claims (e.g., returning identity = claims from the transaction endpoint). Repeating a question I posed = earlier, what is it about identity claims that make them worthy of = special consideration? >=20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity >=20 >=20 > =EF=BB=BFOn 1/16/20, 8:51 AM, "Justin Richer" wrote: >=20 > On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt = wrote: >>=20 >>=20 >>=20 >>> Am 16.01.2020 um 16:45 schrieb Justin Richer : >>>=20 >>> - Approval of identity claims and multiple resources in a single = interaction >>=20 >> This sounds a bit incomplete to me. I assume the user would approve = =E2=80=9Ethe attestation of identity claims=E2=80=9C. I furthermore = think the user would approve =E2=80=9Eaccess to multiple APIs=E2=80=9C. = I would prefer API over resource because it is more universal. For = example, the protocol could also be used to create resources. >=20 > Point taken, but this isn=E2=80=99t meant to be an exhaustive list = of what it can do, merely the list of things we=E2=80=99re positive we = want it to do. I also prefer =E2=80=9CAPI=E2=80=9D over =E2=80=9Cresource=E2= =80=9D, but concede that =E2=80=9Cresource=E2=80=9D can be a writeable = thing too. Even then I=E2=80=99m happy to tweak the language here.=20 >=20 > =E2=80=94 Justin >=20 From nobody Thu Jan 16 13:07: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 A689A120091 for ; Thu, 16 Jan 2020 13:07:34 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 etREreUhOR7Q for ; Thu, 16 Jan 2020 13:07:31 -0800 (PST) Received: from gateway30.websitewelcome.com (gateway30.websitewelcome.com [192.185.150.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E77120026 for ; Thu, 16 Jan 2020 13:07:31 -0800 (PST) Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway30.websitewelcome.com (Postfix) with ESMTP id 25493397D06 for ; Thu, 16 Jan 2020 15:07:31 -0600 (CST) Received: from box5207.bluehost.com ([162.241.224.194]) by cmsmtp with SMTP id sCMViZ7IQNwe7sCMVi9x83; Thu, 16 Jan 2020 15:07:31 -0600 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:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ArLAebsHDEsUdI1jFwPLxISg+4jIvYlJnHcHQqAA7Co=; b=HcEgDIjWUzNlBNDZpSlxycrB80 qD5mazEOE5phtm/p/OLlR88ffiDe2ny4COrDgtIIrc0LxHxgZKTkTbg1+zxbUdvYjXVFMsYMUcvXE 6VTE1rNAfvWUQIgEQ/eI0Ofw1; Received: from c-73-167-220-69.hsd1.ma.comcast.net ([73.167.220.69]:33489 helo=[10.0.1.5]) by box5207.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1isCMU-0037vD-Ob; Thu, 16 Jan 2020 14:07:30 -0700 User-Agent: Microsoft-MacOutlook/10.10.12.200112 Date: Thu, 16 Jan 2020 16:07:28 -0500 From: Thomas Hardjono To: Justin Richer CC: Thomas Hardjono , "txauth@ietf.org" Message-ID: Thread-Topic: [Txauth] alternative charter writeup References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <40DEDA03-58E1-46EE-A46E-15D448283762@hardjono.net> <5F952C70-8EE2-440A-9334-5FBC19CE2A5E@mit.edu> In-Reply-To: <5F952C70-8EE2-440A-9334-5FBC19CE2A5E@mit.edu> 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: 1isCMU-0037vD-Ob X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-73-167-220-69.hsd1.ma.comcast.net ([10.0.1.5]) [73.167.220.69]:33489 X-Source-Auth: ietf-txauth@hardjono.net X-Email-Count: 1 X-Source-Cap: aGFyZGpvbm87aGFyZGpvbm87Ym94NTIwNy5ibHVlaG9zdC5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 21:07:34 -0000 The problem is that the word "delegation" is generally a very loaded term. I understand that WGs need wiggle room, but I'm concerned that this kind of= loose wording may cause confusion down the road. >> What I think is very much out of scope is cross-domain policy processing= . Agree. =EF=BB=BF-----Original Message----- From: Txauth on behalf of Justin Richer Date: Thursday, January 16, 2020 at 11:54 AM To: Thomas Hardjono Cc: "hardjono@mit.edu" , "txauth@ietf.org" Subject: Re: [Txauth] alternative charter writeup On Jan 16, 2020, at 11:43 AM, Thomas Hardjono wr= ote: >=20 >=20 > Looks good, but I have a clarification question: >=20 >>>> - Delegation between multiple users >=20 > What does this mean exactly? >=20 > Is it the "multi-hop" delegation (Alice to Bob to Charlize to ...) >=20 > Or does it only the "1-hop" delegation concurrently (Alice to Bob; Alice = to Charlize; Alice to=E2=80=A6) My thinking was that at the very least we want to allow the person running = the client software and the person doing the authorization to be different p= eople. This is the UMA use case (Alice to bob) and the CIBA use case (agent = getting someone to log in). I think chaining can follow that, where Bob can = then let Charlie do something. This is also along the lines of the token exc= hange model of OAuth 2, with continuously down-scoped access. What I think is very much out of scope is cross-domain policy processing.=20 =E2=80=94 Justin >=20 > -- thomas -- >=20 >=20 >=20 > =EF=BB=BF-----Original Message----- > From: Txauth on behalf of Justin Richer > Date: Thursday, January 16, 2020 at 10:46 AM > To: "txauth@ietf.org" > Cc: "rdd@cert.org" , "Richard Backman, Annabelle" , Benjamin Kaduk , Dick Hardt > Subject: Re: [Txauth] alternative charter writeup >=20 > Here=E2=80=99s my updated text incorporating the feedback so far: >=20 >=20 > This group is chartered to develop a delegation protocol for identity, au= thorization, and API access. This protocol will allow an authorizing party t= o delegate access to client software through an authorization server. The us= e cases supported by this protocol will include widely deployed use cases cu= rrently supported by OAuth 2.0 and OpenID Connect (an extension of OAuth 2.0= ) as well as new use cases not enabled by OAuth 2.0. >=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 which is initiated by the client redirecting the use= r=E2=80=99s browser). The client will involve the authorizing party as necessary t= hrough interaction mechanisms indicated by the protocol. This decoupling avo= ids many of the security concerns and technical challenges of OAuth 2.0 as w= ell as providing a non-invasive path for supporting future types of clients = and interaction channels. >=20 >=20 > Additionally, the delegation process will allow for: >=20 >=20 > - Fine-grained specification of resource access >=20 > - Approval of identity claims and multiple resources in a single interact= ion >=20 > - Delegation between multiple users >=20 > - Web, mobile, single-page, interaction-constrained, and other types of c= lient applications >=20 >=20 > The group will define extension points for this protocol to allow for fle= xibility in areas including: >=20 >=20 > - Cryptographic agility for keys, message signatures, and proof of posses= sion=20 >=20 > - User interaction mechanisms including web and non-web methods >=20 > - Mechanisms for providing user, software, organization, and other pieces= of information used in authorization decisions >=20 > - Token presentation mechanisms and key bindings >=20 >=20 > Additionally, the group will provide mechanisms for management of the pro= tocol lifecycle including: >=20 >=20 > - Discovery of the authorization server >=20 > - Revocation of active tokens >=20 > - Query of token rights by resource servers >=20 >=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 porting from OAuth 2.0 and OpenID Connect to the new protocol w= here possible. >=20 >=20 > While the initial work will focus on using HTTP for communication between= the client and the authorization server, the working group will seek to tak= e advantage of optimization features of HTTP2 and HTTP3 where possible, and = will strive to enable simple mapping to other protocols such as COAP. >=20 >=20 >=20 >=20 >=20 > It=E2=80=99s definitely a lot, but I think we=E2=80=99ve got a good handle on what we= =E2=80=99re working on, and what the boundaries are. I think this is both too much= of an effort and too much of a break to do this in the OAuth WG, where ther= e=E2=80=99s already still plenty of work to be done. We=E2=80=99re leaning a lot on less= ons learned from the OAuth 2 world and its extensions, including OIDC and UM= A2. We=E2=80=99ve got the attention of a lot of the right people to start this as = well. >=20 > So to the AD=E2=80=99s: Ben and Roman =E2=80=94 what=E2=80=99s the next step? This should b= e a new working group and like to get it started so that we can have our fir= st meeting in Vancouver. >=20 > =E2=80=94 Justin >=20 >=20 > On Jan 14, 2020, at 12:12 AM, Dick Hardt wrote: >=20 > Sounds good to me. >=20 > On Mon, Jan 13, 2020 at 6:24 PM Justin Richer wrote: >=20 >=20 > I can get behind this kind of addition. I like Annabelle=E2=80=99s framing of i= t in terms of decoupling, and some explanation of why we=E2=80=99re doing it in re= lation to OAuth 2=E2=80=99s approach. One of the key things, to me, is that we=E2=80=99r= e making a break from OAuth 2=E2=80=99s core architecture but doing so for very sp= ecific reasons.=20 >=20 > =E2=80=94 Justin >=20 >=20 > On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle wrote: >=20 > It=E2=80=99s not just about the initial communication, though. I the key thing = to emphasize is the decoupling the protocol from delegation channels, which = addresses the aforementioned security/complexity issues and also provides a = path to support future delegation channel types without significant changes = to the protocol (unlike OAuth 2.0, where extensions like Device Flow and PAR= introduce substantial changes to the core protocol flow on both client and = AS). Since the protocol isn=E2=80=99t assuming a particular front channel, it=E2=80=99s = easier to add support for a new one. >=20 > Proposal, altered from Dick=E2=80=99s suggestion: > This group is chartered to develop a delegated identity and authorization= protocol. The use cases supported by this protocol will include widely depl= oyed use cases currently supported by OAuth 2.0, and OpenID Connect, an exte= nsion of OAuth 2.0. This protocol will be decoupled from delegation channels= such as an end user=E2=80=99s web browser and operate primarily through a channel= between the client and the authorization server, avoiding many of the secur= ity concerns and technical challenges of OAuth 2.0 and providing a non-invas= ive path for adding support for future types of clients and delegation chann= els. >=20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity >=20 >=20 >=20 > From: Dick Hardt > Date: Monday, January 13, 2020 at 4:35 PM > To: "Richard Backman, Annabelle" > Cc: Justin Richer , "txauth@ietf.org" > Subject: Re: [Txauth] alternative charter writeup >=20 >=20 >=20 > I agree, some more "why" would help a broader audience understand the mot= ivations. How about this change to the first paragraph? >=20 >=20 >=20 > This group is chartered to develop a delegated identity and authorization= protocol. The use cases supported by this protocol will include widely depl= oyed use cases currently supported by OAuth 2.0, and OpenID Connect, an exte= nsion of OAuth 2.0. In contrast to OAuth 2.0, where the protocol is initiate= d by redirecting the user's browser to an authorization server, this protoco= l will be initiated by the client directly interacting with the authorizatio= n server, which will mitigate many of the security concerns and technical ch= allenges of OAuth 2.0. >=20 >=20 >=20 >=20 >=20 > On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle wrote: >=20 >=20 > While I agree with the goals stated in this charter, if I read this from = the perspective of someone who hasn=E2=80=99t been our meetings or listened to Jus= tin=E2=80=99s presentations, I=E2=80=99m hard pressed to see what the point of this grou= p is, relative to the OAuth WG. I=E2=80=99d expect this charter to provide at leas= t a cursory explanation of what problem it is trying to solve. In this case,= the problem should be partially defined in relation to OAuth. What will thi= s WG do that the OAuth WG hasn=E2=80=99t already done or isn=E2=80=99t already doing? >=20 > How about adding something like the following to paragraph 2: >=20 > The protocol will mitigate many of the security concerns and technical ch= allenges of OAuth 2.0 by communicating over secure channels between the clie= nt and the authorization server, and minimizing the amount of information tr= ansmitted over untrusted channels. >=20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity >=20 >=20 >=20 > From: Txauth on behalf of Dick Hardt > Date: Friday, January 10, 2020 at 6:57 PM > To: Justin Richer > Cc: "txauth@ietf.org" > Subject: Re: [Txauth] alternative charter writeup >=20 >=20 >=20 > This looks even better! Thanks Justin. >=20 >=20 > What do others think of the proposed charter now?=20 >=20 >=20 > =E1=90=A7 >=20 >=20 > On Fri, Jan 10, 2020 at 12:43 PM Justin Richer wrote: >=20 >=20 > Thanks, Dick. I=E2=80=99ve been working on an updated charter based on everyone= =E2=80=99s feedback, and I was aiming to have out today anyway, so this timing is = helpful. So here=E2=80=99s my take on a new charter, incorporating some of your po= ints below:=20 >=20 >=20 >=20 > This group is chartered to develop a delegation protocol for identity, au= thorization, and API access. This protocol will allow an authorizing party t= o delegate access to client software through an authorization server. The us= e cases supported by this protocol will include widely deployed use cases cu= rrently supported by OAuth 2.0 and OpenID Connect.=20 >=20 >=20 >=20 > The delegation process will be acted upon by multiple parties in the prot= ocol, each performing a specific role. The protocol will be initiated by the= client interacting directly with the authorization server (in contrast with= OAuth 2 which is initiated by the client redirecting the user=E2=80=99s browser).= The client will involve the authorizing party as necessary through interact= ion mechanisms indicated by the protocol.=20 >=20 >=20 >=20 > Additionally, the delegation process will allow for: >=20 >=20 >=20 > - Fine-grained specification of resource access >=20 > - Approval of identity claims and multiple resources in a single interact= ion >=20 > - Delegation between multiple users >=20 > - Web, mobile, single-page, and other types of client applications >=20 >=20 >=20 > The group will define extension points for this protocol to allow for fle= xibility in areas including: >=20 >=20 >=20 > - Cryptographic agility for keys, message signatures, and proof of posses= sion=20 >=20 > - User interaction mechanisms including web and non-web methods >=20 > - Mechanisms for providing user, software, organization, and other pieces= of information used in authorization decisions >=20 > - Token presentation mechanisms and key bindings >=20 >=20 >=20 > Additionally, the group will provide mechanisms for management of the pro= tocol lifecycle including: >=20 >=20 >=20 > - Discovery of the authorization server >=20 > - Revocation of active tokens >=20 > - Query of token rights by resource servers >=20 >=20 >=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 porting from OAuth 2.0 and OpenID Connect to the new protocol w= here possible. >=20 > While the initial work will focus on using HTTP for communication between= the client and the authorization server, the working group will seek to tak= e advantage of optimization features of HTTP2 and HTTP3, and will strive to = enable simple mapping to other protocols such as COAP. >=20 >=20 >=20 >=20 >=20 > On Jan 10, 2020, at 12:04 PM, Dick Hardt wrote: >=20 >=20 > Hey >=20 >=20 > I've written an alternative charter that I hope captures some of the feed= back on Justin's charter. >=20 >=20 >=20 > I found it easier to rewrite the charter to broaden the marketplace of id= eas.=20 >=20 >=20 >=20 > Key ideas: >=20 >=20 >=20 > - This work supports existing OAuth 2.0, and OpenID Connect use cases. >=20 >=20 >=20 > - The client interacts directly with the authorization server.=20 >=20 >=20 >=20 > /Dick >=20 >=20 >=20 > ---- >=20 >=20 > This group is chartered to develop a delegated identity and authorization= protocol.. The use cases supported by this protocol will include widely dep= loyed use cases currently supported by OAuth 2.0, and OpenID Connect. In con= trast to OAuth 2.0 and OpenID Connect, where the protocol is initiated by re= directing the user's browser to an authorization server, this protocol will = be initiated by the client directly interacting with the authorization serve= r.. >=20 >=20 > Additionally, the protocol will allow: >=20 > - fine-grained specification of resource access >=20 > - the user to approve requests for identity claims and access to multiple= resources in one interaction >=20 > - web, mobile, single-page, and other client applications >=20 > - taking advantage of optimization features in HTTP2 and HTTP3 >=20 >=20 > The group will define extension points for this protocol to allow for fle= xibility in areas including: >=20 >=20 > - discovery of the authorization server >=20 > - cryptographic agility for keys, message signatures, and proof of posses= sion=20 >=20 > - user interaction mechanisms including web and non-web methods- token pr= esentation mechanisms and key bindings >=20 >=20 > Although the artifacts for this work are not intended or expected to be b= ackwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt to s= implify porting from OAuth 2.0 and OpenID Connect, and strive to reuse exist= ing semantics such as client identifiers, OAuth 2.0 scopes and access tokens= , and OpenID Connect ID Tokens and claims. >=20 >=20 > While the initial work will focus on using HTTP for communication between= the client and the authorization server, the working group will strive to e= nable simple mapping to other protocols such as COAP. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =E1=90=A7 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=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 From nobody Thu Jan 16 14:29: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 15422120086 for ; Thu, 16 Jan 2020 14:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, RCVD_IN_DNSWL_HI=-5, 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 O7P3dZoIuWgF for ; Thu, 16 Jan 2020 14:29:37 -0800 (PST) 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 7529712004A for ; Thu, 16 Jan 2020 14:29:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579213778; x=1610749778; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qFoGF9AnZSjMhQ/ByaLbsOkDqaLW07mWLd05GJpkdXU=; b=E0jj1lrCK2x5l0SBDEujtVLcGwbp/sZig9UnUDfSYBX6ISCwXwzWwHzF z8qQXDnrnwX/C04iAUMZOzRD7k8yvQzGfbXj010ioP02VXF9MfzjcFJTl zjVVIO2Bf/RpECFkgGb0KjDlVf+UsIYJBhaf/IBoGMt+oSBzAS/4C3hQ0 0=; IronPort-SDR: f7Uc1hSuue/c9Llrv69Dx/P77kSDb8zkD8rxQr9N792wyHkuxYD19cCMhnPaVWFUvVkvz0WAWK HcDL310DJU8w== X-IronPort-AV: E=Sophos;i="5.70,327,1574121600"; d="scan'208";a="10785513" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1a-807d4a99.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 16 Jan 2020 22:29:26 +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-807d4a99.us-east-1.amazon.com (Postfix) with ESMTPS id 934CCA315F; Thu, 16 Jan 2020 22:29:25 +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; Thu, 16 Jan 2020 22:29:24 +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.1367.3; Thu, 16 Jan 2020 22:29:24 +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.1367.000; Thu, 16 Jan 2020 22:29:24 +0000 From: "Richard Backman, Annabelle" To: Justin Richer CC: Torsten Lodderstedt , "txauth@ietf.org" , Dick Hardt Thread-Topic: [Txauth] alternative charter writeup Thread-Index: AQHVx9g9cyOj1MRzqU6+3+Goa7VakafkXaAAgABoEICAA/l4gIAAld0A//+QawCAAI5HAIAALucAgAPVjwCAAAhfAIAAChsA//+hWgCAAKOzAP//k04A Date: Thu, 16 Jan 2020 22:29:24 +0000 Message-ID: <7A4FC2A4-9960-4A75-847C-0477FE81DB4F@amazon.com> References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> <5A7FEF06-954E-47B1-B3CE-AD5DE2329B52@mit.edu> In-Reply-To: <5A7FEF06-954E-47B1-B3CE-AD5DE2329B52@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.95] Content-Type: text/plain; charset="utf-8" Content-ID: <9053AE562C422046AE6CFB60899A037A@amazon.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 22:29:39 -0000 VGhlIHNhbWUgY291bGQgYmUgc2FpZCBmb3IgYW55IHJlc291cmNlLCBwYXJ0aWN1bGFybHkgaW4g c2NlbmFyaW9zIHdoZXJlIHRoZSBpbnRlcmFjdGlvbiB3YXMga2lja2VkIG9mZiBzbyB0aGF0IHRo ZSBTUCBjYW4gcGVyZm9ybSBhIHNwZWNpZmljIGFjdGlvbiBpbml0aWF0ZWQgYnkgdGhlIHVzZXIg KGUuZy4sIGNoYXJnaW5nIGEgY3JlZGl0IGNhcmQgb3IgYWNjb3VudCwgcHVibGlzaGluZyBhIG1l c3NhZ2UgdG8gYSBtZXNzYWdlIGJvYXJkIG9yIHNvY2lhbCBtZWRpYSBmZWVkLCByZXRyaWV2aW5n IGEgc3BlY2lmaWMgZG9jdW1lbnQgb3IgaW1hZ2UpLg0KDQpDb25zaWRlciBhIGZsb3cgbGlrZSB0 aGUgZm9sbG93aW5nOg0KMS4gVGhlIGVuZCB1c2VyIGlzIG9uIGEgY2xpZW50IHdlYnNpdGUgdGhh dCBwcm92aWRlcyBhIHBob3RvIHByaW50aW5nIHNlcnZpY2UsIGNsaWNrcyB0aGUgIlByaW50IGZy b20gQ2xvdWRTdG9yYWdlUHJvdmlkZXIiIGJ1dHRvbi4NCjQuIFRoZSBjbGllbnQgaW5pdGF0ZXMg VHhBdXRoIHZpYSBDbG91ZFN0b3JhZ2VQcm92aWRlcidzIHRyYW5zYWN0aW9uIGVuZHBvaW50LCBy ZXF1ZXN0aW5nIGEgVVJMIGZvciBhIHBob3RvIHRvIGJlIHNlbGVjdGVkIGJ5IHRoZSBlbmQgdXNl ci4NCjUuIENsb3VkU3RvcmFnZVByb3ZpZGVyIHJldHVybnMgYW4gaW50ZXJhY3RfdXJsIHBvaW50 aW5nIHRvIGl0cyBBUy4NCjYuIFRoZSBjbGllbnQgcmVkaXJlY3RzIHRoZSB1c2VyIGFnZW50IHRv IHRoZSBBUy4NCjcuIFRoZSBlbmQgdXNlciBzaWducyBpbiwgYW5kIHNlbGVjdHMgdGhlIHBob3Rv IHRoZXkgd2FudCB0byBwcmludCwgYW5kIGNvbmZpcm1zIGF1dGhvcml6YXRpb24gdG8gc2hhcmUg d2l0aCB0aGUgY2xpZW50Lg0KOC4gVGhlIEFTIHJlZGlyZWN0cyB0aGUgdXNlciBhZ2VudCBiYWNr IHRvIGNsaWVudC4NCjkuIFRoZSBjbGllbnQgY2FsbHMgYmFjayB0byBDbG91ZFN0b3JhZ2VQcm92 aWRlcidzIHRyYW5zYWN0aW9uIGVuZHBvaW50IHRvIGNvbnRpbnVlIHRoZSBUeEF1dGggdHJhbnNh Y3Rpb24uDQoxMC4gQ2xvdWRTdG9yYWdlUHJvdmlkZXIgcmV0dXJucyBjb25maXJtYXRpb24gdGhh dCB0aGUgYXV0aG9yaXphdGlvbiB3YXMgZ3JhbnRlZCwgYWxvbmcgd2l0aCB0aGUgVVJMIGZvciB0 aGUgc2VsZWN0ZWQgcGhvdG8uDQoNClRoaXMgaXMgaWRlbnRpY2FsIHRvIHRoZSBpZGVudGl0eSB1 c2UgY2FzZSwgd2UndmUganVzdCByZXBsYWNlZCBpZGVudGl0eSBjbGFpbXMgd2l0aCBhIFVSTCB0 byBhIHBob3RvLiBJIHNlZSBhIGxvdCBvZiB2YWx1ZSBpbiBlbmNvdXJhZ2luZyBvbmUtdGltZSBh dXRob3JpemF0aW9uIG9mIHNwZWNpZmljIGFjdGlvbnMgbGlrZSB0aGlzLCBhbmQgaWYgd2UncmUg Z29pbmcgdG8gc3VwcG9ydCBpbmxpbmluZyBvZiByZXNvdXJjZXMgZm9yIGlkZW50aXR5IGNsYWlt cyBhbnl3YXksIGl0J3Mgbm90IGEgYmlnIHN0cmV0Y2ggdG8gYWxsb3cgZm9yIGFyYml0cmFyeSBy ZXNvdXJjZSB0eXBlcy4gSSBkbyB0aGluayBpdCdzIGZhaXIgdG8gbmFycm93bHkgc2NvcGUgdGhl IGtpbmRzIG9mIHJlc291cmNlICpzY2hlbWFzKiB0aGUgV0cgd2lsbCBkZWZpbmUgKGUuZy4sIGRl ZmluaW5nIGNvcmUgaWRlbnRpdHkgY2xhaW1zIGxpa2UgT0lEQyBkaWQpLCBidXQgdGhlIGlubGlu aW5nIG1lY2hhbmlzbSBzaG91bGQgYmUgZmxleGlibGUgKGUuZy4sIG5vdCBsaW1pdGluZyB0aGlz IHRvIGNsYWltcyBhYm91dCB0aGUgZW5kIHVzZXIgaWRlbnRpdHksIGxpa2UgT0lEQyBkaWQpLg0K DQrigJMgDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCiANCg0K77u/ T24gMS8xNi8yMCwgMTI6NTkgUE0sICJUeGF1dGggb24gYmVoYWxmIG9mIEp1c3RpbiBSaWNoZXIi IDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YganJpY2hlckBtaXQuZWR1PiB3 cm90ZToNCg0KICAgIEkgdGhpbmsgdGhhdOKAmXMgZXhhY3RseSB0aGUgcmVhc29uIOKAlCB0aGUg Y2FzZSBvZiBnZXR0aW5nIGluZm9ybWF0aW9uIGFib3V0IHRoZSB1c2VyIGRpcmVjdGx5IGZyb20g dGhlIFRYIGVuZHBvaW50IGlzIHdlbGwgZXN0YWJsaXNoZWQuIFBlb3BsZSBkb27igJl0IHdhbnQg dG8gbWFrZSBhbm90aGVyIHJvdW5kIHRyaXAganVzdCB0byBmaWd1cmUgb3V0IHdob+KAmXMgdGhl cmUsIHdoZW4gYSBsb3Qgb2YgdGltZSB0aGF04oCZcyB0aGUgZmlyc3QgdGhpbmcgdGhleSBjYXJl IGFib3V0LCBhbmQgdGhlbiB0aGXigJlkIG1ha2UgdGhlIGRldGVybWluYXRpb24gb2Ygd2hldGhl ciB0byBmb2xsb3cgb3RoZXIgQVBJcyBhZnRlciB0aGF0LiANCiAgICANCiAgICBTbyBpZiBJIGNh biBzZW5kIHlvdSBhIHZlcnkgYmFzaWMgc2V0IG9mIGF1dGhuIGluZm8gZnJvbSB0aGUgY2FsbGJh Y2ssIGxpa2UgYW4gaWRlbnRpZmllciBhbmQgVm9UIHN0eWxlIGxvZ2luIGluZm9ybWF0aW9uLCB0 aGVuIHlvdSBjYW4gZmlndXJlIG91dCBpZiB5b3UgbmVlZCB0byBrbm93IG1vcmUgYWJvdXQgdGhh dCB1c2VyIG9yIG5vdC4gQnV0IHRoZXNlIGJhc2ljIGNsYWltcyBkbyBnZXQgZWxldmF0ZWQgdG8g dGhlIHNhbWUgbGV2ZWwgYXMgb3RoZXIgcmV0dXJuZWQgYXJ0aWZhY3RzIGZyb20gdGhlIHRyYW5z YWN0aW9uLCBsaWtlIHRoZSBhY2Nlc3MgdG9rZW5zLg0KICAgIA0KICAgICDigJQgSnVzdGluDQog ICAgDQogICAgPiBPbiBKYW4gMTYsIDIwMjAsIGF0IDI6MTIgUE0sIFJpY2hhcmQgQmFja21hbiwg QW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4gVGhl IG9ubHkgcmVhc29uIEkgY2FuIHRoaW5rIG9mIHRvIHNpbmdsZSBvdXQgaWRlbnRpdHkgd2l0aGlu IHRoZSBjaGFydGVyIGlzIGlmIHRoZXJlIGlzIHNvbWUgd29yayBvciBmZWF0dXJlIHRoYXQgaXMg d2l0aGluIHNjb3BlIGZvciB0aGUgd29ya2luZyBncm91cCwgYnV0IG9ubHkgZm9yIGlkZW50aXR5 IGNsYWltcyAoZS5nLiwgcmV0dXJuaW5nIGlkZW50aXR5IGNsYWltcyBmcm9tIHRoZSB0cmFuc2Fj dGlvbiBlbmRwb2ludCkuIFJlcGVhdGluZyBhIHF1ZXN0aW9uIEkgcG9zZWQgZWFybGllciwgd2hh dCBpcyBpdCBhYm91dCBpZGVudGl0eSBjbGFpbXMgdGhhdCBtYWtlIHRoZW0gd29ydGh5IG9mIHNw ZWNpYWwgY29uc2lkZXJhdGlvbj8NCiAgICA+IA0KICAgID4g4oCTIA0KICAgID4gQW5uYWJlbGxl IFJpY2hhcmQgQmFja21hbg0KICAgID4gQVdTIElkZW50aXR5DQogICAgPiANCiAgICA+IA0KICAg ID4gT24gMS8xNi8yMCwgODo1MSBBTSwgIkp1c3RpbiBSaWNoZXIiIDxqcmljaGVyQG1pdC5lZHU+ IHdyb3RlOg0KICAgID4gDQogICAgPiAgICBPbiBKYW4gMTYsIDIwMjAsIGF0IDExOjE1IEFNLCBU b3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6DQogICAg Pj4gDQogICAgPj4gDQogICAgPj4gDQogICAgPj4+IEFtIDE2LjAxLjIwMjAgdW0gMTY6NDUgc2No cmllYiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+Og0KICAgID4+PiANCiAgICA+Pj4g LSBBcHByb3ZhbCBvZiBpZGVudGl0eSBjbGFpbXMgYW5kIG11bHRpcGxlIHJlc291cmNlcyBpbiBh IHNpbmdsZSBpbnRlcmFjdGlvbg0KICAgID4+IA0KICAgID4+IFRoaXMgc291bmRzIGEgYml0IGlu Y29tcGxldGUgdG8gbWUuIEkgYXNzdW1lIHRoZSB1c2VyIHdvdWxkIGFwcHJvdmUg4oCedGhlIGF0 dGVzdGF0aW9uIG9mIGlkZW50aXR5IGNsYWltc+KAnC4gSSBmdXJ0aGVybW9yZSB0aGluayB0aGUg dXNlciB3b3VsZCBhcHByb3ZlIOKAnmFjY2VzcyB0byBtdWx0aXBsZSBBUElz4oCcLiBJIHdvdWxk IHByZWZlciBBUEkgb3ZlciByZXNvdXJjZSBiZWNhdXNlIGl0IGlzIG1vcmUgdW5pdmVyc2FsLiBG b3IgZXhhbXBsZSwgdGhlIHByb3RvY29sIGNvdWxkIGFsc28gYmUgdXNlZCB0byBjcmVhdGUgcmVz b3VyY2VzLg0KICAgID4gDQogICAgPiAgICBQb2ludCB0YWtlbiwgYnV0IHRoaXMgaXNu4oCZdCBt ZWFudCB0byBiZSBhbiBleGhhdXN0aXZlIGxpc3Qgb2Ygd2hhdCBpdCBjYW4gZG8sIG1lcmVseSB0 aGUgbGlzdCBvZiB0aGluZ3Mgd2XigJlyZSBwb3NpdGl2ZSB3ZSB3YW50IGl0IHRvIGRvLiBJIGFs c28gcHJlZmVyIOKAnEFQSeKAnSBvdmVyIOKAnHJlc291cmNl4oCdLCBidXQgY29uY2VkZSB0aGF0 IOKAnHJlc291cmNl4oCdIGNhbiBiZSBhIHdyaXRlYWJsZSB0aGluZyB0b28uIEV2ZW4gdGhlbiBJ 4oCZbSBoYXBweSB0byB0d2VhayB0aGUgbGFuZ3VhZ2UgaGVyZS4gDQogICAgPiANCiAgICA+ICAg ICDigJQgSnVzdGluDQogICAgPiANCiAgICANCiAgICAtLSANCiAgICBUeGF1dGggbWFpbGluZyBs aXN0DQogICAgVHhhdXRoQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90eGF1dGgNCiAgICANCg0K From nobody Thu Jan 16 14:31: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 2BC921200B1 for ; Thu, 16 Jan 2020 14:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 o0CXvLYQp179 for ; Thu, 16 Jan 2020 14:31:31 -0800 (PST) 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 C0A7C12004A for ; Thu, 16 Jan 2020 14:31:30 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id w1so24390299ljh.5 for ; Thu, 16 Jan 2020 14:31:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w1Ie5ec/pgdjc73ypo6verTvYqz0KJ8/8qhV3+Ea5zI=; b=r90zi76GsqEwSoNaMWW+HhZ4eqiWNBUxHWeM6MLFwLh272dktyb9MGgAl3chEdtMPu lgld9/BI/jkOHfANoeuGMKxGkqsdMnqjRq4+K+O3YLw1E0T7Aqcx0TtUTnr1ivV0NxLz K6aRpvHSQPG0TGGt/MR9DHV6eZMxmdO12CpfDod9ZeFySPlosq/F1jvBMIrcgVPAFf+A zkGIrCTutvL7nqjNXdjjwcKTppraCWyVPKpSfr3GE94IhpW8jSJELZtfOhJWtFFypK1Q nGeAlLM0G8xtufP0tnLm49yUCRxrVhLd76u7kJtyTrmxDc5wYUrIMo34hNZn4r0RtD45 nsCw== 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=w1Ie5ec/pgdjc73ypo6verTvYqz0KJ8/8qhV3+Ea5zI=; b=o/tuBVYm8G4P/1PGKkgTEljyRpK1tTtlbeHxHXcSuGrTWtiZvnmSgLKiC2J56DjKpz jm3lvsBdLzIUUpJueeyFvlIqte3z6XBcP6SlhqARg/w5mewc2Y2a+xeg+yE0TCBiicuK UJrI4Spo/c2cdmupQyJ29k1C9CwHtIuKFeM78+vkaq/NbBHtwQDwHj/xamHxZ6FoyEmC o7h+pWNAGISnlZTs6gWkJN1UQubgMtl+6ucWrNWwFH1977grJypCe5gMUZkA0flN+RTE nlM3ewH9L9pmJ9DUJ9A5bRs68jdrB/lNA+0oiBLKF3i0GNGWWn1FlYg+YLekoB2GeirG 5v2Q== X-Gm-Message-State: APjAAAV/+W9EwE2SUKzqV6pN0tR+O6EYHzMmy4VYLXa/bDy3uzLcHFF1 SEL2FnHvXE7bwO8azli9piOznkdbo4IT7oDBHFw= X-Google-Smtp-Source: APXvYqxDpdAMSGhQZbfLCqB5ZygV5giwgQ5SYOE9Qv44fdgDBGle7GRwOShEf9FlcB9TZTXyOngDmZF1CZv9NzZlwA8= X-Received: by 2002:a2e:7505:: with SMTP id q5mr3742212ljc.7.1579213888817; Thu, 16 Jan 2020 14:31:28 -0800 (PST) MIME-Version: 1.0 References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> In-Reply-To: <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> From: Dick Hardt Date: Thu, 16 Jan 2020 14:31:17 -0800 Message-ID: To: Torsten Lodderstedt Cc: Justin Richer , "txauth@ietf.org" , "rdd@cert.org" , "Richard Backman, Annabelle" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000de1ade059c4962d7" Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 22:31:32 -0000 --000000000000de1ade059c4962d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think of the resource as a container that has certain capabilities. An early use case for delegation was for access to Flickr photos. Write access to upload new photos was a capability. An example of a resource without an API is where the client is also the resource, and has delegated authorization to the AS. For example, you can imagine a photo copier where you scan a QR code that send you to an AS that then returns an artifact to the client how the user is authorized to use the photo copier. =E1=90=A7 On Thu, Jan 16, 2020 at 8:15 AM Torsten Lodderstedt wrote: > > > > Am 16.01.2020 um 16:45 schrieb Justin Richer : > > > > - Approval of identity claims and multiple resources in a single > interaction > > This sounds a bit incomplete to me. I assume the user would approve =E2= =80=9Ethe > attestation of identity claims=E2=80=9C. I furthermore think the user wou= ld approve > =E2=80=9Eaccess to multiple APIs=E2=80=9C. I would prefer API over resour= ce because it is > more universal. For example, the protocol could also be used to create > resources. --000000000000de1ade059c4962d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think of the resource as a container that has certain ca= pabilities. An early use case for delegation was for access to Flickr photo= s. Write access to upload new photos was a capability.=C2=A0

=
An example of a resource without an API is where the client is also th= e resource, and has delegated authorization to the AS. For example, you can= imagine a photo copier where you scan a QR code that send you to an AS tha= t then returns an artifact to the client how the user is authorized to use = the photo copier.=C2=A0=C2=A0
3D""=E1=90=A7
On Thu, J= an 16, 2020 at 8:15 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


> Am 16.01.2020 um 16:45 schrieb Justin Richer <jricher@mit.edu>:
>
> - Approval of identity claims and multiple resources in a single inter= action

This sounds a bit incomplete to me. I assume the user would approve =E2=80= =9Ethe attestation of identity claims=E2=80=9C. I furthermore think the use= r would approve =E2=80=9Eaccess to multiple APIs=E2=80=9C. I would prefer A= PI over resource because it is more universal. For example, the protocol co= uld also be used to create resources.
--000000000000de1ade059c4962d7-- From nobody Thu Jan 16 14:49: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 955DC1200B1 for ; Thu, 16 Jan 2020 14:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[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 ZOmYoMcjszHj for ; Thu, 16 Jan 2020 14:49:52 -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 8275B120099 for ; Thu, 16 Jan 2020 14:49:52 -0800 (PST) Received: from [192.168.1.16] (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 00GMnm25022551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 17:49:48 -0500 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: <7A4FC2A4-9960-4A75-847C-0477FE81DB4F@amazon.com> Date: Thu, 16 Jan 2020 17:49:47 -0500 Cc: Torsten Lodderstedt , "txauth@ietf.org" , Dick Hardt Content-Transfer-Encoding: quoted-printable Message-Id: <00C978A2-E4B1-4EEB-BA0E-5FF0A9B871F0@mit.edu> References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> <5A7FEF06-954E-47B1-B3CE-AD5DE2329B52@mit.edu> <7A4FC2A4-9960-4A75-847C-0477FE81DB4F@amazon.com> To: "Richard Backman, Annabelle" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 22:49:55 -0000 I=E2=80=99m cautiously Ok with having resource inlining be in scope =E2=80= =94 IF we can generalize it from the identity case specifically. To do what you=E2=80=99re asking for though, the WG can still be = chartered to solve identity (which we know is a well-established and = understood use case), but also allow other things.=20 This gets back to a fundamental question that I don=E2=80=99t have a = clear answer for yet: what do you get back at the end of a transaction? = Right now we=E2=80=99ve got a clear call for three things: 1. Access tokens to call APIs 2. Transaction handles to continue the transaction later (like a refresh = token but better) 3. User identity claims Maybe the mechanism we use for #3 can be generalized, or maybe there=E2=80= =99s even a good way to provide switches for #1, #2, and #3.=20 And while we=E2=80=99re on the topic of #3, I think there=E2=80=99s a = strong case to be made that it should NOT be a user=E2=80=99s profile = information, but rather just enough information to identify the user to = the RP. If the RP wants to pull more profile info, it can do so via an = API. This keeps us out of the anti-pattern that SAML has of always = sending all claims about a user whether the RP needs them or not. But = the RP will at least need to know if it has to request the claims, and = we can do that by a simple enough structure like: user: { =E2=80=9Ciss=E2=80=9D: =E2=80=9Chttp://foo.bar/=E2=80=9C, =E2=80=9Csub=E2=80=9D: =E2=80=9C12387yhjfre=E2=80=9D, =E2=80=9Clast_updated=E2=80=9D: 54239084 } You can add VoT and other things that can vary per-login here as well. = But I shouldn=E2=80=99t be sending you the user=E2=80=99s name and = address every time they log in =E2=80=94 as an RP you only need to get = that if it=E2=80=99s a new account or if it=E2=80=99s been updated since = you last saw it. You can=E2=80=99t handle that if you=E2=80=99re pushing = all the claims in the response: Since the RP doesn=E2=80=99t know who = the user is until after this stage, it can=E2=80=99t tell that = information to the IdP ahead of time and therefore the IdP is forced to = always send it just in case the RP might need it. But by telling the RP = an identifier for the user and a tag of when any of their information = was last updated I can make the decision whether or not to pull = information at the RP in an intelligent fashion if I want to. =E2=80=94 Justin > On Jan 16, 2020, at 5:29 PM, Richard Backman, Annabelle = wrote: >=20 > The same could be said for any resource, particularly in scenarios = where the interaction was kicked off so that the SP can perform a = specific action initiated by the user (e.g., charging a credit card or = account, publishing a message to a message board or social media feed, = retrieving a specific document or image). >=20 > Consider a flow like the following: > 1. The end user is on a client website that provides a photo printing = service, clicks the "Print from CloudStorageProvider" button. > 4. The client initates TxAuth via CloudStorageProvider's transaction = endpoint, requesting a URL for a photo to be selected by the end user. > 5. CloudStorageProvider returns an interact_url pointing to its AS. > 6. The client redirects the user agent to the AS. > 7. The end user signs in, and selects the photo they want to print, = and confirms authorization to share with the client. > 8. The AS redirects the user agent back to client. > 9. The client calls back to CloudStorageProvider's transaction = endpoint to continue the TxAuth transaction. > 10. CloudStorageProvider returns confirmation that the authorization = was granted, along with the URL for the selected photo. >=20 > This is identical to the identity use case, we've just replaced = identity claims with a URL to a photo. I see a lot of value in = encouraging one-time authorization of specific actions like this, and if = we're going to support inlining of resources for identity claims anyway, = it's not a big stretch to allow for arbitrary resource types. I do think = it's fair to narrowly scope the kinds of resource *schemas* the WG will = define (e.g., defining core identity claims like OIDC did), but the = inlining mechanism should be flexible (e.g., not limiting this to claims = about the end user identity, like OIDC did). >=20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity >=20 >=20 > =EF=BB=BFOn 1/16/20, 12:59 PM, "Txauth on behalf of Justin Richer" = wrote: >=20 > I think that=E2=80=99s exactly the reason =E2=80=94 the case of = getting information about the user directly from the TX endpoint is well = established. People don=E2=80=99t want to make another round trip just = to figure out who=E2=80=99s there, when a lot of time that=E2=80=99s the = first thing they care about, and then the=E2=80=99d make the = determination of whether to follow other APIs after that.=20 >=20 > So if I can send you a very basic set of authn info from the = callback, like an identifier and VoT style login information, then you = can figure out if you need to know more about that user or not. But = these basic claims do get elevated to the same level as other returned = artifacts from the transaction, like the access tokens. >=20 > =E2=80=94 Justin >=20 >> On Jan 16, 2020, at 2:12 PM, Richard Backman, Annabelle = wrote: >>=20 >> The only reason I can think of to single out identity within the = charter is if there is some work or feature that is within scope for the = working group, but only for identity claims (e.g., returning identity = claims from the transaction endpoint). Repeating a question I posed = earlier, what is it about identity claims that make them worthy of = special consideration? >>=20 >> =E2=80=93=20 >> Annabelle Richard Backman >> AWS Identity >>=20 >>=20 >> On 1/16/20, 8:51 AM, "Justin Richer" wrote: >>=20 >> On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt = wrote: >>>=20 >>>=20 >>>=20 >>>> Am 16.01.2020 um 16:45 schrieb Justin Richer : >>>>=20 >>>> - Approval of identity claims and multiple resources in a single = interaction >>>=20 >>> This sounds a bit incomplete to me. I assume the user would approve = =E2=80=9Ethe attestation of identity claims=E2=80=9C. I furthermore = think the user would approve =E2=80=9Eaccess to multiple APIs=E2=80=9C. = I would prefer API over resource because it is more universal. For = example, the protocol could also be used to create resources. >>=20 >> Point taken, but this isn=E2=80=99t meant to be an exhaustive list = of what it can do, merely the list of things we=E2=80=99re positive we = want it to do. I also prefer =E2=80=9CAPI=E2=80=9D over =E2=80=9Cresource=E2= =80=9D, but concede that =E2=80=9Cresource=E2=80=9D can be a writeable = thing too. Even then I=E2=80=99m happy to tweak the language here.=20 >>=20 >> =E2=80=94 Justin >>=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >=20 >=20 From nobody Thu Jan 16 14:50: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 47BBE120099 for ; Thu, 16 Jan 2020 14:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[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 jHX9iDzGQSGo for ; Thu, 16 Jan 2020 14:50:47 -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 470191200B4 for ; Thu, 16 Jan 2020 14:50:47 -0800 (PST) Received: from [192.168.1.16] (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 00GMnm26022551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 17:50:34 -0500 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, 16 Jan 2020 17:50:34 -0500 Cc: Thomas Hardjono , "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <301ADD9B-CCC9-447D-B652-EB377961FBD6@mit.edu> References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <40DEDA03-58E1-46EE-A46E-15D448283762@hardjono.net> <5F952C70-8EE2-440A-9334-5FBC19CE2A5E@mit.edu> To: Thomas Hardjono X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 22:50:50 -0000 I get that, but that=E2=80=99s why the proposed charter text tries to be = very explicit about who is delegating to whom (or what) and for what = purpose. That=E2=80=99s why delegation to software and delegation = between users are both listed separately.=20 =E2=80=94 Justin > On Jan 16, 2020, at 4:07 PM, Thomas Hardjono = wrote: >=20 > The problem is that the word "delegation" is generally a very loaded = term. >=20 > I understand that WGs need wiggle room, but I'm concerned that this = kind of loose wording may cause confusion down the road. >=20 >=20 >=20 >>> What I think is very much out of scope is cross-domain policy = processing. >=20 > Agree. >=20 >=20 >=20 > =EF=BB=BF-----Original Message----- > From: Txauth on behalf of Justin Richer = > Date: Thursday, January 16, 2020 at 11:54 AM > To: Thomas Hardjono > Cc: "hardjono@mit.edu" , "txauth@ietf.org" = > Subject: Re: [Txauth] alternative charter writeup >=20 > On Jan 16, 2020, at 11:43 AM, Thomas Hardjono = wrote: >>=20 >>=20 >> Looks good, but I have a clarification question: >>=20 >>>>> - Delegation between multiple users >>=20 >> What does this mean exactly? >>=20 >> Is it the "multi-hop" delegation (Alice to Bob to Charlize to ...) >>=20 >> Or does it only the "1-hop" delegation concurrently (Alice to Bob; = Alice to Charlize; Alice to=E2=80=A6) >=20 > My thinking was that at the very least we want to allow the person = running the client software and the person doing the authorization to be = different people. This is the UMA use case (Alice to bob) and the CIBA = use case (agent getting someone to log in). I think chaining can follow = that, where Bob can then let Charlie do something. This is also along = the lines of the token exchange model of OAuth 2, with continuously = down-scoped access. >=20 > What I think is very much out of scope is cross-domain policy = processing.=20 >=20 > =E2=80=94 Justin >=20 >>=20 >> -- thomas -- >>=20 >>=20 >>=20 >> =EF=BB=BF-----Original Message----- >> From: Txauth on behalf of Justin Richer = >> Date: Thursday, January 16, 2020 at 10:46 AM >> To: "txauth@ietf.org" >> Cc: "rdd@cert.org" , "Richard Backman, Annabelle" = , Benjamin Kaduk , Dick Hardt = >> Subject: Re: [Txauth] alternative charter writeup >>=20 >> Here=E2=80=99s my updated text incorporating the feedback so far: >>=20 >>=20 >> This group is chartered to develop a delegation protocol for = identity, authorization, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0 and = OpenID Connect (an extension of OAuth 2.0) as well as new use cases not = enabled by OAuth 2.0. >>=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 which is initiated by = the client redirecting the user=E2=80=99s browser). The client will = involve the authorizing party as necessary through interaction = mechanisms indicated by the protocol. This decoupling avoids many of the = security concerns and technical challenges of OAuth 2.0 as well as = providing a non-invasive path for supporting future types of clients and = interaction channels. >>=20 >>=20 >> Additionally, the delegation process will allow for: >>=20 >>=20 >> - Fine-grained specification of resource access >>=20 >> - Approval of identity claims and multiple resources in a single = interaction >>=20 >> - Delegation between multiple users >>=20 >> - Web, mobile, single-page, interaction-constrained, and other types = of client applications >>=20 >>=20 >> The group will define extension points for this protocol to allow for = flexibility in areas including: >>=20 >>=20 >> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >>=20 >> - User interaction mechanisms including web and non-web methods >>=20 >> - Mechanisms for providing user, software, organization, and other = pieces of information used in authorization decisions >>=20 >> - Token presentation mechanisms and key bindings >>=20 >>=20 >> Additionally, the group will provide mechanisms for management of the = protocol lifecycle including: >>=20 >>=20 >> - Discovery of the authorization server >>=20 >> - Revocation of active tokens >>=20 >> - Query of token rights by resource servers >>=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 porting from OAuth 2.0 and OpenID Connect to the new = protocol where possible. >>=20 >>=20 >> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3 where = possible, and will strive to enable simple mapping to other protocols = such as COAP. >>=20 >>=20 >>=20 >>=20 >>=20 >> It=E2=80=99s definitely a lot, but I think we=E2=80=99ve got a good = handle on what we=E2=80=99re working on, and what the boundaries are. I = think this is both too much of an effort and too much of a break to do = this in the OAuth WG, where there=E2=80=99s already still plenty of work = to be done. We=E2=80=99re leaning a lot on lessons learned from the = OAuth 2 world and its extensions, including OIDC and UMA2. We=E2=80=99ve = got the attention of a lot of the right people to start this as well. >>=20 >> So to the AD=E2=80=99s: Ben and Roman =E2=80=94 what=E2=80=99s the = next step? This should be a new working group and like to get it started = so that we can have our first meeting in Vancouver. >>=20 >> =E2=80=94 Justin >>=20 >>=20 >> On Jan 14, 2020, at 12:12 AM, Dick Hardt = wrote: >>=20 >> Sounds good to me. >>=20 >> On Mon, Jan 13, 2020 at 6:24 PM Justin Richer = wrote: >>=20 >>=20 >> I can get behind this kind of addition. I like Annabelle=E2=80=99s = framing of it in terms of decoupling, and some explanation of why = we=E2=80=99re doing it in relation to OAuth 2=E2=80=99s approach. One of = the key things, to me, is that we=E2=80=99re making a break from OAuth = 2=E2=80=99s core architecture but doing so for very specific reasons.=20 >>=20 >> =E2=80=94 Justin >>=20 >>=20 >> On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle = wrote: >>=20 >> It=E2=80=99s not just about the initial communication, though. I the = key thing to emphasize is the decoupling the protocol from delegation = channels, which addresses the aforementioned security/complexity issues = and also provides a path to support future delegation channel types = without significant changes to the protocol (unlike OAuth 2.0, where = extensions like Device Flow and PAR introduce substantial changes to the = core protocol flow on both client and AS). Since the protocol isn=E2=80=99= t assuming a particular front channel, it=E2=80=99s easier to add = support for a new one. >>=20 >> Proposal, altered from Dick=E2=80=99s suggestion: >> This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. This protocol will be = decoupled from delegation channels such as an end user=E2=80=99s web = browser and operate primarily through a channel between the client and = the authorization server, avoiding many of the security concerns and = technical challenges of OAuth 2.0 and providing a non-invasive path for = adding support for future types of clients and delegation channels. >>=20 >> =E2=80=93=20 >> Annabelle Richard Backman >> AWS Identity >>=20 >>=20 >>=20 >> From: Dick Hardt >> Date: Monday, January 13, 2020 at 4:35 PM >> To: "Richard Backman, Annabelle" >> Cc: Justin Richer , "txauth@ietf.org" = >> Subject: Re: [Txauth] alternative charter writeup >>=20 >>=20 >>=20 >> I agree, some more "why" would help a broader audience understand the = motivations. How about this change to the first paragraph? >>=20 >>=20 >>=20 >> This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. In contrast to OAuth 2.0, = where the protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server, which will mitigate = many of the security concerns and technical challenges of OAuth 2.0. >>=20 >>=20 >>=20 >>=20 >>=20 >> On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle = wrote: >>=20 >>=20 >> While I agree with the goals stated in this charter, if I read this = from the perspective of someone who hasn=E2=80=99t been our meetings or = listened to Justin=E2=80=99s presentations, I=E2=80=99m hard pressed to = see what the point of this group is, relative to the OAuth WG. I=E2=80=99d= expect this charter to provide at least a cursory explanation of what = problem it is trying to solve. In this case, the problem should be = partially defined in relation to OAuth. What will this WG do that the = OAuth WG hasn=E2=80=99t already done or isn=E2=80=99t already doing? >>=20 >> How about adding something like the following to paragraph 2: >>=20 >> The protocol will mitigate many of the security concerns and = technical challenges of OAuth 2.0 by communicating over secure channels = between the client and the authorization server, and minimizing the = amount of information transmitted over untrusted channels. >>=20 >> =E2=80=93=20 >> Annabelle Richard Backman >> AWS Identity >>=20 >>=20 >>=20 >> From: Txauth on behalf of Dick Hardt = >> Date: Friday, January 10, 2020 at 6:57 PM >> To: Justin Richer >> Cc: "txauth@ietf.org" >> Subject: Re: [Txauth] alternative charter writeup >>=20 >>=20 >>=20 >> This looks even better! Thanks Justin. >>=20 >>=20 >> What do others think of the proposed charter now?=20 >>=20 >>=20 >> =E1=90=A7 >>=20 >>=20 >> On Fri, Jan 10, 2020 at 12:43 PM Justin Richer = wrote: >>=20 >>=20 >> Thanks, Dick. I=E2=80=99ve been working on an updated charter based = on everyone=E2=80=99s feedback, and I was aiming to have out today = anyway, so this timing is helpful. So here=E2=80=99s my take on a new = charter, incorporating some of your points below:=20 >>=20 >>=20 >>=20 >> This group is chartered to develop a delegation protocol for = identity, authorization, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0 and = OpenID Connect.=20 >>=20 >>=20 >>=20 >> The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will be = initiated by the client interacting directly with the authorization = server (in contrast with OAuth 2 which is initiated by the client = redirecting the user=E2=80=99s browser). The client will involve the = authorizing party as necessary through interaction mechanisms indicated = by the protocol.=20 >>=20 >>=20 >>=20 >> Additionally, the delegation process will allow for: >>=20 >>=20 >>=20 >> - Fine-grained specification of resource access >>=20 >> - Approval of identity claims and multiple resources in a single = interaction >>=20 >> - Delegation between multiple users >>=20 >> - Web, mobile, single-page, and other types of client applications >>=20 >>=20 >>=20 >> The group will define extension points for this protocol to allow for = flexibility in areas including: >>=20 >>=20 >>=20 >> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >>=20 >> - User interaction mechanisms including web and non-web methods >>=20 >> - Mechanisms for providing user, software, organization, and other = pieces of information used in authorization decisions >>=20 >> - Token presentation mechanisms and key bindings >>=20 >>=20 >>=20 >> Additionally, the group will provide mechanisms for management of the = protocol lifecycle including: >>=20 >>=20 >>=20 >> - Discovery of the authorization server >>=20 >> - Revocation of active tokens >>=20 >> - Query of token rights by resource servers >>=20 >>=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 porting from OAuth 2.0 and OpenID Connect to the new = protocol where possible. >>=20 >> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3, and = will strive to enable simple mapping to other protocols such as COAP. >>=20 >>=20 >>=20 >>=20 >>=20 >> On Jan 10, 2020, at 12:04 PM, Dick Hardt = wrote: >>=20 >>=20 >> Hey >>=20 >>=20 >> I've written an alternative charter that I hope captures some of the = feedback on Justin's charter. >>=20 >>=20 >>=20 >> I found it easier to rewrite the charter to broaden the marketplace = of ideas.=20 >>=20 >>=20 >>=20 >> Key ideas: >>=20 >>=20 >>=20 >> - This work supports existing OAuth 2.0, and OpenID Connect use = cases. >>=20 >>=20 >>=20 >> - The client interacts directly with the authorization server.=20 >>=20 >>=20 >>=20 >> /Dick >>=20 >>=20 >>=20 >> ---- >>=20 >>=20 >> This group is chartered to develop a delegated identity and = authorization protocol.. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the = protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server.. >>=20 >>=20 >> Additionally, the protocol will allow: >>=20 >> - fine-grained specification of resource access >>=20 >> - the user to approve requests for identity claims and access to = multiple resources in one interaction >>=20 >> - web, mobile, single-page, and other client applications >>=20 >> - taking advantage of optimization features in HTTP2 and HTTP3 >>=20 >>=20 >> The group will define extension points for this protocol to allow for = flexibility in areas including: >>=20 >>=20 >> - discovery of the authorization server >>=20 >> - cryptographic agility for keys, message signatures, and proof of = possession=20 >>=20 >> - user interaction mechanisms including web and non-web methods- = token presentation mechanisms and key bindings >>=20 >>=20 >> Although the artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 or OpenID Connect, they will = attempt to simplify porting from OAuth 2.0 and OpenID Connect, and = strive to reuse existing semantics such as client identifiers, OAuth 2.0 = scopes and access tokens, and OpenID Connect ID Tokens and claims. >>=20 >>=20 >> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = strive to enable simple mapping to other protocols such as COAP. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> =E1=90=A7 >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=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 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >=20 >=20 From nobody Thu Jan 16 15:00: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 8761A1200C3 for ; Thu, 16 Jan 2020 15:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 pmQAJDaU9Xeq for ; Thu, 16 Jan 2020 15:00:18 -0800 (PST) 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 6F883120099 for ; Thu, 16 Jan 2020 15:00:17 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id y6so24479609lji.0 for ; Thu, 16 Jan 2020 15:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q/ZAKO9n1G9wDlvI7kk2qEeYg49JiAtnBJ3Gn0Yw+Pw=; b=cqyRz8JSVEc0KpRe2vnkwZNe5P5xyfugAkTKABsSAchV6TBzOpPaJNDV7R8rFbO7fO BT4QEFqkl8E9Wil53KHCLC0ZQDTIy4ObxYqbAcucgYYeYyUR83Ku6eOgTP6T+g/+p/cW TUdPvNxKydWJ+Cn+i7bEqybRZgSXjouDX2498+Fi15EcjYWwAirynKv+kEyd8a1/zBAF 97Fd3paVbr11ogS2BU+EOqRSKcYCG37kqekBj4IMGNYbhuAUzLqj/UOyHC46fgxDgAOi q/jWPC/ggWmJgcGNeSvDNwUiXYhmNRbXjUOSLfnabrNdmbGE+pRqFgolZ5/QAb4JQz2N /h9A== 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=Q/ZAKO9n1G9wDlvI7kk2qEeYg49JiAtnBJ3Gn0Yw+Pw=; b=opPXxOeQoyDZWtYPwT0aEDwSv2qWi/RFa47hn7rzkzzQPQHkpr6T+8wRwHNgcd7e2S RjUR/5w2AhXVZFf2megrPGZoDI8gZI1izyiDuD6mNOPZiJW74bR14ZV3IHBRZNNG4/Gv cdCYwzwXvSkYyjNERJsNjNcS9iFAe1TJP+IG7BMKdSF1yhcjg8L79Z5XrsU44ujwviw7 aEH5A6VO611uavSTm9fIlIS7t79GxyflBZclrROY7XYudZAlBToxof3dlMa7Pi9yRQre d2+lGPHBq5e1RgfFh9sLvKN4uhr8yakp5xLjvIMKbVw9vBS/e6om95O+73rNGfvDJJCf iVUg== X-Gm-Message-State: APjAAAWMTjyi/2H7mnlfx0hagX2RPAum1jZ+DuLBgiCU3IMo+634Edmg kh5zmo5RGhG2Al0Gje5zk9raMNs2dufTIstJ60GmPI5u X-Google-Smtp-Source: APXvYqwmdHBxOR4EyJ5vs4X3RP9M7TkqSz/0JPn7iA/G6vYRW7VJtvIjLX89i5zAi/Moouwp6gtIiGUdEIrrrqFTH1g= X-Received: by 2002:a2e:9008:: with SMTP id h8mr3560573ljg.217.1579215615533; Thu, 16 Jan 2020 15:00:15 -0800 (PST) MIME-Version: 1.0 References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> <5A7FEF06-954E-47B1-B3CE-AD5DE2329B52@mit.edu> <7A4FC2A4-9960-4A75-847C-0477FE81DB4F@amazon.com> <00C978A2-E4B1-4EEB-BA0E-5FF0A9B871F0@mit.edu> In-Reply-To: <00C978A2-E4B1-4EEB-BA0E-5FF0A9B871F0@mit.edu> From: Dick Hardt Date: Thu, 16 Jan 2020 15:00:04 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , Torsten Lodderstedt , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c9a738059c49c996" Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 23:00:21 -0000 --000000000000c9a738059c49c996 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was thinking that other kinds of delegation results would be yet another top level request, and matching response. Since it is not a widely deployed use case today, it would be an extension to the core protocol. Justin: What to you mean by VoT? wrt. returning claims, vs access to claims, I think it is an important discussion -- but let's put a pin in that for discussion in the WG once we are formed! I don't think that needs to be in the charter, but happy to be convinced otherwise. =E1=90=A7 On Thu, Jan 16, 2020 at 2:49 PM Justin Richer wrote: > I=E2=80=99m cautiously Ok with having resource inlining be in scope =E2= =80=94 IF we can > generalize it from the identity case specifically. > > To do what you=E2=80=99re asking for though, the WG can still be chartere= d to > solve identity (which we know is a well-established and understood use > case), but also allow other things. > > This gets back to a fundamental question that I don=E2=80=99t have a clea= r answer > for yet: what do you get back at the end of a transaction? Right now we= =E2=80=99ve > got a clear call for three things: > > 1. Access tokens to call APIs > 2. Transaction handles to continue the transaction later (like a refresh > token but better) > 3. User identity claims > > Maybe the mechanism we use for #3 can be generalized, or maybe there=E2= =80=99s > even a good way to provide switches for #1, #2, and #3. > > And while we=E2=80=99re on the topic of #3, I think there=E2=80=99s a str= ong case to be > made that it should NOT be a user=E2=80=99s profile information, but rath= er just > enough information to identify the user to the RP. If the RP wants to pul= l > more profile info, it can do so via an API. This keeps us out of the > anti-pattern that SAML has of always sending all claims about a user > whether the RP needs them or not. But the RP will at least need to know i= f > it has to request the claims, and we can do that by a simple enough > structure like: > > user: { > =E2=80=9Ciss=E2=80=9D: =E2=80=9Chttp://foo.bar/=E2=80=9C, > =E2=80=9Csub=E2=80=9D: =E2=80=9C12387yhjfre=E2=80=9D, > =E2=80=9Clast_updated=E2=80=9D: 54239084 > } > > > You can add VoT and other things that can vary per-login here as well. Bu= t > I shouldn=E2=80=99t be sending you the user=E2=80=99s name and address ev= ery time they log > in =E2=80=94 as an RP you only need to get that if it=E2=80=99s a new acc= ount or if it=E2=80=99s > been updated since you last saw it. You can=E2=80=99t handle that if you= =E2=80=99re pushing > all the claims in the response: Since the RP doesn=E2=80=99t know who the= user is > until after this stage, it can=E2=80=99t tell that information to the IdP= ahead of > time and therefore the IdP is forced to always send it just in case the R= P > might need it. But by telling the RP an identifier for the user and a tag > of when any of their information was last updated I can make the decision > whether or not to pull information at the RP in an intelligent fashion if= I > want to. > > =E2=80=94 Justin > > > On Jan 16, 2020, at 5:29 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > > > The same could be said for any resource, particularly in scenarios wher= e > the interaction was kicked off so that the SP can perform a specific acti= on > initiated by the user (e.g., charging a credit card or account, publishin= g > a message to a message board or social media feed, retrieving a specific > document or image). > > > > Consider a flow like the following: > > 1. The end user is on a client website that provides a photo printing > service, clicks the "Print from CloudStorageProvider" button. > > 4. The client initates TxAuth via CloudStorageProvider's transaction > endpoint, requesting a URL for a photo to be selected by the end user. > > 5. CloudStorageProvider returns an interact_url pointing to its AS. > > 6. The client redirects the user agent to the AS. > > 7. The end user signs in, and selects the photo they want to print, and > confirms authorization to share with the client. > > 8. The AS redirects the user agent back to client. > > 9. The client calls back to CloudStorageProvider's transaction endpoint > to continue the TxAuth transaction. > > 10. CloudStorageProvider returns confirmation that the authorization wa= s > granted, along with the URL for the selected photo. > > > > This is identical to the identity use case, we've just replaced identit= y > claims with a URL to a photo. I see a lot of value in encouraging one-tim= e > authorization of specific actions like this, and if we're going to suppor= t > inlining of resources for identity claims anyway, it's not a big stretch = to > allow for arbitrary resource types. I do think it's fair to narrowly scop= e > the kinds of resource *schemas* the WG will define (e.g., defining core > identity claims like OIDC did), but the inlining mechanism should be > flexible (e.g., not limiting this to claims about the end user identity, > like OIDC did). > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > =EF=BB=BFOn 1/16/20, 12:59 PM, "Txauth on behalf of Justin Richer" < > txauth-bounces@ietf.org on behalf of jricher@mit.edu> wrote: > > > > I think that=E2=80=99s exactly the reason =E2=80=94 the case of gett= ing information > about the user directly from the TX endpoint is well established. People > don=E2=80=99t want to make another round trip just to figure out who=E2= =80=99s there, when > a lot of time that=E2=80=99s the first thing they care about, and then th= e=E2=80=99d make > the determination of whether to follow other APIs after that. > > > > So if I can send you a very basic set of authn info from the > callback, like an identifier and VoT style login information, then you ca= n > figure out if you need to know more about that user or not. But these bas= ic > claims do get elevated to the same level as other returned artifacts from > the transaction, like the access tokens. > > > > =E2=80=94 Justin > > > >> On Jan 16, 2020, at 2:12 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > >> > >> The only reason I can think of to single out identity within the > charter is if there is some work or feature that is within scope for the > working group, but only for identity claims (e.g., returning identity > claims from the transaction endpoint). Repeating a question I posed > earlier, what is it about identity claims that make them worthy of specia= l > consideration? > >> > >> =E2=80=93 > >> Annabelle Richard Backman > >> AWS Identity > >> > >> > >> On 1/16/20, 8:51 AM, "Justin Richer" wrote: > >> > >> On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >>> > >>> > >>> > >>>> Am 16.01.2020 um 16:45 schrieb Justin Richer : > >>>> > >>>> - Approval of identity claims and multiple resources in a single > interaction > >>> > >>> This sounds a bit incomplete to me. I assume the user would approve > =E2=80=9Ethe attestation of identity claims=E2=80=9C. I furthermore think= the user would > approve =E2=80=9Eaccess to multiple APIs=E2=80=9C. I would prefer API ove= r resource because > it is more universal. For example, the protocol could also be used to > create resources. > >> > >> Point taken, but this isn=E2=80=99t meant to be an exhaustive list o= f what it > can do, merely the list of things we=E2=80=99re positive we want it to do= . I also > prefer =E2=80=9CAPI=E2=80=9D over =E2=80=9Cresource=E2=80=9D, but concede= that =E2=80=9Cresource=E2=80=9D can be a > writeable thing too. Even then I=E2=80=99m happy to tweak the language he= re. > >> > >> =E2=80=94 Justin > >> > > > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > > > > > --000000000000c9a738059c49c996 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was thinking that other kinds of delegation results woul= d be yet another top level request, and matching response. Since it is not = a widely deployed use case today, it would be an extension to the core prot= ocol.

Justin:=C2=A0 What to you mean by VoT?
<= br>
wrt. returning claims, vs access to claims, I think it is an = important discussion -- but let's put a pin in that for discussion in t= he WG once we are formed! I don't think=C2=A0that needs to be in the ch= arter, but happy to be convinced otherwise.=C2=A0
3D""=E1= =90=A7

On Thu, Jan 16, 2020 at 2:49 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m cautiously Ok with having= resource inlining be in scope =E2=80=94 IF we can generalize it from the i= dentity case specifically.

To do what you=E2=80=99re asking for though, the WG can still be chartered = to solve identity (which we know is a well-established and understood use c= ase), but also allow other things.

This gets back to a fundamental question that I don=E2=80=99t have a clear = answer for yet: what do you get back at the end of a transaction? Right now= we=E2=80=99ve got a clear call for three things:

1. Access tokens to call APIs
2. Transaction handles to continue the transaction later (like a refresh to= ken but better)
3. User identity claims

Maybe the mechanism we use for #3 can be generalized, or maybe there=E2=80= =99s even a good way to provide switches for #1, #2, and #3.

And while we=E2=80=99re on the topic of #3, I think there=E2=80=99s a stron= g case to be made that it should NOT be a user=E2=80=99s profile informatio= n, but rather just enough information to identify the user to the RP. If th= e RP wants to pull more profile info, it can do so via an API. This keeps u= s out of the anti-pattern that SAML has of always sending all claims about = a user whether the RP needs them or not. But the RP will at least need to k= now if it has to request the claims, and we can do that by a simple enough = structure like:

user: {
=C2=A0 =E2=80=9Ciss=E2=80=9D: =E2=80=9Chttp://foo.bar/=E2=80=9C,
=C2=A0 =E2=80=9Csub=E2=80=9D: =E2=80=9C12387yhjfre=E2=80=9D,
=C2=A0 =E2=80=9Clast_updated=E2=80=9D: 54239084
}


You can add VoT and other things that can vary per-login here as well. But = I shouldn=E2=80=99t be sending you the user=E2=80=99s name and address ever= y time they log in =E2=80=94 as an RP you only need to get that if it=E2=80= =99s a new account or if it=E2=80=99s been updated since you last saw it. Y= ou can=E2=80=99t handle that if you=E2=80=99re pushing all the claims in th= e response: Since the RP doesn=E2=80=99t know who the user is until after t= his stage, it can=E2=80=99t tell that information to the IdP ahead of time = and therefore the IdP is forced to always send it just in case the RP might= need it. But by telling the RP an identifier for the user and a tag of whe= n any of their information was last updated I can make the decision whether= or not to pull information at the RP in an intelligent fashion if I want t= o.

=C2=A0=E2=80=94 Justin

> On Jan 16, 2020, at 5:29 PM, Richard Backman, Annabelle <richanna@amazon.com> = wrote:
>
> The same could be said for any resource, particularly in scenarios whe= re the interaction was kicked off so that the SP can perform a specific act= ion initiated by the user (e.g., charging a credit card or account, publish= ing a message to a message board or social media feed, retrieving a specifi= c document or image).
>
> Consider a flow like the following:
> 1. The end user is on a client website that provides a photo printing = service, clicks the "Print from CloudStorageProvider" button.
> 4. The client initates TxAuth via CloudStorageProvider's transacti= on endpoint, requesting a URL for a photo to be selected by the end user. > 5. CloudStorageProvider returns an interact_url pointing to its AS. > 6. The client redirects the user agent to the AS.
> 7. The end user signs in, and selects the photo they want to print, an= d confirms authorization to share with the client.
> 8. The AS redirects the user agent back to client.
> 9. The client calls back to CloudStorageProvider's transaction end= point to continue the TxAuth transaction.
> 10. CloudStorageProvider returns confirmation that the authorization w= as granted, along with the URL for the selected photo.
>
> This is identical to the identity use case, we've just replaced id= entity claims with a URL to a photo. I see a lot of value in encouraging on= e-time authorization of specific actions like this, and if we're going = to support inlining of resources for identity claims anyway, it's not a= big stretch to allow for arbitrary resource types. I do think it's fai= r to narrowly scope the kinds of resource *schemas* the WG will define (e.g= ., defining core identity claims like OIDC did), but the inlining mechanism= should be flexible (e.g., not limiting this to claims about the end user i= dentity, like OIDC did).
>
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
>
> =EF=BB=BFOn 1/16/20, 12:59 PM, "Txauth on behalf of Justin Richer= " <txa= uth-bounces@ietf.org on behalf of jricher@mit.edu> wrote:
>
>=C2=A0 =C2=A0 I think that=E2=80=99s exactly the reason =E2=80=94 the c= ase of getting information about the user directly from the TX endpoint is = well established. People don=E2=80=99t want to make another round trip just= to figure out who=E2=80=99s there, when a lot of time that=E2=80=99s the f= irst thing they care about, and then the=E2=80=99d make the determination o= f whether to follow other APIs after that.
>
>=C2=A0 =C2=A0 So if I can send you a very basic set of authn info from = the callback, like an identifier and VoT style login information, then you = can figure out if you need to know more about that user or not. But these b= asic claims do get elevated to the same level as other returned artifacts f= rom the transaction, like the access tokens.
>
>=C2=A0 =C2=A0 =C2=A0=E2=80=94 Justin
>
>> On Jan 16, 2020, at 2:12 PM, Richard Backman, Annabelle <richanna@amazon.com&= gt; wrote:
>>
>> The only reason I can think of to single out identity within the c= harter is if there is some work or feature that is within scope for the wor= king group, but only for identity claims (e.g., returning identity claims f= rom the transaction endpoint). Repeating a question I posed earlier, what i= s it about identity claims that make them worthy of special consideration?<= br> >>
>> =E2=80=93
>> Annabelle Richard Backman
>> AWS Identity
>>
>>
>> On 1/16/20, 8:51 AM, "Justin Richer" <jricher@mit.edu> wrote:
>>
>>=C2=A0 =C2=A0On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt <= torsten@lodder= stedt.net> wrote:
>>>
>>>
>>>
>>>> Am 16.01.2020 um 16:45 schrieb Justin Richer <jricher@mit.edu>:
>>>>
>>>> - Approval of identity claims and multiple resources in a = single interaction
>>>
>>> This sounds a bit incomplete to me. I assume the user would ap= prove =E2=80=9Ethe attestation of identity claims=E2=80=9C. I furthermore t= hink the user would approve =E2=80=9Eaccess to multiple APIs=E2=80=9C. I wo= uld prefer API over resource because it is more universal. For example, the= protocol could also be used to create resources.
>>
>>=C2=A0 =C2=A0Point taken, but this isn=E2=80=99t meant to be an exh= austive list of what it can do, merely the list of things we=E2=80=99re pos= itive we want it to do. I also prefer =E2=80=9CAPI=E2=80=9D over =E2=80=9Cr= esource=E2=80=9D, but concede that =E2=80=9Cresource=E2=80=9D can be a writ= eable thing too. Even then I=E2=80=99m happy to tweak the language here. >>
>>=C2=A0 =C2=A0 =E2=80=94 Justin
>>
>
>=C2=A0 =C2=A0 --
>=C2=A0 =C2=A0 Txauth mailing list
>=C2=A0 =C2=A0 Txau= th@ietf.org
>=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/= txauth
>
>

--000000000000c9a738059c49c996-- From nobody Thu Jan 16 15:17: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 A819C1200DF for ; Thu, 16 Jan 2020 15:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 lDhjBYTR-CMU for ; Thu, 16 Jan 2020 15:17:37 -0800 (PST) Received: from gateway36.websitewelcome.com (gateway36.websitewelcome.com [192.185.199.121]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609FC1200D7 for ; Thu, 16 Jan 2020 15:17:37 -0800 (PST) Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway36.websitewelcome.com (Postfix) with ESMTP id 3209740CBCD1F for ; Thu, 16 Jan 2020 16:29:08 -0600 (CST) Received: from box5207.bluehost.com ([162.241.224.194]) by cmsmtp with SMTP id sENPiX1w6HunhsENPieeAH; Thu, 16 Jan 2020 17:16:35 -0600 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:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qBejVhA95zmjd++v1C6s2I1nV9A67uKtgYzKrj/Ac4g=; b=JoMWcr2ZsS+6RC2PKm9UnGmTqq iFnTOtBoxD2juyLtnE9LJYd2OGLndan+olPdOXQ9bsnZ09BgUWAIL74jcp0MlUxJFZg+dL7FrmWS8 QcAJTRPbrd70XaaH+ETrJD9yZ; Received: from c-73-167-220-69.hsd1.ma.comcast.net ([73.167.220.69]:60873 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 1isENP-003lbr-0a; Thu, 16 Jan 2020 16:16:35 -0700 User-Agent: Microsoft-MacOutlook/10.10.12.200112 Date: Thu, 16 Jan 2020 18:16:32 -0500 From: Thomas Hardjono To: Justin Richer CC: Thomas Hardjono , "txauth@ietf.org" Message-ID: <3119F975-5ED2-4E5E-B6D4-997871FF6EF6@hardjono.net> Thread-Topic: [Txauth] alternative charter writeup References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <40DEDA03-58E1-46EE-A46E-15D448283762@hardjono.net> <5F952C70-8EE2-440A-9334-5FBC19CE2A5E@mit.edu> <301ADD9B-CCC9-447D-B652-EB377961FBD6@mit.edu> In-Reply-To: <301ADD9B-CCC9-447D-B652-EB377961FBD6@mit.edu> 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: 1isENP-003lbr-0a 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]:60873 X-Source-Auth: ietf-txauth@hardjono.net X-Email-Count: 1 X-Source-Cap: aGFyZGpvbm87aGFyZGpvbm87Ym94NTIwNy5ibHVlaG9zdC5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 23:17:40 -0000 Yes, I see that sentence ("This protocol will allow an authorizing party to= delegate access to client software through an authorization server"). That'= s very specific, which is good. Just wanted to be sure that the bullet further below ("Delegation between m= ultiple users") also makes sense given that the first sentence is talking ab= out delegation to a piece of software. It=E2=80=99s a big jump between (i) a person delegating to a piece of software, t= o (ii) a person delegating to another person. Sorry for being pedantic. -- thomas -- =EF=BB=BF-----Original Message----- From: Justin Richer Date: Thursday, January 16, 2020 at 5:50 PM To: Thomas Hardjono Cc: "hardjono@mit.edu" , "txauth@ietf.org" Subject: Re: [Txauth] alternative charter writeup I get that, but that=E2=80=99s why the proposed charter text tries to be very exp= licit about who is delegating to whom (or what) and for what purpose. That=E2=80= =99s why delegation to software and delegation between users are both listed s= eparately.=20 =E2=80=94 Justin > On Jan 16, 2020, at 4:07 PM, Thomas Hardjono w= rote: >=20 > The problem is that the word "delegation" is generally a very loaded term= . >=20 > I understand that WGs need wiggle room, but I'm concerned that this kind = of loose wording may cause confusion down the road. >=20 >=20 >=20 >>> What I think is very much out of scope is cross-domain policy processin= g. >=20 > Agree. >=20 >=20 >=20 > =EF=BB=BF-----Original Message----- > From: Txauth on behalf of Justin Richer > Date: Thursday, January 16, 2020 at 11:54 AM > To: Thomas Hardjono > Cc: "hardjono@mit.edu" , "txauth@ietf.org" > Subject: Re: [Txauth] alternative charter writeup >=20 > On Jan 16, 2020, at 11:43 AM, Thomas Hardjono = wrote: >>=20 >>=20 >> Looks good, but I have a clarification question: >>=20 >>>>> - Delegation between multiple users >>=20 >> What does this mean exactly? >>=20 >> Is it the "multi-hop" delegation (Alice to Bob to Charlize to ...) >>=20 >> Or does it only the "1-hop" delegation concurrently (Alice to Bob; Alice= to Charlize; Alice to=E2=80=A6) >=20 > My thinking was that at the very least we want to allow the person runnin= g the client software and the person doing the authorization to be different= people. This is the UMA use case (Alice to bob) and the CIBA use case (agen= t getting someone to log in). I think chaining can follow that, where Bob ca= n then let Charlie do something. This is also along the lines of the token e= xchange model of OAuth 2, with continuously down-scoped access. >=20 > What I think is very much out of scope is cross-domain policy processing.= =20 >=20 > =E2=80=94 Justin >=20 >>=20 >> -- thomas -- >>=20 >>=20 >>=20 >> =EF=BB=BF-----Original Message----- >> From: Txauth on behalf of Justin Richer >> Date: Thursday, January 16, 2020 at 10:46 AM >> To: "txauth@ietf.org" >> Cc: "rdd@cert.org" , "Richard Backman, Annabelle" , Benjamin Kaduk , Dick Hardt >> Subject: Re: [Txauth] alternative charter writeup >>=20 >> Here=E2=80=99s my updated text incorporating the feedback so far: >>=20 >>=20 >> This group is chartered to develop a delegation protocol for identity, a= uthorization, and API access. This protocol will allow an authorizing party = to delegate access to client software through an authorization server. The u= se cases supported by this protocol will include widely deployed use cases c= urrently supported by OAuth 2.0 and OpenID Connect (an extension of OAuth 2.= 0) as well as new use cases not enabled by OAuth 2.0. >>=20 >>=20 >> The delegation process will be acted upon by multiple parties in the pro= tocol, each performing a specific role. The protocol will decouple the inter= action channels, such as the end user=E2=80=99s browser, from the delegation chann= el, which happens directly between the client and the authorization server (= in contrast with OAuth 2 which is initiated by the client redirecting the us= er=E2=80=99s browser). The client will involve the authorizing party as necessary = through interaction mechanisms indicated by the protocol. This decoupling av= oids many of the security concerns and technical challenges of OAuth 2.0 as = well as providing a non-invasive path for supporting future types of clients= and interaction channels. >>=20 >>=20 >> Additionally, the delegation process will allow for: >>=20 >>=20 >> - Fine-grained specification of resource access >>=20 >> - Approval of identity claims and multiple resources in a single interac= tion >>=20 >> - Delegation between multiple users >>=20 >> - Web, mobile, single-page, interaction-constrained, and other types of = client applications >>=20 >>=20 >> The group will define extension points for this protocol to allow for fl= exibility in areas including: >>=20 >>=20 >> - Cryptographic agility for keys, message signatures, and proof of posse= ssion=20 >>=20 >> - User interaction mechanisms including web and non-web methods >>=20 >> - Mechanisms for providing user, software, organization, and other piece= s of information used in authorization decisions >>=20 >> - Token presentation mechanisms and key bindings >>=20 >>=20 >> Additionally, the group will provide mechanisms for management of the pr= otocol lifecycle including: >>=20 >>=20 >> - Discovery of the authorization server >>=20 >> - Revocation of active tokens >>=20 >> - Query of token rights by resource servers >>=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 attemp= t to simplify porting from OAuth 2.0 and OpenID Connect to the new protocol = where possible. >>=20 >>=20 >> While the initial work will focus on using HTTP for communication betwee= n the client and the authorization server, the working group will seek to ta= ke advantage of optimization features of HTTP2 and HTTP3 where possible, and= will strive to enable simple mapping to other protocols such as COAP. >>=20 >>=20 >>=20 >>=20 >>=20 >> It=E2=80=99s definitely a lot, but I think we=E2=80=99ve got a good handle on what w= e=E2=80=99re working on, and what the boundaries are. I think this is both too muc= h of an effort and too much of a break to do this in the OAuth WG, where the= re=E2=80=99s already still plenty of work to be done. We=E2=80=99re leaning a lot on les= sons learned from the OAuth 2 world and its extensions, including OIDC and U= MA2. We=E2=80=99ve got the attention of a lot of the right people to start this as= well. >>=20 >> So to the AD=E2=80=99s: Ben and Roman =E2=80=94 what=E2=80=99s the next step? This should = be a new working group and like to get it started so that we can have our fi= rst meeting in Vancouver. >>=20 >> =E2=80=94 Justin >>=20 >>=20 >> On Jan 14, 2020, at 12:12 AM, Dick Hardt wrote: >>=20 >> Sounds good to me. >>=20 >> On Mon, Jan 13, 2020 at 6:24 PM Justin Richer wrote: >>=20 >>=20 >> I can get behind this kind of addition. I like Annabelle=E2=80=99s framing of = it in terms of decoupling, and some explanation of why we=E2=80=99re doing it in r= elation to OAuth 2=E2=80=99s approach. One of the key things, to me, is that we=E2=80=99= re making a break from OAuth 2=E2=80=99s core architecture but doing so for very s= pecific reasons.=20 >>=20 >> =E2=80=94 Justin >>=20 >>=20 >> On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle wrote: >>=20 >> It=E2=80=99s not just about the initial communication, though. I the key thing= to emphasize is the decoupling the protocol from delegation channels, which= addresses the aforementioned security/complexity issues and also provides a= path to support future delegation channel types without significant changes= to the protocol (unlike OAuth 2.0, where extensions like Device Flow and PA= R introduce substantial changes to the core protocol flow on both client and= AS). Since the protocol isn=E2=80=99t assuming a particular front channel, it=E2=80=99s= easier to add support for a new one. >>=20 >> Proposal, altered from Dick=E2=80=99s suggestion: >> This group is chartered to develop a delegated identity and authorizatio= n protocol. The use cases supported by this protocol will include widely dep= loyed use cases currently supported by OAuth 2.0, and OpenID Connect, an ext= ension of OAuth 2.0. This protocol will be decoupled from delegation channel= s such as an end user=E2=80=99s web browser and operate primarily through a channe= l between the client and the authorization server, avoiding many of the secu= rity concerns and technical challenges of OAuth 2.0 and providing a non-inva= sive path for adding support for future types of clients and delegation chan= nels. >>=20 >> =E2=80=93=20 >> Annabelle Richard Backman >> AWS Identity >>=20 >>=20 >>=20 >> From: Dick Hardt >> Date: Monday, January 13, 2020 at 4:35 PM >> To: "Richard Backman, Annabelle" >> Cc: Justin Richer , "txauth@ietf.org" >> Subject: Re: [Txauth] alternative charter writeup >>=20 >>=20 >>=20 >> I agree, some more "why" would help a broader audience understand the mo= tivations. How about this change to the first paragraph? >>=20 >>=20 >>=20 >> This group is chartered to develop a delegated identity and authorizatio= n protocol. The use cases supported by this protocol will include widely dep= loyed use cases currently supported by OAuth 2.0, and OpenID Connect, an ext= ension of OAuth 2.0. In contrast to OAuth 2.0, where the protocol is initiat= ed by redirecting the user's browser to an authorization server, this protoc= ol will be initiated by the client directly interacting with the authorizati= on server, which will mitigate many of the security concerns and technical c= hallenges of OAuth 2.0. >>=20 >>=20 >>=20 >>=20 >>=20 >> On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle wrote: >>=20 >>=20 >> While I agree with the goals stated in this charter, if I read this from= the perspective of someone who hasn=E2=80=99t been our meetings or listened to Ju= stin=E2=80=99s presentations, I=E2=80=99m hard pressed to see what the point of this gro= up is, relative to the OAuth WG. I=E2=80=99d expect this charter to provide at lea= st a cursory explanation of what problem it is trying to solve. In this case= , the problem should be partially defined in relation to OAuth. What will th= is WG do that the OAuth WG hasn=E2=80=99t already done or isn=E2=80=99t already doing? >>=20 >> How about adding something like the following to paragraph 2: >>=20 >> The protocol will mitigate many of the security concerns and technical c= hallenges of OAuth 2.0 by communicating over secure channels between the cli= ent and the authorization server, and minimizing the amount of information t= ransmitted over untrusted channels. >>=20 >> =E2=80=93=20 >> Annabelle Richard Backman >> AWS Identity >>=20 >>=20 >>=20 >> From: Txauth on behalf of Dick Hardt >> Date: Friday, January 10, 2020 at 6:57 PM >> To: Justin Richer >> Cc: "txauth@ietf.org" >> Subject: Re: [Txauth] alternative charter writeup >>=20 >>=20 >>=20 >> This looks even better! Thanks Justin. >>=20 >>=20 >> What do others think of the proposed charter now?=20 >>=20 >>=20 >> =E1=90=A7 >>=20 >>=20 >> On Fri, Jan 10, 2020 at 12:43 PM Justin Richer wrote: >>=20 >>=20 >> Thanks, Dick. I=E2=80=99ve been working on an updated charter based on everyon= e=E2=80=99s feedback, and I was aiming to have out today anyway, so this timing is= helpful. So here=E2=80=99s my take on a new charter, incorporating some of your p= oints below:=20 >>=20 >>=20 >>=20 >> This group is chartered to develop a delegation protocol for identity, a= uthorization, and API access. This protocol will allow an authorizing party = to delegate access to client software through an authorization server. The u= se cases supported by this protocol will include widely deployed use cases c= urrently supported by OAuth 2.0 and OpenID Connect.=20 >>=20 >>=20 >>=20 >> The delegation process will be acted upon by multiple parties in the pro= tocol, each performing a specific role. The protocol will be initiated by th= e client interacting directly with the authorization server (in contrast wit= h OAuth 2 which is initiated by the client redirecting the user=E2=80=99s browser)= . The client will involve the authorizing party as necessary through interac= tion mechanisms indicated by the protocol.=20 >>=20 >>=20 >>=20 >> Additionally, the delegation process will allow for: >>=20 >>=20 >>=20 >> - Fine-grained specification of resource access >>=20 >> - Approval of identity claims and multiple resources in a single interac= tion >>=20 >> - Delegation between multiple users >>=20 >> - Web, mobile, single-page, and other types of client applications >>=20 >>=20 >>=20 >> The group will define extension points for this protocol to allow for fl= exibility in areas including: >>=20 >>=20 >>=20 >> - Cryptographic agility for keys, message signatures, and proof of posse= ssion=20 >>=20 >> - User interaction mechanisms including web and non-web methods >>=20 >> - Mechanisms for providing user, software, organization, and other piece= s of information used in authorization decisions >>=20 >> - Token presentation mechanisms and key bindings >>=20 >>=20 >>=20 >> Additionally, the group will provide mechanisms for management of the pr= otocol lifecycle including: >>=20 >>=20 >>=20 >> - Discovery of the authorization server >>=20 >> - Revocation of active tokens >>=20 >> - Query of token rights by resource servers >>=20 >>=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 attemp= t to simplify porting from OAuth 2.0 and OpenID Connect to the new protocol = where possible. >>=20 >> While the initial work will focus on using HTTP for communication betwee= n the client and the authorization server, the working group will seek to ta= ke advantage of optimization features of HTTP2 and HTTP3, and will strive to= enable simple mapping to other protocols such as COAP. >>=20 >>=20 >>=20 >>=20 >>=20 >> On Jan 10, 2020, at 12:04 PM, Dick Hardt wrote: >>=20 >>=20 >> Hey >>=20 >>=20 >> I've written an alternative charter that I hope captures some of the fee= dback on Justin's charter. >>=20 >>=20 >>=20 >> I found it easier to rewrite the charter to broaden the marketplace of i= deas.=20 >>=20 >>=20 >>=20 >> Key ideas: >>=20 >>=20 >>=20 >> - This work supports existing OAuth 2.0, and OpenID Connect use cases. >>=20 >>=20 >>=20 >> - The client interacts directly with the authorization server.=20 >>=20 >>=20 >>=20 >> /Dick >>=20 >>=20 >>=20 >> ---- >>=20 >>=20 >> This group is chartered to develop a delegated identity and authorizatio= n protocol.. The use cases supported by this protocol will include widely de= ployed use cases currently supported by OAuth 2.0, and OpenID Connect. In co= ntrast to OAuth 2.0 and OpenID Connect, where the protocol is initiated by r= edirecting the user's browser to an authorization server, this protocol will= be initiated by the client directly interacting with the authorization serv= er.. >>=20 >>=20 >> Additionally, the protocol will allow: >>=20 >> - fine-grained specification of resource access >>=20 >> - the user to approve requests for identity claims and access to multipl= e resources in one interaction >>=20 >> - web, mobile, single-page, and other client applications >>=20 >> - taking advantage of optimization features in HTTP2 and HTTP3 >>=20 >>=20 >> The group will define extension points for this protocol to allow for fl= exibility in areas including: >>=20 >>=20 >> - discovery of the authorization server >>=20 >> - cryptographic agility for keys, message signatures, and proof of posse= ssion=20 >>=20 >> - user interaction mechanisms including web and non-web methods- token p= resentation mechanisms and key bindings >>=20 >>=20 >> Although the artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt to = simplify porting from OAuth 2.0 and OpenID Connect, and strive to reuse exis= ting semantics such as client identifiers, OAuth 2.0 scopes and access token= s, and OpenID Connect ID Tokens and claims. >>=20 >>=20 >> While the initial work will focus on using HTTP for communication betwee= n the client and the authorization server, the working group will strive to = enable simple mapping to other protocols such as COAP. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> =E1=90=A7 >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=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 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >=20 >=20 From nobody Thu Jan 16 15:21: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 6C2C5120802 for ; Thu, 16 Jan 2020 15:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 xdNox7bRv1of for ; Thu, 16 Jan 2020 15:21:39 -0800 (PST) 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 19E9B12081A for ; Thu, 16 Jan 2020 15:21:39 -0800 (PST) Received: by mail-lj1-x244.google.com with SMTP id r19so24479368ljg.3 for ; Thu, 16 Jan 2020 15:21:39 -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=H3nxSl/pIKNbOubsOnOZZrmNhMwLUDHJV9213gjXrvI=; b=BUOQWoyrAY67kXjz9ijL2yx672TY7A8ZlHtO8Zh2jrxuq436riSvjFerTvdFuosbMN C+2zoEUtvq7ywWynLBjK0FgFqkH93caeTnT9CG9UGy8jH2zOGDARbL8dMo9mJXvt+uXc qJasu4kD5y8bKE2V9vO2kIXBUTwfAvBIjfLUfnak1le67D3eXAA1iGb5rkLNHHcRtIIb PfeCxGTF7FupfZRycs+TyeZ4yRlOX8sH/6GDW2e15PMwTI7xeuUQcYlFD7mCQPX64KDf 30Df0VxDfOgukwe35UYgLMs/ZnO1VXRCalfefLZcIXm6BiAzsbNNim1WOYbZvMqJyT5R Q/cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H3nxSl/pIKNbOubsOnOZZrmNhMwLUDHJV9213gjXrvI=; b=klAApW6EHOi4vRyifCifC2hfn+hP+VKPOIXkxjyG2USng6bvkzS0WfyQSfdKVWIHed rJufY4L78J8r19caNxHzQAILvOi/DnSWCSaA/171gYTnJQ6KBudbeiF8HX50OIpk7RmK yL8wVk1fXIEsO9HNVCztRCIMRkBKVmAoDYo1LsRrEF48S9F+vtkFvGi6jqqAmRcYoDRK +uqmkR+Qwh2yjbjhkc6ZDeXHH70w/uTFAM2jH4QjwQc2z4DKWSwLwoNYNljOUlGO0hrb bRm6c9S+toqcws4J9GXl1CWcKGmsBueIDYJgavEu7pnw0hHsp7PI3/bJ95FWR283gZBs nUEg== X-Gm-Message-State: APjAAAWXO5SL0becmW3Xtm+LXoiQ7z3UEYpUnzg150VbtkmN3scEFlmt 8HAsz3Tw/H2w+fnxqCokadRwz2RrclaXhlUw0RspqkXV X-Google-Smtp-Source: APXvYqxtf4OF9/tkmxBkagQGeBk6fyxQHN4+/p/6U+qdY2MQB+pPX6UyaZ40yC7u8niYNShOVxO8s/lvD5cmw8T4BD8= X-Received: by 2002:a2e:9e4c:: with SMTP id g12mr3791878ljk.15.1579216897144; Thu, 16 Jan 2020 15:21:37 -0800 (PST) MIME-Version: 1.0 References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <40DEDA03-58E1-46EE-A46E-15D448283762@hardjono.net> <5F952C70-8EE2-440A-9334-5FBC19CE2A5E@mit.edu> <301ADD9B-CCC9-447D-B652-EB377961FBD6@mit.edu> <3119F975-5ED2-4E5E-B6D4-997871FF6EF6@hardjono.net> In-Reply-To: <3119F975-5ED2-4E5E-B6D4-997871FF6EF6@hardjono.net> From: Dick Hardt Date: Thu, 16 Jan 2020 15:21:25 -0800 Message-ID: To: Thomas Hardjono Cc: Justin Richer , Thomas Hardjono , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002d7ebc059c4a16de" Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 16 Jan 2020 23:21:46 -0000 --0000000000002d7ebc059c4a16de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What I have understood we are enabling is a separation between the user using the client software, and the user that is the resource owner. Justin: is that what you had in mind? =E1=90=A7 On Thu, Jan 16, 2020 at 3:17 PM Thomas Hardjono wrote: > Yes, I see that sentence ("This protocol will allow an authorizing party > to delegate access to client software through an authorization server"). > That's very specific, which is good. > > Just wanted to be sure that the bullet further below ("Delegation between > multiple users") also makes sense given that the first sentence is talkin= g > about delegation to a piece of software. > > It=E2=80=99s a big jump between (i) a person delegating to a piece of sof= tware, to > (ii) a person delegating to another person. > > Sorry for being pedantic. > > > > -- thomas -- > > > > =EF=BB=BF-----Original Message----- > From: Justin Richer > Date: Thursday, January 16, 2020 at 5:50 PM > To: Thomas Hardjono > Cc: "hardjono@mit.edu" , "txauth@ietf.org" < > txauth@ietf.org> > Subject: Re: [Txauth] alternative charter writeup > > I get that, but that=E2=80=99s why the proposed charter text tries to be = very > explicit about who is delegating to whom (or what) and for what purpose. > That=E2=80=99s why delegation to software and delegation between users ar= e both > listed separately. > > =E2=80=94 Justin > > > On Jan 16, 2020, at 4:07 PM, Thomas Hardjono > wrote: > > > > The problem is that the word "delegation" is generally a very loaded > term. > > > > I understand that WGs need wiggle room, but I'm concerned that this kin= d > of loose wording may cause confusion down the road. > > > > > > > >>> What I think is very much out of scope is cross-domain policy > processing. > > > > Agree. > > > > > > > > =EF=BB=BF-----Original Message----- > > From: Txauth on behalf of Justin Richer < > jricher@mit.edu> > > Date: Thursday, January 16, 2020 at 11:54 AM > > To: Thomas Hardjono > > Cc: "hardjono@mit.edu" , "txauth@ietf.org" < > txauth@ietf.org> > > Subject: Re: [Txauth] alternative charter writeup > > > > On Jan 16, 2020, at 11:43 AM, Thomas Hardjono > wrote: > >> > >> > >> Looks good, but I have a clarification question: > >> > >>>>> - Delegation between multiple users > >> > >> What does this mean exactly? > >> > >> Is it the "multi-hop" delegation (Alice to Bob to Charlize to ...) > >> > >> Or does it only the "1-hop" delegation concurrently (Alice to Bob; > Alice to Charlize; Alice to=E2=80=A6) > > > > My thinking was that at the very least we want to allow the person > running the client software and the person doing the authorization to be > different people. This is the UMA use case (Alice to bob) and the CIBA us= e > case (agent getting someone to log in). I think chaining can follow that, > where Bob can then let Charlie do something. This is also along the lines > of the token exchange model of OAuth 2, with continuously down-scoped > access. > > > > What I think is very much out of scope is cross-domain policy > processing. > > > > =E2=80=94 Justin > > > >> > >> -- thomas -- > >> > >> > >> > >> =EF=BB=BF-----Original Message----- > >> From: Txauth on behalf of Justin Richer < > jricher@mit.edu> > >> Date: Thursday, January 16, 2020 at 10:46 AM > >> To: "txauth@ietf.org" > >> Cc: "rdd@cert.org" , "Richard Backman, Annabelle" < > richanna@amazon.com>, Benjamin Kaduk , Dick Hardt < > dick.hardt@gmail.com> > >> Subject: Re: [Txauth] alternative charter writeup > >> > >> Here=E2=80=99s my updated text incorporating the feedback so far: > >> > >> > >> This group is chartered to develop a delegation protocol for identity, > authorization, and API access. This protocol will allow an authorizing > party to delegate access to client software through an authorization > server. The use cases supported by this protocol will include widely > deployed use cases currently supported by OAuth 2.0 and OpenID Connect (a= n > extension of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0= . > >> > >> > >> 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 which is initiated by the client > redirecting the user=E2=80=99s browser). The client will involve the auth= orizing > party as necessary through interaction mechanisms indicated by the > protocol. This decoupling avoids many of the security concerns and > technical challenges of OAuth 2.0 as well as providing a non-invasive pat= h > for supporting future types of clients and interaction channels. > >> > >> > >> Additionally, the delegation process will allow for: > >> > >> > >> - Fine-grained specification of resource access > >> > >> - Approval of identity claims and multiple resources in a single > interaction > >> > >> - Delegation between multiple users > >> > >> - Web, mobile, single-page, interaction-constrained, and other types o= f > client 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 providing user, software, organization, and other > pieces of information used in authorization decisions > >> > >> - Token presentation mechanisms and key bindings > >> > >> > >> 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 porting from OAuth 2.0 and OpenID Connect to the new > protocol where possible. > >> > >> > >> While the initial work will focus on using HTTP for communication > between the client and the authorization server, the working group will > seek to take advantage of optimization features of HTTP2 and HTTP3 where > possible, and will strive to enable simple mapping to other protocols suc= h > as COAP. > >> > >> > >> > >> > >> > >> It=E2=80=99s definitely a lot, but I think we=E2=80=99ve got a good ha= ndle on what > we=E2=80=99re working on, and what the boundaries are. I think this is bo= th too > much of an effort and too much of a break to do this in the OAuth WG, whe= re > there=E2=80=99s already still plenty of work to be done. We=E2=80=99re le= aning a lot on > lessons learned from the OAuth 2 world and its extensions, including OIDC > and UMA2. We=E2=80=99ve got the attention of a lot of the right people to= start > this as well. > >> > >> So to the AD=E2=80=99s: Ben and Roman =E2=80=94 what=E2=80=99s the nex= t step? This should be a > new working group and like to get it started so that we can have our firs= t > meeting in Vancouver. > >> > >> =E2=80=94 Justin > >> > >> > >> On Jan 14, 2020, at 12:12 AM, Dick Hardt wrote: > >> > >> Sounds good to me. > >> > >> On Mon, Jan 13, 2020 at 6:24 PM Justin Richer wrote: > >> > >> > >> I can get behind this kind of addition. I like Annabelle=E2=80=99s fra= ming of > it in terms of decoupling, and some explanation of why we=E2=80=99re doin= g it in > relation to OAuth 2=E2=80=99s approach. One of the key things, to me, is = that we=E2=80=99re > making a break from OAuth 2=E2=80=99s core architecture but doing so for = very > specific reasons. > >> > >> =E2=80=94 Justin > >> > >> > >> On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > >> > >> It=E2=80=99s not just about the initial communication, though. I the k= ey thing > to emphasize is the decoupling the protocol from delegation channels, whi= ch > addresses the aforementioned security/complexity issues and also provides= a > path to support future delegation channel types without significant chang= es > to the protocol (unlike OAuth 2.0, where extensions like Device Flow and > PAR introduce substantial changes to the core protocol flow on both clien= t > and AS). Since the protocol isn=E2=80=99t assuming a particular front cha= nnel, it=E2=80=99s > easier to add support for a new one. > >> > >> Proposal, altered from Dick=E2=80=99s suggestion: > >> This group is chartered to develop a delegated identity and > authorization protocol. The use cases supported by this protocol will > include widely deployed use cases currently supported by OAuth 2.0, and > OpenID Connect, an extension of OAuth 2.0. This protocol will be decouple= d > from delegation channels such as an end user=E2=80=99s web browser and op= erate > primarily through a channel between the client and the authorization > server, avoiding many of the security concerns and technical challenges o= f > OAuth 2.0 and providing a non-invasive path for adding support for future > types of clients and delegation channels. > >> > >> =E2=80=93 > >> Annabelle Richard Backman > >> AWS Identity > >> > >> > >> > >> From: Dick Hardt > >> Date: Monday, January 13, 2020 at 4:35 PM > >> To: "Richard Backman, Annabelle" > >> Cc: Justin Richer , "txauth@ietf.org" > > >> Subject: Re: [Txauth] alternative charter writeup > >> > >> > >> > >> I agree, some more "why" would help a broader audience understand the > motivations. How about this change to the first paragraph? > >> > >> > >> > >> This group is chartered to develop a delegated identity and > authorization protocol. The use cases supported by this protocol will > include widely deployed use cases currently supported by OAuth 2.0, and > OpenID Connect, an extension of OAuth 2.0. In contrast to OAuth 2.0, wher= e > the protocol is initiated by redirecting the user's browser to an > authorization server, this protocol will be initiated by the client > directly interacting with the authorization server, which will mitigate > many of the security concerns and technical challenges of OAuth 2.0. > >> > >> > >> > >> > >> > >> On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > >> > >> > >> While I agree with the goals stated in this charter, if I read this > from the perspective of someone who hasn=E2=80=99t been our meetings or l= istened to > Justin=E2=80=99s presentations, I=E2=80=99m hard pressed to see what the = point of this > group is, relative to the OAuth WG. I=E2=80=99d expect this charter to pr= ovide at > least a cursory explanation of what problem it is trying to solve. In thi= s > case, the problem should be partially defined in relation to OAuth. What > will this WG do that the OAuth WG hasn=E2=80=99t already done or isn=E2= =80=99t already > doing? > >> > >> How about adding something like the following to paragraph 2: > >> > >> The protocol will mitigate many of the security concerns and technical > challenges of OAuth 2.0 by communicating over secure channels between the > client and the authorization server, and minimizing the amount of > information transmitted over untrusted channels. > >> > >> =E2=80=93 > >> Annabelle Richard Backman > >> AWS Identity > >> > >> > >> > >> From: Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > >> Date: Friday, January 10, 2020 at 6:57 PM > >> To: Justin Richer > >> Cc: "txauth@ietf.org" > >> Subject: Re: [Txauth] alternative charter writeup > >> > >> > >> > >> This looks even better! Thanks Justin. > >> > >> > >> What do others think of the proposed charter now? > >> > >> > >> =E1=90=A7 > >> > >> > >> On Fri, Jan 10, 2020 at 12:43 PM Justin Richer wrote= : > >> > >> > >> Thanks, Dick. I=E2=80=99ve been working on an updated charter based on > everyone=E2=80=99s feedback, and I was aiming to have out today anyway, s= o this > timing is helpful. So here=E2=80=99s my take on a new charter, incorporat= ing some > of your points below: > >> > >> > >> > >> This group is chartered to develop a delegation protocol for identity, > authorization, and API access. This protocol will allow an authorizing > party to delegate access to client software through an authorization > server. The use cases supported by this protocol will include widely > deployed use cases currently supported by OAuth 2.0 and OpenID Connect. > >> > >> > >> > >> The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will be initiated > by the client interacting directly with the authorization server (in > contrast with OAuth 2 which is initiated by the client redirecting the > user=E2=80=99s browser). The client will involve the authorizing party as= necessary > through interaction mechanisms indicated by the protocol. > >> > >> > >> > >> Additionally, the delegation process will allow for: > >> > >> > >> > >> - Fine-grained specification of resource access > >> > >> - Approval of identity claims and multiple resources in a single > interaction > >> > >> - Delegation between multiple users > >> > >> - Web, mobile, single-page, and other types of client 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 providing user, software, organization, and other > pieces of information used in authorization decisions > >> > >> - Token presentation mechanisms and key bindings > >> > >> > >> > >> 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 porting from OAuth 2.0 and OpenID Connect to the new > protocol where possible. > >> > >> While the initial work will focus on using HTTP for communication > between the client and the authorization server, the working group will > seek to take advantage of optimization features of HTTP2 and HTTP3, and > will strive to enable simple mapping to other protocols such as COAP. > >> > >> > >> > >> > >> > >> On Jan 10, 2020, at 12:04 PM, Dick Hardt wrote: > >> > >> > >> Hey > >> > >> > >> I've written an alternative charter that I hope captures some of the > feedback on Justin's charter. > >> > >> > >> > >> I found it easier to rewrite the charter to broaden the marketplace of > ideas. > >> > >> > >> > >> Key ideas: > >> > >> > >> > >> - This work supports existing OAuth 2.0, and OpenID Connect use cases. > >> > >> > >> > >> - The client interacts directly with the authorization server. > >> > >> > >> > >> /Dick > >> > >> > >> > >> ---- > >> > >> > >> This group is chartered to develop a delegated identity and > authorization protocol.. The use cases supported by this protocol will > include widely deployed use cases currently supported by OAuth 2.0, and > OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the > protocol is initiated by redirecting the user's browser to an authorizati= on > server, this protocol will be initiated by the client directly interactin= g > with the authorization server.. > >> > >> > >> Additionally, the protocol will allow: > >> > >> - fine-grained specification of resource access > >> > >> - the user to approve requests for identity claims and access to > multiple resources in one interaction > >> > >> - web, mobile, single-page, and other client applications > >> > >> - taking advantage of optimization features in HTTP2 and HTTP3 > >> > >> > >> The group will define extension points for this protocol to allow for > flexibility in areas including: > >> > >> > >> - discovery of the authorization server > >> > >> - cryptographic agility for keys, message signatures, and proof of > possession > >> > >> - user interaction mechanisms including web and non-web methods- token > presentation mechanisms and key bindings > >> > >> > >> Although the artifacts for this work are not intended or expected to b= e > backwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt = to > simplify porting from OAuth 2.0 and OpenID Connect, and strive to reuse > existing semantics such as client identifiers, OAuth 2.0 scopes and acces= s > tokens, and OpenID Connect ID Tokens and claims. > >> > >> > >> While the initial work will focus on using HTTP for communication > between the client and the authorization server, the working group will > strive to enable simple mapping to other protocols such as COAP. > >> > >> > >> > >> > >> > >> > >> > >> =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 > > > > -- > > 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 > --0000000000002d7ebc059c4a16de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What I have understood=C2=A0we are enabling is a separatio= n between the user using the client software, and the user that is the reso= urce owner.=C2=A0

Justin: is that what you=C2=A0had in m= ind?
=E1=90=A7

On Thu, Jan 16, 2020 at 3:17 PM Th= omas Hardjono <ietf-txauth@h= ardjono.net> wrote:
Yes, I see that sentence ("This protocol will allow an auth= orizing party to delegate access to client software through an authorizatio= n server"). That's very specific, which is good.

Just wanted to be sure that the bullet further below ("Delegation betw= een multiple users") also makes sense given that the first sentence is= talking about delegation to a piece of software.

It=E2=80=99s a big jump between (i) a person delegating to a piece of softw= are, to (ii) a person delegating to another person.

Sorry for being pedantic.



-- thomas --



=EF=BB=BF-----Original Message-----
From: Justin Richer <jricher@mit.edu>
Date: Thursday, January 16, 2020 at 5:50 PM
To: Thomas Hardjono <ietf-txauth@hardjono.net>
Cc: "hardjono@mi= t.edu" <h= ardjono@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] alternative charter writeup

I get that, but that=E2=80=99s why the proposed charter text tries to be ve= ry explicit about who is delegating to whom (or what) and for what purpose.= That=E2=80=99s why delegation to software and delegation between users are= both listed separately.

=C2=A0=E2=80=94 Justin

> On Jan 16, 2020, at 4:07 PM, Thomas Hardjono <ietf-txauth@hardjono.net> w= rote:
>
> The problem is that the word "delegation" is generally a ver= y loaded term.
>
> I understand that WGs need wiggle room, but I'm concerned that thi= s kind of loose wording may cause confusion down the road.
>
>
>
>>> What I think is very much out of scope is cross-domain policy = processing.
>
> Agree.
>
>
>
> =EF=BB=BF-----Original Message-----
> From: Txauth <txauth-bounces@ietf.org> on behalf of Justin Richer <jricher@mit.edu> > Date: Thursday, January 16, 2020 at 11:54 AM
> To: Thomas Hardjono <ietf-txauth@hardjono.net>
> Cc: "hardjo= no@mit.edu" <hardjono@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
> Subject: Re: [Txauth] alternative charter writeup
>
> On Jan 16, 2020, at 11:43 AM, Thomas Hardjono <ietf-txauth@hardjono.net> = wrote:
>>
>>
>> Looks good, but I have a clarification question:
>>
>>>>> - Delegation between multiple users
>>
>> What does this mean exactly?
>>
>> Is it the "multi-hop" delegation (Alice to Bob to Charli= ze to ...)
>>
>> Or does it only the "1-hop" delegation concurrently (Ali= ce to Bob; Alice to Charlize; Alice to=E2=80=A6)
>
> My thinking was that at the very least we want to allow the person run= ning the client software and the person doing the authorization to be diffe= rent people. This is the UMA use case (Alice to bob) and the CIBA use case = (agent getting someone to log in). I think chaining can follow that, where = Bob can then let Charlie do something. This is also along the lines of the = token exchange model of OAuth 2, with continuously down-scoped access.
>
> What I think is very much out of scope is cross-domain policy processi= ng.
>
> =E2=80=94 Justin
>
>>
>> -- thomas --
>>
>>
>>
>> =EF=BB=BF-----Original Message-----
>> From: Txauth <txauth-bounces@ietf.org> on behalf of Justin Richer <= jricher@mit.edu>= ;
>> Date: Thursday, January 16, 2020 at 10:46 AM
>> To: "txa= uth@ietf.org" <txauth@ietf.org>
>> Cc: "rdd@ce= rt.org" <rdd@= cert.org>, "Richard Backman, Annabelle" <richanna@amazon.com>, Ben= jamin Kaduk <kaduk@mi= t.edu>, Dick Hardt <dick.hardt@gmail.com>
>> Subject: Re: [Txauth] alternative charter writeup
>>
>> Here=E2=80=99s my updated text incorporating the feedback so far:<= br> >>
>>
>> This group is chartered to develop a delegation protocol for ident= ity, authorization, and API access. This protocol will allow an authorizing= party to delegate access to client software through an authorization serve= r. The use cases supported by this protocol will include widely deployed us= e cases currently supported by OAuth 2.0 and OpenID Connect (an extension o= f OAuth 2.0) as well as new use cases not enabled by OAuth 2.0.
>>
>>
>> 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 which is initiated by the client re= directing the user=E2=80=99s browser). The client will involve the authoriz= ing party as necessary through interaction mechanisms indicated by the prot= ocol. This decoupling avoids many of the security concerns and technical ch= allenges of OAuth 2.0 as well as providing a non-invasive path for supporti= ng future types of clients and interaction channels.
>>
>>
>> Additionally, the delegation process will allow for:
>>
>>
>> - Fine-grained specification of resource access
>>
>> - Approval of identity claims and multiple resources in a single i= nteraction
>>
>> - Delegation between multiple users
>>
>> - Web, mobile, single-page, interaction-constrained, and other typ= es of client 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 providing user, software, organization, and other= pieces of information used in authorization decisions
>>
>> - Token presentation mechanisms and key bindings
>>
>>
>> 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 porting from OAuth 2.0 and OpenID Connect to the new p= rotocol where possible.
>>
>>
>> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will see= k to take advantage of optimization features of HTTP2 and HTTP3 where possi= ble, and will strive to enable simple mapping to other protocols such as CO= AP.
>>
>>
>>
>>
>>
>> It=E2=80=99s definitely a lot, but I think we=E2=80=99ve got a goo= d handle on what we=E2=80=99re working on, and what the boundaries are. I t= hink this is both too much of an effort and too much of a break to do this = in the OAuth WG, where there=E2=80=99s already still plenty of work to be d= one. We=E2=80=99re leaning a lot on lessons learned from the OAuth 2 world = and its extensions, including OIDC and UMA2. We=E2=80=99ve got the attentio= n of a lot of the right people to start this as well.
>>
>> So to the AD=E2=80=99s: Ben and Roman =E2=80=94 what=E2=80=99s the= next step? This should be a new working group and like to get it started s= o that we can have our first meeting in Vancouver.
>>
>> =E2=80=94 Justin
>>
>>
>> On Jan 14, 2020, at 12:12 AM, Dick Hardt <dick.hardt@gmail.com> wrote: >>
>> Sounds good to me.
>>
>> On Mon, Jan 13, 2020 at 6:24 PM Justin Richer <jricher@mit.edu> wrote:
>>
>>
>> I can get behind this kind of addition. I like Annabelle=E2=80=99s= framing of it in terms of decoupling, and some explanation of why we=E2=80= =99re doing it in relation to OAuth 2=E2=80=99s approach. One of the key th= ings, to me, is that we=E2=80=99re making a break from OAuth 2=E2=80=99s co= re architecture but doing so for very specific reasons.
>>
>> =E2=80=94 Justin
>>
>>
>> On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle <richanna@amazon.com&= gt; wrote:
>>
>> It=E2=80=99s not just about the initial communication, though. I t= he key thing to emphasize is the decoupling the protocol from delegation ch= annels, which addresses the aforementioned security/complexity issues and a= lso provides a path to support future delegation channel types without sign= ificant changes to the protocol (unlike OAuth 2.0, where extensions like De= vice Flow and PAR introduce substantial changes to the core protocol flow o= n both client and AS). Since the protocol isn=E2=80=99t assuming a particul= ar front channel, it=E2=80=99s easier to add support for a new one.
>>
>> Proposal, altered from Dick=E2=80=99s suggestion:
>> This group is chartered to develop a delegated identity and author= ization protocol. The use cases supported by this protocol will include wid= ely deployed use cases currently supported by OAuth 2.0, and OpenID Connect= , an extension of OAuth 2.0. This protocol will be decoupled from delegatio= n channels such as an end user=E2=80=99s web browser and operate primarily = through a channel between the client and the authorization server, avoiding= many of the security concerns and technical challenges of OAuth 2.0 and pr= oviding a non-invasive path for adding support for future types of clients = and delegation channels.
>>
>> =E2=80=93
>> Annabelle Richard Backman
>> AWS Identity
>>
>>
>>
>> From: Dick Hardt <dick.hardt@gmail.com>
>> Date: Monday, January 13, 2020 at 4:35 PM
>> To: "Richard Backman, Annabelle" <richanna@amazon.com>
>> Cc: Justin Richer <jricher@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
>> Subject: Re: [Txauth] alternative charter writeup
>>
>>
>>
>> I agree, some more "why" would help a broader audience u= nderstand the motivations. How about this change to the first paragraph? >>
>>
>>
>> This group is chartered to develop a delegated identity and author= ization protocol. The use cases supported by this protocol will include wid= ely deployed use cases currently supported by OAuth 2.0, and OpenID Connect= , an extension of OAuth 2.0. In contrast to OAuth 2.0, where the protocol i= s initiated by redirecting the user's browser to an authorization serve= r, this protocol will be initiated by the client directly interacting with = the authorization server, which will mitigate many of the security concerns= and technical challenges of OAuth 2.0.
>>
>>
>>
>>
>>
>> On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:
>>
>>
>> While I agree with the goals stated in this charter, if I read thi= s from the perspective of someone who hasn=E2=80=99t been our meetings or l= istened to Justin=E2=80=99s presentations, I=E2=80=99m hard pressed to see = what the point of this group is, relative to the OAuth WG. I=E2=80=99d expe= ct this charter to provide at least a cursory explanation of what problem i= t is trying to solve. In this case, the problem should be partially defined= in relation to OAuth. What will this WG do that the OAuth WG hasn=E2=80=99= t already done or isn=E2=80=99t already doing?
>>
>> How about adding something like the following to paragraph 2:
>>
>> The protocol will mitigate many of the security concerns and techn= ical challenges of OAuth 2.0 by communicating over secure channels between = the client and the authorization server, and minimizing the amount of infor= mation transmitted over untrusted channels.
>>
>> =E2=80=93
>> Annabelle Richard Backman
>> AWS Identity
>>
>>
>>
>> From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com= >
>> Date: Friday, January 10, 2020 at 6:57 PM
>> To: Justin Richer <jricher@mit.edu>
>> Cc: "txa= uth@ietf.org" <txauth@ietf.org>
>> Subject: Re: [Txauth] alternative charter writeup
>>
>>
>>
>> This looks even better! Thanks Justin.
>>
>>
>> What do others think of the proposed charter now?
>>
>>
>> =E1=90=A7
>>
>>
>> On Fri, Jan 10, 2020 at 12:43 PM Justin Richer <jricher@mit.edu> wrote:
>>
>>
>> Thanks, Dick. I=E2=80=99ve been working on an updated charter base= d on everyone=E2=80=99s feedback, and I was aiming to have out today anyway= , so this timing is helpful. So here=E2=80=99s my take on a new charter, in= corporating some of your points below:
>>
>>
>>
>> This group is chartered to develop a delegation protocol for ident= ity, authorization, and API access. This protocol will allow an authorizing= party to delegate access to client software through an authorization serve= r. The use cases supported by this protocol will include widely deployed us= e cases currently supported by OAuth 2.0 and OpenID Connect.
>>
>>
>>
>> The delegation process will be acted upon by multiple parties in t= he protocol, each performing a specific role. The protocol will be initiate= d by the client interacting directly with the authorization server (in cont= rast with OAuth 2 which is initiated by the client redirecting the user=E2= =80=99s browser). The client will involve the authorizing party as necessar= y through interaction mechanisms indicated by the protocol.
>>
>>
>>
>> Additionally, the delegation process will allow for:
>>
>>
>>
>> - Fine-grained specification of resource access
>>
>> - Approval of identity claims and multiple resources in a single i= nteraction
>>
>> - Delegation between multiple users
>>
>> - Web, mobile, single-page, and other types of client 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 providing user, software, organization, and other= pieces of information used in authorization decisions
>>
>> - Token presentation mechanisms and key bindings
>>
>>
>>
>> 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 porting from OAuth 2.0 and OpenID Connect to the new p= rotocol where possible.
>>
>> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will see= k to take advantage of optimization features of HTTP2 and HTTP3, and will s= trive to enable simple mapping to other protocols such as COAP.
>>
>>
>>
>>
>>
>> On Jan 10, 2020, at 12:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote: >>
>>
>> Hey
>>
>>
>> I've written an alternative charter that I hope captures some = of the feedback on Justin's charter.
>>
>>
>>
>> I found it easier to rewrite the charter to broaden the marketplac= e of ideas.
>>
>>
>>
>> Key ideas:
>>
>>
>>
>> - This work supports existing OAuth 2.0, and OpenID Connect use ca= ses.
>>
>>
>>
>> - The client interacts directly with the authorization server. >>
>>
>>
>> /Dick
>>
>>
>>
>> ----
>>
>>
>> This group is chartered to develop a delegated identity and author= ization protocol.. The use cases supported by this protocol will include wi= dely deployed use cases currently supported by OAuth 2.0, and OpenID Connec= t. In contrast to OAuth 2.0 and OpenID Connect, where the protocol is initi= ated by redirecting the user's browser to an authorization server, this= protocol will be initiated by the client directly interacting with the aut= horization server..
>>
>>
>> Additionally, the protocol will allow:
>>
>> - fine-grained specification of resource access
>>
>> - the user to approve requests for identity claims and access to m= ultiple resources in one interaction
>>
>> - web, mobile, single-page, and other client applications
>>
>> - taking advantage of optimization features in HTTP2 and HTTP3
>>
>>
>> The group will define extension points for this protocol to allow = for flexibility in areas including:
>>
>>
>> - discovery of the authorization server
>>
>> - cryptographic agility for keys, message signatures, and proof of= possession
>>
>> - user interaction mechanisms including web and non-web methods- t= oken presentation mechanisms and key bindings
>>
>>
>> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, they will atte= mpt to simplify porting from OAuth 2.0 and OpenID Connect, and strive to re= use existing semantics such as client identifiers, OAuth 2.0 scopes and acc= ess tokens, and OpenID Connect ID Tokens and claims.
>>
>>
>> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will str= ive to enable simple mapping to other protocols such as COAP.
>>
>>
>>
>>
>>
>>
>>
>> =E1=90=A7
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>> --
>> 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
--0000000000002d7ebc059c4a16de-- From nobody Fri Jan 17 05:46: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 E19B312006E for ; Fri, 17 Jan 2020 05:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[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 Az09XUS_l5_t for ; Fri, 17 Jan 2020 05:46:47 -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 B250012001A for ; Fri, 17 Jan 2020 05:46:46 -0800 (PST) Received: from [192.168.1.16] (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 00HDkWtY025020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2020 08:46:33 -0500 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: <3119F975-5ED2-4E5E-B6D4-997871FF6EF6@hardjono.net> Date: Fri, 17 Jan 2020 08:46:32 -0500 Cc: Thomas Hardjono , "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0E3B0DF8-190F-4691-8AD6-8293BF8CFC91@mit.edu> References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <40DEDA03-58E1-46EE-A46E-15D448283762@hardjono.net> <5F952C70-8EE2-440A-9334-5FBC19CE2A5E@mit.edu> <301ADD9B-CCC9-447D-B652-EB377961FBD6@mit.edu> <3119F975-5ED2-4E5E-B6D4-997871FF6EF6@hardjono.net> To: Thomas Hardjono X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 17 Jan 2020 13:46:52 -0000 So really we=E2=80=99re talking about =E2=80=9Cdelegating to a piece of = software that someone else is using=E2=80=9D when we say =E2=80=9Cdelegati= on between multiple users=E2=80=9D.=20 Is there a better or more succinct way to put that in the charter text? = Really we want the RO/RqP separation that UMA gives us explicitly to be = an option here, and I think it naturally can be given our structure. =E2=80=94 Justin > On Jan 16, 2020, at 6:16 PM, Thomas Hardjono = wrote: >=20 > Yes, I see that sentence ("This protocol will allow an authorizing = party to delegate access to client software through an authorization = server"). That's very specific, which is good. >=20 > Just wanted to be sure that the bullet further below ("Delegation = between multiple users") also makes sense given that the first sentence = is talking about delegation to a piece of software. >=20 > It=E2=80=99s a big jump between (i) a person delegating to a piece of = software, to (ii) a person delegating to another person. >=20 > Sorry for being pedantic. >=20 >=20 >=20 > -- thomas -- >=20 >=20 >=20 > =EF=BB=BF-----Original Message----- > From: Justin Richer > Date: Thursday, January 16, 2020 at 5:50 PM > To: Thomas Hardjono > Cc: "hardjono@mit.edu" , "txauth@ietf.org" = > Subject: Re: [Txauth] alternative charter writeup >=20 > I get that, but that=E2=80=99s why the proposed charter text tries to = be very explicit about who is delegating to whom (or what) and for what = purpose. That=E2=80=99s why delegation to software and delegation = between users are both listed separately.=20 >=20 > =E2=80=94 Justin >=20 >> On Jan 16, 2020, at 4:07 PM, Thomas Hardjono = wrote: >>=20 >> The problem is that the word "delegation" is generally a very loaded = term. >>=20 >> I understand that WGs need wiggle room, but I'm concerned that this = kind of loose wording may cause confusion down the road. >>=20 >>=20 >>=20 >>>> What I think is very much out of scope is cross-domain policy = processing. >>=20 >> Agree. >>=20 >>=20 >>=20 >> =EF=BB=BF-----Original Message----- >> From: Txauth on behalf of Justin Richer = >> Date: Thursday, January 16, 2020 at 11:54 AM >> To: Thomas Hardjono >> Cc: "hardjono@mit.edu" , "txauth@ietf.org" = >> Subject: Re: [Txauth] alternative charter writeup >>=20 >> On Jan 16, 2020, at 11:43 AM, Thomas Hardjono = wrote: >>>=20 >>>=20 >>> Looks good, but I have a clarification question: >>>=20 >>>>>> - Delegation between multiple users >>>=20 >>> What does this mean exactly? >>>=20 >>> Is it the "multi-hop" delegation (Alice to Bob to Charlize to ...) >>>=20 >>> Or does it only the "1-hop" delegation concurrently (Alice to Bob; = Alice to Charlize; Alice to=E2=80=A6) >>=20 >> My thinking was that at the very least we want to allow the person = running the client software and the person doing the authorization to be = different people. This is the UMA use case (Alice to bob) and the CIBA = use case (agent getting someone to log in). I think chaining can follow = that, where Bob can then let Charlie do something. This is also along = the lines of the token exchange model of OAuth 2, with continuously = down-scoped access. >>=20 >> What I think is very much out of scope is cross-domain policy = processing.=20 >>=20 >> =E2=80=94 Justin >>=20 >>>=20 >>> -- thomas -- >>>=20 >>>=20 >>>=20 >>> =EF=BB=BF-----Original Message----- >>> From: Txauth on behalf of Justin Richer = >>> Date: Thursday, January 16, 2020 at 10:46 AM >>> To: "txauth@ietf.org" >>> Cc: "rdd@cert.org" , "Richard Backman, Annabelle" = , Benjamin Kaduk , Dick Hardt = >>> Subject: Re: [Txauth] alternative charter writeup >>>=20 >>> Here=E2=80=99s my updated text incorporating the feedback so far: >>>=20 >>>=20 >>> This group is chartered to develop a delegation protocol for = identity, authorization, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0 and = OpenID Connect (an extension of OAuth 2.0) as well as new use cases not = enabled by OAuth 2.0. >>>=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 which is initiated by = the client redirecting the user=E2=80=99s browser). The client will = involve the authorizing party as necessary through interaction = mechanisms indicated by the protocol. This decoupling avoids many of the = security concerns and technical challenges of OAuth 2.0 as well as = providing a non-invasive path for supporting future types of clients and = interaction channels. >>>=20 >>>=20 >>> Additionally, the delegation process will allow for: >>>=20 >>>=20 >>> - Fine-grained specification of resource access >>>=20 >>> - Approval of identity claims and multiple resources in a single = interaction >>>=20 >>> - Delegation between multiple users >>>=20 >>> - Web, mobile, single-page, interaction-constrained, and other types = of client applications >>>=20 >>>=20 >>> The group will define extension points for this protocol to allow = for flexibility in areas including: >>>=20 >>>=20 >>> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >>>=20 >>> - User interaction mechanisms including web and non-web methods >>>=20 >>> - Mechanisms for providing user, software, organization, and other = pieces of information used in authorization decisions >>>=20 >>> - Token presentation mechanisms and key bindings >>>=20 >>>=20 >>> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including: >>>=20 >>>=20 >>> - Discovery of the authorization server >>>=20 >>> - Revocation of active tokens >>>=20 >>> - Query of token rights by resource servers >>>=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 porting from OAuth 2.0 and OpenID Connect to the new = protocol where possible. >>>=20 >>>=20 >>> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3 where = possible, and will strive to enable simple mapping to other protocols = such as COAP. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> It=E2=80=99s definitely a lot, but I think we=E2=80=99ve got a good = handle on what we=E2=80=99re working on, and what the boundaries are. I = think this is both too much of an effort and too much of a break to do = this in the OAuth WG, where there=E2=80=99s already still plenty of work = to be done. We=E2=80=99re leaning a lot on lessons learned from the = OAuth 2 world and its extensions, including OIDC and UMA2. We=E2=80=99ve = got the attention of a lot of the right people to start this as well. >>>=20 >>> So to the AD=E2=80=99s: Ben and Roman =E2=80=94 what=E2=80=99s the = next step? This should be a new working group and like to get it started = so that we can have our first meeting in Vancouver. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>=20 >>> On Jan 14, 2020, at 12:12 AM, Dick Hardt = wrote: >>>=20 >>> Sounds good to me. >>>=20 >>> On Mon, Jan 13, 2020 at 6:24 PM Justin Richer = wrote: >>>=20 >>>=20 >>> I can get behind this kind of addition. I like Annabelle=E2=80=99s = framing of it in terms of decoupling, and some explanation of why = we=E2=80=99re doing it in relation to OAuth 2=E2=80=99s approach. One of = the key things, to me, is that we=E2=80=99re making a break from OAuth = 2=E2=80=99s core architecture but doing so for very specific reasons.=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>=20 >>> On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle = wrote: >>>=20 >>> It=E2=80=99s not just about the initial communication, though. I the = key thing to emphasize is the decoupling the protocol from delegation = channels, which addresses the aforementioned security/complexity issues = and also provides a path to support future delegation channel types = without significant changes to the protocol (unlike OAuth 2.0, where = extensions like Device Flow and PAR introduce substantial changes to the = core protocol flow on both client and AS). Since the protocol isn=E2=80=99= t assuming a particular front channel, it=E2=80=99s easier to add = support for a new one. >>>=20 >>> Proposal, altered from Dick=E2=80=99s suggestion: >>> This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. This protocol will be = decoupled from delegation channels such as an end user=E2=80=99s web = browser and operate primarily through a channel between the client and = the authorization server, avoiding many of the security concerns and = technical challenges of OAuth 2.0 and providing a non-invasive path for = adding support for future types of clients and delegation channels. >>>=20 >>> =E2=80=93=20 >>> Annabelle Richard Backman >>> AWS Identity >>>=20 >>>=20 >>>=20 >>> From: Dick Hardt >>> Date: Monday, January 13, 2020 at 4:35 PM >>> To: "Richard Backman, Annabelle" >>> Cc: Justin Richer , "txauth@ietf.org" = >>> Subject: Re: [Txauth] alternative charter writeup >>>=20 >>>=20 >>>=20 >>> I agree, some more "why" would help a broader audience understand = the motivations. How about this change to the first paragraph? >>>=20 >>>=20 >>>=20 >>> This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. In contrast to OAuth 2.0, = where the protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server, which will mitigate = many of the security concerns and technical challenges of OAuth 2.0. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle = wrote: >>>=20 >>>=20 >>> While I agree with the goals stated in this charter, if I read this = from the perspective of someone who hasn=E2=80=99t been our meetings or = listened to Justin=E2=80=99s presentations, I=E2=80=99m hard pressed to = see what the point of this group is, relative to the OAuth WG. I=E2=80=99d= expect this charter to provide at least a cursory explanation of what = problem it is trying to solve. In this case, the problem should be = partially defined in relation to OAuth. What will this WG do that the = OAuth WG hasn=E2=80=99t already done or isn=E2=80=99t already doing? >>>=20 >>> How about adding something like the following to paragraph 2: >>>=20 >>> The protocol will mitigate many of the security concerns and = technical challenges of OAuth 2.0 by communicating over secure channels = between the client and the authorization server, and minimizing the = amount of information transmitted over untrusted channels. >>>=20 >>> =E2=80=93=20 >>> Annabelle Richard Backman >>> AWS Identity >>>=20 >>>=20 >>>=20 >>> From: Txauth on behalf of Dick Hardt = >>> Date: Friday, January 10, 2020 at 6:57 PM >>> To: Justin Richer >>> Cc: "txauth@ietf.org" >>> Subject: Re: [Txauth] alternative charter writeup >>>=20 >>>=20 >>>=20 >>> This looks even better! Thanks Justin. >>>=20 >>>=20 >>> What do others think of the proposed charter now?=20 >>>=20 >>>=20 >>> =E1=90=A7 >>>=20 >>>=20 >>> On Fri, Jan 10, 2020 at 12:43 PM Justin Richer = wrote: >>>=20 >>>=20 >>> Thanks, Dick. I=E2=80=99ve been working on an updated charter based = on everyone=E2=80=99s feedback, and I was aiming to have out today = anyway, so this timing is helpful. So here=E2=80=99s my take on a new = charter, incorporating some of your points below:=20 >>>=20 >>>=20 >>>=20 >>> This group is chartered to develop a delegation protocol for = identity, authorization, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0 and = OpenID Connect.=20 >>>=20 >>>=20 >>>=20 >>> The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will be = initiated by the client interacting directly with the authorization = server (in contrast with OAuth 2 which is initiated by the client = redirecting the user=E2=80=99s browser). The client will involve the = authorizing party as necessary through interaction mechanisms indicated = by the protocol.=20 >>>=20 >>>=20 >>>=20 >>> Additionally, the delegation process will allow for: >>>=20 >>>=20 >>>=20 >>> - Fine-grained specification of resource access >>>=20 >>> - Approval of identity claims and multiple resources in a single = interaction >>>=20 >>> - Delegation between multiple users >>>=20 >>> - Web, mobile, single-page, and other types of client applications >>>=20 >>>=20 >>>=20 >>> The group will define extension points for this protocol to allow = for flexibility in areas including: >>>=20 >>>=20 >>>=20 >>> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >>>=20 >>> - User interaction mechanisms including web and non-web methods >>>=20 >>> - Mechanisms for providing user, software, organization, and other = pieces of information used in authorization decisions >>>=20 >>> - Token presentation mechanisms and key bindings >>>=20 >>>=20 >>>=20 >>> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including: >>>=20 >>>=20 >>>=20 >>> - Discovery of the authorization server >>>=20 >>> - Revocation of active tokens >>>=20 >>> - Query of token rights by resource servers >>>=20 >>>=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 porting from OAuth 2.0 and OpenID Connect to the new = protocol where possible. >>>=20 >>> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3, and = will strive to enable simple mapping to other protocols such as COAP. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Jan 10, 2020, at 12:04 PM, Dick Hardt = wrote: >>>=20 >>>=20 >>> Hey >>>=20 >>>=20 >>> I've written an alternative charter that I hope captures some of the = feedback on Justin's charter. >>>=20 >>>=20 >>>=20 >>> I found it easier to rewrite the charter to broaden the marketplace = of ideas.=20 >>>=20 >>>=20 >>>=20 >>> Key ideas: >>>=20 >>>=20 >>>=20 >>> - This work supports existing OAuth 2.0, and OpenID Connect use = cases. >>>=20 >>>=20 >>>=20 >>> - The client interacts directly with the authorization server.=20 >>>=20 >>>=20 >>>=20 >>> /Dick >>>=20 >>>=20 >>>=20 >>> ---- >>>=20 >>>=20 >>> This group is chartered to develop a delegated identity and = authorization protocol.. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the = protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server.. >>>=20 >>>=20 >>> Additionally, the protocol will allow: >>>=20 >>> - fine-grained specification of resource access >>>=20 >>> - the user to approve requests for identity claims and access to = multiple resources in one interaction >>>=20 >>> - web, mobile, single-page, and other client applications >>>=20 >>> - taking advantage of optimization features in HTTP2 and HTTP3 >>>=20 >>>=20 >>> The group will define extension points for this protocol to allow = for flexibility in areas including: >>>=20 >>>=20 >>> - discovery of the authorization server >>>=20 >>> - cryptographic agility for keys, message signatures, and proof of = possession=20 >>>=20 >>> - user interaction mechanisms including web and non-web methods- = token presentation mechanisms and key bindings >>>=20 >>>=20 >>> Although the artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 or OpenID Connect, they will = attempt to simplify porting from OAuth 2.0 and OpenID Connect, and = strive to reuse existing semantics such as client identifiers, OAuth 2.0 = scopes and access tokens, and OpenID Connect ID Tokens and claims. >>>=20 >>>=20 >>> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = strive to enable simple mapping to other protocols such as COAP. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> =E1=90=A7 >>>=20 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=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 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >>=20 >>=20 >=20 >=20 >=20 From nobody Fri Jan 17 05: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 19B2C12001A for ; Fri, 17 Jan 2020 05:47:09 -0800 (PST) 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 T_iJMvK9FqgK for ; Fri, 17 Jan 2020 05:47:04 -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 5E52912006E for ; Fri, 17 Jan 2020 05:47:03 -0800 (PST) Received: from [192.168.1.16] (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 00HDkWtZ025020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2020 08:46:49 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1639EF8C-1FC5-4CEE-8A73-C2C1D34C553F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 17 Jan 2020 08:46:49 -0500 In-Reply-To: Cc: Thomas Hardjono , Thomas Hardjono , "txauth@ietf.org" To: Dick Hardt References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <40DEDA03-58E1-46EE-A46E-15D448283762@hardjono.net> <5F952C70-8EE2-440A-9334-5FBC19CE2A5E@mit.edu> <301ADD9B-CCC9-447D-B652-EB377961FBD6@mit.edu> <3119F975-5ED2-4E5E-B6D4-997871FF6EF6@hardjono.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 17 Jan 2020 13:47:09 -0000 --Apple-Mail=_1639EF8C-1FC5-4CEE-8A73-C2C1D34C553F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, this. > On Jan 16, 2020, at 6:21 PM, Dick Hardt wrote: >=20 > What I have understood we are enabling is a separation between the = user using the client software, and the user that is the resource owner.=20= >=20 > Justin: is that what you had in mind? > =E1=90=A7 >=20 > On Thu, Jan 16, 2020 at 3:17 PM Thomas Hardjono = > wrote: > Yes, I see that sentence ("This protocol will allow an authorizing = party to delegate access to client software through an authorization = server"). That's very specific, which is good. >=20 > Just wanted to be sure that the bullet further below ("Delegation = between multiple users") also makes sense given that the first sentence = is talking about delegation to a piece of software. >=20 > It=E2=80=99s a big jump between (i) a person delegating to a piece of = software, to (ii) a person delegating to another person. >=20 > Sorry for being pedantic. >=20 >=20 >=20 > -- thomas -- >=20 >=20 >=20 > =EF=BB=BF-----Original Message----- > From: Justin Richer > > Date: Thursday, January 16, 2020 at 5:50 PM > To: Thomas Hardjono > > Cc: "hardjono@mit.edu " >, "txauth@ietf.org " = > > Subject: Re: [Txauth] alternative charter writeup >=20 > I get that, but that=E2=80=99s why the proposed charter text tries to = be very explicit about who is delegating to whom (or what) and for what = purpose. That=E2=80=99s why delegation to software and delegation = between users are both listed separately.=20 >=20 > =E2=80=94 Justin >=20 > > On Jan 16, 2020, at 4:07 PM, Thomas Hardjono = > wrote: > >=20 > > The problem is that the word "delegation" is generally a very loaded = term. > >=20 > > I understand that WGs need wiggle room, but I'm concerned that this = kind of loose wording may cause confusion down the road. > >=20 > >=20 > >=20 > >>> What I think is very much out of scope is cross-domain policy = processing. > >=20 > > Agree. > >=20 > >=20 > >=20 > > =EF=BB=BF-----Original Message----- > > From: Txauth > on behalf of Justin Richer = > > > Date: Thursday, January 16, 2020 at 11:54 AM > > To: Thomas Hardjono > > > Cc: "hardjono@mit.edu " >, "txauth@ietf.org " = > > > Subject: Re: [Txauth] alternative charter writeup > >=20 > > On Jan 16, 2020, at 11:43 AM, Thomas Hardjono = > wrote: > >>=20 > >>=20 > >> Looks good, but I have a clarification question: > >>=20 > >>>>> - Delegation between multiple users > >>=20 > >> What does this mean exactly? > >>=20 > >> Is it the "multi-hop" delegation (Alice to Bob to Charlize to ...) > >>=20 > >> Or does it only the "1-hop" delegation concurrently (Alice to Bob; = Alice to Charlize; Alice to=E2=80=A6) > >=20 > > My thinking was that at the very least we want to allow the person = running the client software and the person doing the authorization to be = different people. This is the UMA use case (Alice to bob) and the CIBA = use case (agent getting someone to log in). I think chaining can follow = that, where Bob can then let Charlie do something. This is also along = the lines of the token exchange model of OAuth 2, with continuously = down-scoped access. > >=20 > > What I think is very much out of scope is cross-domain policy = processing.=20 > >=20 > > =E2=80=94 Justin > >=20 > >>=20 > >> -- thomas -- > >>=20 > >>=20 > >>=20 > >> =EF=BB=BF-----Original Message----- > >> From: Txauth > on behalf of Justin Richer = > > >> Date: Thursday, January 16, 2020 at 10:46 AM > >> To: "txauth@ietf.org " > > >> Cc: "rdd@cert.org " >, "Richard Backman, Annabelle" = >, Benjamin Kaduk = >, Dick Hardt > > >> Subject: Re: [Txauth] alternative charter writeup > >>=20 > >> Here=E2=80=99s my updated text incorporating the feedback so far: > >>=20 > >>=20 > >> This group is chartered to develop a delegation protocol for = identity, authorization, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0 and = OpenID Connect (an extension of OAuth 2.0) as well as new use cases not = enabled by OAuth 2.0. > >>=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 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client will involve the authorizing party as necessary through = interaction mechanisms indicated by the protocol. This decoupling avoids = many of the security concerns and technical challenges of OAuth 2.0 as = well as providing a non-invasive path for supporting future types of = clients and interaction channels. > >>=20 > >>=20 > >> Additionally, the delegation process will allow for: > >>=20 > >>=20 > >> - Fine-grained specification of resource access > >>=20 > >> - Approval of identity claims and multiple resources in a single = interaction > >>=20 > >> - Delegation between multiple users > >>=20 > >> - Web, mobile, single-page, interaction-constrained, and other = types of client applications > >>=20 > >>=20 > >> The group will define extension points for this protocol to allow = for flexibility in areas including: > >>=20 > >>=20 > >> - Cryptographic agility for keys, message signatures, and proof of = possession=20 > >>=20 > >> - User interaction mechanisms including web and non-web methods > >>=20 > >> - Mechanisms for providing user, software, organization, and other = pieces of information used in authorization decisions > >>=20 > >> - Token presentation mechanisms and key bindings > >>=20 > >>=20 > >> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including: > >>=20 > >>=20 > >> - Discovery of the authorization server > >>=20 > >> - Revocation of active tokens > >>=20 > >> - Query of token rights by resource servers > >>=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 porting from OAuth 2.0 and OpenID Connect to = the new protocol where possible. > >>=20 > >>=20 > >> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3 where = possible, and will strive to enable simple mapping to other protocols = such as COAP. > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >> It=E2=80=99s definitely a lot, but I think we=E2=80=99ve got a good = handle on what we=E2=80=99re working on, and what the boundaries are. I = think this is both too much of an effort and too much of a break to do = this in the OAuth WG, where there=E2=80=99s already still plenty of work = to be done. We=E2=80=99re leaning a lot on lessons learned from the = OAuth 2 world and its extensions, including OIDC and UMA2. We=E2=80=99ve = got the attention of a lot of the right people to start this as well. > >>=20 > >> So to the AD=E2=80=99s: Ben and Roman =E2=80=94 what=E2=80=99s the = next step? This should be a new working group and like to get it started = so that we can have our first meeting in Vancouver. > >>=20 > >> =E2=80=94 Justin > >>=20 > >>=20 > >> On Jan 14, 2020, at 12:12 AM, Dick Hardt > wrote: > >>=20 > >> Sounds good to me. > >>=20 > >> On Mon, Jan 13, 2020 at 6:24 PM Justin Richer > wrote: > >>=20 > >>=20 > >> I can get behind this kind of addition. I like Annabelle=E2=80=99s = framing of it in terms of decoupling, and some explanation of why = we=E2=80=99re doing it in relation to OAuth 2=E2=80=99s approach. One of = the key things, to me, is that we=E2=80=99re making a break from OAuth = 2=E2=80=99s core architecture but doing so for very specific reasons.=20 > >>=20 > >> =E2=80=94 Justin > >>=20 > >>=20 > >> On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle = > wrote: > >>=20 > >> It=E2=80=99s not just about the initial communication, though. I = the key thing to emphasize is the decoupling the protocol from = delegation channels, which addresses the aforementioned = security/complexity issues and also provides a path to support future = delegation channel types without significant changes to the protocol = (unlike OAuth 2.0, where extensions like Device Flow and PAR introduce = substantial changes to the core protocol flow on both client and AS). = Since the protocol isn=E2=80=99t assuming a particular front channel, = it=E2=80=99s easier to add support for a new one. > >>=20 > >> Proposal, altered from Dick=E2=80=99s suggestion: > >> This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. This protocol will be = decoupled from delegation channels such as an end user=E2=80=99s web = browser and operate primarily through a channel between the client and = the authorization server, avoiding many of the security concerns and = technical challenges of OAuth 2.0 and providing a non-invasive path for = adding support for future types of clients and delegation channels. > >>=20 > >> =E2=80=93=20 > >> Annabelle Richard Backman > >> AWS Identity > >>=20 > >>=20 > >>=20 > >> From: Dick Hardt > > >> Date: Monday, January 13, 2020 at 4:35 PM > >> To: "Richard Backman, Annabelle" > > >> Cc: Justin Richer >, = "txauth@ietf.org " > > >> Subject: Re: [Txauth] alternative charter writeup > >>=20 > >>=20 > >>=20 > >> I agree, some more "why" would help a broader audience understand = the motivations. How about this change to the first paragraph? > >>=20 > >>=20 > >>=20 > >> This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. In contrast to OAuth 2.0, = where the protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server, which will mitigate = many of the security concerns and technical challenges of OAuth 2.0. > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >> On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle = > wrote: > >>=20 > >>=20 > >> While I agree with the goals stated in this charter, if I read this = from the perspective of someone who hasn=E2=80=99t been our meetings or = listened to Justin=E2=80=99s presentations, I=E2=80=99m hard pressed to = see what the point of this group is, relative to the OAuth WG. I=E2=80=99d= expect this charter to provide at least a cursory explanation of what = problem it is trying to solve. In this case, the problem should be = partially defined in relation to OAuth. What will this WG do that the = OAuth WG hasn=E2=80=99t already done or isn=E2=80=99t already doing? > >>=20 > >> How about adding something like the following to paragraph 2: > >>=20 > >> The protocol will mitigate many of the security concerns and = technical challenges of OAuth 2.0 by communicating over secure channels = between the client and the authorization server, and minimizing the = amount of information transmitted over untrusted channels. > >>=20 > >> =E2=80=93=20 > >> Annabelle Richard Backman > >> AWS Identity > >>=20 > >>=20 > >>=20 > >> From: Txauth > on behalf of Dick Hardt = > > >> Date: Friday, January 10, 2020 at 6:57 PM > >> To: Justin Richer > > >> Cc: "txauth@ietf.org " > > >> Subject: Re: [Txauth] alternative charter writeup > >>=20 > >>=20 > >>=20 > >> This looks even better! Thanks Justin. > >>=20 > >>=20 > >> What do others think of the proposed charter now?=20 > >>=20 > >>=20 > >> =E1=90=A7 > >>=20 > >>=20 > >> On Fri, Jan 10, 2020 at 12:43 PM Justin Richer > wrote: > >>=20 > >>=20 > >> Thanks, Dick. I=E2=80=99ve been working on an updated charter based = on everyone=E2=80=99s feedback, and I was aiming to have out today = anyway, so this timing is helpful. So here=E2=80=99s my take on a new = charter, incorporating some of your points below:=20 > >>=20 > >>=20 > >>=20 > >> This group is chartered to develop a delegation protocol for = identity, authorization, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0 and = OpenID Connect.=20 > >>=20 > >>=20 > >>=20 > >> The delegation process will be acted upon by multiple parties in = the protocol, each performing a specific role. The protocol will be = initiated by the client interacting directly with the authorization = server (in contrast with OAuth 2 which is initiated by the client = redirecting the user=E2=80=99s browser). The client will involve the = authorizing party as necessary through interaction mechanisms indicated = by the protocol.=20 > >>=20 > >>=20 > >>=20 > >> Additionally, the delegation process will allow for: > >>=20 > >>=20 > >>=20 > >> - Fine-grained specification of resource access > >>=20 > >> - Approval of identity claims and multiple resources in a single = interaction > >>=20 > >> - Delegation between multiple users > >>=20 > >> - Web, mobile, single-page, and other types of client applications > >>=20 > >>=20 > >>=20 > >> The group will define extension points for this protocol to allow = for flexibility in areas including: > >>=20 > >>=20 > >>=20 > >> - Cryptographic agility for keys, message signatures, and proof of = possession=20 > >>=20 > >> - User interaction mechanisms including web and non-web methods > >>=20 > >> - Mechanisms for providing user, software, organization, and other = pieces of information used in authorization decisions > >>=20 > >> - Token presentation mechanisms and key bindings > >>=20 > >>=20 > >>=20 > >> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including: > >>=20 > >>=20 > >>=20 > >> - Discovery of the authorization server > >>=20 > >> - Revocation of active tokens > >>=20 > >> - Query of token rights by resource servers > >>=20 > >>=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 porting from OAuth 2.0 and OpenID Connect to = the new protocol where possible. > >>=20 > >> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3, and = will strive to enable simple mapping to other protocols such as COAP. > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >> On Jan 10, 2020, at 12:04 PM, Dick Hardt > wrote: > >>=20 > >>=20 > >> Hey > >>=20 > >>=20 > >> I've written an alternative charter that I hope captures some of = the feedback on Justin's charter. > >>=20 > >>=20 > >>=20 > >> I found it easier to rewrite the charter to broaden the marketplace = of ideas.=20 > >>=20 > >>=20 > >>=20 > >> Key ideas: > >>=20 > >>=20 > >>=20 > >> - This work supports existing OAuth 2.0, and OpenID Connect use = cases. > >>=20 > >>=20 > >>=20 > >> - The client interacts directly with the authorization server.=20 > >>=20 > >>=20 > >>=20 > >> /Dick > >>=20 > >>=20 > >>=20 > >> ---- > >>=20 > >>=20 > >> This group is chartered to develop a delegated identity and = authorization protocol.. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the = protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server.. > >>=20 > >>=20 > >> Additionally, the protocol will allow: > >>=20 > >> - fine-grained specification of resource access > >>=20 > >> - the user to approve requests for identity claims and access to = multiple resources in one interaction > >>=20 > >> - web, mobile, single-page, and other client applications > >>=20 > >> - taking advantage of optimization features in HTTP2 and HTTP3 > >>=20 > >>=20 > >> The group will define extension points for this protocol to allow = for flexibility in areas including: > >>=20 > >>=20 > >> - discovery of the authorization server > >>=20 > >> - cryptographic agility for keys, message signatures, and proof of = possession=20 > >>=20 > >> - user interaction mechanisms including web and non-web methods- = token presentation mechanisms and key bindings > >>=20 > >>=20 > >> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, they will = attempt to simplify porting from OAuth 2.0 and OpenID Connect, and = strive to reuse existing semantics such as client identifiers, OAuth 2.0 = scopes and access tokens, and OpenID Connect ID Tokens and claims. > >>=20 > >>=20 > >> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = strive to enable simple mapping to other protocols such as COAP. > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >> =E1=90=A7 > >>=20 > >> --=20 > >> Txauth mailing list > >> Txauth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth = > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=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 > > --=20 > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth = > >=20 > >=20 >=20 >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_1639EF8C-1FC5-4CEE-8A73-C2C1D34C553F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes, = this.

On Jan 16, 2020, at 6:21 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:

What I have understood we = are enabling is a separation between the user using the client software, = and the user that is the resource owner. 

Justin: is that what you had in = mind?
3D""=E1=90=A7

On Thu, Jan = 16, 2020 at 3:17 PM Thomas Hardjono <ietf-txauth@hardjono.net> wrote:
Yes, I see that sentence ("This = protocol will allow an authorizing party to delegate access to client = software through an authorization server"). That's very specific, which = is good.

Just wanted to be sure that the bullet further below ("Delegation = between multiple users") also makes sense given that the first sentence = is talking about delegation to a piece of software.

It=E2=80=99s a big jump between (i) a person delegating to a piece of = software, to (ii) a person delegating to another person.

Sorry for being pedantic.



-- thomas --



=EF=BB=BF-----Original Message-----
From: Justin Richer <jricher@mit.edu>
Date: Thursday, January 16, 2020 at 5:50 PM
To: Thomas Hardjono <ietf-txauth@hardjono.net>
Cc: "hardjono@mit.edu" <hardjono@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] alternative charter writeup

I get that, but that=E2=80=99s why the proposed charter text tries to be = very explicit about who is delegating to whom (or what) and for what = purpose. That=E2=80=99s why delegation to software and delegation = between users are both listed separately.

 =E2=80=94 Justin

> On Jan 16, 2020, at 4:07 PM, Thomas Hardjono <ietf-txauth@hardjono.net> wrote:
>
> The problem is that the word "delegation" is generally a very = loaded term.
>
> I understand that WGs need wiggle room, but I'm concerned that this = kind of loose wording may cause confusion down the road.
>
>
>
>>> What I think is very much out of scope is cross-domain = policy processing.
>
> Agree.
>
>
>
> =EF=BB=BF-----Original Message-----
> From: Txauth <txauth-bounces@ietf.org> on behalf = of Justin Richer <jricher@mit.edu>
> Date: Thursday, January 16, 2020 at 11:54 AM
> To: Thomas Hardjono <ietf-txauth@hardjono.net>
> Cc: "hardjono@mit.edu" <hardjono@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
> Subject: Re: [Txauth] alternative charter writeup
>
> On Jan 16, 2020, at 11:43 AM, Thomas Hardjono <ietf-txauth@hardjono.net> wrote:
>>
>>
>> Looks good, but I have a clarification question:
>>
>>>>> - Delegation between multiple users
>>
>> What does this mean exactly?
>>
>> Is it the "multi-hop" delegation (Alice to Bob to Charlize to = ...)
>>
>> Or does it only the "1-hop" delegation concurrently (Alice to = Bob; Alice to Charlize; Alice to=E2=80=A6)
>
> My thinking was that at the very least we want to allow the person = running the client software and the person doing the authorization to be = different people. This is the UMA use case (Alice to bob) and the CIBA = use case (agent getting someone to log in). I think chaining can follow = that, where Bob can then let Charlie do something. This is also along = the lines of the token exchange model of OAuth 2, with continuously = down-scoped access.
>
> What I think is very much out of scope is cross-domain policy = processing.
>
> =E2=80=94 Justin
>
>>
>> -- thomas --
>>
>>
>>
>> =EF=BB=BF-----Original Message-----
>> From: Txauth <txauth-bounces@ietf.org> on behalf = of Justin Richer <jricher@mit.edu>
>> Date: Thursday, January 16, 2020 at 10:46 AM
>> To: "txauth@ietf.org" <txauth@ietf.org>
>> Cc: "rdd@cert.org" <rdd@cert.org>, "Richard Backman, = Annabelle" <richanna@amazon.com>, Benjamin Kaduk <kaduk@mit.edu>, Dick Hardt <dick.hardt@gmail.com>
>> Subject: Re: [Txauth] alternative charter writeup
>>
>> Here=E2=80=99s my updated text incorporating the feedback so = far:
>>
>>
>> This group is chartered to develop a delegation protocol for = identity, authorization, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0 and = OpenID Connect (an extension of OAuth 2.0) as well as new use cases not = enabled by OAuth 2.0.
>>
>>
>> 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 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client will involve the authorizing party as necessary through = interaction mechanisms indicated by the protocol. This decoupling avoids = many of the security concerns and technical challenges of OAuth 2.0 as = well as providing a non-invasive path for supporting future types of = clients and interaction channels.
>>
>>
>> Additionally, the delegation process will allow for:
>>
>>
>> - Fine-grained specification of resource access
>>
>> - Approval of identity claims and multiple resources in a = single interaction
>>
>> - Delegation between multiple users
>>
>> - Web, mobile, single-page, interaction-constrained, and other = types of client 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 providing user, software, organization, and = other pieces of information used in authorization decisions
= >>
>> - Token presentation mechanisms and key bindings
>>
>>
>> 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 porting from OAuth 2.0 and OpenID = Connect to the new protocol where possible.
>>
>>
>> While the initial work will focus on using HTTP for = communication between the client and the authorization server, the = working group will seek to take advantage of optimization features of = HTTP2 and HTTP3 where possible, and will strive to enable simple mapping = to other protocols such as COAP.
>>
>>
>>
>>
>>
>> It=E2=80=99s definitely a lot, but I think we=E2=80=99ve got a = good handle on what we=E2=80=99re working on, and what the boundaries = are. I think this is both too much of an effort and too much of a break = to do this in the OAuth WG, where there=E2=80=99s already still plenty = of work to be done. We=E2=80=99re leaning a lot on lessons learned from = the OAuth 2 world and its extensions, including OIDC and UMA2. We=E2=80=99= ve got the attention of a lot of the right people to start this as = well.
>>
>> So to the AD=E2=80=99s: Ben and Roman =E2=80=94 what=E2=80=99s = the next step? This should be a new working group and like to get it = started so that we can have our first meeting in Vancouver.
= >>
>> =E2=80=94 Justin
>>
>>
>> On Jan 14, 2020, at 12:12 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>> Sounds good to me.
>>
>> On Mon, Jan 13, 2020 at 6:24 PM Justin Richer <jricher@mit.edu> wrote:
>>
>>
>> I can get behind this kind of addition. I like Annabelle=E2=80=99= s framing of it in terms of decoupling, and some explanation of why = we=E2=80=99re doing it in relation to OAuth 2=E2=80=99s approach. One of = the key things, to me, is that we=E2=80=99re making a break from OAuth = 2=E2=80=99s core architecture but doing so for very specific reasons. =
>>
>> =E2=80=94 Justin
>>
>>
>> On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
>>
>> It=E2=80=99s not just about the initial communication, though. = I the key thing to emphasize is the decoupling the protocol from = delegation channels, which addresses the aforementioned = security/complexity issues and also provides a path to support future = delegation channel types without significant changes to the protocol = (unlike OAuth 2.0, where extensions like Device Flow and PAR introduce = substantial changes to the core protocol flow on both client and AS). = Since the protocol isn=E2=80=99t assuming a particular front channel, = it=E2=80=99s easier to add support for a new one.
>>
>> Proposal, altered from Dick=E2=80=99s suggestion:
>> This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. This protocol will be = decoupled from delegation channels such as an end user=E2=80=99s web = browser and operate primarily through a channel between the client and = the authorization server, avoiding many of the security concerns and = technical challenges of OAuth 2.0 and providing a non-invasive path for = adding support for future types of clients and delegation channels.
>>
>> =E2=80=93
>> Annabelle Richard Backman
>> AWS Identity
>>
>>
>>
>> From: Dick Hardt <dick.hardt@gmail.com>
>> Date: Monday, January 13, 2020 at 4:35 PM
>> To: "Richard Backman, Annabelle" <richanna@amazon.com>
>> Cc: Justin Richer <jricher@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
>> Subject: Re: [Txauth] alternative charter writeup
>>
>>
>>
>> I agree, some more "why" would help a broader audience = understand the motivations. How about this change to the first = paragraph?
>>
>>
>>
>> This group is chartered to develop a delegated identity and = authorization protocol. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect, an extension of OAuth 2.0. In contrast to OAuth 2.0, = where the protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server, which will mitigate = many of the security concerns and technical challenges of OAuth 2.0.
>>
>>
>>
>>
>>
>> On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle = <richanna@amazon.com> wrote:
>>
>>
>> While I agree with the goals stated in this charter, if I read = this from the perspective of someone who hasn=E2=80=99t been our = meetings or listened to Justin=E2=80=99s presentations, I=E2=80=99m hard = pressed to see what the point of this group is, relative to the OAuth = WG. I=E2=80=99d expect this charter to provide at least a cursory = explanation of what problem it is trying to solve. In this case, the = problem should be partially defined in relation to OAuth. What will this = WG do that the OAuth WG hasn=E2=80=99t already done or isn=E2=80=99t = already doing?
>>
>> How about adding something like the following to paragraph = 2:
>>
>> The protocol will mitigate many of the security concerns and = technical challenges of OAuth 2.0 by communicating over secure channels = between the client and the authorization server, and minimizing the = amount of information transmitted over untrusted channels.
>>
>> =E2=80=93
>> Annabelle Richard Backman
>> AWS Identity
>>
>>
>>
>> From: Txauth <txauth-bounces@ietf.org> on behalf = of Dick Hardt <dick.hardt@gmail.com>
>> Date: Friday, January 10, 2020 at 6:57 PM
>> To: Justin Richer <jricher@mit.edu>
>> Cc: "txauth@ietf.org" <txauth@ietf.org>
>> Subject: Re: [Txauth] alternative charter writeup
>>
>>
>>
>> This looks even better! Thanks Justin.
>>
>>
>> What do others think of the proposed charter now?
= >>
>>
>> =E1=90=A7
>>
>>
>> On Fri, Jan 10, 2020 at 12:43 PM Justin Richer <jricher@mit.edu> wrote:
>>
>>
>> Thanks, Dick. I=E2=80=99ve been working on an updated charter = based on everyone=E2=80=99s feedback, and I was aiming to have out today = anyway, so this timing is helpful. So here=E2=80=99s my take on a new = charter, incorporating some of your points below:
>>
>>
>>
>> This group is chartered to develop a delegation protocol for = identity, authorization, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0 and = OpenID Connect.
>>
>>
>>
>> The delegation process will be acted upon by multiple parties = in the protocol, each performing a specific role. The protocol will be = initiated by the client interacting directly with the authorization = server (in contrast with OAuth 2 which is initiated by the client = redirecting the user=E2=80=99s browser). The client will involve the = authorizing party as necessary through interaction mechanisms indicated = by the protocol.
>>
>>
>>
>> Additionally, the delegation process will allow for:
>>
>>
>>
>> - Fine-grained specification of resource access
>>
>> - Approval of identity claims and multiple resources in a = single interaction
>>
>> - Delegation between multiple users
>>
>> - Web, mobile, single-page, and other types of client = 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 providing user, software, organization, and = other pieces of information used in authorization decisions
= >>
>> - Token presentation mechanisms and key bindings
>>
>>
>>
>> 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 porting from OAuth 2.0 and OpenID = Connect to the new protocol where possible.
>>
>> While the initial work will focus on using HTTP for = communication between the client and the authorization server, the = working group will seek to take advantage of optimization features of = HTTP2 and HTTP3, and will strive to enable simple mapping to other = protocols such as COAP.
>>
>>
>>
>>
>>
>> On Jan 10, 2020, at 12:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>>
>> Hey
>>
>>
>> I've written an alternative charter that I hope captures some = of the feedback on Justin's charter.
>>
>>
>>
>> I found it easier to rewrite the charter to broaden the = marketplace of ideas.
>>
>>
>>
>> Key ideas:
>>
>>
>>
>> - This work supports existing OAuth 2.0, and OpenID Connect use = cases.
>>
>>
>>
>> - The client interacts directly with the authorization server. =
>>
>>
>>
>> /Dick
>>
>>
>>
>> ----
>>
>>
>> This group is chartered to develop a delegated identity and = authorization protocol.. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0, and = OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the = protocol is initiated by redirecting the user's browser to an = authorization server, this protocol will be initiated by the client = directly interacting with the authorization server..
>>
>>
>> Additionally, the protocol will allow:
>>
>> - fine-grained specification of resource access
>>
>> - the user to approve requests for identity claims and access = to multiple resources in one interaction
>>
>> - web, mobile, single-page, and other client applications
>>
>> - taking advantage of optimization features in HTTP2 and = HTTP3
>>
>>
>> The group will define extension points for this protocol to = allow for flexibility in areas including:
>>
>>
>> - discovery of the authorization server
>>
>> - cryptographic agility for keys, message signatures, and proof = of possession
>>
>> - user interaction mechanisms including web and non-web = methods- token presentation mechanisms and key bindings
>>
>>
>> Although the artifacts for this work are not intended or = expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, = they will attempt to simplify porting from OAuth 2.0 and OpenID Connect, = and strive to reuse existing semantics such as client identifiers, OAuth = 2.0 scopes and access tokens, and OpenID Connect ID Tokens and = claims.
>>
>>
>> While the initial work will focus on using HTTP for = communication between the client and the authorization server, the = working group will strive to enable simple mapping to other protocols = such as COAP.
>>
>>
>>
>>
>>
>>
>>
>> =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
= >
> --
> 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=_1639EF8C-1FC5-4CEE-8A73-C2C1D34C553F-- From nobody Fri Jan 17 05:49: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 6DA2A12001A for ; Fri, 17 Jan 2020 05:49:27 -0800 (PST) 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 pXgwC21qPYyq for ; Fri, 17 Jan 2020 05:49:21 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA806120071 for ; Fri, 17 Jan 2020 05:49:20 -0800 (PST) Received: from [192.168.1.16] (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 00HDnFfK025625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2020 08:49:16 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E6BB72FB-18E6-455E-9BAF-E72D5B4754AE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 17 Jan 2020 08:49:15 -0500 In-Reply-To: Cc: "Richard Backman, Annabelle" , Torsten Lodderstedt , "txauth@ietf.org" To: Dick Hardt References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> <5A7FEF06-954E-47B1-B3CE-AD5DE2329B52@mit.edu> <7A4FC2A4-9960-4A75-847C-0477FE81DB4F@amazon.com> <00C978A2-E4B1-4EEB-BA0E-5FF0A9B871F0@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 17 Jan 2020 13:49:27 -0000 --Apple-Mail=_E6BB72FB-18E6-455E-9BAF-E72D5B4754AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m thinking this as well =E2=80=94 I think it=E2=80=99s the = kind of detail that the WG can sort out, and that=E2=80=99s what I mean = by figuring out a way to generalize my point #3 below into Annabelle=E2=80= =99s use cases. I=E2=80=99m for figuring it out if we can do it, but not = at the expense of what I=E2=80=99m seeing as a pretty clear set of = semantics already.=20 VoT =3D=3D Vectors of Trust, RFC8485. A way to communicate information = about the user logging in, basically authentication context but with = more dimensions. =E2=80=94 Justin > On Jan 16, 2020, at 6:00 PM, Dick Hardt wrote: >=20 > I was thinking that other kinds of delegation results would be yet = another top level request, and matching response. Since it is not a = widely deployed use case today, it would be an extension to the core = protocol. >=20 > Justin: What to you mean by VoT? >=20 > wrt. returning claims, vs access to claims, I think it is an important = discussion -- but let's put a pin in that for discussion in the WG once = we are formed! I don't think that needs to be in the charter, but happy = to be convinced otherwise.=20 > =E1=90=A7 >=20 > On Thu, Jan 16, 2020 at 2:49 PM Justin Richer > wrote: > I=E2=80=99m cautiously Ok with having resource inlining be in scope = =E2=80=94 IF we can generalize it from the identity case specifically. >=20 > To do what you=E2=80=99re asking for though, the WG can still be = chartered to solve identity (which we know is a well-established and = understood use case), but also allow other things.=20 >=20 > This gets back to a fundamental question that I don=E2=80=99t have a = clear answer for yet: what do you get back at the end of a transaction? = Right now we=E2=80=99ve got a clear call for three things: >=20 > 1. Access tokens to call APIs > 2. Transaction handles to continue the transaction later (like a = refresh token but better) > 3. User identity claims >=20 > Maybe the mechanism we use for #3 can be generalized, or maybe = there=E2=80=99s even a good way to provide switches for #1, #2, and #3.=20= >=20 > And while we=E2=80=99re on the topic of #3, I think there=E2=80=99s a = strong case to be made that it should NOT be a user=E2=80=99s profile = information, but rather just enough information to identify the user to = the RP. If the RP wants to pull more profile info, it can do so via an = API. This keeps us out of the anti-pattern that SAML has of always = sending all claims about a user whether the RP needs them or not. But = the RP will at least need to know if it has to request the claims, and = we can do that by a simple enough structure like: >=20 > user: { > =E2=80=9Ciss=E2=80=9D: =E2=80=9Chttp://foo.bar/ = =E2=80=9C, > =E2=80=9Csub=E2=80=9D: =E2=80=9C12387yhjfre=E2=80=9D, > =E2=80=9Clast_updated=E2=80=9D: 54239084 > } >=20 >=20 > You can add VoT and other things that can vary per-login here as well. = But I shouldn=E2=80=99t be sending you the user=E2=80=99s name and = address every time they log in =E2=80=94 as an RP you only need to get = that if it=E2=80=99s a new account or if it=E2=80=99s been updated since = you last saw it. You can=E2=80=99t handle that if you=E2=80=99re pushing = all the claims in the response: Since the RP doesn=E2=80=99t know who = the user is until after this stage, it can=E2=80=99t tell that = information to the IdP ahead of time and therefore the IdP is forced to = always send it just in case the RP might need it. But by telling the RP = an identifier for the user and a tag of when any of their information = was last updated I can make the decision whether or not to pull = information at the RP in an intelligent fashion if I want to. >=20 > =E2=80=94 Justin >=20 > > On Jan 16, 2020, at 5:29 PM, Richard Backman, Annabelle = > wrote: > >=20 > > The same could be said for any resource, particularly in scenarios = where the interaction was kicked off so that the SP can perform a = specific action initiated by the user (e.g., charging a credit card or = account, publishing a message to a message board or social media feed, = retrieving a specific document or image). > >=20 > > Consider a flow like the following: > > 1. The end user is on a client website that provides a photo = printing service, clicks the "Print from CloudStorageProvider" button. > > 4. The client initates TxAuth via CloudStorageProvider's transaction = endpoint, requesting a URL for a photo to be selected by the end user. > > 5. CloudStorageProvider returns an interact_url pointing to its AS. > > 6. The client redirects the user agent to the AS. > > 7. The end user signs in, and selects the photo they want to print, = and confirms authorization to share with the client. > > 8. The AS redirects the user agent back to client. > > 9. The client calls back to CloudStorageProvider's transaction = endpoint to continue the TxAuth transaction. > > 10. CloudStorageProvider returns confirmation that the authorization = was granted, along with the URL for the selected photo. > >=20 > > This is identical to the identity use case, we've just replaced = identity claims with a URL to a photo. I see a lot of value in = encouraging one-time authorization of specific actions like this, and if = we're going to support inlining of resources for identity claims anyway, = it's not a big stretch to allow for arbitrary resource types. I do think = it's fair to narrowly scope the kinds of resource *schemas* the WG will = define (e.g., defining core identity claims like OIDC did), but the = inlining mechanism should be flexible (e.g., not limiting this to claims = about the end user identity, like OIDC did). > >=20 > > =E2=80=93=20 > > Annabelle Richard Backman > > AWS Identity > >=20 > >=20 > > =EF=BB=BFOn 1/16/20, 12:59 PM, "Txauth on behalf of Justin Richer" = on behalf of = jricher@mit.edu > wrote: > >=20 > > I think that=E2=80=99s exactly the reason =E2=80=94 the case of = getting information about the user directly from the TX endpoint is well = established. People don=E2=80=99t want to make another round trip just = to figure out who=E2=80=99s there, when a lot of time that=E2=80=99s the = first thing they care about, and then the=E2=80=99d make the = determination of whether to follow other APIs after that.=20 > >=20 > > So if I can send you a very basic set of authn info from the = callback, like an identifier and VoT style login information, then you = can figure out if you need to know more about that user or not. But = these basic claims do get elevated to the same level as other returned = artifacts from the transaction, like the access tokens. > >=20 > > =E2=80=94 Justin > >=20 > >> On Jan 16, 2020, at 2:12 PM, Richard Backman, Annabelle = > wrote: > >>=20 > >> The only reason I can think of to single out identity within the = charter is if there is some work or feature that is within scope for the = working group, but only for identity claims (e.g., returning identity = claims from the transaction endpoint). Repeating a question I posed = earlier, what is it about identity claims that make them worthy of = special consideration? > >>=20 > >> =E2=80=93=20 > >> Annabelle Richard Backman > >> AWS Identity > >>=20 > >>=20 > >> On 1/16/20, 8:51 AM, "Justin Richer" > wrote: > >>=20 > >> On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt = > wrote: > >>>=20 > >>>=20 > >>>=20 > >>>> Am 16.01.2020 um 16:45 schrieb Justin Richer >: > >>>>=20 > >>>> - Approval of identity claims and multiple resources in a single = interaction > >>>=20 > >>> This sounds a bit incomplete to me. I assume the user would = approve =E2=80=9Ethe attestation of identity claims=E2=80=9C. I = furthermore think the user would approve =E2=80=9Eaccess to multiple = APIs=E2=80=9C. I would prefer API over resource because it is more = universal. For example, the protocol could also be used to create = resources. > >>=20 > >> Point taken, but this isn=E2=80=99t meant to be an exhaustive = list of what it can do, merely the list of things we=E2=80=99re positive = we want it to do. I also prefer =E2=80=9CAPI=E2=80=9D over = =E2=80=9Cresource=E2=80=9D, but concede that =E2=80=9Cresource=E2=80=9D = can be a writeable thing too. Even then I=E2=80=99m happy to tweak the = language here.=20 > >>=20 > >> =E2=80=94 Justin > >>=20 > >=20 > > --=20 > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth = > >=20 > >=20 >=20 --Apple-Mail=_E6BB72FB-18E6-455E-9BAF-E72D5B4754AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m thinking this as well =E2=80=94 I think it=E2=80=99s the kind of = detail that the WG can sort out, and that=E2=80=99s what I mean by = figuring out a way to generalize my point #3 below into Annabelle=E2=80=99= s use cases. I=E2=80=99m for figuring it out if we can do it, but not at = the expense of what I=E2=80=99m seeing as a pretty clear set of = semantics already. 

VoT =3D=3D Vectors of Trust, RFC8485. A way to communicate = information about the user logging in, basically authentication context = but with more dimensions.

 =E2=80=94 Justin

On Jan = 16, 2020, at 6:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I was thinking that other kinds = of delegation results would be yet another top level request, and = matching response. Since it is not a widely deployed use case today, it = would be an extension to the core protocol.

Justin:  What to you mean by = VoT?

wrt. = returning claims, vs access to claims, I think it is an important = discussion -- but let's put a pin in that for discussion in the WG once = we are formed! I don't think that needs to be in the charter, but = happy to be convinced otherwise. 
3D""=E1=90=A7

On Thu, Jan = 16, 2020 at 2:49 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m cautiously Ok with = having resource inlining be in scope =E2=80=94 IF we can generalize it = from the identity case specifically.

To do what you=E2=80=99re asking for though, the WG can still be = chartered to solve identity (which we know is a well-established and = understood use case), but also allow other things.

This gets back to a fundamental question that I don=E2=80=99t have a = clear answer for yet: what do you get back at the end of a transaction? = Right now we=E2=80=99ve got a clear call for three things:

1. Access tokens to call APIs
2. Transaction handles to continue the transaction later (like a refresh = token but better)
3. User identity claims

Maybe the mechanism we use for #3 can be generalized, or maybe there=E2=80= =99s even a good way to provide switches for #1, #2, and #3.

And while we=E2=80=99re on the topic of #3, I think there=E2=80=99s a = strong case to be made that it should NOT be a user=E2=80=99s profile = information, but rather just enough information to identify the user to = the RP. If the RP wants to pull more profile info, it can do so via an = API. This keeps us out of the anti-pattern that SAML has of always = sending all claims about a user whether the RP needs them or not. But = the RP will at least need to know if it has to request the claims, and = we can do that by a simple enough structure like:

user: {
  =E2=80=9Ciss=E2=80=9D: =E2=80=9Chttp://foo.bar/=E2=80=9C= ,
  =E2=80=9Csub=E2=80=9D: =E2=80=9C12387yhjfre=E2=80=9D,
  =E2=80=9Clast_updated=E2=80=9D: 54239084
}


You can add VoT and other things that can vary per-login here as well. = But I shouldn=E2=80=99t be sending you the user=E2=80=99s name and = address every time they log in =E2=80=94 as an RP you only need to get = that if it=E2=80=99s a new account or if it=E2=80=99s been updated since = you last saw it. You can=E2=80=99t handle that if you=E2=80=99re pushing = all the claims in the response: Since the RP doesn=E2=80=99t know who = the user is until after this stage, it can=E2=80=99t tell that = information to the IdP ahead of time and therefore the IdP is forced to = always send it just in case the RP might need it. But by telling the RP = an identifier for the user and a tag of when any of their information = was last updated I can make the decision whether or not to pull = information at the RP in an intelligent fashion if I want to.

 =E2=80=94 Justin

> On Jan 16, 2020, at 5:29 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
>
> The same could be said for any resource, particularly in scenarios = where the interaction was kicked off so that the SP can perform a = specific action initiated by the user (e.g., charging a credit card or = account, publishing a message to a message board or social media feed, = retrieving a specific document or image).
>
> Consider a flow like the following:
> 1. The end user is on a client website that provides a photo = printing service, clicks the "Print from CloudStorageProvider" = button.
> 4. The client initates TxAuth via CloudStorageProvider's = transaction endpoint, requesting a URL for a photo to be selected by the = end user.
> 5. CloudStorageProvider returns an interact_url pointing to its = AS.
> 6. The client redirects the user agent to the AS.
> 7. The end user signs in, and selects the photo they want to print, = and confirms authorization to share with the client.
> 8. The AS redirects the user agent back to client.
> 9. The client calls back to CloudStorageProvider's transaction = endpoint to continue the TxAuth transaction.
> 10. CloudStorageProvider returns confirmation that the = authorization was granted, along with the URL for the selected photo.
>
> This is identical to the identity use case, we've just replaced = identity claims with a URL to a photo. I see a lot of value in = encouraging one-time authorization of specific actions like this, and if = we're going to support inlining of resources for identity claims anyway, = it's not a big stretch to allow for arbitrary resource types. I do think = it's fair to narrowly scope the kinds of resource *schemas* the WG will = define (e.g., defining core identity claims like OIDC did), but the = inlining mechanism should be flexible (e.g., not limiting this to claims = about the end user identity, like OIDC did).
>
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
>
> =EF=BB=BFOn 1/16/20, 12:59 PM, "Txauth on behalf of Justin Richer" = <txauth-bounces@ietf.org on behalf of jricher@mit.edu> wrote:
>
>    I think that=E2=80=99s exactly the reason =E2=80=94 = the case of getting information about the user directly from the TX = endpoint is well established. People don=E2=80=99t want to make another = round trip just to figure out who=E2=80=99s there, when a lot of time = that=E2=80=99s the first thing they care about, and then the=E2=80=99d = make the determination of whether to follow other APIs after that.
>
>    So if I can send you a very basic set of authn info = from the callback, like an identifier and VoT style login information, = then you can figure out if you need to know more about that user or not. = But these basic claims do get elevated to the same level as other = returned artifacts from the transaction, like the access tokens.
>
>     =E2=80=94 Justin
>
>> On Jan 16, 2020, at 2:12 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
>>
>> The only reason I can think of to single out identity within = the charter is if there is some work or feature that is within scope for = the working group, but only for identity claims (e.g., returning = identity claims from the transaction endpoint). Repeating a question I = posed earlier, what is it about identity claims that make them worthy of = special consideration?
>>
>> =E2=80=93
>> Annabelle Richard Backman
>> AWS Identity
>>
>>
>> On 1/16/20, 8:51 AM, "Justin Richer" <jricher@mit.edu> wrote:
>>
>>   On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt = <torsten@lodderstedt.net> wrote:
>>>
>>>
>>>
>>>> Am 16.01.2020 um 16:45 schrieb Justin Richer <jricher@mit.edu>:
>>>>
>>>> - Approval of identity claims and multiple resources in = a single interaction
>>>
>>> This sounds a bit incomplete to me. I assume the user would = approve =E2=80=9Ethe attestation of identity claims=E2=80=9C. I = furthermore think the user would approve =E2=80=9Eaccess to multiple = APIs=E2=80=9C. I would prefer API over resource because it is more = universal. For example, the protocol could also be used to create = resources.
>>
>>   Point taken, but this isn=E2=80=99t meant to be an = exhaustive list of what it can do, merely the list of things we=E2=80=99re= positive we want it to do. I also prefer =E2=80=9CAPI=E2=80=9D over = =E2=80=9Cresource=E2=80=9D, but concede that =E2=80=9Cresource=E2=80=9D = can be a writeable thing too. Even then I=E2=80=99m happy to tweak the = language here.
>>
>>    =E2=80=94 Justin
>>
>
>    --
>    Txauth mailing list
>    Txauth@ietf.org
>    https://www.ietf.org/mailman/listinfo/txauth
= >
>


= --Apple-Mail=_E6BB72FB-18E6-455E-9BAF-E72D5B4754AE-- From nobody Fri Jan 17 07:59: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 0D65D120824 for ; Fri, 17 Jan 2020 07:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.496 X-Spam-Level: X-Spam-Status: No, score=-14.496 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 KkY_N2kRMGiq for ; Fri, 17 Jan 2020 07:59:32 -0800 (PST) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.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 634E71207FB for ; Fri, 17 Jan 2020 07:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579276772; x=1610812772; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=A+/n90AvgUIMj1bUb3m4ZUYZyLzzXE7SLfVBOnDKYBg=; b=FCJXth30+h0NFy9a718iVxH8H/WTpnrQYIbeGpSfMmkip2i+2urSCqf3 3fgjwsI6M1EgPv8DBeoiimwe6cRtlYCTopGWcllZM6BsM0yNrC37eLEJH tIBMCnQo9PKpn11oUfs4Fnp2a8FgWqVZ2PeIgfbdSDC9pvrdoePoXRPuh s=; IronPort-SDR: dgGtkMnQmMg9OuYzJk8rrqnXb/oYchp7h+/bVRphfB6pFsbks0tb6PFVmiaaLPKTQ9wnn/VLRg rSibdXLmy2rw== X-IronPort-AV: E=Sophos; i="5.70,330,1574121600"; d="scan'208,217"; a="12924097" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 17 Jan 2020 15:59:30 +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 8D983282279; Fri, 17 Jan 2020 15:59:28 +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; Fri, 17 Jan 2020 15:59:27 +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.1367.3; Fri, 17 Jan 2020 15:59:27 +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.1367.000; Fri, 17 Jan 2020 15:59:27 +0000 From: "Richard Backman, Annabelle" To: Justin Richer CC: Dick Hardt , Torsten Lodderstedt , "txauth@ietf.org" Thread-Topic: [Txauth] alternative charter writeup Thread-Index: AQHVx9g9cyOj1MRzqU6+3+Goa7VakafkXaAAgABoEICAA/l4gIAAld0A//+QawCAAI5HAIAALucAgAPVjwCAAAhfAIAAChsA//+hWgCAAKOzAP//k04AABF5z4AAAFvxAAAfDeuAAASMKwU= Date: Fri, 17 Jan 2020 15:59:27 +0000 Message-ID: <82AAD649-5A47-4A89-A32F-BCC593EEE343@amazon.com> References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> <5A7FEF06-954E-47B1-B3CE-AD5DE2329B52@mit.edu> <7A4FC2A4-9960-4A75-847C-0477FE81DB4F@amazon.com> <00C978A2-E4B1-4EEB-BA0E-5FF0A9B871F0@mit.edu> , 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: multipart/alternative; boundary="_000_82AAD6495A474A89A32FBCC593EEE343amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 17 Jan 2020 15:59:35 -0000 --_000_82AAD6495A474A89A32FBCC593EEE343amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgZXhwZXJpZW5jZSBpcyB0aGF0IHBlb3BsZSB3aWxsIHN0cmV0Y2ggYW5kIGNvbWZvcnQgdGhl IHNlbWFudGljcyBvZiDigJxpZGVudGl0eSBjbGFpbXPigJ0gdG8gZml0IHRoaXMgdXNlIGNhc2Vz LiBJ4oCZbSBmaW5lIHdpdGggZGVmZXJyaW5nIHRoZSBkaXNjdXNzaW9uIHRvIHRoZSBXRywgcHJv dmlkZWQgdGhhdCB3ZSBhZ3JlZSB0aGUgY2hhcnRlciBkb2VzbuKAmXQgcnVsZSBvdXQgdGhlIHBv c3NpYmlsaXR5Lg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIEphbiAxNywgMjAyMCwgYXQg NTo0OSBBTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiB3cm90ZToNCg0K77u/IEni gJltIHRoaW5raW5nIHRoaXMgYXMgd2VsbCDigJQgSSB0aGluayBpdOKAmXMgdGhlIGtpbmQgb2Yg ZGV0YWlsIHRoYXQgdGhlIFdHIGNhbiBzb3J0IG91dCwgYW5kIHRoYXTigJlzIHdoYXQgSSBtZWFu IGJ5IGZpZ3VyaW5nIG91dCBhIHdheSB0byBnZW5lcmFsaXplIG15IHBvaW50ICMzIGJlbG93IGlu dG8gQW5uYWJlbGxl4oCZcyB1c2UgY2FzZXMuIEnigJltIGZvciBmaWd1cmluZyBpdCBvdXQgaWYg d2UgY2FuIGRvIGl0LCBidXQgbm90IGF0IHRoZSBleHBlbnNlIG9mIHdoYXQgSeKAmW0gc2VlaW5n IGFzIGEgcHJldHR5IGNsZWFyIHNldCBvZiBzZW1hbnRpY3MgYWxyZWFkeS4NCg0KVm9UID09IFZl Y3RvcnMgb2YgVHJ1c3QsIFJGQzg0ODUuIEEgd2F5IHRvIGNvbW11bmljYXRlIGluZm9ybWF0aW9u IGFib3V0IHRoZSB1c2VyIGxvZ2dpbmcgaW4sIGJhc2ljYWxseSBhdXRoZW50aWNhdGlvbiBjb250 ZXh0IGJ1dCB3aXRoIG1vcmUgZGltZW5zaW9ucy4NCg0KIOKAlCBKdXN0aW4NCg0KT24gSmFuIDE2 LCAyMDIwLCBhdCA2OjAwIFBNLCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWls dG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCg0KSSB3YXMgdGhpbmtpbmcgdGhhdCBv dGhlciBraW5kcyBvZiBkZWxlZ2F0aW9uIHJlc3VsdHMgd291bGQgYmUgeWV0IGFub3RoZXIgdG9w IGxldmVsIHJlcXVlc3QsIGFuZCBtYXRjaGluZyByZXNwb25zZS4gU2luY2UgaXQgaXMgbm90IGEg d2lkZWx5IGRlcGxveWVkIHVzZSBjYXNlIHRvZGF5LCBpdCB3b3VsZCBiZSBhbiBleHRlbnNpb24g dG8gdGhlIGNvcmUgcHJvdG9jb2wuDQoNCkp1c3RpbjogIFdoYXQgdG8geW91IG1lYW4gYnkgVm9U Pw0KDQp3cnQuIHJldHVybmluZyBjbGFpbXMsIHZzIGFjY2VzcyB0byBjbGFpbXMsIEkgdGhpbmsg aXQgaXMgYW4gaW1wb3J0YW50IGRpc2N1c3Npb24gLS0gYnV0IGxldCdzIHB1dCBhIHBpbiBpbiB0 aGF0IGZvciBkaXNjdXNzaW9uIGluIHRoZSBXRyBvbmNlIHdlIGFyZSBmb3JtZWQhIEkgZG9uJ3Qg dGhpbmsgdGhhdCBuZWVkcyB0byBiZSBpbiB0aGUgY2hhcnRlciwgYnV0IGhhcHB5IHRvIGJlIGNv bnZpbmNlZCBvdGhlcndpc2UuDQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2Vu ZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlk PWI3NmMzNDkwLTMxNzctNGQ1NC04MTRlLTk0NmM4NGZkOTE1Yl3hkKcNCg0KT24gVGh1LCBKYW4g MTYsIDIwMjAgYXQgMjo0OSBQTSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRv OmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KSeKAmW0gY2F1dGlvdXNseSBPayB3aXRoIGhhdmlu ZyByZXNvdXJjZSBpbmxpbmluZyBiZSBpbiBzY29wZSDigJQgSUYgd2UgY2FuIGdlbmVyYWxpemUg aXQgZnJvbSB0aGUgaWRlbnRpdHkgY2FzZSBzcGVjaWZpY2FsbHkuDQoNClRvIGRvIHdoYXQgeW91 4oCZcmUgYXNraW5nIGZvciB0aG91Z2gsIHRoZSBXRyBjYW4gc3RpbGwgYmUgY2hhcnRlcmVkIHRv IHNvbHZlIGlkZW50aXR5ICh3aGljaCB3ZSBrbm93IGlzIGEgd2VsbC1lc3RhYmxpc2hlZCBhbmQg dW5kZXJzdG9vZCB1c2UgY2FzZSksIGJ1dCBhbHNvIGFsbG93IG90aGVyIHRoaW5ncy4NCg0KVGhp cyBnZXRzIGJhY2sgdG8gYSBmdW5kYW1lbnRhbCBxdWVzdGlvbiB0aGF0IEkgZG9u4oCZdCBoYXZl IGEgY2xlYXIgYW5zd2VyIGZvciB5ZXQ6IHdoYXQgZG8geW91IGdldCBiYWNrIGF0IHRoZSBlbmQg b2YgYSB0cmFuc2FjdGlvbj8gUmlnaHQgbm93IHdl4oCZdmUgZ290IGEgY2xlYXIgY2FsbCBmb3Ig dGhyZWUgdGhpbmdzOg0KDQoxLiBBY2Nlc3MgdG9rZW5zIHRvIGNhbGwgQVBJcw0KMi4gVHJhbnNh Y3Rpb24gaGFuZGxlcyB0byBjb250aW51ZSB0aGUgdHJhbnNhY3Rpb24gbGF0ZXIgKGxpa2UgYSBy ZWZyZXNoIHRva2VuIGJ1dCBiZXR0ZXIpDQozLiBVc2VyIGlkZW50aXR5IGNsYWltcw0KDQpNYXli ZSB0aGUgbWVjaGFuaXNtIHdlIHVzZSBmb3IgIzMgY2FuIGJlIGdlbmVyYWxpemVkLCBvciBtYXli ZSB0aGVyZeKAmXMgZXZlbiBhIGdvb2Qgd2F5IHRvIHByb3ZpZGUgc3dpdGNoZXMgZm9yICMxLCAj MiwgYW5kICMzLg0KDQpBbmQgd2hpbGUgd2XigJlyZSBvbiB0aGUgdG9waWMgb2YgIzMsIEkgdGhp bmsgdGhlcmXigJlzIGEgc3Ryb25nIGNhc2UgdG8gYmUgbWFkZSB0aGF0IGl0IHNob3VsZCBOT1Qg YmUgYSB1c2Vy4oCZcyBwcm9maWxlIGluZm9ybWF0aW9uLCBidXQgcmF0aGVyIGp1c3QgZW5vdWdo IGluZm9ybWF0aW9uIHRvIGlkZW50aWZ5IHRoZSB1c2VyIHRvIHRoZSBSUC4gSWYgdGhlIFJQIHdh bnRzIHRvIHB1bGwgbW9yZSBwcm9maWxlIGluZm8sIGl0IGNhbiBkbyBzbyB2aWEgYW4gQVBJLiBU aGlzIGtlZXBzIHVzIG91dCBvZiB0aGUgYW50aS1wYXR0ZXJuIHRoYXQgU0FNTCBoYXMgb2YgYWx3 YXlzIHNlbmRpbmcgYWxsIGNsYWltcyBhYm91dCBhIHVzZXIgd2hldGhlciB0aGUgUlAgbmVlZHMg dGhlbSBvciBub3QuIEJ1dCB0aGUgUlAgd2lsbCBhdCBsZWFzdCBuZWVkIHRvIGtub3cgaWYgaXQg aGFzIHRvIHJlcXVlc3QgdGhlIGNsYWltcywgYW5kIHdlIGNhbiBkbyB0aGF0IGJ5IGEgc2ltcGxl IGVub3VnaCBzdHJ1Y3R1cmUgbGlrZToNCg0KdXNlcjogew0KICDigJxpc3PigJ06IOKAnGh0dHA6 Ly9mb28uYmFyL+KAnCwNCiAg4oCcc3Vi4oCdOiDigJwxMjM4N3loamZyZeKAnSwNCiAg4oCcbGFz dF91cGRhdGVk4oCdOiA1NDIzOTA4NA0KfQ0KDQoNCllvdSBjYW4gYWRkIFZvVCBhbmQgb3RoZXIg dGhpbmdzIHRoYXQgY2FuIHZhcnkgcGVyLWxvZ2luIGhlcmUgYXMgd2VsbC4gQnV0IEkgc2hvdWxk buKAmXQgYmUgc2VuZGluZyB5b3UgdGhlIHVzZXLigJlzIG5hbWUgYW5kIGFkZHJlc3MgZXZlcnkg dGltZSB0aGV5IGxvZyBpbiDigJQgYXMgYW4gUlAgeW91IG9ubHkgbmVlZCB0byBnZXQgdGhhdCBp ZiBpdOKAmXMgYSBuZXcgYWNjb3VudCBvciBpZiBpdOKAmXMgYmVlbiB1cGRhdGVkIHNpbmNlIHlv dSBsYXN0IHNhdyBpdC4gWW91IGNhbuKAmXQgaGFuZGxlIHRoYXQgaWYgeW914oCZcmUgcHVzaGlu ZyBhbGwgdGhlIGNsYWltcyBpbiB0aGUgcmVzcG9uc2U6IFNpbmNlIHRoZSBSUCBkb2VzbuKAmXQg a25vdyB3aG8gdGhlIHVzZXIgaXMgdW50aWwgYWZ0ZXIgdGhpcyBzdGFnZSwgaXQgY2Fu4oCZdCB0 ZWxsIHRoYXQgaW5mb3JtYXRpb24gdG8gdGhlIElkUCBhaGVhZCBvZiB0aW1lIGFuZCB0aGVyZWZv cmUgdGhlIElkUCBpcyBmb3JjZWQgdG8gYWx3YXlzIHNlbmQgaXQganVzdCBpbiBjYXNlIHRoZSBS UCBtaWdodCBuZWVkIGl0LiBCdXQgYnkgdGVsbGluZyB0aGUgUlAgYW4gaWRlbnRpZmllciBmb3Ig dGhlIHVzZXIgYW5kIGEgdGFnIG9mIHdoZW4gYW55IG9mIHRoZWlyIGluZm9ybWF0aW9uIHdhcyBs YXN0IHVwZGF0ZWQgSSBjYW4gbWFrZSB0aGUgZGVjaXNpb24gd2hldGhlciBvciBub3QgdG8gcHVs bCBpbmZvcm1hdGlvbiBhdCB0aGUgUlAgaW4gYW4gaW50ZWxsaWdlbnQgZmFzaGlvbiBpZiBJIHdh bnQgdG8uDQoNCiDigJQgSnVzdGluDQoNCj4gT24gSmFuIDE2LCAyMDIwLCBhdCA1OjI5IFBNLCBS aWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmlj aGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KPg0KPiBUaGUgc2FtZSBjb3VsZCBiZSBzYWlkIGZv ciBhbnkgcmVzb3VyY2UsIHBhcnRpY3VsYXJseSBpbiBzY2VuYXJpb3Mgd2hlcmUgdGhlIGludGVy YWN0aW9uIHdhcyBraWNrZWQgb2ZmIHNvIHRoYXQgdGhlIFNQIGNhbiBwZXJmb3JtIGEgc3BlY2lm aWMgYWN0aW9uIGluaXRpYXRlZCBieSB0aGUgdXNlciAoZS5nLiwgY2hhcmdpbmcgYSBjcmVkaXQg Y2FyZCBvciBhY2NvdW50LCBwdWJsaXNoaW5nIGEgbWVzc2FnZSB0byBhIG1lc3NhZ2UgYm9hcmQg b3Igc29jaWFsIG1lZGlhIGZlZWQsIHJldHJpZXZpbmcgYSBzcGVjaWZpYyBkb2N1bWVudCBvciBp bWFnZSkuDQo+DQo+IENvbnNpZGVyIGEgZmxvdyBsaWtlIHRoZSBmb2xsb3dpbmc6DQo+IDEuIFRo ZSBlbmQgdXNlciBpcyBvbiBhIGNsaWVudCB3ZWJzaXRlIHRoYXQgcHJvdmlkZXMgYSBwaG90byBw cmludGluZyBzZXJ2aWNlLCBjbGlja3MgdGhlICJQcmludCBmcm9tIENsb3VkU3RvcmFnZVByb3Zp ZGVyIiBidXR0b24uDQo+IDQuIFRoZSBjbGllbnQgaW5pdGF0ZXMgVHhBdXRoIHZpYSBDbG91ZFN0 b3JhZ2VQcm92aWRlcidzIHRyYW5zYWN0aW9uIGVuZHBvaW50LCByZXF1ZXN0aW5nIGEgVVJMIGZv ciBhIHBob3RvIHRvIGJlIHNlbGVjdGVkIGJ5IHRoZSBlbmQgdXNlci4NCj4gNS4gQ2xvdWRTdG9y YWdlUHJvdmlkZXIgcmV0dXJucyBhbiBpbnRlcmFjdF91cmwgcG9pbnRpbmcgdG8gaXRzIEFTLg0K PiA2LiBUaGUgY2xpZW50IHJlZGlyZWN0cyB0aGUgdXNlciBhZ2VudCB0byB0aGUgQVMuDQo+IDcu IFRoZSBlbmQgdXNlciBzaWducyBpbiwgYW5kIHNlbGVjdHMgdGhlIHBob3RvIHRoZXkgd2FudCB0 byBwcmludCwgYW5kIGNvbmZpcm1zIGF1dGhvcml6YXRpb24gdG8gc2hhcmUgd2l0aCB0aGUgY2xp ZW50Lg0KPiA4LiBUaGUgQVMgcmVkaXJlY3RzIHRoZSB1c2VyIGFnZW50IGJhY2sgdG8gY2xpZW50 Lg0KPiA5LiBUaGUgY2xpZW50IGNhbGxzIGJhY2sgdG8gQ2xvdWRTdG9yYWdlUHJvdmlkZXIncyB0 cmFuc2FjdGlvbiBlbmRwb2ludCB0byBjb250aW51ZSB0aGUgVHhBdXRoIHRyYW5zYWN0aW9uLg0K PiAxMC4gQ2xvdWRTdG9yYWdlUHJvdmlkZXIgcmV0dXJucyBjb25maXJtYXRpb24gdGhhdCB0aGUg YXV0aG9yaXphdGlvbiB3YXMgZ3JhbnRlZCwgYWxvbmcgd2l0aCB0aGUgVVJMIGZvciB0aGUgc2Vs ZWN0ZWQgcGhvdG8uDQo+DQo+IFRoaXMgaXMgaWRlbnRpY2FsIHRvIHRoZSBpZGVudGl0eSB1c2Ug Y2FzZSwgd2UndmUganVzdCByZXBsYWNlZCBpZGVudGl0eSBjbGFpbXMgd2l0aCBhIFVSTCB0byBh IHBob3RvLiBJIHNlZSBhIGxvdCBvZiB2YWx1ZSBpbiBlbmNvdXJhZ2luZyBvbmUtdGltZSBhdXRo b3JpemF0aW9uIG9mIHNwZWNpZmljIGFjdGlvbnMgbGlrZSB0aGlzLCBhbmQgaWYgd2UncmUgZ29p bmcgdG8gc3VwcG9ydCBpbmxpbmluZyBvZiByZXNvdXJjZXMgZm9yIGlkZW50aXR5IGNsYWltcyBh bnl3YXksIGl0J3Mgbm90IGEgYmlnIHN0cmV0Y2ggdG8gYWxsb3cgZm9yIGFyYml0cmFyeSByZXNv dXJjZSB0eXBlcy4gSSBkbyB0aGluayBpdCdzIGZhaXIgdG8gbmFycm93bHkgc2NvcGUgdGhlIGtp bmRzIG9mIHJlc291cmNlICpzY2hlbWFzKiB0aGUgV0cgd2lsbCBkZWZpbmUgKGUuZy4sIGRlZmlu aW5nIGNvcmUgaWRlbnRpdHkgY2xhaW1zIGxpa2UgT0lEQyBkaWQpLCBidXQgdGhlIGlubGluaW5n IG1lY2hhbmlzbSBzaG91bGQgYmUgZmxleGlibGUgKGUuZy4sIG5vdCBsaW1pdGluZyB0aGlzIHRv IGNsYWltcyBhYm91dCB0aGUgZW5kIHVzZXIgaWRlbnRpdHksIGxpa2UgT0lEQyBkaWQpLg0KPg0K PiDigJMNCj4gQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KPiBBV1MgSWRlbnRpdHkNCj4NCj4N Cj4g77u/T24gMS8xNi8yMCwgMTI6NTkgUE0sICJUeGF1dGggb24gYmVoYWxmIG9mIEp1c3RpbiBS aWNoZXIiIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHhhdXRoLWJvdW5jZXNAaWV0 Zi5vcmc+IG9uIGJlaGFsZiBvZiBqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVk dT4+IHdyb3RlOg0KPg0KPiAgICBJIHRoaW5rIHRoYXTigJlzIGV4YWN0bHkgdGhlIHJlYXNvbiDi gJQgdGhlIGNhc2Ugb2YgZ2V0dGluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgdXNlciBkaXJlY3Rs eSBmcm9tIHRoZSBUWCBlbmRwb2ludCBpcyB3ZWxsIGVzdGFibGlzaGVkLiBQZW9wbGUgZG9u4oCZ dCB3YW50IHRvIG1ha2UgYW5vdGhlciByb3VuZCB0cmlwIGp1c3QgdG8gZmlndXJlIG91dCB3aG/i gJlzIHRoZXJlLCB3aGVuIGEgbG90IG9mIHRpbWUgdGhhdOKAmXMgdGhlIGZpcnN0IHRoaW5nIHRo ZXkgY2FyZSBhYm91dCwgYW5kIHRoZW4gdGhl4oCZZCBtYWtlIHRoZSBkZXRlcm1pbmF0aW9uIG9m IHdoZXRoZXIgdG8gZm9sbG93IG90aGVyIEFQSXMgYWZ0ZXIgdGhhdC4NCj4NCj4gICAgU28gaWYg SSBjYW4gc2VuZCB5b3UgYSB2ZXJ5IGJhc2ljIHNldCBvZiBhdXRobiBpbmZvIGZyb20gdGhlIGNh bGxiYWNrLCBsaWtlIGFuIGlkZW50aWZpZXIgYW5kIFZvVCBzdHlsZSBsb2dpbiBpbmZvcm1hdGlv biwgdGhlbiB5b3UgY2FuIGZpZ3VyZSBvdXQgaWYgeW91IG5lZWQgdG8ga25vdyBtb3JlIGFib3V0 IHRoYXQgdXNlciBvciBub3QuIEJ1dCB0aGVzZSBiYXNpYyBjbGFpbXMgZG8gZ2V0IGVsZXZhdGVk IHRvIHRoZSBzYW1lIGxldmVsIGFzIG90aGVyIHJldHVybmVkIGFydGlmYWN0cyBmcm9tIHRoZSB0 cmFuc2FjdGlvbiwgbGlrZSB0aGUgYWNjZXNzIHRva2Vucy4NCj4NCj4gICAgIOKAlCBKdXN0aW4N Cj4NCj4+IE9uIEphbiAxNiwgMjAyMCwgYXQgMjoxMiBQTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5h YmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiB3 cm90ZToNCj4+DQo+PiBUaGUgb25seSByZWFzb24gSSBjYW4gdGhpbmsgb2YgdG8gc2luZ2xlIG91 dCBpZGVudGl0eSB3aXRoaW4gdGhlIGNoYXJ0ZXIgaXMgaWYgdGhlcmUgaXMgc29tZSB3b3JrIG9y IGZlYXR1cmUgdGhhdCBpcyB3aXRoaW4gc2NvcGUgZm9yIHRoZSB3b3JraW5nIGdyb3VwLCBidXQg b25seSBmb3IgaWRlbnRpdHkgY2xhaW1zIChlLmcuLCByZXR1cm5pbmcgaWRlbnRpdHkgY2xhaW1z IGZyb20gdGhlIHRyYW5zYWN0aW9uIGVuZHBvaW50KS4gUmVwZWF0aW5nIGEgcXVlc3Rpb24gSSBw b3NlZCBlYXJsaWVyLCB3aGF0IGlzIGl0IGFib3V0IGlkZW50aXR5IGNsYWltcyB0aGF0IG1ha2Ug dGhlbSB3b3J0aHkgb2Ygc3BlY2lhbCBjb25zaWRlcmF0aW9uPw0KPj4NCj4+IOKAkw0KPj4gQW5u YWJlbGxlIFJpY2hhcmQgQmFja21hbg0KPj4gQVdTIElkZW50aXR5DQo+Pg0KPj4NCj4+IE9uIDEv MTYvMjAsIDg6NTEgQU0sICJKdXN0aW4gUmljaGVyIiA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpq cmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCj4+DQo+PiAgIE9uIEphbiAxNiwgMjAyMCwgYXQgMTE6 MTUgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0 bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+IHdyb3RlOg0KPj4+DQo+Pj4NCj4+Pg0KPj4+PiBB bSAxNi4wMS4yMDIwIHVtIDE2OjQ1IHNjaHJpZWIgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQu ZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PjoNCj4+Pj4NCj4+Pj4gLSBBcHByb3ZhbCBvZiBp ZGVudGl0eSBjbGFpbXMgYW5kIG11bHRpcGxlIHJlc291cmNlcyBpbiBhIHNpbmdsZSBpbnRlcmFj dGlvbg0KPj4+DQo+Pj4gVGhpcyBzb3VuZHMgYSBiaXQgaW5jb21wbGV0ZSB0byBtZS4gSSBhc3N1 bWUgdGhlIHVzZXIgd291bGQgYXBwcm92ZSDigJ50aGUgYXR0ZXN0YXRpb24gb2YgaWRlbnRpdHkg Y2xhaW1z4oCcLiBJIGZ1cnRoZXJtb3JlIHRoaW5rIHRoZSB1c2VyIHdvdWxkIGFwcHJvdmUg4oCe YWNjZXNzIHRvIG11bHRpcGxlIEFQSXPigJwuIEkgd291bGQgcHJlZmVyIEFQSSBvdmVyIHJlc291 cmNlIGJlY2F1c2UgaXQgaXMgbW9yZSB1bml2ZXJzYWwuIEZvciBleGFtcGxlLCB0aGUgcHJvdG9j b2wgY291bGQgYWxzbyBiZSB1c2VkIHRvIGNyZWF0ZSByZXNvdXJjZXMuDQo+Pg0KPj4gICBQb2lu dCB0YWtlbiwgYnV0IHRoaXMgaXNu4oCZdCBtZWFudCB0byBiZSBhbiBleGhhdXN0aXZlIGxpc3Qg b2Ygd2hhdCBpdCBjYW4gZG8sIG1lcmVseSB0aGUgbGlzdCBvZiB0aGluZ3Mgd2XigJlyZSBwb3Np dGl2ZSB3ZSB3YW50IGl0IHRvIGRvLiBJIGFsc28gcHJlZmVyIOKAnEFQSeKAnSBvdmVyIOKAnHJl c291cmNl4oCdLCBidXQgY29uY2VkZSB0aGF0IOKAnHJlc291cmNl4oCdIGNhbiBiZSBhIHdyaXRl YWJsZSB0aGluZyB0b28uIEV2ZW4gdGhlbiBJ4oCZbSBoYXBweSB0byB0d2VhayB0aGUgbGFuZ3Vh Z2UgaGVyZS4NCj4+DQo+PiAgICDigJQgSnVzdGluDQo+Pg0KPg0KPiAgICAtLQ0KPiAgICBUeGF1 dGggbWFpbGluZyBsaXN0DQo+ICAgIFR4YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRoQGlldGYu b3JnPg0KPiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0K Pg0KPg0KDQoNCi0tDQpUeGF1dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQo= --_000_82AAD6495A474A89A32FBCC593EEE343amazoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpN eSBleHBlcmllbmNlIGlzIHRoYXQgcGVvcGxlIHdpbGwgc3RyZXRjaCBhbmQgY29tZm9ydCB0aGUg c2VtYW50aWNzIG9mIOKAnGlkZW50aXR5IGNsYWltc+KAnSB0byBmaXQgdGhpcyB1c2UgY2FzZXMu IEnigJltIGZpbmUgd2l0aCBkZWZlcnJpbmcgdGhlIGRpc2N1c3Npb24gdG8gdGhlIFdHLCBwcm92 aWRlZCB0aGF0IHdlIGFncmVlIHRoZSBjaGFydGVyIGRvZXNu4oCZdCBydWxlIG91dCB0aGUgcG9z c2liaWxpdHkuPGJyPg0KPGJyPg0KPGRpdiBkaXI9Imx0ciI+U2VudCBmcm9tIG15IGlQaG9uZTwv ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+T24gSmFu IDE3LCAyMDIwLCBhdCA1OjQ5IEFNLCBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUm Z3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj7vu78gSeKAmW0gdGhpbmtpbmcgdGhpcyBhcyB3 ZWxsIOKAlCBJIHRoaW5rIGl04oCZcyB0aGUga2luZCBvZiBkZXRhaWwgdGhhdCB0aGUgV0cgY2Fu IHNvcnQgb3V0LCBhbmQgdGhhdOKAmXMgd2hhdCBJIG1lYW4gYnkgZmlndXJpbmcgb3V0IGEgd2F5 IHRvIGdlbmVyYWxpemUgbXkgcG9pbnQgIzMgYmVsb3cgaW50byBBbm5hYmVsbGXigJlzIHVzZSBj YXNlcy4gSeKAmW0gZm9yIGZpZ3VyaW5nIGl0IG91dCBpZiB3ZSBjYW4gZG8gaXQsIGJ1dCBub3QN CiBhdCB0aGUgZXhwZW5zZSBvZiB3aGF0IEnigJltIHNlZWluZyBhcyBhIHByZXR0eSBjbGVhciBz ZXQgb2Ygc2VtYW50aWNzIGFscmVhZHkuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Wb1QgPT0gVmVjdG9ycyBvZiBUcnVzdCwgUkZDODQ4 NS4gQSB3YXkgdG8gY29tbXVuaWNhdGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHVzZXIgbG9nZ2lu ZyBpbiwgYmFzaWNhbGx5IGF1dGhlbnRpY2F0aW9uIGNvbnRleHQgYnV0IHdpdGggbW9yZSBkaW1l bnNpb25zLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+Jm5ic3A74oCUIEp1c3RpbjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEph biAxNiwgMjAyMCwgYXQgNjowMCBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRp Y2suaGFyZHRAZ21haWwuY29tIiBjbGFzcz0iIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7 IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5JIHdhcyB0aGlua2luZyB0aGF0 IG90aGVyIGtpbmRzIG9mIGRlbGVnYXRpb24gcmVzdWx0cyB3b3VsZCBiZSB5ZXQgYW5vdGhlciB0 b3AgbGV2ZWwgcmVxdWVzdCwgYW5kIG1hdGNoaW5nIHJlc3BvbnNlLiBTaW5jZSBpdCBpcyBub3Qg YSB3aWRlbHkgZGVwbG95ZWQgdXNlIGNhc2UgdG9kYXksIGl0IHdvdWxkIGJlIGFuIGV4dGVuc2lv biB0byB0aGUgY29yZSBwcm90b2NvbC4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkp1c3RpbjombmJzcDsgV2hhdCB0byB5b3UgbWVhbiBieSBWb1Q/ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij53cnQuIHJldHVybmluZyBjbGFpbXMsIHZzIGFjY2VzcyB0byBjbGFpbXMsIEkgdGhpbmsgaXQg aXMgYW4gaW1wb3J0YW50IGRpc2N1c3Npb24gLS0gYnV0IGxldCdzIHB1dCBhIHBpbiBpbiB0aGF0 IGZvciBkaXNjdXNzaW9uIGluIHRoZSBXRyBvbmNlIHdlIGFyZSBmb3JtZWQhIEkgZG9uJ3QgdGhp bmsmbmJzcDt0aGF0IG5lZWRzIHRvIGJlIGluIHRoZSBjaGFydGVyLCBidXQgaGFwcHkgdG8gYmUg Y29udmluY2VkIG90aGVyd2lzZS4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBoc3BhY2U9InN0 cmVhay1wdC1tYXJrIiBzdHlsZT0ibWF4LWhlaWdodDoxcHgiIGNsYXNzPSIiPjxpbWcgYWx0PSIi IHN0eWxlPSJ3aWR0aDowcHg7bWF4LWhlaWdodDowcHg7b3ZlcmZsb3c6aGlkZGVuIiBzcmM9Imh0 dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJX RnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPWI3NmMzNDkwLTMxNzct NGQ1NC04MTRlLTk0NmM4NGZkOTE1YiIgY2xhc3M9IiIgZGF0YS11bmlxdWUtaWRlbnRpZmllcj0i Ij48Zm9udCBjb2xvcj0iI2ZmZmZmZiIgc2l6ZT0iMSIgY2xhc3M9IiI+4ZCnPC9mb250PjwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0 ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFRodSwgSmFuIDE2LCAyMDIwIGF0IDI6NDkgUE0gSnVz dGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgY2xhc3M9IiI+ anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFl eCI+DQpJ4oCZbSBjYXV0aW91c2x5IE9rIHdpdGggaGF2aW5nIHJlc291cmNlIGlubGluaW5nIGJl IGluIHNjb3BlIOKAlCBJRiB3ZSBjYW4gZ2VuZXJhbGl6ZSBpdCBmcm9tIHRoZSBpZGVudGl0eSBj YXNlIHNwZWNpZmljYWxseS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUbyBkbyB3aGF0 IHlvdeKAmXJlIGFza2luZyBmb3IgdGhvdWdoLCB0aGUgV0cgY2FuIHN0aWxsIGJlIGNoYXJ0ZXJl ZCB0byBzb2x2ZSBpZGVudGl0eSAod2hpY2ggd2Uga25vdyBpcyBhIHdlbGwtZXN0YWJsaXNoZWQg YW5kIHVuZGVyc3Rvb2QgdXNlIGNhc2UpLCBidXQgYWxzbyBhbGxvdyBvdGhlciB0aGluZ3MuDQo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlzIGdldHMgYmFjayB0byBhIGZ1bmRhbWVu dGFsIHF1ZXN0aW9uIHRoYXQgSSBkb27igJl0IGhhdmUgYSBjbGVhciBhbnN3ZXIgZm9yIHlldDog d2hhdCBkbyB5b3UgZ2V0IGJhY2sgYXQgdGhlIGVuZCBvZiBhIHRyYW5zYWN0aW9uPyBSaWdodCBu b3cgd2XigJl2ZSBnb3QgYSBjbGVhciBjYWxsIGZvciB0aHJlZSB0aGluZ3M6PGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KMS4gQWNjZXNzIHRva2VucyB0byBjYWxsIEFQSXM8YnIgY2xhc3M9 IiI+DQoyLiBUcmFuc2FjdGlvbiBoYW5kbGVzIHRvIGNvbnRpbnVlIHRoZSB0cmFuc2FjdGlvbiBs YXRlciAobGlrZSBhIHJlZnJlc2ggdG9rZW4gYnV0IGJldHRlcik8YnIgY2xhc3M9IiI+DQozLiBV c2VyIGlkZW50aXR5IGNsYWltczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk1heWJlIHRo ZSBtZWNoYW5pc20gd2UgdXNlIGZvciAjMyBjYW4gYmUgZ2VuZXJhbGl6ZWQsIG9yIG1heWJlIHRo ZXJl4oCZcyBldmVuIGEgZ29vZCB3YXkgdG8gcHJvdmlkZSBzd2l0Y2hlcyBmb3IgIzEsICMyLCBh bmQgIzMuDQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBbmQgd2hpbGUgd2XigJlyZSBv biB0aGUgdG9waWMgb2YgIzMsIEkgdGhpbmsgdGhlcmXigJlzIGEgc3Ryb25nIGNhc2UgdG8gYmUg bWFkZSB0aGF0IGl0IHNob3VsZCBOT1QgYmUgYSB1c2Vy4oCZcyBwcm9maWxlIGluZm9ybWF0aW9u LCBidXQgcmF0aGVyIGp1c3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGlkZW50aWZ5IHRoZSB1c2Vy IHRvIHRoZSBSUC4gSWYgdGhlIFJQIHdhbnRzIHRvIHB1bGwgbW9yZSBwcm9maWxlIGluZm8sIGl0 IGNhbiBkbyBzbyB2aWEgYW4NCiBBUEkuIFRoaXMga2VlcHMgdXMgb3V0IG9mIHRoZSBhbnRpLXBh dHRlcm4gdGhhdCBTQU1MIGhhcyBvZiBhbHdheXMgc2VuZGluZyBhbGwgY2xhaW1zIGFib3V0IGEg dXNlciB3aGV0aGVyIHRoZSBSUCBuZWVkcyB0aGVtIG9yIG5vdC4gQnV0IHRoZSBSUCB3aWxsIGF0 IGxlYXN0IG5lZWQgdG8ga25vdyBpZiBpdCBoYXMgdG8gcmVxdWVzdCB0aGUgY2xhaW1zLCBhbmQg d2UgY2FuIGRvIHRoYXQgYnkgYSBzaW1wbGUgZW5vdWdoIHN0cnVjdHVyZSBsaWtlOjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCnVzZXI6IHs8YnIgY2xhc3M9IiI+DQombmJzcDsg4oCcaXNz 4oCdOiDigJw8YSBocmVmPSJodHRwOi8vZm9vLmJhci8iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHA6Ly9mb28uYmFyLzwvYT7igJwsPGJyIGNsYXNzPSIiPg0K Jm5ic3A7IOKAnHN1YuKAnTog4oCcMTIzODd5aGpmcmXigJ0sPGJyIGNsYXNzPSIiPg0KJm5ic3A7 IOKAnGxhc3RfdXBkYXRlZOKAnTogNTQyMzkwODQ8YnIgY2xhc3M9IiI+DQp9PGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KWW91IGNhbiBhZGQgVm9UIGFuZCBvdGhl ciB0aGluZ3MgdGhhdCBjYW4gdmFyeSBwZXItbG9naW4gaGVyZSBhcyB3ZWxsLiBCdXQgSSBzaG91 bGRu4oCZdCBiZSBzZW5kaW5nIHlvdSB0aGUgdXNlcuKAmXMgbmFtZSBhbmQgYWRkcmVzcyBldmVy eSB0aW1lIHRoZXkgbG9nIGluIOKAlCBhcyBhbiBSUCB5b3Ugb25seSBuZWVkIHRvIGdldCB0aGF0 IGlmIGl04oCZcyBhIG5ldyBhY2NvdW50IG9yIGlmIGl04oCZcyBiZWVuIHVwZGF0ZWQgc2luY2Ug eW91IGxhc3Qgc2F3IGl0Lg0KIFlvdSBjYW7igJl0IGhhbmRsZSB0aGF0IGlmIHlvdeKAmXJlIHB1 c2hpbmcgYWxsIHRoZSBjbGFpbXMgaW4gdGhlIHJlc3BvbnNlOiBTaW5jZSB0aGUgUlAgZG9lc27i gJl0IGtub3cgd2hvIHRoZSB1c2VyIGlzIHVudGlsIGFmdGVyIHRoaXMgc3RhZ2UsIGl0IGNhbuKA mXQgdGVsbCB0aGF0IGluZm9ybWF0aW9uIHRvIHRoZSBJZFAgYWhlYWQgb2YgdGltZSBhbmQgdGhl cmVmb3JlIHRoZSBJZFAgaXMgZm9yY2VkIHRvIGFsd2F5cyBzZW5kIGl0IGp1c3QgaW4gY2FzZQ0K IHRoZSBSUCBtaWdodCBuZWVkIGl0LiBCdXQgYnkgdGVsbGluZyB0aGUgUlAgYW4gaWRlbnRpZmll ciBmb3IgdGhlIHVzZXIgYW5kIGEgdGFnIG9mIHdoZW4gYW55IG9mIHRoZWlyIGluZm9ybWF0aW9u IHdhcyBsYXN0IHVwZGF0ZWQgSSBjYW4gbWFrZSB0aGUgZGVjaXNpb24gd2hldGhlciBvciBub3Qg dG8gcHVsbCBpbmZvcm1hdGlvbiBhdCB0aGUgUlAgaW4gYW4gaW50ZWxsaWdlbnQgZmFzaGlvbiBp ZiBJIHdhbnQgdG8uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A74oCUIEp1c3Rp bjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZndDsgT24gSmFuIDE2LCAyMDIwLCBhdCA1 OjI5IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJp Y2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5yaWNoYW5uYUBhbWF6 b24uY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQom Z3Q7IFRoZSBzYW1lIGNvdWxkIGJlIHNhaWQgZm9yIGFueSByZXNvdXJjZSwgcGFydGljdWxhcmx5 IGluIHNjZW5hcmlvcyB3aGVyZSB0aGUgaW50ZXJhY3Rpb24gd2FzIGtpY2tlZCBvZmYgc28gdGhh dCB0aGUgU1AgY2FuIHBlcmZvcm0gYSBzcGVjaWZpYyBhY3Rpb24gaW5pdGlhdGVkIGJ5IHRoZSB1 c2VyIChlLmcuLCBjaGFyZ2luZyBhIGNyZWRpdCBjYXJkIG9yIGFjY291bnQsIHB1Ymxpc2hpbmcg YSBtZXNzYWdlIHRvIGEgbWVzc2FnZSBib2FyZCBvcg0KIHNvY2lhbCBtZWRpYSBmZWVkLCByZXRy aWV2aW5nIGEgc3BlY2lmaWMgZG9jdW1lbnQgb3IgaW1hZ2UpLjxiciBjbGFzcz0iIj4NCiZndDsg PGJyIGNsYXNzPSIiPg0KJmd0OyBDb25zaWRlciBhIGZsb3cgbGlrZSB0aGUgZm9sbG93aW5nOjxi ciBjbGFzcz0iIj4NCiZndDsgMS4gVGhlIGVuZCB1c2VyIGlzIG9uIGEgY2xpZW50IHdlYnNpdGUg dGhhdCBwcm92aWRlcyBhIHBob3RvIHByaW50aW5nIHNlcnZpY2UsIGNsaWNrcyB0aGUgJnF1b3Q7 UHJpbnQgZnJvbSBDbG91ZFN0b3JhZ2VQcm92aWRlciZxdW90OyBidXR0b24uPGJyIGNsYXNzPSIi Pg0KJmd0OyA0LiBUaGUgY2xpZW50IGluaXRhdGVzIFR4QXV0aCB2aWEgQ2xvdWRTdG9yYWdlUHJv dmlkZXIncyB0cmFuc2FjdGlvbiBlbmRwb2ludCwgcmVxdWVzdGluZyBhIFVSTCBmb3IgYSBwaG90 byB0byBiZSBzZWxlY3RlZCBieSB0aGUgZW5kIHVzZXIuPGJyIGNsYXNzPSIiPg0KJmd0OyA1LiBD bG91ZFN0b3JhZ2VQcm92aWRlciByZXR1cm5zIGFuIGludGVyYWN0X3VybCBwb2ludGluZyB0byBp dHMgQVMuPGJyIGNsYXNzPSIiPg0KJmd0OyA2LiBUaGUgY2xpZW50IHJlZGlyZWN0cyB0aGUgdXNl ciBhZ2VudCB0byB0aGUgQVMuPGJyIGNsYXNzPSIiPg0KJmd0OyA3LiBUaGUgZW5kIHVzZXIgc2ln bnMgaW4sIGFuZCBzZWxlY3RzIHRoZSBwaG90byB0aGV5IHdhbnQgdG8gcHJpbnQsIGFuZCBjb25m aXJtcyBhdXRob3JpemF0aW9uIHRvIHNoYXJlIHdpdGggdGhlIGNsaWVudC48YnIgY2xhc3M9IiI+ DQomZ3Q7IDguIFRoZSBBUyByZWRpcmVjdHMgdGhlIHVzZXIgYWdlbnQgYmFjayB0byBjbGllbnQu PGJyIGNsYXNzPSIiPg0KJmd0OyA5LiBUaGUgY2xpZW50IGNhbGxzIGJhY2sgdG8gQ2xvdWRTdG9y YWdlUHJvdmlkZXIncyB0cmFuc2FjdGlvbiBlbmRwb2ludCB0byBjb250aW51ZSB0aGUgVHhBdXRo IHRyYW5zYWN0aW9uLjxiciBjbGFzcz0iIj4NCiZndDsgMTAuIENsb3VkU3RvcmFnZVByb3ZpZGVy IHJldHVybnMgY29uZmlybWF0aW9uIHRoYXQgdGhlIGF1dGhvcml6YXRpb24gd2FzIGdyYW50ZWQs IGFsb25nIHdpdGggdGhlIFVSTCBmb3IgdGhlIHNlbGVjdGVkIHBob3RvLjxiciBjbGFzcz0iIj4N CiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBUaGlzIGlzIGlkZW50aWNhbCB0byB0aGUgaWRlbnRp dHkgdXNlIGNhc2UsIHdlJ3ZlIGp1c3QgcmVwbGFjZWQgaWRlbnRpdHkgY2xhaW1zIHdpdGggYSBV UkwgdG8gYSBwaG90by4gSSBzZWUgYSBsb3Qgb2YgdmFsdWUgaW4gZW5jb3VyYWdpbmcgb25lLXRp bWUgYXV0aG9yaXphdGlvbiBvZiBzcGVjaWZpYyBhY3Rpb25zIGxpa2UgdGhpcywgYW5kIGlmIHdl J3JlIGdvaW5nIHRvIHN1cHBvcnQgaW5saW5pbmcgb2YgcmVzb3VyY2VzIGZvciBpZGVudGl0eQ0K IGNsYWltcyBhbnl3YXksIGl0J3Mgbm90IGEgYmlnIHN0cmV0Y2ggdG8gYWxsb3cgZm9yIGFyYml0 cmFyeSByZXNvdXJjZSB0eXBlcy4gSSBkbyB0aGluayBpdCdzIGZhaXIgdG8gbmFycm93bHkgc2Nv cGUgdGhlIGtpbmRzIG9mIHJlc291cmNlICpzY2hlbWFzKiB0aGUgV0cgd2lsbCBkZWZpbmUgKGUu Zy4sIGRlZmluaW5nIGNvcmUgaWRlbnRpdHkgY2xhaW1zIGxpa2UgT0lEQyBkaWQpLCBidXQgdGhl IGlubGluaW5nIG1lY2hhbmlzbSBzaG91bGQgYmUNCiBmbGV4aWJsZSAoZS5nLiwgbm90IGxpbWl0 aW5nIHRoaXMgdG8gY2xhaW1zIGFib3V0IHRoZSBlbmQgdXNlciBpZGVudGl0eSwgbGlrZSBPSURD IGRpZCkuPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IOKAkyA8YnIgY2xh c3M9IiI+DQomZ3Q7IEFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48YnIgY2xhc3M9IiI+DQomZ3Q7 IEFXUyBJZGVudGl0eTxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIg Y2xhc3M9IiI+DQomZ3Q7IO+7v09uIDEvMTYvMjAsIDEyOjU5IFBNLCAmcXVvdDtUeGF1dGggb24g YmVoYWxmIG9mIEp1c3RpbiBSaWNoZXImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1dGgt Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnR4YXV0aC1ib3VuY2Vz QGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5l ZHUiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90 ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7IEkg dGhpbmsgdGhhdOKAmXMgZXhhY3RseSB0aGUgcmVhc29uIOKAlCB0aGUgY2FzZSBvZiBnZXR0aW5n IGluZm9ybWF0aW9uIGFib3V0IHRoZSB1c2VyIGRpcmVjdGx5IGZyb20gdGhlIFRYIGVuZHBvaW50 IGlzIHdlbGwgZXN0YWJsaXNoZWQuIFBlb3BsZSBkb27igJl0IHdhbnQgdG8gbWFrZSBhbm90aGVy IHJvdW5kIHRyaXAganVzdCB0byBmaWd1cmUgb3V0IHdob+KAmXMgdGhlcmUsIHdoZW4gYSBsb3Qg b2YgdGltZSB0aGF04oCZcyB0aGUgZmlyc3QgdGhpbmcNCiB0aGV5IGNhcmUgYWJvdXQsIGFuZCB0 aGVuIHRoZeKAmWQgbWFrZSB0aGUgZGV0ZXJtaW5hdGlvbiBvZiB3aGV0aGVyIHRvIGZvbGxvdyBv dGhlciBBUElzIGFmdGVyIHRoYXQuDQo8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4N CiZndDsmbmJzcDsgJm5ic3A7IFNvIGlmIEkgY2FuIHNlbmQgeW91IGEgdmVyeSBiYXNpYyBzZXQg b2YgYXV0aG4gaW5mbyBmcm9tIHRoZSBjYWxsYmFjaywgbGlrZSBhbiBpZGVudGlmaWVyIGFuZCBW b1Qgc3R5bGUgbG9naW4gaW5mb3JtYXRpb24sIHRoZW4geW91IGNhbiBmaWd1cmUgb3V0IGlmIHlv dSBuZWVkIHRvIGtub3cgbW9yZSBhYm91dCB0aGF0IHVzZXIgb3Igbm90LiBCdXQgdGhlc2UgYmFz aWMgY2xhaW1zIGRvIGdldCBlbGV2YXRlZCB0byB0aGUgc2FtZSBsZXZlbA0KIGFzIG90aGVyIHJl dHVybmVkIGFydGlmYWN0cyBmcm9tIHRoZSB0cmFuc2FjdGlvbiwgbGlrZSB0aGUgYWNjZXNzIHRv a2Vucy48YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO+KAlCBKdXN0aW48YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7IE9uIEphbiAxNiwgMjAyMCwgYXQgMjoxMiBQTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFu ayIgY2xhc3M9IiI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFRoZSBvbmx5IHJlYXNvbiBJIGNh biB0aGluayBvZiB0byBzaW5nbGUgb3V0IGlkZW50aXR5IHdpdGhpbiB0aGUgY2hhcnRlciBpcyBp ZiB0aGVyZSBpcyBzb21lIHdvcmsgb3IgZmVhdHVyZSB0aGF0IGlzIHdpdGhpbiBzY29wZSBmb3Ig dGhlIHdvcmtpbmcgZ3JvdXAsIGJ1dCBvbmx5IGZvciBpZGVudGl0eSBjbGFpbXMgKGUuZy4sIHJl dHVybmluZyBpZGVudGl0eSBjbGFpbXMgZnJvbSB0aGUgdHJhbnNhY3Rpb24gZW5kcG9pbnQpLiBS ZXBlYXRpbmcNCiBhIHF1ZXN0aW9uIEkgcG9zZWQgZWFybGllciwgd2hhdCBpcyBpdCBhYm91dCBp ZGVudGl0eSBjbGFpbXMgdGhhdCBtYWtlIHRoZW0gd29ydGh5IG9mIHNwZWNpYWwgY29uc2lkZXJh dGlvbj88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyDigJMg PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7IEFXUyBJZGVudGl0eTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IE9uIDEvMTYvMjAsIDg6 NTEgQU0sICZxdW90O0p1c3RpbiBSaWNoZXImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmlj aGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5qcmljaGVyQG1pdC5lZHU8L2E+ Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDtPbiBKYW4gMTYsIDIwMjAsIGF0IDExOjE1IEFNLCBUb3JzdGVuIExvZGRl cnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdyb3Rl OjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsg PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyZn dDsgQW0gMTYuMDEuMjAyMCB1bSAxNjo0NSBzY2hyaWViIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5qcmlj aGVyQG1pdC5lZHU8L2E+Jmd0Ozo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyZndDsgLSBBcHByb3ZhbCBvZiBpZGVudGl0eSBjbGFpbXMg YW5kIG11bHRpcGxlIHJlc291cmNlcyBpbiBhIHNpbmdsZSBpbnRlcmFjdGlvbjxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgVGhpcyBzb3VuZHMg YSBiaXQgaW5jb21wbGV0ZSB0byBtZS4gSSBhc3N1bWUgdGhlIHVzZXIgd291bGQgYXBwcm92ZSDi gJ50aGUgYXR0ZXN0YXRpb24gb2YgaWRlbnRpdHkgY2xhaW1z4oCcLiBJIGZ1cnRoZXJtb3JlIHRo aW5rIHRoZSB1c2VyIHdvdWxkIGFwcHJvdmUg4oCeYWNjZXNzIHRvIG11bHRpcGxlIEFQSXPigJwu IEkgd291bGQgcHJlZmVyIEFQSSBvdmVyIHJlc291cmNlIGJlY2F1c2UgaXQgaXMgbW9yZSB1bml2 ZXJzYWwuIEZvciBleGFtcGxlLCB0aGUNCiBwcm90b2NvbCBjb3VsZCBhbHNvIGJlIHVzZWQgdG8g Y3JlYXRlIHJlc291cmNlcy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyZuYnNwOyAmbmJzcDtQb2ludCB0YWtlbiwgYnV0IHRoaXMgaXNu4oCZdCBtZWFudCB0 byBiZSBhbiBleGhhdXN0aXZlIGxpc3Qgb2Ygd2hhdCBpdCBjYW4gZG8sIG1lcmVseSB0aGUgbGlz dCBvZiB0aGluZ3Mgd2XigJlyZSBwb3NpdGl2ZSB3ZSB3YW50IGl0IHRvIGRvLiBJIGFsc28gcHJl ZmVyIOKAnEFQSeKAnSBvdmVyIOKAnHJlc291cmNl4oCdLCBidXQgY29uY2VkZSB0aGF0IOKAnHJl c291cmNl4oCdIGNhbiBiZSBhIHdyaXRlYWJsZSB0aGluZyB0b28uIEV2ZW4gdGhlbiBJ4oCZbSBo YXBweQ0KIHRvIHR3ZWFrIHRoZSBsYW5ndWFnZSBoZXJlLiA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg4oCUIEp1c3RpbjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZu YnNwOyAmbmJzcDsgLS0gPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgVHhhdXRoIG1h aWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0 bzpUeGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5UeGF1dGhAaWV0Zi5v cmc8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFy Z2V0PSJfYmxhbmsiIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90eGF1dGg8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IDxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPHNwYW4+LS0g PC9zcGFuPjxicj4NCjxzcGFuPlR4YXV0aCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+ VHhhdXRoQGlldGYub3JnPC9zcGFuPjxicj4NCjxzcGFuPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHhhdXRoPC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_82AAD6495A474A89A32FBCC593EEE343amazoncom_-- From nobody Sat Jan 18 06:02: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 C71B1120019 for ; Sat, 18 Jan 2020 06:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 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] 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 JyN0sKiDBbT1 for ; Sat, 18 Jan 2020 06:02:06 -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 E6E14120013 for ; Sat, 18 Jan 2020 06:02:05 -0800 (PST) Received: from himiko.home (pool-70-109-130-118.cncdnh.east.myfairpoint.net [70.109.130.118] (may be forged)) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00IE21Gj031480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 18 Jan 2020 09:02:02 -0500 From: Justin Richer Message-Id: <185A1120-8A89-45D5-A703-FA85238C57C5@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_9D8A0EBE-4BC0-473D-BD25-25B8DB862FDA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 18 Jan 2020 09:02:01 -0500 In-Reply-To: <82AAD649-5A47-4A89-A32F-BCC593EEE343@amazon.com> Cc: Dick Hardt , Torsten Lodderstedt , "txauth@ietf.org" To: "Richard Backman, Annabelle" References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> <5A7FEF06-954E-47B1-B3CE-AD5DE2329B52@mit.edu> <7A4FC2A4-9960-4A75-847C-0477FE81DB4F@amazon.com> <00C978A2-E4B1-4EEB-BA0E-5FF0A9B871F0@mit.edu> <82AAD649-5A47-4A89-A32F-BCC593EEE343@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] alternative charter writeup 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, 18 Jan 2020 14:02:11 -0000 --Apple-Mail=_9D8A0EBE-4BC0-473D-BD25-25B8DB862FDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That=E2=80=99s a reasonable take, thanks for bringing up the discussion. =E2=80=94 Justin > On Jan 17, 2020, at 10:59 AM, Richard Backman, Annabelle = wrote: >=20 > My experience is that people will stretch and comfort the semantics of = =E2=80=9Cidentity claims=E2=80=9D to fit this use cases. I=E2=80=99m = fine with deferring the discussion to the WG, provided that we agree the = charter doesn=E2=80=99t rule out the possibility. >=20 > Sent from my iPhone >=20 >> On Jan 17, 2020, at 5:49 AM, Justin Richer wrote: >>=20 >> =EF=BB=BF I=E2=80=99m thinking this as well =E2=80=94 I think it=E2=80=99= s the kind of detail that the WG can sort out, and that=E2=80=99s what I = mean by figuring out a way to generalize my point #3 below into = Annabelle=E2=80=99s use cases. I=E2=80=99m for figuring it out if we can = do it, but not at the expense of what I=E2=80=99m seeing as a pretty = clear set of semantics already.=20 >>=20 >> VoT =3D=3D Vectors of Trust, RFC8485. A way to communicate = information about the user logging in, basically authentication context = but with more dimensions. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jan 16, 2020, at 6:00 PM, Dick Hardt > wrote: >>>=20 >>> I was thinking that other kinds of delegation results would be yet = another top level request, and matching response. Since it is not a = widely deployed use case today, it would be an extension to the core = protocol. >>>=20 >>> Justin: What to you mean by VoT? >>>=20 >>> wrt. returning claims, vs access to claims, I think it is an = important discussion -- but let's put a pin in that for discussion in = the WG once we are formed! I don't think that needs to be in the = charter, but happy to be convinced otherwise.=20 >>> =E1=90=A7 >>>=20 >>> On Thu, Jan 16, 2020 at 2:49 PM Justin Richer > wrote: >>> I=E2=80=99m cautiously Ok with having resource inlining be in scope = =E2=80=94 IF we can generalize it from the identity case specifically. >>>=20 >>> To do what you=E2=80=99re asking for though, the WG can still be = chartered to solve identity (which we know is a well-established and = understood use case), but also allow other things.=20 >>>=20 >>> This gets back to a fundamental question that I don=E2=80=99t have a = clear answer for yet: what do you get back at the end of a transaction? = Right now we=E2=80=99ve got a clear call for three things: >>>=20 >>> 1. Access tokens to call APIs >>> 2. Transaction handles to continue the transaction later (like a = refresh token but better) >>> 3. User identity claims >>>=20 >>> Maybe the mechanism we use for #3 can be generalized, or maybe = there=E2=80=99s even a good way to provide switches for #1, #2, and #3.=20= >>>=20 >>> And while we=E2=80=99re on the topic of #3, I think there=E2=80=99s = a strong case to be made that it should NOT be a user=E2=80=99s profile = information, but rather just enough information to identify the user to = the RP. If the RP wants to pull more profile info, it can do so via an = API. This keeps us out of the anti-pattern that SAML has of always = sending all claims about a user whether the RP needs them or not. But = the RP will at least need to know if it has to request the claims, and = we can do that by a simple enough structure like: >>>=20 >>> user: { >>> =E2=80=9Ciss=E2=80=9D: =E2=80=9Chttp://foo.bar/ = =E2=80=9C, >>> =E2=80=9Csub=E2=80=9D: =E2=80=9C12387yhjfre=E2=80=9D, >>> =E2=80=9Clast_updated=E2=80=9D: 54239084 >>> } >>>=20 >>>=20 >>> You can add VoT and other things that can vary per-login here as = well. But I shouldn=E2=80=99t be sending you the user=E2=80=99s name and = address every time they log in =E2=80=94 as an RP you only need to get = that if it=E2=80=99s a new account or if it=E2=80=99s been updated since = you last saw it. You can=E2=80=99t handle that if you=E2=80=99re pushing = all the claims in the response: Since the RP doesn=E2=80=99t know who = the user is until after this stage, it can=E2=80=99t tell that = information to the IdP ahead of time and therefore the IdP is forced to = always send it just in case the RP might need it. But by telling the RP = an identifier for the user and a tag of when any of their information = was last updated I can make the decision whether or not to pull = information at the RP in an intelligent fashion if I want to. >>>=20 >>> =E2=80=94 Justin >>>=20 >>> > On Jan 16, 2020, at 5:29 PM, Richard Backman, Annabelle = > wrote: >>> >=20 >>> > The same could be said for any resource, particularly in scenarios = where the interaction was kicked off so that the SP can perform a = specific action initiated by the user (e.g., charging a credit card or = account, publishing a message to a message board or social media feed, = retrieving a specific document or image). >>> >=20 >>> > Consider a flow like the following: >>> > 1. The end user is on a client website that provides a photo = printing service, clicks the "Print from CloudStorageProvider" button. >>> > 4. The client initates TxAuth via CloudStorageProvider's = transaction endpoint, requesting a URL for a photo to be selected by the = end user. >>> > 5. CloudStorageProvider returns an interact_url pointing to its = AS. >>> > 6. The client redirects the user agent to the AS. >>> > 7. The end user signs in, and selects the photo they want to = print, and confirms authorization to share with the client. >>> > 8. The AS redirects the user agent back to client. >>> > 9. The client calls back to CloudStorageProvider's transaction = endpoint to continue the TxAuth transaction. >>> > 10. CloudStorageProvider returns confirmation that the = authorization was granted, along with the URL for the selected photo. >>> >=20 >>> > This is identical to the identity use case, we've just replaced = identity claims with a URL to a photo. I see a lot of value in = encouraging one-time authorization of specific actions like this, and if = we're going to support inlining of resources for identity claims anyway, = it's not a big stretch to allow for arbitrary resource types. I do think = it's fair to narrowly scope the kinds of resource *schemas* the WG will = define (e.g., defining core identity claims like OIDC did), but the = inlining mechanism should be flexible (e.g., not limiting this to claims = about the end user identity, like OIDC did). >>> >=20 >>> > =E2=80=93=20 >>> > Annabelle Richard Backman >>> > AWS Identity >>> >=20 >>> >=20 >>> > =EF=BB=BFOn 1/16/20, 12:59 PM, "Txauth on behalf of Justin Richer" = on behalf of = jricher@mit.edu > wrote: >>> >=20 >>> > I think that=E2=80=99s exactly the reason =E2=80=94 the case of = getting information about the user directly from the TX endpoint is well = established. People don=E2=80=99t want to make another round trip just = to figure out who=E2=80=99s there, when a lot of time that=E2=80=99s the = first thing they care about, and then the=E2=80=99d make the = determination of whether to follow other APIs after that.=20 >>> >=20 >>> > So if I can send you a very basic set of authn info from the = callback, like an identifier and VoT style login information, then you = can figure out if you need to know more about that user or not. But = these basic claims do get elevated to the same level as other returned = artifacts from the transaction, like the access tokens. >>> >=20 >>> > =E2=80=94 Justin >>> >=20 >>> >> On Jan 16, 2020, at 2:12 PM, Richard Backman, Annabelle = > wrote: >>> >>=20 >>> >> The only reason I can think of to single out identity within the = charter is if there is some work or feature that is within scope for the = working group, but only for identity claims (e.g., returning identity = claims from the transaction endpoint). Repeating a question I posed = earlier, what is it about identity claims that make them worthy of = special consideration? >>> >>=20 >>> >> =E2=80=93=20 >>> >> Annabelle Richard Backman >>> >> AWS Identity >>> >>=20 >>> >>=20 >>> >> On 1/16/20, 8:51 AM, "Justin Richer" > wrote: >>> >>=20 >>> >> On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt = > wrote: >>> >>>=20 >>> >>>=20 >>> >>>=20 >>> >>>> Am 16.01.2020 um 16:45 schrieb Justin Richer >: >>> >>>>=20 >>> >>>> - Approval of identity claims and multiple resources in a = single interaction >>> >>>=20 >>> >>> This sounds a bit incomplete to me. I assume the user would = approve =E2=80=9Ethe attestation of identity claims=E2=80=9C. I = furthermore think the user would approve =E2=80=9Eaccess to multiple = APIs=E2=80=9C. I would prefer API over resource because it is more = universal. For example, the protocol could also be used to create = resources. >>> >>=20 >>> >> Point taken, but this isn=E2=80=99t meant to be an exhaustive = list of what it can do, merely the list of things we=E2=80=99re positive = we want it to do. I also prefer =E2=80=9CAPI=E2=80=9D over = =E2=80=9Cresource=E2=80=9D, but concede that =E2=80=9Cresource=E2=80=9D = can be a writeable thing too. Even then I=E2=80=99m happy to tweak the = language here.=20 >>> >>=20 >>> >> =E2=80=94 Justin >>> >>=20 >>> >=20 >>> > --=20 >>> > Txauth mailing list >>> > Txauth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/txauth = >>> >=20 >>> >=20 >>>=20 >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_9D8A0EBE-4BC0-473D-BD25-25B8DB862FDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That=E2=80=99s a reasonable take, thanks for bringing up the = discussion.

 =E2=80= =94 Justin

On Jan 17, 2020, at 10:59 AM, Richard = Backman, Annabelle <richanna@amazon.com> wrote:

My experience is that people will stretch and comfort the semantics of = =E2=80=9Cidentity claims=E2=80=9D to fit this use cases. I=E2=80=99m = fine with deferring the discussion to the WG, provided that we agree the = charter doesn=E2=80=99t rule out the possibility.

Sent from my iPhone

On Jan 17, 2020, at 5:49 AM, Justin = Richer <jricher@mit.edu> wrote:

=EF=BB=BF I=E2=80=99m thinking this as well = =E2=80=94 I think it=E2=80=99s the kind of detail that the WG can sort = out, and that=E2=80=99s what I mean by figuring out a way to generalize = my point #3 below into Annabelle=E2=80=99s use cases. I=E2=80=99m for = figuring it out if we can do it, but not at the expense of what I=E2=80=99m seeing as a pretty clear set of = semantics already. 

VoT =3D=3D Vectors of Trust, RFC8485. A way to = communicate information about the user logging in, basically = authentication context but with more dimensions.

 =E2=80=94 Justin

On Jan 16, 2020, at 6:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I was thinking that other kinds of = delegation results would be yet another top level request, and matching = response. Since it is not a widely deployed use case today, it would be = an extension to the core protocol.

Justin:  What to you mean by VoT?

wrt. returning claims, vs access to claims, I think it = is an important discussion -- but let's put a pin in that for discussion = in the WG once we are formed! I don't think that needs to be in the = charter, but happy to be convinced otherwise. 
3D""=E1=90=A7

On Thu, Jan 16, 2020 at 2:49 PM = Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m cautiously Ok with having resource inlining be in scope =E2=80= =94 IF we can generalize it from the identity case specifically.

To do what you=E2=80=99re asking for though, the WG can still be = chartered to solve identity (which we know is a well-established and = understood use case), but also allow other things.

This gets back to a fundamental question that I don=E2=80=99t have a = clear answer for yet: what do you get back at the end of a transaction? = Right now we=E2=80=99ve got a clear call for three things:

1. Access tokens to call APIs
2. Transaction handles to continue the transaction later (like a refresh = token but better)
3. User identity claims

Maybe the mechanism we use for #3 can be generalized, or maybe there=E2=80= =99s even a good way to provide switches for #1, #2, and #3.

And while we=E2=80=99re on the topic of #3, I think there=E2=80=99s a = strong case to be made that it should NOT be a user=E2=80=99s profile = information, but rather just enough information to identify the user to = the RP. If the RP wants to pull more profile info, it can do so via an API. This keeps us out of the anti-pattern that SAML has of always = sending all claims about a user whether the RP needs them or not. But = the RP will at least need to know if it has to request the claims, and = we can do that by a simple enough structure like:

user: {
  =E2=80=9Ciss=E2=80=9D: =E2=80=9Chttp://foo.bar/=E2=80=9C= ,
  =E2=80=9Csub=E2=80=9D: =E2=80=9C12387yhjfre=E2=80=9D,
  =E2=80=9Clast_updated=E2=80=9D: 54239084
}


You can add VoT and other things that can vary per-login here as well. = But I shouldn=E2=80=99t be sending you the user=E2=80=99s name and = address every time they log in =E2=80=94 as an RP you only need to get = that if it=E2=80=99s a new account or if it=E2=80=99s been updated since = you last saw it. You can=E2=80=99t handle that if you=E2=80=99re pushing all the claims = in the response: Since the RP doesn=E2=80=99t know who the user is until = after this stage, it can=E2=80=99t tell that information to the IdP = ahead of time and therefore the IdP is forced to always send it just in = case the RP might need it. But by telling the RP an identifier for the user = and a tag of when any of their information was last updated I can make = the decision whether or not to pull information at the RP in an = intelligent fashion if I want to.

 =E2=80=94 Justin

> On Jan 16, 2020, at 5:29 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
>
> The same could be said for any resource, particularly in scenarios = where the interaction was kicked off so that the SP can perform a = specific action initiated by the user (e.g., charging a credit card or = account, publishing a message to a message board or social media feed, retrieving a specific document or image).
>
> Consider a flow like the following:
> 1. The end user is on a client website that provides a photo = printing service, clicks the "Print from CloudStorageProvider" = button.
> 4. The client initates TxAuth via CloudStorageProvider's = transaction endpoint, requesting a URL for a photo to be selected by the = end user.
> 5. CloudStorageProvider returns an interact_url pointing to its = AS.
> 6. The client redirects the user agent to the AS.
> 7. The end user signs in, and selects the photo they want to print, = and confirms authorization to share with the client.
> 8. The AS redirects the user agent back to client.
> 9. The client calls back to CloudStorageProvider's transaction = endpoint to continue the TxAuth transaction.
> 10. CloudStorageProvider returns confirmation that the = authorization was granted, along with the URL for the selected photo.
>
> This is identical to the identity use case, we've just replaced = identity claims with a URL to a photo. I see a lot of value in = encouraging one-time authorization of specific actions like this, and if = we're going to support inlining of resources for identity claims anyway, it's not a big stretch to allow for arbitrary resource = types. I do think it's fair to narrowly scope the kinds of resource = *schemas* the WG will define (e.g., defining core identity claims like = OIDC did), but the inlining mechanism should be flexible (e.g., not limiting this to claims about the end user = identity, like OIDC did).
>
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
>
> =EF=BB=BFOn 1/16/20, 12:59 PM, "Txauth on behalf of Justin Richer" = <txauth-bounces@ietf.org on behalf of jricher@mit.edu> wrote:
>
>    I think that=E2=80=99s exactly the reason =E2=80=94 = the case of getting information about the user directly from the TX = endpoint is well established. People don=E2=80=99t want to make another = round trip just to figure out who=E2=80=99s there, when a lot of time = that=E2=80=99s the first thing they care about, and then the=E2=80=99d make the determination of = whether to follow other APIs after that.
>
>    So if I can send you a very basic set of authn info = from the callback, like an identifier and VoT style login information, = then you can figure out if you need to know more about that user or not. = But these basic claims do get elevated to the same level as other returned artifacts from the transaction, like the access = tokens.
>
>     =E2=80=94 Justin
>
>> On Jan 16, 2020, at 2:12 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
>>
>> The only reason I can think of to single out identity within = the charter is if there is some work or feature that is within scope for = the working group, but only for identity claims (e.g., returning = identity claims from the transaction endpoint). Repeating a question I posed earlier, what is it about identity claims that make = them worthy of special consideration?
>>
>> =E2=80=93
>> Annabelle Richard Backman
>> AWS Identity
>>
>>
>> On 1/16/20, 8:51 AM, "Justin Richer" <jricher@mit.edu> wrote:
>>
>>   On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt = <torsten@lodderstedt.net> wrote:
>>>
>>>
>>>
>>>> Am 16.01.2020 um 16:45 schrieb Justin Richer <jricher@mit.edu>:
>>>>
>>>> - Approval of identity claims and multiple resources in = a single interaction
>>>
>>> This sounds a bit incomplete to me. I assume the user would = approve =E2=80=9Ethe attestation of identity claims=E2=80=9C. I = furthermore think the user would approve =E2=80=9Eaccess to multiple = APIs=E2=80=9C. I would prefer API over resource because it is more = universal. For example, the protocol could also be used to create resources.
>>
>>   Point taken, but this isn=E2=80=99t meant to be an = exhaustive list of what it can do, merely the list of things we=E2=80=99re= positive we want it to do. I also prefer =E2=80=9CAPI=E2=80=9D over = =E2=80=9Cresource=E2=80=9D, but concede that =E2=80=9Cresource=E2=80=9D = can be a writeable thing too. Even then I=E2=80=99m happy to tweak the language here.
>>
>>    =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=_9D8A0EBE-4BC0-473D-BD25-25B8DB862FDA-- From nobody Sat Jan 18 06:15: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 A28FF120106 for ; Sat, 18 Jan 2020 06:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 fse40jdV9k_X for ; Sat, 18 Jan 2020 06:15:07 -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 AA07D120013 for ; Sat, 18 Jan 2020 06:15:07 -0800 (PST) Received: from himiko.home (pool-70-109-130-118.cncdnh.east.myfairpoint.net [70.109.130.118]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00IEF5nS001692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 18 Jan 2020 09:15:06 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_54A76FB4-0721-4393-8135-76E950556CCA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <741262A9-A258-40DC-87AB-0ED7515D136E@mit.edu> Date: Sat, 18 Jan 2020 09:15:05 -0500 To: txauth@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Txauth] TxAuth Charter (Take 3.5) 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, 18 Jan 2020 14:15:16 -0000 --Apple-Mail=_54A76FB4-0721-4393-8135-76E950556CCA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for all the feedback and discussion on the last round of the = charter. I=E2=80=99ve made a few tweaks to it based on the conversations = on this list, and a couple off-list, and have incorporated them here. This group is chartered to develop a 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. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0 and = OpenID Connect (an extension of OAuth 2.0) as well as new use cases not = enabled by OAuth 2.0. 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 the authorizing party as necessary through interaction = mechanisms indicated by the protocol. This decoupling avoids many of the = security concerns and technical challenges of OAuth 2.0 as well as = providing 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 multiple resources and APIs in a single interaction - Separation between the party authorizing access and the party = operating the client requesting access - Web, mobile, single-page, interaction-constrained, and other types of = client 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 providing user, software, organization, and other = pieces of information used in authorization decisions - Token presentation mechanisms and key bindings - Optimization of information and API access beyond identity through the = delegation process 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 porting from OAuth 2.0 and OpenID Connect to the new = protocol where possible. While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3 where = possible, and will strive to enable simple mapping to other protocols = such as COAP. I would really appreciate the security AD=E2=80=99s weighing in at this = stage. Thanks again everyone! =E2=80=94 Justin= --Apple-Mail=_54A76FB4-0721-4393-8135-76E950556CCA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for all the feedback and discussion on the last round = of the charter. I=E2=80=99ve made a few tweaks to it based on the = conversations on this list, and a couple off-list, and have incorporated = them here.


This group is chartered to develop a 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. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0 and = OpenID Connect (an extension of OAuth 2.0) as well as new use cases not = enabled by OAuth 2.0.

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 = the authorizing party as necessary through interaction mechanisms = indicated by the protocol. This decoupling avoids many of the security = concerns and technical challenges of OAuth 2.0 as well as providing 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 multiple resources and APIs in a single = interaction
- Separation = between the party authorizing access and the party operating the client = requesting access
- Web, = mobile, single-page, interaction-constrained, and other types of client = 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 providing user, software, = organization, and other pieces of information used in authorization = decisions
- Token = presentation mechanisms and key bindings
- = Optimization of information and API access beyond identity through the = delegation process

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 porting from OAuth 2.0 and = OpenID Connect to the new protocol where possible.

While the initial work will focus on using HTTP for = communication between the client and the authorization server, the = working group will seek to take advantage of optimization features of = HTTP2 and HTTP3 where possible, and will strive to enable simple = mapping to other protocols such as = COAP.

I would really appreciate the security = AD=E2=80=99s weighing in at this stage. Thanks again everyone!

 =E2=80=94 = Justin
= --Apple-Mail=_54A76FB4-0721-4393-8135-76E950556CCA-- From nobody Mon Jan 20 08:55: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 CBBF71208E1 for ; Mon, 20 Jan 2020 08:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 0aZtl5Q_fUUF for ; Mon, 20 Jan 2020 08:55:14 -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 13AF61200A1 for ; Mon, 20 Jan 2020 08:55:13 -0800 (PST) Received: from [18.20.149.103] ([18.20.149.103]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00KGtCVA025608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 20 Jan 2020 11:55:12 -0500 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Mon, 20 Jan 2020 11:55:12 -0500 To: txauth@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Txauth] HTTP Signing Draft in HTTP 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, 20 Jan 2020 16:55:21 -0000 As many of you know, Annabelle and I have put forward a general-purpose = HTTP Signing specification in the HTTP Working Group, at least initially = based on the old Cavage signatures spec that=E2=80=99s been used in the = wild. We expect a number of important changes to happen as it goes = through the standards process (which is to say, we aren=E2=80=99t = approaching this to get a stamp on existing code), including some key = things that would allow it to be used for one of TxAuth=E2=80=99s proof = os possession mechanisms. In fact, I=E2=80=99ve implemented a version of = the Cavage draft in the XYZ prototype alongside DPoP style signatures = and my old OAuth HTTP Signing draft (which is now expired).=20 I believe this work will be an important building block for TxAuth, = alongside MTLS, JOSE, and other crypto systems.=20 The new draft is currently going through its call for adoption within = the HTTP WG, and if you have any interest in this work moving forward, = please join the thread on the HTTP list to show your support for the = draft. The Call For Adoption is currently open and runs through Jan 31. Thanks, =E2=80=94 Justin= From nobody Mon Jan 20 10:05: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 C573512008A for ; Mon, 20 Jan 2020 10:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 u97Buj5Y91V0 for ; Mon, 20 Jan 2020 10:05:53 -0800 (PST) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.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 02C9C1200A4 for ; Mon, 20 Jan 2020 10:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579543553; x=1611079553; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=UkaDjZxUSyBhH5UukS6ICmO0KUrrIGKAEca21VJNi94=; b=UZz5sKNmUrjgVEu8UMA9mxfIbci2bNxtj2R8xcSYQcn3G446fL5KZU4M 5icGdgoKfGnvzPRnGhcA1PLJLyIC+T8EW2S3Q0Gp4zwZs1eGkqFFHJOnJ uidwYIhu1PGqIG/W05aFAjjVnOJnKkIfDqCVsljxdBpRTCOTwzshpYdhr c=; IronPort-SDR: vBwQhqCAlwWRvZY3dK0f6Wh8esFinYdPOcmj87pPc50nXlKz/tz19Wvy0+nBd4j4lE3XZo32qM 2e4Xm8Rxxr4g== X-IronPort-AV: E=Sophos; i="5.70,342,1574121600"; d="scan'208,217"; a="13202522" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2c-168cbb73.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 20 Jan 2020 18:05:50 +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-168cbb73.us-west-2.amazon.com (Postfix) with ESMTPS id BD460A219D; Mon, 20 Jan 2020 18:05:49 +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, 20 Jan 2020 18:05: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.1367.3; Mon, 20 Jan 2020 18:05: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.1367.000; Mon, 20 Jan 2020 18:05:48 +0000 From: "Richard Backman, Annabelle" To: Justin Richer , "txauth@ietf.org" Thread-Topic: [Txauth] TxAuth Charter (Take 3.5) Thread-Index: AQHVzgnRN98YkPBboUqjc2m+EFLyh6fzVkwA Date: Mon, 20 Jan 2020 18:05:48 +0000 Message-ID: References: <741262A9-A258-40DC-87AB-0ED7515D136E@mit.edu> In-Reply-To: <741262A9-A258-40DC-87AB-0ED7515D136E@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.48] Content-Type: multipart/alternative; boundary="_000_F7F47DEFDB584F1DA00A8731D44F2FA0amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 20 Jan 2020 18:05:56 -0000 --_000_F7F47DEFDB584F1DA00A8731D44F2FA0amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TklUOiBNaXhlZCB2ZXJiIHRlbnNlcyBpbiB0aGUgbGFzdCBzZW50ZW5jZSBvZiBwYXJhZ3JhcGgg Mi4gUmVwbGFjZSDigJxhcyB3ZWxsIGFzIHByb3ZpZGluZ+KAnSB3aXRoIOKAnGFuZCBwcm92aWRl c+KAnS4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0K DQpGcm9tOiBUeGF1dGggPHR4YXV0aC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSnVz dGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1Pg0KRGF0ZTogU2F0dXJkYXksIEphbnVhcnkgMTgs IDIwMjAgYXQgNjoxNiBBTQ0KVG86ICJ0eGF1dGhAaWV0Zi5vcmciIDx0eGF1dGhAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbVHhhdXRoXSBUeEF1dGggQ2hhcnRlciAoVGFrZSAzLjUpDQoNClRoYW5rcyBm b3IgYWxsIHRoZSBmZWVkYmFjayBhbmQgZGlzY3Vzc2lvbiBvbiB0aGUgbGFzdCByb3VuZCBvZiB0 aGUgY2hhcnRlci4gSeKAmXZlIG1hZGUgYSBmZXcgdHdlYWtzIHRvIGl0IGJhc2VkIG9uIHRoZSBj b252ZXJzYXRpb25zIG9uIHRoaXMgbGlzdCwgYW5kIGEgY291cGxlIG9mZi1saXN0LCBhbmQgaGF2 ZSBpbmNvcnBvcmF0ZWQgdGhlbSBoZXJlLg0KDQoNClRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVkIHRv IGRldmVsb3AgYSBkZWxlZ2F0aW9uIHByb3RvY29sIGZvciBhdXRob3JpemF0aW9uLCBpZGVudGl0 eSwgYW5kIEFQSSBhY2Nlc3MuIFRoaXMgcHJvdG9jb2wgd2lsbCBhbGxvdyBhbiBhdXRob3Jpemlu ZyBwYXJ0eSB0byBkZWxlZ2F0ZSBhY2Nlc3MgdG8gY2xpZW50IHNvZnR3YXJlIHRocm91Z2ggYW4g YXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRoZSB1c2UgY2FzZXMgc3VwcG9ydGVkIGJ5IHRoaXMgcHJv dG9jb2wgd2lsbCBpbmNsdWRlIHdpZGVseSBkZXBsb3llZCB1c2UgY2FzZXMgY3VycmVudGx5IHN1 cHBvcnRlZCBieSBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0IChhbiBleHRlbnNpb24gb2Yg T0F1dGggMi4wKSBhcyB3ZWxsIGFzIG5ldyB1c2UgY2FzZXMgbm90IGVuYWJsZWQgYnkgT0F1dGgg Mi4wLg0KDQpUaGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYmUgYWN0ZWQgdXBvbiBieSBtdWx0 aXBsZSBwYXJ0aWVzIGluIHRoZSBwcm90b2NvbCwgZWFjaCBwZXJmb3JtaW5nIGEgc3BlY2lmaWMg cm9sZS4gVGhlIHByb3RvY29sIHdpbGwgZGVjb3VwbGUgdGhlIGludGVyYWN0aW9uIGNoYW5uZWxz LCBzdWNoIGFzIHRoZSBlbmQgdXNlcuKAmXMgYnJvd3NlciwgZnJvbSB0aGUgZGVsZWdhdGlvbiBj aGFubmVsLCB3aGljaCBoYXBwZW5zIGRpcmVjdGx5IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIChpbiBjb250cmFzdCB3aXRoIE9BdXRoIDIuMCB3aGljaCBp cyBpbml0aWF0ZWQgYnkgdGhlIGNsaWVudCByZWRpcmVjdGluZyB0aGUgdXNlcuKAmXMgYnJvd3Nl cikuIFRoZSBjbGllbnQgYW5kIEFTIHdpbGwgaW52b2x2ZSB0aGUgYXV0aG9yaXppbmcgcGFydHkg YXMgbmVjZXNzYXJ5IHRocm91Z2ggaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmRpY2F0ZWQgYnkg dGhlIHByb3RvY29sLiBUaGlzIGRlY291cGxpbmcgYXZvaWRzIG1hbnkgb2YgdGhlIHNlY3VyaXR5 IGNvbmNlcm5zIGFuZCB0ZWNobmljYWwgY2hhbGxlbmdlcyBvZiBPQXV0aCAyLjAgYXMgd2VsbCBh cyBwcm92aWRpbmcgYSBub24taW52YXNpdmUgcGF0aCBmb3Igc3VwcG9ydGluZyBmdXR1cmUgdHlw ZXMgb2YgY2xpZW50cyBhbmQgaW50ZXJhY3Rpb24gY2hhbm5lbHMuDQoNCkFkZGl0aW9uYWxseSwg dGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGFsbG93IGZvcjoNCg0KLSBGaW5lLWdyYWluZWQg c3BlY2lmaWNhdGlvbiBvZiBhY2Nlc3MNCi0gQXBwcm92YWwgb2YgQVMgYXR0ZXN0YXRpb24gdG8g aWRlbnRpdHkgY2xhaW1zDQotIEFwcHJvdmFsIG9mIG11bHRpcGxlIHJlc291cmNlcyBhbmQgQVBJ cyBpbiBhIHNpbmdsZSBpbnRlcmFjdGlvbg0KLSBTZXBhcmF0aW9uIGJldHdlZW4gdGhlIHBhcnR5 IGF1dGhvcml6aW5nIGFjY2VzcyBhbmQgdGhlIHBhcnR5IG9wZXJhdGluZyB0aGUgY2xpZW50IHJl cXVlc3RpbmcgYWNjZXNzDQotIFdlYiwgbW9iaWxlLCBzaW5nbGUtcGFnZSwgaW50ZXJhY3Rpb24t Y29uc3RyYWluZWQsIGFuZCBvdGhlciB0eXBlcyBvZiBjbGllbnQgYXBwbGljYXRpb25zDQoNClRo ZSBncm91cCB3aWxsIGRlZmluZSBleHRlbnNpb24gcG9pbnRzIGZvciB0aGlzIHByb3RvY29sIHRv IGFsbG93IGZvciBmbGV4aWJpbGl0eSBpbiBhcmVhcyBpbmNsdWRpbmc6DQoNCi0gQ3J5cHRvZ3Jh cGhpYyBhZ2lsaXR5IGZvciBrZXlzLCBtZXNzYWdlIHNpZ25hdHVyZXMsIGFuZCBwcm9vZiBvZiBw b3NzZXNzaW9uDQotIFVzZXIgaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFu ZCBub24td2ViIG1ldGhvZHMNCi0gTWVjaGFuaXNtcyBmb3IgcHJvdmlkaW5nIHVzZXIsIHNvZnR3 YXJlLCBvcmdhbml6YXRpb24sIGFuZCBvdGhlciBwaWVjZXMgb2YgaW5mb3JtYXRpb24gdXNlZCBp biBhdXRob3JpemF0aW9uIGRlY2lzaW9ucw0KLSBUb2tlbiBwcmVzZW50YXRpb24gbWVjaGFuaXNt cyBhbmQga2V5IGJpbmRpbmdzDQotIE9wdGltaXphdGlvbiBvZiBpbmZvcm1hdGlvbiBhbmQgQVBJ IGFjY2VzcyBiZXlvbmQgaWRlbnRpdHkgdGhyb3VnaCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzDQoN CkFkZGl0aW9uYWxseSwgdGhlIGdyb3VwIHdpbGwgcHJvdmlkZSBtZWNoYW5pc21zIGZvciBtYW5h Z2VtZW50IG9mIHRoZSBwcm90b2NvbCBsaWZlY3ljbGUgaW5jbHVkaW5nOg0KDQotIERpc2NvdmVy eSBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXINCi0gUmV2b2NhdGlvbiBvZiBhY3RpdmUgdG9r ZW5zDQotIFF1ZXJ5IG9mIHRva2VuIHJpZ2h0cyBieSByZXNvdXJjZSBzZXJ2ZXJzDQoNCkFsdGhv dWdoIHRoZSBhcnRpZmFjdHMgZm9yIHRoaXMgd29yayBhcmUgbm90IGludGVuZGVkIG9yIGV4cGVj dGVkIHRvIGJlIGJhY2t3YXJkcy1jb21wYXRpYmxlIHdpdGggT0F1dGggMi4wIG9yIE9wZW5JRCBD b25uZWN0LCB0aGUgZ3JvdXAgd2lsbCBhdHRlbXB0IHRvIHNpbXBsaWZ5IHBvcnRpbmcgZnJvbSBP QXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0IHRvIHRoZSBuZXcgcHJvdG9jb2wgd2hlcmUgcG9z c2libGUuDQoNCldoaWxlIHRoZSBpbml0aWFsIHdvcmsgd2lsbCBmb2N1cyBvbiB1c2luZyBIVFRQ IGZvciBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyLCB0aGUgd29ya2luZyBncm91cCB3aWxsIHNlZWsgdG8gdGFrZSBhZHZhbnRhZ2Ug b2Ygb3B0aW1pemF0aW9uIGZlYXR1cmVzIG9mIEhUVFAyIGFuZCBIVFRQMyB3aGVyZSBwb3NzaWJs ZSwgYW5kIHdpbGwgc3RyaXZlIHRvIGVuYWJsZSBzaW1wbGUgbWFwcGluZyB0byBvdGhlciBwcm90 b2NvbHMgc3VjaCBhcyBDT0FQLg0KDQpJIHdvdWxkIHJlYWxseSBhcHByZWNpYXRlIHRoZSBzZWN1 cml0eSBBROKAmXMgd2VpZ2hpbmcgaW4gYXQgdGhpcyBzdGFnZS4gVGhhbmtzIGFnYWluIGV2ZXJ5 b25lIQ0KDQog4oCUIEp1c3Rpbg0K --_000_F7F47DEFDB584F1DA00A8731D44F2FA0amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2 M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0Rjcy Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5JVDog TWl4ZWQgdmVyYiB0ZW5zZXMgaW4gdGhlIGxhc3Qgc2VudGVuY2Ugb2YgcGFyYWdyYXBoIDIuIFJl cGxhY2Ug4oCcYXMgd2VsbCBhcyBwcm92aWRpbmfigJ0gd2l0aCDigJxhbmQgcHJvdmlkZXPigJ0u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2tt YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlR4YXV0aCAmbHQ7dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7IG9uIGJlaGFsZiBvZiBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPlNhdHVyZGF5LCBKYW51YXJ5IDE4LCAyMDIwIGF0IDY6MTYgQU08YnI+ DQo8Yj5UbzogPC9iPiZxdW90O3R4YXV0aEBpZXRmLm9yZyZxdW90OyAmbHQ7dHhhdXRoQGlldGYu b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bVHhhdXRoXSBUeEF1dGggQ2hhcnRlciAoVGFr ZSAzLjUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyBmb3IgYWxsIHRoZSBmZWVkYmFjayBhbmQgZGlzY3Vzc2lvbiBvbiB0aGUgbGFz dCByb3VuZCBvZiB0aGUgY2hhcnRlci4gSeKAmXZlIG1hZGUgYSBmZXcgdHdlYWtzIHRvIGl0IGJh c2VkIG9uIHRoZSBjb252ZXJzYXRpb25zIG9uIHRoaXMgbGlzdCwgYW5kIGEgY291cGxlIG9mZi1s aXN0LCBhbmQgaGF2ZSBpbmNvcnBvcmF0ZWQgdGhlbSBoZXJlLg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZ3JvdXAg aXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBkZWxlZ2F0aW9uIHByb3RvY29sIGZvciBhdXRob3Jp emF0aW9uLCBpZGVudGl0eSwgYW5kIEFQSSBhY2Nlc3MuIFRoaXMgcHJvdG9jb2wgd2lsbCBhbGxv dyBhbiBhdXRob3JpemluZyBwYXJ0eSB0byBkZWxlZ2F0ZSBhY2Nlc3MgdG8gY2xpZW50IHNvZnR3 YXJlIHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRoZSB1c2UgY2FzZXMgc3VwcG9y dGVkDQogYnkgdGhpcyBwcm90b2NvbCB3aWxsIGluY2x1ZGUgd2lkZWx5IGRlcGxveWVkIHVzZSBj YXNlcyBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5IE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3Qg KGFuIGV4dGVuc2lvbiBvZiBPQXV0aCAyLjApIGFzIHdlbGwgYXMgbmV3IHVzZSBjYXNlcyBub3Qg ZW5hYmxlZCBieSBPQXV0aCAyLjAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkZWxl Z2F0aW9uIHByb2Nlc3Mgd2lsbCBiZSBhY3RlZCB1cG9uIGJ5IG11bHRpcGxlIHBhcnRpZXMgaW4g dGhlIHByb3RvY29sLCBlYWNoIHBlcmZvcm1pbmcgYSBzcGVjaWZpYyByb2xlLiBUaGUgcHJvdG9j b2wgd2lsbCBkZWNvdXBsZSB0aGUgaW50ZXJhY3Rpb24gY2hhbm5lbHMsIHN1Y2ggYXMgdGhlIGVu ZCB1c2Vy4oCZcyBicm93c2VyLCBmcm9tIHRoZSBkZWxlZ2F0aW9uIGNoYW5uZWwsIHdoaWNoIGhh cHBlbnMNCiBkaXJlY3RseSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciAoaW4gY29udHJhc3Qgd2l0aCBPQXV0aCAyLjAgd2hpY2ggaXMgaW5pdGlhdGVkIGJ5 IHRoZSBjbGllbnQgcmVkaXJlY3RpbmcgdGhlIHVzZXLigJlzIGJyb3dzZXIpLiBUaGUgY2xpZW50 IGFuZCBBUyB3aWxsIGludm9sdmUgdGhlIGF1dGhvcml6aW5nIHBhcnR5IGFzIG5lY2Vzc2FyeSB0 aHJvdWdoIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5kaWNhdGVkDQogYnkgdGhlIHByb3RvY29s LiBUaGlzIGRlY291cGxpbmcgYXZvaWRzIG1hbnkgb2YgdGhlIHNlY3VyaXR5IGNvbmNlcm5zIGFu ZCB0ZWNobmljYWwgY2hhbGxlbmdlcyBvZiBPQXV0aCAyLjAgYXMgd2VsbCBhcyBwcm92aWRpbmcg YSBub24taW52YXNpdmUgcGF0aCBmb3Igc3VwcG9ydGluZyBmdXR1cmUgdHlwZXMgb2YgY2xpZW50 cyBhbmQgaW50ZXJhY3Rpb24gY2hhbm5lbHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFk ZGl0aW9uYWxseSwgdGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGFsbG93IGZvcjo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBGaW5lLWdyYWluZWQgc3BlY2lmaWNhdGlvbiBvZiBhY2Nl c3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0gQXBwcm92YWwgb2YgQVMgYXR0ZXN0YXRpb24gdG8gaWRlbnRpdHkgY2xh aW1zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t IEFwcHJvdmFsIG9mIG11bHRpcGxlIHJlc291cmNlcyBhbmQgQVBJcyBpbiBhIHNpbmdsZSBpbnRl cmFjdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LSBTZXBhcmF0aW9uIGJldHdlZW4gdGhlIHBhcnR5IGF1dGhvcml6 aW5nIGFjY2VzcyBhbmQgdGhlIHBhcnR5IG9wZXJhdGluZyB0aGUgY2xpZW50IHJlcXVlc3Rpbmcg YWNjZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tIFdlYiwgbW9iaWxlLCBzaW5nbGUtcGFnZSwgaW50ZXJhY3Rpb24t Y29uc3RyYWluZWQsIGFuZCBvdGhlciB0eXBlcyBvZiBjbGllbnQgYXBwbGljYXRpb25zPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBncm91cCB3aWxsIGRlZmluZSBleHRlbnNpb24gcG9p bnRzIGZvciB0aGlzIHByb3RvY29sIHRvIGFsbG93IGZvciBmbGV4aWJpbGl0eSBpbiBhcmVhcyBp bmNsdWRpbmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gQ3J5cHRvZ3JhcGhpYyBhZ2ls aXR5IGZvciBrZXlzLCBtZXNzYWdlIHNpZ25hdHVyZXMsIGFuZCBwcm9vZiBvZiBwb3NzZXNzaW9u Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tIFVzZXIgaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcg d2ViIGFuZCBub24td2ViIG1ldGhvZHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gTWVjaGFuaXNtcyBmb3IgcHJvdmlk aW5nIHVzZXIsIHNvZnR3YXJlLCBvcmdhbml6YXRpb24sIGFuZCBvdGhlciBwaWVjZXMgb2YgaW5m b3JtYXRpb24gdXNlZCBpbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uczxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBUb2tl biBwcmVzZW50YXRpb24gbWVjaGFuaXNtcyBhbmQga2V5IGJpbmRpbmdzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIE9wdGltaXphdGlvbiBvZiBp bmZvcm1hdGlvbiBhbmQgQVBJIGFjY2VzcyBiZXlvbmQgaWRlbnRpdHkgdGhyb3VnaCB0aGUgZGVs ZWdhdGlvbiBwcm9jZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFkZGl0aW9uYWxseSwg dGhlIGdyb3VwIHdpbGwgcHJvdmlkZSBtZWNoYW5pc21zIGZvciBtYW5hZ2VtZW50IG9mIHRoZSBw cm90b2NvbCBsaWZlY3ljbGUgaW5jbHVkaW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t IERpc2NvdmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXI8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gUmV2b2Nh dGlvbiBvZiBhY3RpdmUgdG9rZW5zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFF1ZXJ5IG9mIHRva2VuIHJpZ2h0cyBi eSByZXNvdXJjZSBzZXJ2ZXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsdGhvdWdoIHRo ZSBhcnRpZmFjdHMgZm9yIHRoaXMgd29yayBhcmUgbm90IGludGVuZGVkIG9yIGV4cGVjdGVkIHRv IGJlIGJhY2t3YXJkcy1jb21wYXRpYmxlIHdpdGggT0F1dGggMi4wIG9yIE9wZW5JRCBDb25uZWN0 LCB0aGUgZ3JvdXAgd2lsbCZuYnNwO2F0dGVtcHQgdG8gc2ltcGxpZnkgcG9ydGluZyBmcm9tIE9B dXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3QgdG8gdGhlIG5ldyBwcm90b2NvbCB3aGVyZSBwb3Nz aWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgdGhlIGluaXRpYWwgd29yayB3 aWxsIGZvY3VzIG9uIHVzaW5nIEhUVFAgZm9yIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgY2xp ZW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwg c2VlayB0byB0YWtlIGFkdmFudGFnZSBvZiBvcHRpbWl6YXRpb24gZmVhdHVyZXMgb2YgSFRUUDIg YW5kIEhUVFAzIHdoZXJlIHBvc3NpYmxlLCBhbmQgd2lsbCBzdHJpdmUNCiB0byZuYnNwO2VuYWJs ZSBzaW1wbGUgbWFwcGluZyB0byBvdGhlciBwcm90b2NvbHMgc3VjaCBhcyBDT0FQLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCByZWFsbHkgYXBwcmVjaWF0ZSB0aGUgc2VjdXJp dHkgQUTigJlzIHdlaWdoaW5nIGluIGF0IHRoaXMgc3RhZ2UuIFRoYW5rcyBhZ2FpbiBldmVyeW9u ZSE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_F7F47DEFDB584F1DA00A8731D44F2FA0amazoncom_-- From nobody Tue Jan 21 02:57: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 6C64B1200C1 for ; Tue, 21 Jan 2020 02:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 SMwZarhxCuza for ; Tue, 21 Jan 2020 02:57:13 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C319120091 for ; Tue, 21 Jan 2020 02:57:13 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id b6so2680134wrq.0 for ; Tue, 21 Jan 2020 02:57:13 -0800 (PST) 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=wGtsnrjlxJVn83lCp7+6PUDML/ATunbNDID7eFh35wg=; b=md7030okp8yVx4KxOB9CUwgNU9zCUX/Z6ap03MnqKMxKYnWL4ZCL1F6e+livXZttK8 u/hABXexYU49xFiBHvMSyRALVpw991WmkbfJF+JsafVjk1WpG4W41eEz0ijPW+dUzp5+ Pq+AHlxVrmCiM+LRyGziqp1TkTDXFbqFNPoJgbTDUP14hehycCmkY7Fpivy8Aso57isR wtFyGaRXnVsHSP4w/fNbrMO1lD8TvAF29dkhihJljq9J1AJVvxv1/1KXiRH2YGbO3UES wKEqRszbqzzZ3VavABn+R5LfkJAxLLVYn9B6PDBtkeA7dOK7kEy9R/IiN11NR/Dae5La QeTQ== 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=wGtsnrjlxJVn83lCp7+6PUDML/ATunbNDID7eFh35wg=; b=GJ8KUBsH/sd9MXDeBpFL4pkMSEGJui3xhGzh3/paeWEJdMOXgQN7ASnQRwkAFFW/iI khM88uB1HfsjO/lxW6WJDyXHuG7Py9tOdOMBOUD9obJMf4aj6g0dv0itKJcPsJTlN5bR 9EavsV7z9iD3Lom6XxE0ZCgWELiBgXeJ5RgAtFrnUmsNF+wKzU7pojb+daxERcDvcAmN gnLazRJoEG6e0jL7CyqlxY7jWR3f9xzJbqXxJs92xFS3l2qCr4FDvI+qadbv42rEYr6A ryjTNF9wsqqfyVvkq/+/qangHvabKmDQ45WqdnQNQuX/cLnI6DEZRM48cODgrc/a2Thz wItQ== X-Gm-Message-State: APjAAAXQHcdi4yyr9sgj0YKatA+Ode1uAEg8pfTIjY37vBv2lqeGqM1S ljXUR+6VkagDpc4tL4D538T9VA== X-Google-Smtp-Source: APXvYqxc+lRNcxI9e4D3eXMHeo5GNVhedb2OPK41bVoxZA0893ueb1OMc2Jz61WTpfO9ivLZxRjEvg== X-Received: by 2002:a5d:6ac2:: with SMTP id u2mr4342373wrw.233.1579604231631; Tue, 21 Jan 2020 02:57:11 -0800 (PST) Received: from [10.3.21.206] (gate.haus-staade.de. [80.155.34.3]) by smtp.gmail.com with ESMTPSA id z8sm51021839wrq.22.2020.01.21.02.57.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jan 2020 02:57:10 -0800 (PST) From: Torsten Lodderstedt Message-Id: <2B53E22D-2C4C-4364-9A45-285D1195E642@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_B7CBABDB-7EAD-492B-8333-79B59CD9B37A"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Tue, 21 Jan 2020 11:56:07 +0100 In-Reply-To: Cc: Justin Richer , "txauth@ietf.org" To: "Richard Backman, Annabelle" References: <741262A9-A258-40DC-87AB-0ED7515D136E@mit.edu> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 21 Jan 2020 10:57:17 -0000 --Apple-Mail=_B7CBABDB-7EAD-492B-8333-79B59CD9B37A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 another NIT: Approval of =E2=80=9Caccess to=E2=80=9D multiple resources = and APIs in a single interaction > On 20. Jan 2020, at 19:05, Richard Backman, Annabelle = wrote: >=20 > NIT: Mixed verb tenses in the last sentence of paragraph 2. Replace = =E2=80=9Cas well as providing=E2=80=9D with =E2=80=9Cand provides=E2=80=9D= . > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: Txauth on behalf of Justin Richer = > Date: Saturday, January 18, 2020 at 6:16 AM > To: "txauth@ietf.org" > Subject: [Txauth] TxAuth Charter (Take 3.5) > =20 > Thanks for all the feedback and discussion on the last round of the = charter. I=E2=80=99ve made a few tweaks to it based on the conversations = on this list, and a couple off-list, and have incorporated them here. > =20 >> =20 >> This group is chartered to develop a 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. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0 and = OpenID Connect (an extension of OAuth 2.0) as well as new use cases not = enabled by OAuth 2.0. >> =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 the authorizing party as necessary through interaction = mechanisms indicated by the protocol. This decoupling avoids many of the = security concerns and technical challenges of OAuth 2.0 as well as = providing 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 multiple resources and APIs in a single interaction >> - Separation between the party authorizing access and the party = operating the client requesting access >> - Web, mobile, single-page, interaction-constrained, and other types = of client 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 providing user, software, organization, and other = pieces of information used in authorization decisions >> - Token presentation mechanisms and key bindings >> - Optimization of information and API access beyond identity through = the delegation process >> =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 porting from OAuth 2.0 and OpenID Connect to the new = protocol where possible. >> =20 >> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3 where = possible, and will strive to enable simple mapping to other protocols = such as COAP. > =20 > I would really appreciate the security AD=E2=80=99s weighing in at = this stage. Thanks again everyone! > =20 > =E2=80=94 Justin > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_B7CBABDB-7EAD-492B-8333-79B59CD9B37A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0yMDAxMjExMDU2MDdaMC8GCSqGSIb3DQEJBDEiBCCaiU4j+wd3TU7eLiau7IsYry6lhyeEWCsV 0byqIHFVBzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAETf1SqgMFZNnaM2SpghWA8bFyiBHz5/71ONWMPnQHai5TiSZv+3xuFExdpt qLi8NkJaI6b5WJHhImKmH0mDe/hIn8XljL4RxZwMu4h29eZw/0m5zTejk2Fa+XbzJsgxjtN569kH DJ8LUjVXGaQo6PvimUWxbGS8iQt6in3vAGvEpyA3sUHJ3sR12zgv7ObP1VMUVyJI9qJkQUcdHxeB jLB7CgXhwPIhYMLyiZ1/8Vmf3tYe7zMe4TDrOT/A8eYlpxEWTZZ93NRoMtdM5QhefNrCUiCmgnYf 1mAtToFOI+xtMZEmemz/cScYMbWpMnFMN/fG8OTGbS0iMjBASOwQYcQAAAAAAAA= --Apple-Mail=_B7CBABDB-7EAD-492B-8333-79B59CD9B37A-- From nobody Tue Jan 21 10:47: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 83CE81209EA for ; Tue, 21 Jan 2020 10:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 BhsugUIcrPGj for ; Tue, 21 Jan 2020 10:47:40 -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 0099C1209E2 for ; Tue, 21 Jan 2020 10:47:39 -0800 (PST) Received: from [192.168.1.7] (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 00LIlZ5p006060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jan 2020 13:47:37 -0500 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: <2B53E22D-2C4C-4364-9A45-285D1195E642@lodderstedt.net> Date: Tue, 21 Jan 2020 13:47:35 -0500 Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9A1D966F-F31D-4785-9FEF-6A87F1D80E37@mit.edu> References: <741262A9-A258-40DC-87AB-0ED7515D136E@mit.edu> <2B53E22D-2C4C-4364-9A45-285D1195E642@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 21 Jan 2020 18:47:44 -0000 Thanks, both of those nits make sense and we=E2=80=99ll be sure to = incorporate them.=20 =E2=80=94 Justin > On Jan 21, 2020, at 5:56 AM, Torsten Lodderstedt = wrote: >=20 > another NIT: Approval of =E2=80=9Caccess to=E2=80=9D multiple = resources and APIs in a single interaction >=20 >> On 20. Jan 2020, at 19:05, Richard Backman, Annabelle = wrote: >>=20 >> NIT: Mixed verb tenses in the last sentence of paragraph 2. Replace = =E2=80=9Cas well as providing=E2=80=9D with =E2=80=9Cand provides=E2=80=9D= . >>=20 >> =E2=80=93=20 >> Annabelle Richard Backman >> AWS Identity >>=20 >>=20 >> From: Txauth on behalf of Justin Richer = >> Date: Saturday, January 18, 2020 at 6:16 AM >> To: "txauth@ietf.org" >> Subject: [Txauth] TxAuth Charter (Take 3.5) >>=20 >> Thanks for all the feedback and discussion on the last round of the = charter. I=E2=80=99ve made a few tweaks to it based on the conversations = on this list, and a couple off-list, and have incorporated them here. >>=20 >>>=20 >>> This group is chartered to develop a 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. The use cases supported by this protocol will = include widely deployed use cases currently supported by OAuth 2.0 and = OpenID Connect (an extension of OAuth 2.0) as well as new use cases not = enabled by OAuth 2.0. >>>=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 the authorizing party as necessary through interaction = mechanisms indicated by the protocol. This decoupling avoids many of the = security concerns and technical challenges of OAuth 2.0 as well as = providing 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 multiple resources and APIs in a single interaction >>> - Separation between the party authorizing access and the party = operating the client requesting access >>> - Web, mobile, single-page, interaction-constrained, and other types = of client 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 providing user, software, organization, and other = pieces of information used in authorization decisions >>> - Token presentation mechanisms and key bindings >>> - Optimization of information and API access beyond identity through = the delegation process >>>=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 porting from OAuth 2.0 and OpenID Connect to the new = protocol where possible. >>>=20 >>> While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3 where = possible, and will strive to enable simple mapping to other protocols = such as COAP. >>=20 >> I would really appreciate the security AD=E2=80=99s weighing in at = this stage. Thanks again everyone! >>=20 >> =E2=80=94 Justin >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >=20 From nobody Mon Jan 27 07:00: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 26E8B12024E for ; Mon, 27 Jan 2020 07:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham 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 5eiwKu6ULESn for ; Mon, 27 Jan 2020 07:00:28 -0800 (PST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2100.outbound.protection.outlook.com [40.107.244.100]) (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 D4B1312025D for ; Mon, 27 Jan 2020 07:00:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f4Kl6/+TO2Wnnju1ukww3Y0lP7wn0afKOnvi5Tww0ZqCmIhhrpmrykBXJp+EUAvmE34xTMdFYiZJzjKm6uulf2R8rIxPbHFGU1kvu+0NbrMzk8YjIHC/Gwow+KBPtVt9VpGjGEJbvHuTJbWqjwHqKqJl5LTH7CfC4yYpa+6t9QRZms9OtxGpHAdUTBzQvGf/s//1FlwOGYfyK2Ig8o70FHXfRWNh8evSx6RctFcCA37dwA8tMQIK307TYCJSA14nw/5AWP3Ek5kk4Tw7zDmZNSfCdpgiA+vgxoBSuHcrMIRHqWitGsaamllLbUfTXVrLbypN16eu9HSGy93XKnTzow== 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=jAlnFlOJzNfp3xWoaE4bYY31wfayoLOI/hgzpu6b+jg=; b=hG7r4Oak7ogn1SWTTjYm+is6OfsfvQB94N9G3pXqIBYJBACdKaFXfrDK49CiZ65JFEaNeSkD/MhnkqluZVFQkw3M7I8iWyeLe+N4jg9bxl67uZF/a4wb/4/R2xWdX4bZPp255pg2e/fU5u90s3lpsynSy7ZxwivAqxlGO5kD6aqFua6J/woH6GmAo8GE/rtJ4X/ZeurWkDPe6j7ES5ZfCLlutmmjutS1lukcKxEoc/Y5QGPiEFXJ9ltsesj0xGozSVQW1Kx/Jo4QoV8wG8vCLgUwt7qr51SSLpeD3Hy/0S+ivVdeXjN/A+nbIXg118VBdqYygLNYM04qIXFPh7iD7Q== 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=jAlnFlOJzNfp3xWoaE4bYY31wfayoLOI/hgzpu6b+jg=; b=Y5F5zTipd/Z84uwOgI3Oq1QEe1hujv8qCL+ogzk0rtp7MabNiqf/lnKdCKiFuFeTJ+Z0la/tTt4PAosmvtN/KTQH76s6T/rl1OOt9sK7+cKysjv0jbppc6ve/oQGE2pWQTqs5MP3L0R+CCivVev5yIL5B4fRYT9zGzWx52rPxeA= Received: from MWHPR1601MB1280.namprd16.prod.outlook.com (10.172.98.11) by MWHPR1601MB1311.namprd16.prod.outlook.com (10.172.98.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.22; Mon, 27 Jan 2020 15:00:26 +0000 Received: from MWHPR1601MB1280.namprd16.prod.outlook.com ([fe80::3452:f8ca:1662:552e]) by MWHPR1601MB1280.namprd16.prod.outlook.com ([fe80::3452:f8ca:1662:552e%11]) with mapi id 15.20.2665.026; Mon, 27 Jan 2020 15:00:26 +0000 From: Kim To: "txauth@ietf.org" Thread-Index: AQHV1SJ4TSlQ5Xa4u0CGThHwZ3/fHQ== Date: Mon, 27 Jan 2020 15:00:26 +0000 Message-ID: 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: [172.58.139.145] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2eca1344-9e40-4d5f-e224-08d7a339a465 x-ms-traffictypediagnostic: MWHPR1601MB1311: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:605; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(39830400003)(136003)(366004)(199004)(189003)(91956017)(76116006)(66946007)(64756008)(66556008)(66476007)(45080400002)(86362001)(66446008)(6916009)(33656002)(2906002)(316002)(55016002)(26005)(81166006)(81156014)(52536014)(558084003)(8936002)(5406001)(6506007)(508600001)(71200400001)(7696005)(5660300002)(9686003)(186003)(4270600006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR1601MB1311; H:MWHPR1601MB1280.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: Lym22DI+VAYgqT+7tf+OOnbjan4f5RQqdure4bHQk5c2unkKeU59ODwzOflW3XLSv6AuXd6Ow3VsjvIDlTKsNBxNqMBclVBAaqZ/gHfO+WxxOHkkgPfLkqeqp/G5l6ER2dkT0IsKPrOF6LbC6Q3TalhgcF19XGGkiS7jDf8hmSx1J6UQhGHt2mRB3WvC+aBs1bERXqgyZkiTKkXv1IhZaMX5lPbgK0flR2auhbIffKQCDAxcpKsXNufnWWzWRtIkRFODpSRqHIIp4pDwJJ/odVx2M0rn1FBEn06KHhNE8L7M8WGzK44zQ6KxLd1boTt/lY0ixTG4DfaLGE6j58Sf+ifkbxKb6IZ2KzLgOq7VfoMAmfqRa7oIVKyzeGsMSwRrxTWHXpBn7lrF/8wHgFm6zh6o4Sgr3gsJ/MfIPKAy+UXf/5IvIqMSAUBgkVxlCKNzPnDrTcX81Nb82HC3NNnSWzkXsTOiTvK7gEao3NfQsi8eQNl6I2cAVKx+5r109pvK5Gcg5J03r9Dj9SBjfWfUjQ== x-ms-exchange-antispam-messagedata: GEvrMhX9cp4RpF11pn2e6UNyV1jM5eMwcN4Po7FSqjRe8R3t+9SxvuHS9v/vCefgGjYv5RyAsOo21Mx/9b7e0Y0ujWbXlUtjgZXDFz5NWNMaFmjSATXj7+C3u96TCWJMsXuPqBKGqAKpELcTF4akgg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR1601MB12804B5CC63C7145E067B996CA0B0MWHPR1601MB1280_" MIME-Version: 1.0 X-OriginatorOrg: identityblog.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2eca1344-9e40-4d5f-e224-08d7a339a465 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2020 15:00:26.0519 (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: 0gPDX8LD1KxAR9iD7sypC4PGL7IiQmylUpS0p+KbFuroNxQYA6+4VKkJGm7MifckXd+3JvtvI45o2xTsAd1PzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1601MB1311 Archived-At: Subject: [Txauth] (no subject) 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, 27 Jan 2020 15:00:32 -0000 --_000_MWHPR1601MB12804B5CC63C7145E067B996CA0B0MWHPR1601MB1280_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Get Outlook for Android --_000_MWHPR1601MB12804B5CC63C7145E067B996CA0B0MWHPR1601MB1280_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_MWHPR1601MB12804B5CC63C7145E067B996CA0B0MWHPR1601MB1280_-- From nobody Tue Jan 28 03:29: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 296C9120130 for ; Tue, 28 Jan 2020 03:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 xzJ2mDGxwtJp for ; Tue, 28 Jan 2020 03:28:59 -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 A6EA9120045 for ; Tue, 28 Jan 2020 03:28:51 -0800 (PST) Received: from [100.83.133.69] (static.kpn.net [217.166.240.200] (may be forged)) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00SBSj70023021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Jan 2020 06:28:47 -0500 From: Justin Richer Message-Id: <4EBBC47D-8EF1-46F2-9623-89070428FA25@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_540C6579-E6B4-44E1-9B14-64B5D11832C2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 28 Jan 2020 12:28:44 +0100 In-Reply-To: Cc: "txauth@ietf.org" To: Kim References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Questions on the 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: Tue, 28 Jan 2020 11:29:21 -0000 --Apple-Mail=_540C6579-E6B4-44E1-9B14-64B5D11832C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Kim, thanks for the feedback. Answers inline, below. > On Jan 28, 2020, at 1:57 AM, Kim wrote: >=20 > Dear Justin, >=20 > The current wording of the draft charter raised questions for me that = others might share. Clarifying these would help those of us not familiar = with the work to date. >=20 > > This group is chartered to develop a delegation protocol for = authorization, identity, and API access. >=20 > Can you please expand on what you mean by delegation of identity and = whether that leverages claims and tokens as defined in OpenID Connect? >=20 We would not necessarily be using the exact claims and mechanisms in = OIDC. > > The use cases supported by this protocol will include widely = deployed use cases currently supported by OAuth 2.0 and OpenID Connect = (an extension of OAuth 2.0) as well as new use cases not enabled by = OAuth 2.0. >=20 > I understand and support the motivations to rework the authorization = flows. However, the identity representations in OpenID Connect have = already shown themselves to work well in conveying the identity of the = end user. It seems prudent to avoid the confusion and complexity that = would result from introducing new mechanisms to do the same thing. Will = the enhancements to the authorization leverage what already works and = has become a unifying technology? >=20 And when OIDC was invented, SAML had already been shown to work well in = conveying the identity of an end user. I believe we can make a similar = leap forward here. This is not just a new conveyance mechanism for OIDC, = but it will certainly learn from it as OIDC learned from SAML and other = things that came before. > > This protocol will allow an authorizing party to delegate access to = client software through an authorization server=E2=80=A6=20 >=20 > > The client and AS will involve the authorizing party as necessary = through interaction mechanisms indicated by the protocol.=20 >=20 > What is the authorizing party? Is that one of the roles in the = protocol? Is it the end user? >=20 It=E2=80=99s the OAuth/UMA =E2=80=9CResource Owner=E2=80=9D, which might = be the user using the client software and might be someone else that the = AS can contact through other means.=20 > > Approval of AS attestation to identity claims >=20 > Does this mean that the AS is approving of the claims and conveying = that approval to another party (and what party would that be)?=20 >=20 No, the authorizing party is approving the claims and the AS is = conveying the identity claims and the delegated access token to the = client.=20 > By identity claims are you leveraging claims as defined in OpenID = Connect? >=20 Not necessarily, but they=E2=80=99re on the table as items to consider. > Are the identity claims about the end user =E2=80=93 or other subjects = as well? >=20 Generally speaking yes, though in the multi-user case (CIBA, UMA, and = some device-flow use cases today), the claims of the authorizing party = are being conveyed to the end user of the client, who might be a = different party. This is an advanced use case, though, so I see it as = something we can enable but not likely to be the most common use case, = which is conveying the current user=E2=80=99s claims to a piece of = software that they=E2=80=99re using. > > Mechanisms for providing user, software, organization, and other = pieces of information used in authorization decisions =E2=80=93=20 >=20 > Could you elaborate on what information about users would be = supplemental to those expressed as claims? Also, would information = about software and organization be expressed as claims?=20 >=20 How the user logged in today, how the user was proofed when they got the = account, the status of the client software that was making the request = at the time, etc. So yes, software and organization could also be = represented as claims, though I can also imagine those being in = different data structures.=20 > > Optimization of information and API access beyond identity through = the delegation process >=20 > Could you please explain what is meant by this goal and how it relates = to identity? >=20 At its core this isn=E2=80=99t an identity protocol, but a delegation = protocol. One of the core things that it can delegate is knowledge of = the identity of the user. This is how OIDC is built on top of OAuth 2, = and we=E2=80=99re looking at repeating that kind of layering but in a = more direct way as possible. =E2=80=94 Justin > Thanks! >=20 > Kim Cameron >=20 > =20 >=20 > =20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_540C6579-E6B4-44E1-9B14-64B5D11832C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Kim, thanks for the feedback. Answers inline, below.

On Jan 28, 2020, at 1:57 AM, Kim <kim@identityblog.com> wrote:

Dear Justin,

The current wording of = the draft charter raised questions for me that others might share. = Clarifying these would help those of us not familiar with the work to = date.

> This group is chartered to develop a = delegation protocol for authorization, identity, and API access.

Can you please expand on = what you mean by delegation of identity and whether that leverages = claims and tokens as defined in OpenID = Connect?


We would not necessarily be using the exact claims = and mechanisms in OIDC.

> The use cases = supported by this protocol will include widely deployed use cases = currently supported by OAuth 2.0 and OpenID Connect (an extension of = OAuth 2.0) as well as new use cases not enabled by OAuth 2.0.

I understand and support = the motivations to rework the authorization flows.  However, the = identity representations in OpenID Connect have already shown themselves = to work well in conveying the identity of the end user. It seems prudent = to avoid the confusion and complexity that would result from introducing = new mechanisms to do the same thing. Will the enhancements to the = authorization leverage what already works and has become a unifying = technology?


And when OIDC was invented, SAML had already been = shown to work well in conveying the identity of an end user. I believe = we can make a similar leap forward here. This is not just a new = conveyance mechanism for OIDC, but it will certainly learn from it as = OIDC learned from SAML and other things that came before.

> This protocol will = allow an authorizing party to delegate access to client software through = an authorization server=E2=80=A6 

> The client and AS = will involve the authorizing party as necessary through interaction = mechanisms indicated by the protocol. 

What is the authorizing = party? Is that one of the roles in the protocol?  Is it the end = user?


It=E2=80=99s the OAuth/UMA =E2=80=9CResource = Owner=E2=80=9D, which might be the user using the client software and = might be someone else that the AS can contact through other = means. 

> Approval of AS = attestation to identity claims

Does this mean that the = AS is approving of the claims and conveying that approval to another = party (and what party would that = be)? 

No, the authorizing = party is approving the claims and the AS is conveying the identity = claims and the delegated access token to the client. 

By identity claims are = you leveraging claims as defined in OpenID = Connect?


Not = necessarily, but they=E2=80=99re on the table as items to = consider.

Are the identity claims = about the end user =E2=80=93 or other subjects as = well?


Generally speaking yes, though in the multi-user = case (CIBA, UMA, and some device-flow use cases today), the claims of = the authorizing party are being conveyed to the end user of the client, = who might be a different party. This is an advanced use case, though, so = I see it as something we can enable but not likely to be the most common = use case, which is conveying the current user=E2=80=99s claims to a = piece of software that they=E2=80=99re using.

> Mechanisms for = providing user, software, organization, and other pieces of information = used in authorization decisions =E2=80=93 

Could you elaborate on = what information about users would be supplemental to those expressed as = claims?  Also, would information about software and organization be = expressed as claims? 


How the user logged in today, how = the user was proofed when they got the account, the status of the client = software that was making the request at the time, etc. So yes, software = and organization could also be represented as claims, though I can also = imagine those being in different data structures. 

> Optimization of = information and API access beyond identity through the delegation = process

Could you please explain what is meant by this goal = and how it relates to = identity?


At its core this isn=E2=80=99t an identity = protocol, but a delegation protocol. One of the core things that it can = delegate is knowledge of the identity of the user. This is how OIDC is = built on top of OAuth 2, and we=E2=80=99re looking at repeating that = kind of layering but in a more direct way as possible.

 =E2=80=94 Justin

Thanks!

Kim Cameron

 

 

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

= --Apple-Mail=_540C6579-E6B4-44E1-9B14-64B5D11832C2-- From nobody Tue Jan 28 08:09: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 0B2EC120AB3 for ; Tue, 28 Jan 2020 08:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=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 kiuBtB5LFeCz for ; Tue, 28 Jan 2020 08:09:15 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A82120A22 for ; Tue, 28 Jan 2020 08:09:15 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id t23so9502737lfk.6 for ; Tue, 28 Jan 2020 08:09:14 -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=fbHww13qRho1gd8Cy2/Xndn0sWChEZiI1hu8ILS7aHQ=; b=txgDXENVdLGO3neuU70rFOUfRRU3UtGyM6UUvn/KuIYdnvaU89OU/q3NV2Qv7XhtKx lYTNCuW+mDhBVsgvJQHwdQK+mTFcxk/Ux/dk13yBPpiDaRoEWrNI7z488jBeRJFlFmiH SDQJXpnUNwd/xQuMkfZc1xwtLWVcuFQTPcJdM276QU8Zk/4NUKc9X/oaq1EysaxurtV4 DDfMj4Hj8ngH3wPclMyifKEHTUj+vyOKD5UnuHhIF0Qlf+c4o2ZoLTZR0IKU31MufkWU Oe/YbGxcsaKmdSLRwSTtzcxqNDaubLyyUaD6PHZ/qNk85Gsjlferf2xBKtt9lKy9+z7G Q4RA== 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=fbHww13qRho1gd8Cy2/Xndn0sWChEZiI1hu8ILS7aHQ=; b=jeP4Sn0yqYwGxevfuzmdw4utlmPuIfddrE/Xf2dmChfEQVhbxtbbdW0UgLFvIw7YCi DihdHnScA4lqg0dSTredT4tXlsxZLW2nJpGNM0G+2eRY0t+2ksuxc5p8GG4Uv4SYic65 gLx1XE1XoZAR2qDMSa5cahF3kIeu1ZZxjPaE0OHH0D/Vcjo8rTrmQYfL0j6UMWYlLI0+ tXGSsNiK3I1KhXCst9iIAVZoOY8AD6p7OwI4bDmyfu9bAwJ2f1gs5N1/LZMXb6ogE6/u j9j4056R6/kAPYzcRCeJ5isJQ/hHqfCPe1XXeCVWsou5ozNwY1zz7Gnq00aLH+oapfZB XJuA== X-Gm-Message-State: APjAAAWKgLKmJICckLHYRkFKMpyrEgGZx07urW3w/8rJcvBkgXoP41GZ 0sIQZnMDYrgcluuL25KCHz5D/jZrgiRKys8jizU= X-Google-Smtp-Source: APXvYqzGyQ3XCYgI/9TI/zg2tWFnLryJ0P9FjwKzgus9oKW+CAgk3Qg1ntp5KvJublYG7HYq1YmUS00hFN6ttJWXoQE= X-Received: by 2002:a19:7711:: with SMTP id s17mr2813277lfc.164.1580227753120; Tue, 28 Jan 2020 08:09:13 -0800 (PST) MIME-Version: 1.0 References: <741262A9-A258-40DC-87AB-0ED7515D136E@mit.edu> <2B53E22D-2C4C-4364-9A45-285D1195E642@lodderstedt.net> <9A1D966F-F31D-4785-9FEF-6A87F1D80E37@mit.edu> In-Reply-To: <9A1D966F-F31D-4785-9FEF-6A87F1D80E37@mit.edu> From: Dick Hardt Date: Tue, 28 Jan 2020 08:09:01 -0800 Message-ID: To: Justin Richer Cc: Torsten Lodderstedt , "txauth@ietf.org" , "Richard Backman, Annabelle" Content-Type: multipart/alternative; boundary="000000000000e39793059d35716f" Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 28 Jan 2020 16:09:19 -0000 --000000000000e39793059d35716f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Small suggestion: s/porting/migrating/ 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 porting *migrating* from OAuth 2.0 and OpenID Connect to the new protocol where possible. On Tue, Jan 21, 2020 at 10:47 AM Justin Richer wrote: > Thanks, both of those nits make sense and we=E2=80=99ll be sure to incorp= orate > them. > > =E2=80=94 Justin > > > On Jan 21, 2020, at 5:56 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > > > another NIT: Approval of =E2=80=9Caccess to=E2=80=9D multiple resources= and APIs in a > single interaction > > > >> On 20. Jan 2020, at 19:05, Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > >> > >> NIT: Mixed verb tenses in the last sentence of paragraph 2. Replace = =E2=80=9Cas > well as providing=E2=80=9D with =E2=80=9Cand provides=E2=80=9D. > >> > >> =E2=80=93 > >> Annabelle Richard Backman > >> AWS Identity > >> > >> > >> From: Txauth on behalf of Justin Richer < > jricher@mit.edu> > >> Date: Saturday, January 18, 2020 at 6:16 AM > >> To: "txauth@ietf.org" > >> Subject: [Txauth] TxAuth Charter (Take 3.5) > >> > >> Thanks for all the feedback and discussion on the last round of the > charter. I=E2=80=99ve made a few tweaks to it based on the conversations = on this > list, and a couple off-list, and have incorporated them here. > >> > >>> > >>> This group is chartered to develop a 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. The use cases supported by this protocol will inclu= de > widely deployed use cases currently supported by OAuth 2.0 and OpenID > Connect (an extension of OAuth 2.0) as well as new use cases not enabled = by > OAuth 2.0. > >>> > >>> 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 t= he > authorizing party as necessary through interaction mechanisms indicated b= y > the protocol. This decoupling avoids many of the security concerns and > technical challenges of OAuth 2.0 as well as providing a non-invasive pat= h > 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 multiple resources and APIs in a single interaction > >>> - Separation between the party authorizing access and the party > operating the client requesting access > >>> - Web, mobile, single-page, interaction-constrained, and other types > of client 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 providing user, software, organization, and other > pieces of information used in authorization decisions > >>> - Token presentation mechanisms and key bindings > >>> - Optimization of information and API access beyond identity through > the delegation process > >>> > >>> 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 porting from OAuth 2.0 and OpenID Connect to the new > protocol where possible. > >>> > >>> While the initial work will focus on using HTTP for communication > between the client and the authorization server, the working group will > seek to take advantage of optimization features of HTTP2 and HTTP3 where > possible, and will strive to enable simple mapping to other protocols suc= h > as COAP. > >> > >> I would really appreciate the security AD=E2=80=99s weighing in at thi= s stage. > Thanks again everyone! > >> > >> =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 > --000000000000e39793059d35716f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Small suggestion: s/porting/migrating/

Although the artifacts for this work ar= e not intended or expected to be backwards-compatible with OAuth 2.0 or Ope= nID Connect, the group will=C2=A0attempt to simplify porting=C2=A0migrating from OAuth 2.0 and OpenID Connect to the new proto= col where possible.

On Tue, Jan 21, 2020 at 10:47 AM Justin Riche= r <jricher@mit.edu> wrote:
=
Thanks, both of tho= se nits make sense and we=E2=80=99ll be sure to incorporate them.

=C2=A0=E2=80=94 Justin

> On Jan 21, 2020, at 5:56 AM, Torsten Lodderstedt <torsten@lodderstedt.net>= wrote:
>
> another NIT: Approval of =E2=80=9Caccess to=E2=80=9D multiple resource= s and APIs in a single interaction
>
>> On 20. Jan 2020, at 19:05, Richard Backman, Annabelle <richanna= =3D40amazo= n.com@dmarc.ietf.org> wrote:
>>
>> NIT: Mixed verb tenses in the last sentence of paragraph 2. Replac= e =E2=80=9Cas well as providing=E2=80=9D with =E2=80=9Cand provides=E2=80= =9D.
>>
>> =E2=80=93
>> Annabelle Richard Backman
>> AWS Identity
>>
>>
>> From: Txauth <txauth-bounces@ietf.org> on behalf of Justin Richer <= jricher@mit.edu>= ;
>> Date: Saturday, January 18, 2020 at 6:16 AM
>> To: "txa= uth@ietf.org" <txauth@ietf.org>
>> Subject: [Txauth] TxAuth Charter (Take 3.5)
>>
>> Thanks for all the feedback and discussion on the last round of th= e charter. I=E2=80=99ve made a few tweaks to it based on the conversations = on this list, and a couple off-list, and have incorporated them here.
>>
>>>
>>> This group is chartered to develop a 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. The use cases supported by this protocol will include widely deploye= d use cases currently supported by OAuth 2.0 and OpenID Connect (an extensi= on of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0.
>>>
>>> The delegation process will be acted upon by multiple parties = in the protocol, each performing a specific role. The protocol will decoupl= e the interaction channels, such as the end user=E2=80=99s browser, from th= e delegation channel, which happens directly between the client and the aut= horization server (in contrast with OAuth 2.0 which is initiated by the cli= ent redirecting the user=E2=80=99s browser). The client and AS will involve= the authorizing party as necessary through interaction mechanisms indicate= d by the protocol. This decoupling avoids many of the security concerns and= technical challenges of OAuth 2.0 as well as providing 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 multiple resources and APIs in a single interact= ion
>>> - Separation between the party authorizing access and the part= y operating the client requesting access
>>> - Web, mobile, single-page, interaction-constrained, and other= types of client applications
>>>
>>> The group will define extension points for this protocol to al= low for flexibility in areas including:
>>>
>>> - Cryptographic agility for keys, message signatures, and proo= f of possession
>>> - User interaction mechanisms including web and non-web method= s
>>> - Mechanisms for providing user, software, organization, and o= ther pieces of information used in authorization decisions
>>> - Token presentation mechanisms and key bindings
>>> - Optimization of information and API access beyond identity t= hrough the delegation process
>>>
>>> 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 expec= ted to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group = will attempt to simplify porting from OAuth 2.0 and OpenID Connect to the n= ew protocol where possible.
>>>
>>> While the initial work will focus on using HTTP for communicat= ion between the client and the authorization server, the working group will= seek to take advantage of optimization features of HTTP2 and HTTP3 where p= ossible, and will strive to enable simple mapping to other protocols such a= s COAP.
>>
>> I would really appreciate the security AD=E2=80=99s weighing in at= this stage. Thanks again everyone!
>>
>> =E2=80=94 Justin
>> --
>> 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
--000000000000e39793059d35716f-- From nobody Tue Jan 28 08:12: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 02FE6120AB5 for ; Tue, 28 Jan 2020 08:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVhCEImsiurr for ; Tue, 28 Jan 2020 08:12:11 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0A31209BC for ; Tue, 28 Jan 2020 08:12:11 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id v201so9499464lfa.11 for ; Tue, 28 Jan 2020 08:12:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2rdnq6Gued2uhxR9vSy9oScruP1aSEh/4J41+X8rGC8=; b=ITtFVMisbaOCw76GqGbGGe1wsPj96ZVs9RGrmk0/wVGjq119wGt+l88xj4gff1rTWj PLLnTLjkltBCXl+MN3ILDQkooSwjJHhq1VsLtn4rg/KR9CvKlmJTmx9RwqqPEYega3ly WCWy48Ilx7iJzdgAtulRlpxtZArcPGI7kAl3hTCDr2LGIdbyp/kHi+KeMxHcMVw0dXHD WnhIlIxSeS7VadWeOVr8ib5nV26jF+0KgbahiSGciOdT1qvycMgXUtM6QBUDw9wP3uSX su/Gfolawcpko3H0UiXigycLu88VUyx//33Ca56lFc2K3+XPMp5TlFr9Dd4ZetEXbJsV JJoA== 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=2rdnq6Gued2uhxR9vSy9oScruP1aSEh/4J41+X8rGC8=; b=cS8Tc/ybjeYM8MToo1Ev3/GSeWCTiOB+0W1SCSrkQNDFERRPUeWJVIyiZ0mAKouNWI 34j/N8f/7kvnpxQYaCk9BqVdb/NNAU3gyI8BXyBRUN2WNRqf+mgHJ/FT+2zX8beTYImn BEbFZlyjyhA3ykAiE6FHagIihOalJwp+gA81vvBX42gwx6xpqU/nRcbVPKxr9a+DZ5m9 6wXTJGlhOeHpcNqnga9sVgyy4wKXcHgqxDnPTwECsEUINktFdMc8YydQPOeUfto8o46K T4wcFeGZENIk+E3otV1iMmiCyBi+ySMOLXp2tum8cToS/IidMYgMpgLFj7IU9WV+B6WF wqVg== X-Gm-Message-State: APjAAAWgAdj2L0og+CS8PaRVOaSwlYH+7yJ/ZXuBm+GN+j9GY520N4cd C4pzMCt68Chi1IvwDKfHTaa4rqGSQWa0/3LnMRw= X-Google-Smtp-Source: APXvYqxiiM/oryL60JjcP5O7LWKT8oEXACCV5DegdS7YyF3+gB90pVZ2Ev9dVmjx4Bqay3ywdqpVmq59NLZuvNc21AM= X-Received: by 2002:a19:7711:: with SMTP id s17mr2820272lfc.164.1580227929357; Tue, 28 Jan 2020 08:12:09 -0800 (PST) MIME-Version: 1.0 References: <4EBBC47D-8EF1-46F2-9623-89070428FA25@mit.edu> In-Reply-To: <4EBBC47D-8EF1-46F2-9623-89070428FA25@mit.edu> From: Dick Hardt Date: Tue, 28 Jan 2020 08:11:58 -0800 Message-ID: To: Justin Richer Cc: Kim , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000064c032059d357cbb" Archived-At: Subject: Re: [Txauth] Questions on the 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: Tue, 28 Jan 2020 16:12:14 -0000 --00000000000064c032059d357cbb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Kim: are you suggesting that supporting OIDC claims be in the charter? While I think that supporting OIDC claims is desirable, I don't think that belongs in the charter. Justin: OIDC claims inherently had to be different from SAML as the syntax was JSON vs XML. Are you suggesting that a different document format be used than JSON? What do you see as lacking in the OIDC claims? On Tue, Jan 28, 2020 at 3:30 AM Justin Richer wrote: > Hi Kim, thanks for the feedback. Answers inline, below. > > On Jan 28, 2020, at 1:57 AM, Kim wrote: > > Dear Justin, > > The current wording of the draft charter raised questions for me that > others might share. Clarifying these would help those of us not familiar > with the work to date. > > > This group is chartered to develop a delegation protocol for > authorization, identity, and API access. > > Can you please expand on what you mean by delegation of identity and > whether that leverages claims and tokens as defined in OpenID Connect? > > > We would not necessarily be using the exact claims and mechanisms in OIDC= . > > > The use cases supported by this protocol will include widely deployed > use cases currently supported by OAuth 2.0 and OpenID Connect (an extensi= on > of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0. > > I understand and support the motivations to rework the authorization > flows. However, the identity representations in OpenID Connect have > already shown themselves to work well in conveying the identity of the en= d > user. It seems prudent to avoid the confusion and complexity that would > result from introducing new mechanisms to do the same thing. Will the > enhancements to the authorization leverage what already works and has > become a unifying technology? > > > And when OIDC was invented, SAML had already been shown to work well in > conveying the identity of an end user. I believe we can make a similar le= ap > forward here. This is not just a new conveyance mechanism for OIDC, but i= t > will certainly learn from it as OIDC learned from SAML and other things > that came before. > > > This protocol will allow an authorizing party to delegate access to > client software through an authorization server=E2=80=A6 > > > The client and AS will involve the authorizing party as necessary > through interaction mechanisms indicated by the protocol. > > What is the authorizing party? Is that one of the roles in the protocol? > Is it the end user? > > > It=E2=80=99s the OAuth/UMA =E2=80=9CResource Owner=E2=80=9D, which might = be the user using the > client software and might be someone else that the AS can contact through > other means. > > > Approval of AS attestation to identity claims > > Does this mean that the AS is approving of the claims and conveying that > approval to another party (and what party would that be)? > > No, the authorizing party is approving the claims and the AS is conveying > the identity claims and the delegated access token to the client. > > By identity claims are you leveraging claims as defined in OpenID Connect= ? > > > Not necessarily, but they=E2=80=99re on the table as items to consider. > > Are the identity claims about the end user =E2=80=93 or other subjects as= well? > > > Generally speaking yes, though in the multi-user case (CIBA, UMA, and som= e > device-flow use cases today), the claims of the authorizing party are bei= ng > conveyed to the end user of the client, who might be a different party. > This is an advanced use case, though, so I see it as something we can > enable but not likely to be the most common use case, which is conveying > the current user=E2=80=99s claims to a piece of software that they=E2=80= =99re using. > > > Mechanisms for providing user, software, organization, and other pieces > of information used in authorization decisions =E2=80=93 > > Could you elaborate on what information about users would be supplemental > to those expressed as claims? Also, would information about software and > organization be expressed as claims? > > > How the user logged in today, how the user was proofed when they got the > account, the status of the client software that was making the request at > the time, etc. So yes, software and organization could also be represente= d > as claims, though I can also imagine those being in different data > structures. > > > Optimization of information and API access beyond identity through the > delegation process > > Could you please explain what is meant by this goal and how it relates to > identity? > > > At its core this isn=E2=80=99t an identity protocol, but a delegation pro= tocol. > One of the core things that it can delegate is knowledge of the identity = of > the user. This is how OIDC is built on top of OAuth 2, and we=E2=80=99re = looking at > repeating that kind of layering but in a more direct way as possible. > > =E2=80=94 Justin > > Thanks! > > Kim Cameron > > > > > -- > 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 > --00000000000064c032059d357cbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kim: are you suggesting that supporting OIDC claims be in = the charter?

While I think that supporting OIDC claims i= s desirable, I don't think that belongs in the charter.

<= /div>
Justin: OIDC claims inherently had to be different from SAML as t= he syntax was JSON vs XML.

Are you suggesting that= a different document format be used than JSON?

Wh= at do you see as lacking in the OIDC claims?

=C2= =A0




On Tue, Jan 28, 2020= at 3:30 AM Justin Richer <jricher@mit.edu> wrote:
Hi Kim, thanks for the feedback. Answers inline= , below.

On Jan 28, 2020, at 1:5= 7 AM, Kim <kim= @identityblog.com> wrote:

Dear Justin,

The current wording of the dr= aft charter raised questions for me that others might share. Clarifying the= se would help those of us not familiar with the work to date.=

> This group is chartered to develop a delegati= on protocol for authorization, identity, and API access.

Can you please expand on what you mean by delegation of ident= ity and whether that leverages claims and tokens as defined in OpenID Conne= ct?


We would not nec= essarily be using the exact claims and mechanisms in OIDC.

<= /u>

> The use cases supported by this protocol= will include widely deployed use cases currently supported by OAuth 2.0 an= d OpenID Connect (an extension of OAuth 2.0) as well as new use cases not e= nabled by OAuth 2.0.

I understand and sup= port the motivations to rework the authorization flows.=C2=A0 However, the = identity representations in OpenID Connect have already shown themselves to= work well in conveying the identity of the end user. It seems prudent to a= void the confusion and complexity that would result from introducing new me= chanisms to do the same thing. Will the enhancements to the authorization l= everage what already works and has become a unifying technology?

=

And when OIDC was invented, SA= ML had already been shown to work well in conveying the identity of an end = user. I believe we can make a similar leap forward here. This is not just a= new conveyance mechanism for OIDC, but it will certainly learn from it as = OIDC learned from SAML and other things that came before.

> This protocol will allow an authorizing par= ty to delegate access to client software through an authorization server=E2= =80=A6=C2=A0

> The cl= ient and AS will involve the authorizing party as necessary through interac= tion mechanisms indicated by the protocol.=C2=A0=

What is the authorizing party? Is that one of the roles = in the protocol?=C2=A0 Is it the end user?


It=E2=80=99s the OAuth/UMA =E2=80=9CResource Owner= =E2=80=9D, which might be the user using the client software and might be s= omeone else that the AS can contact through other means.=C2=A0

> Approval of AS attestation to identity claims<= /u>

Does this mean that the AS is approving of th= e claims and conveying that approval to another party (and what party would= that be)?=C2=A0

No, the authorizin= g party is approving the claims and the AS is conveying the identity claims= and the delegated access token to the client.=C2=A0

By identity claims are you leveraging claims as defined in = OpenID Connect?


Not neces= sarily, but they=E2=80=99re on the table as items to consider.

Are the identity claims about the end user =E2=80=93 or= other subjects as well?


=
Generally speaking yes, though in the multi-user case (CIBA, UMA, and = some device-flow use cases today), the claims of the authorizing party are = being conveyed to the end user of the client, who might be a different part= y. This is an advanced use case, though, so I see it as something we can en= able but not likely to be the most common use case, which is conveying the = current user=E2=80=99s claims to a piece of software that they=E2=80=99re u= sing.

=

> Mechanisms for providing user, = software, organization, and other pieces of information used in authorizati= on decisions =E2=80=93=C2=A0

= Could you elaborate on what information about users would be supplemental t= o those expressed as claims?=C2=A0 Also, would information about software a= nd organization be expressed as claims?=C2=A0

=

How the user logged in today, how th= e user was proofed when they got the account, the status of the client soft= ware that was making the request at the time, etc. So yes, software and org= anization could also be represented as claims, though I can also imagine th= ose being in different data structures.=C2=A0

= > Optimization of information and API access beyond identity through the= delegation process

Could you please explai= n what is meant by this goal and how it relates to identity?


At its core this isn=E2=80=99t an = identity protocol, but a delegation protocol. One of the core things that i= t can delegate is knowledge of the identity of the user. This is how OIDC i= s built on top of OAuth 2, and we=E2=80=99re looking at repeating that kind= of layering but in a more direct way as possible.

=C2=A0=E2=80=94 Justin

Thanks!

Kim Cameron

<= u>=C2=A0

=C2= =A0

--=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
--00000000000064c032059d357cbb-- From nobody Tue Jan 28 08:57: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 DB77B12004D for ; Tue, 28 Jan 2020 08:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 3XOyBViAdlDx for ; Tue, 28 Jan 2020 08:57:31 -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 3EC691201EA for ; Tue, 28 Jan 2020 08:57:31 -0800 (PST) Received: from [100.83.133.69] (static.kpn.net [217.166.240.200] (may be forged)) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00SGvOal022659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Jan 2020 11:57:26 -0500 From: Justin Richer Message-Id: <9403A1A5-8D3F-4425-8447-4A40FF7AB8FD@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_D8676BD4-4661-4CE6-B80F-E0AD0D12BB60" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 28 Jan 2020 17:57:24 +0100 In-Reply-To: Cc: Kim , "txauth@ietf.org" To: Dick Hardt References: <4EBBC47D-8EF1-46F2-9623-89070428FA25@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Questions on the 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: Tue, 28 Jan 2020 16:57:35 -0000 --Apple-Mail=_D8676BD4-4661-4CE6-B80F-E0AD0D12BB60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The claims in OIDC aren=E2=80=99t just JSON, many of them are JWT = payload elements, which need to be compact so that it could fit better = into browser redirects and places like that. I contend that we are not = bound by the same restrictions, so just like with the SAML translations = of =E2=80=9C=E2=80=9D to =E2=80=9Ciss=E2=80=9D we should = consider what we really need in the new space even if it=E2=80=99s the = same concepts translated over. We=E2=80=99d be foolish to ignore them, but also nearly as foolish to = take them just because they exist and it=E2=80=99s the world we know. = For instance, we know that the OIDC separation of issuer and subject = into a pair of values is really confusing to developers and leads to = people using email address, username, or other incorrect fields as a = universal identifier. There are some things that we got right, though, = such as the flat namespace-less JSON data model that allows domain = extensions. So just as with anything else in this proposed new work, I am arguing = that we should take OIDC claims as an influencing input to be evaluated = in the context of what we=E2=80=99re trying to do. =E2=80=9CWe did it = this way in OIDC=E2=80=9D is not a sufficient argument for its inclusion = in TxAuth, and therefore I agree that it does not belong anywhere in the = charter. But we also need to look at what we did do in OIDC and figure = out how and if it fits as we=E2=80=99re figuring out solutions. =E2=80=94 Justin > On Jan 28, 2020, at 5:11 PM, Dick Hardt wrote: >=20 > Kim: are you suggesting that supporting OIDC claims be in the charter? >=20 > While I think that supporting OIDC claims is desirable, I don't think = that belongs in the charter. >=20 > Justin: OIDC claims inherently had to be different from SAML as the = syntax was JSON vs XML. >=20 > Are you suggesting that a different document format be used than JSON? >=20 > What do you see as lacking in the OIDC claims? >=20 > =20 >=20 >=20 >=20 >=20 > On Tue, Jan 28, 2020 at 3:30 AM Justin Richer > wrote: > Hi Kim, thanks for the feedback. Answers inline, below. >=20 >> On Jan 28, 2020, at 1:57 AM, Kim > wrote: >>=20 >> Dear Justin, >>=20 >> The current wording of the draft charter raised questions for me that = others might share. Clarifying these would help those of us not familiar = with the work to date. >>=20 >> > This group is chartered to develop a delegation protocol for = authorization, identity, and API access. >>=20 >> Can you please expand on what you mean by delegation of identity and = whether that leverages claims and tokens as defined in OpenID Connect? >>=20 >=20 > We would not necessarily be using the exact claims and mechanisms in = OIDC. >=20 >> > The use cases supported by this protocol will include widely = deployed use cases currently supported by OAuth 2.0 and OpenID Connect = (an extension of OAuth 2.0) as well as new use cases not enabled by = OAuth 2.0. >>=20 >> I understand and support the motivations to rework the authorization = flows. However, the identity representations in OpenID Connect have = already shown themselves to work well in conveying the identity of the = end user. It seems prudent to avoid the confusion and complexity that = would result from introducing new mechanisms to do the same thing. Will = the enhancements to the authorization leverage what already works and = has become a unifying technology? >>=20 >=20 > And when OIDC was invented, SAML had already been shown to work well = in conveying the identity of an end user. I believe we can make a = similar leap forward here. This is not just a new conveyance mechanism = for OIDC, but it will certainly learn from it as OIDC learned from SAML = and other things that came before. >=20 >> > This protocol will allow an authorizing party to delegate access to = client software through an authorization server=E2=80=A6=20 >>=20 >> > The client and AS will involve the authorizing party as necessary = through interaction mechanisms indicated by the protocol.=20 >>=20 >> What is the authorizing party? Is that one of the roles in the = protocol? Is it the end user? >>=20 >=20 > It=E2=80=99s the OAuth/UMA =E2=80=9CResource Owner=E2=80=9D, which = might be the user using the client software and might be someone else = that the AS can contact through other means.=20 >=20 >> > Approval of AS attestation to identity claims >>=20 >> Does this mean that the AS is approving of the claims and conveying = that approval to another party (and what party would that be)?=20 >>=20 > No, the authorizing party is approving the claims and the AS is = conveying the identity claims and the delegated access token to the = client.=20 >=20 >> By identity claims are you leveraging claims as defined in OpenID = Connect? >>=20 >=20 > Not necessarily, but they=E2=80=99re on the table as items to = consider. >=20 >> Are the identity claims about the end user =E2=80=93 or other = subjects as well? >>=20 >=20 > Generally speaking yes, though in the multi-user case (CIBA, UMA, and = some device-flow use cases today), the claims of the authorizing party = are being conveyed to the end user of the client, who might be a = different party. This is an advanced use case, though, so I see it as = something we can enable but not likely to be the most common use case, = which is conveying the current user=E2=80=99s claims to a piece of = software that they=E2=80=99re using. >=20 >> > Mechanisms for providing user, software, organization, and other = pieces of information used in authorization decisions =E2=80=93=20 >>=20 >> Could you elaborate on what information about users would be = supplemental to those expressed as claims? Also, would information = about software and organization be expressed as claims?=20 >>=20 >=20 > How the user logged in today, how the user was proofed when they got = the account, the status of the client software that was making the = request at the time, etc. So yes, software and organization could also = be represented as claims, though I can also imagine those being in = different data structures.=20 >> > Optimization of information and API access beyond identity through = the delegation process >>=20 >> Could you please explain what is meant by this goal and how it = relates to identity? >>=20 >=20 > At its core this isn=E2=80=99t an identity protocol, but a delegation = protocol. One of the core things that it can delegate is knowledge of = the identity of the user. This is how OIDC is built on top of OAuth 2, = and we=E2=80=99re looking at repeating that kind of layering but in a = more direct way as possible. >=20 > =E2=80=94 Justin >=20 >> Thanks! >>=20 >> Kim Cameron >>=20 >> =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=_D8676BD4-4661-4CE6-B80F-E0AD0D12BB60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = claims in OIDC aren=E2=80=99t just JSON, many of them are JWT payload = elements, which need to be compact so that it could fit better into = browser redirects and places like that. I contend that we are not bound = by the same restrictions, so just like with the SAML translations of = =E2=80=9C<saml:Issuer>=E2=80=9D to =E2=80=9Ciss=E2=80=9D we should = consider what we really need in the new space even if it=E2=80=99s the = same concepts translated over.

We=E2=80=99d be foolish to ignore them, but also nearly as = foolish to take them just because they exist and it=E2=80=99s the world = we know. For instance, we know that the OIDC separation of issuer and = subject into a pair of values is really confusing to developers and = leads to people using email address, username, or other incorrect fields = as a universal identifier. There are some things that we got right, = though, such as the flat namespace-less JSON data model that allows = domain extensions.

So just as with anything else in this proposed new work, I am = arguing that we should take OIDC claims as an influencing input to be = evaluated in the context of what we=E2=80=99re trying to do. =E2=80=9CWe = did it this way in OIDC=E2=80=9D is not a sufficient argument for its = inclusion in TxAuth, and therefore I agree that it does not belong = anywhere in the charter. But we also need to look at what we did do in = OIDC and figure out how and if it fits as we=E2=80=99re figuring out = solutions.

 =E2=80=94 Justin

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

Kim: are you suggesting that = supporting OIDC claims be in the charter?

While I think that supporting OIDC = claims is desirable, I don't think that belongs in the = charter.

Justin:= OIDC claims inherently had to be different from SAML as the syntax was = JSON vs XML.

Are= you suggesting that a different document format be used than = JSON?

What do = you see as lacking in the OIDC claims?

 




On Tue, Jan 28, 2020 at 3:30 AM Justin = Richer <jricher@mit.edu> wrote:
Hi Kim, thanks = for the feedback. Answers inline, below.
On Jan = 28, 2020, at 1:57 AM, Kim <kim@identityblog.com> = wrote:

Dear Justin,

The current wording of = the draft charter raised questions for me that others might share. = Clarifying these would help those of us not familiar with the work to = date.

> This group is = chartered to develop a delegation protocol for authorization, identity, = and API access.

Can you please expand on = what you mean by delegation of identity and whether that leverages = claims and tokens as defined in OpenID = Connect?


We would not necessarily be using the = exact claims and mechanisms in OIDC.

> The use cases = supported by this protocol will include widely deployed use cases = currently supported by OAuth 2.0 and OpenID Connect (an extension of = OAuth 2.0) as well as new use cases not enabled by OAuth 2.0.

I understand and support = the motivations to rework the authorization flows.  However, the = identity representations in OpenID Connect have already shown themselves = to work well in conveying the identity of the end user. It seems prudent = to avoid the confusion and complexity that would result from introducing = new mechanisms to do the same thing. Will the enhancements to the = authorization leverage what already works and has become a unifying = technology?


And when OIDC was invented, SAML had = already been shown to work well in conveying the identity of an end = user. I believe we can make a similar leap forward here. This is not = just a new conveyance mechanism for OIDC, but it will certainly learn = from it as OIDC learned from SAML and other things that came = before.

> This protocol will = allow an authorizing party to delegate access to client software through = an authorization server=E2=80=A6 

> The client and AS = will involve the authorizing party as necessary through interaction = mechanisms indicated by the protocol. 

What is the authorizing = party? Is that one of the roles in the protocol?  Is it the end = user?


It=E2=80=99s the OAuth/UMA =E2=80=9CResou= rce Owner=E2=80=9D, which might be the user using the client software = and might be someone else that the AS can contact through other = means. 

> Approval of AS = attestation to identity claims

Does this mean that the = AS is approving of the claims and conveying that approval to another = party (and what party would that = be)? 

No, the = authorizing party is approving the claims and the AS is conveying the = identity claims and the delegated access token to the = client. 

By identity claims are = you leveraging claims as defined in OpenID = Connect?


Not necessarily, but they=E2=80=99re on the table as = items to consider.

Are the identity claims = about the end user =E2=80=93 or other subjects as = well?


Generally speaking yes, though in the = multi-user case (CIBA, UMA, and some device-flow use cases today), the = claims of the authorizing party are being conveyed to the end user of = the client, who might be a different party. This is an advanced use = case, though, so I see it as something we can enable but not likely to = be the most common use case, which is conveying the current user=E2=80=99s= claims to a piece of software that they=E2=80=99re using.

> Mechanisms for = providing user, software, organization, and other pieces of information = used in authorization decisions =E2=80=93 

Could you elaborate on = what information about users would be supplemental to those expressed as = claims?  Also, would information about software and organization be = expressed as claims? 


How the user logged in = today, how the user was proofed when they got the account, the status of = the client software that was making the request at the time, etc. So = yes, software and organization could also be represented as claims, = though I can also imagine those being in different data = structures. 

> Optimization of = information and API access beyond identity through the delegation = process

Could you please explain = what is meant by this goal and how it relates to = identity?


At its core this isn=E2=80=99t an = identity protocol, but a delegation protocol. One of the core things = that it can delegate is knowledge of the identity of the user. This is = how OIDC is built on top of OAuth 2, and we=E2=80=99re looking at = repeating that kind of layering but in a more direct way as = possible.

 =E2=80=94 Justin

Than= ks!

Kim = Cameron

 

 

-- 
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=_D8676BD4-4661-4CE6-B80F-E0AD0D12BB60-- From nobody Tue Jan 28 09: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 C7492120041 for ; Tue, 28 Jan 2020 09:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.488 X-Spam-Level: X-Spam-Status: No, score=-14.488 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 WuNeJ1-Gi8Yw for ; Tue, 28 Jan 2020 09:00:20 -0800 (PST) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.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 A41E8120045 for ; Tue, 28 Jan 2020 09:00:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1580230821; x=1611766821; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wJdkjpK+rchF6WKCRD7y6VVGGE1de9OMDY9z0ca6Cu8=; b=WzKM66ePp31GOpjG1GRV39v6coMrAwuckSWqX98SdOBWbSxw3Jr3luxm 2spEtYegsVyrMPzIhQC+uEwzbdRxhAUy+o7AXn1FvloSYfE8FjUh13Frm ge6AmPxY7BCSjdGHHxUyY9qhU3Z8+gJtFMI2c/grq2CjCnW/Nik5wi/3r w=; IronPort-SDR: wJ7PKp9/LA2Ga3aBmhEjP0FEaSgqIRmJKrTjd8SIEgIPn7vqF0cHGvkrqAhwib/ITP+xmguuZl te0pOz2EZUQw== X-IronPort-AV: E=Sophos; i="5.70,374,1574121600"; d="scan'208,217"; a="14606712" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1e-17c49630.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 28 Jan 2020 17:00:16 +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-17c49630.us-east-1.amazon.com (Postfix) with ESMTPS id 960B7A29F2; Tue, 28 Jan 2020 17:00:15 +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; Tue, 28 Jan 2020 17:00:14 +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.1367.3; Tue, 28 Jan 2020 17:00:14 +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.1367.000; Tue, 28 Jan 2020 17:00:14 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt CC: Justin Richer , Kim , "txauth@ietf.org" Thread-Topic: [Txauth] Questions on the TxAuth charter Thread-Index: AdXVdev1XhtwHfEhQu6tUSp4GGwQ5gAWC08AAAnkTQAAAa+NOQ== Date: Tue, 28 Jan 2020 17:00:14 +0000 Message-ID: <3BA85F10-4D24-4682-BC97-AA8954CA24A5@amazon.com> References: <4EBBC47D-8EF1-46F2-9623-89070428FA25@mit.edu>, 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: multipart/alternative; boundary="_000_3BA85F104D244682BC97AA8954CA24A5amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Questions on the 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: Tue, 28 Jan 2020 17:00:32 -0000 --_000_3BA85F104D244682BC97AA8954CA24A5amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T0lEQyBjbGFpbXMgZ290IGEgbG90IHJpZ2h0LCBidXQgdGhleSBhcmVu4oCZdCBwZXJmZWN0LiBI ZXJlIGFyZSBhIGZldyBpc3N1ZXMgd2l0aCB0aGVtOg0KDQogICogICBUaGUgb25seSBkZWZpbmVk IHZhbHVlcyBmb3IgZ2VuZGVyIGFyZSBtYWxlIGFuZCBmZW1hbGUuDQogICogICBUaGUgLi4uX25h bWUgY2xhaW1zIGVuY291cmFnZSBkZXNpZ25zIHRoYXQgY2F0ZXIgdG8gV2VzdGVybiBuYW1pbmcg Y29udmVudGlvbnMuDQogICogICBUaGUgLi4uX3ZlcmlmaWVkIGNsYWltcyBkb27igJl0IGRlZmlu ZSBob3cgb3Igd2hlbiB2ZXJpZmljYXRpb24gb2NjdXJyZWQuDQogICogICBQb29yIHN1cHBvcnQg Zm9yIG11bHRpcGxlIGVtYWlsIGFkZHJlc3NlcyBvciBwaG9uZSBudW1iZXJzLg0KICAqICAgTm8g bWVjaGFuaXNtIGZvciBzcGVjaWZ5aW5nIGEgcmVxdWlyZWQgdmFsdWUgZm9yIHBhcnQgb2YgYSBj b21wbGV4IGNsYWltIChlLmcuLCByZXF1aXJpbmcgYW4gYWRkcmVzcyBpbiBhIHBhcnRpY3VsYXIg Y291bnRyeSkuDQogICogICBUaGUgcGljdHVyZSBjbGFpbSBpcyB1bm5lY2Vzc2FyaWx5IGNvbnN0 cmFpbmVkIHRvIGJlIGEgcGhvdG8gb2YgdGhlIGVuZCB1c2VyLg0KICAqICAgVGhlIHNlbWFudGlj IGRpZmZlcmVuY2UgYmV0d2VlbiBhIGNsYWltIGFib3V0IGEgc3ViamVjdCBhbmQgcmVzb3VyY2Vz IG93bmVkIGJ5IGEgc3ViamVjdCBpcyBsb3N0IG9uIGRldmVsb3BlcnMsIGxlYWRpbmcgdG8gY3Vz dG9tIGNsYWltcyB0aGF0IGRvbuKAmXQgcmVhbGx5IG1ha2Ugc2Vuc2UgYXMgY2xhaW1zLg0KDQpP biBKYW4gMjgsIDIwMjAsIGF0IDg6MTIgQU0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwu Y29tPiB3cm90ZToNCg0KV2hhdCBkbyB5b3Ugc2VlIGFzIGxhY2tpbmcgaW4gdGhlIE9JREMgY2xh aW1zPw0K --_000_3BA85F104D244682BC97AA8954CA24A5amazoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2IGRpcj0ibHRyIj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29s b3I6IHJnYigwLCAwLCAwKTsiPk9JREMgY2xhaW1zIGdvdCBhIGxvdCByaWdodCwgYnV0IHRoZXkg YXJlbuKAmXQgcGVyZmVjdC4gSGVyZSBhcmUgYSBmZXcmbmJzcDs8L3NwYW4+aXNzdWVzIHdpdGgg dGhlbToNCjxkaXY+DQo8dWw+DQo8bGk+VGhlIG9ubHkgZGVmaW5lZCB2YWx1ZXMgZm9yIGdlbmRl ciBhcmUgbWFsZSBhbmQgZmVtYWxlLjwvbGk+PGxpPlRoZSAuLi5fbmFtZSBjbGFpbXMgZW5jb3Vy YWdlIGRlc2lnbnMgdGhhdCBjYXRlciB0byBXZXN0ZXJuIG5hbWluZyBjb252ZW50aW9ucy48L2xp PjxsaT5UaGUgLi4uX3ZlcmlmaWVkIGNsYWltcyBkb27igJl0IGRlZmluZSBob3cgb3Igd2hlbiB2 ZXJpZmljYXRpb24gb2NjdXJyZWQuPC9saT48bGk+UG9vciBzdXBwb3J0IGZvciBtdWx0aXBsZSBl bWFpbCBhZGRyZXNzZXMgb3IgcGhvbmUgbnVtYmVycy48L2xpPjxsaT5ObyBtZWNoYW5pc20gZm9y IHNwZWNpZnlpbmcgYSByZXF1aXJlZCB2YWx1ZSBmb3IgcGFydCBvZiBhIGNvbXBsZXggY2xhaW0g KGUuZy4sIHJlcXVpcmluZyBhbiBhZGRyZXNzIGluIGEgcGFydGljdWxhciBjb3VudHJ5KS48L2xp PjxsaT5UaGUgcGljdHVyZSBjbGFpbSBpcyB1bm5lY2Vzc2FyaWx5IGNvbnN0cmFpbmVkIHRvIGJl IGEgcGhvdG8gb2YgdGhlIGVuZCB1c2VyLjwvbGk+PGxpPlRoZSBzZW1hbnRpYyBkaWZmZXJlbmNl IGJldHdlZW4gYSBjbGFpbSBhYm91dCBhIHN1YmplY3QgYW5kIHJlc291cmNlcyBvd25lZCBieSBh IHN1YmplY3QgaXMgbG9zdCBvbiBkZXZlbG9wZXJzLCBsZWFkaW5nIHRvIGN1c3RvbSBjbGFpbXMg dGhhdCBkb27igJl0IHJlYWxseSBtYWtlIHNlbnNlIGFzIGNsYWltcy48L2xpPjwvdWw+DQo8ZGl2 IGRpcj0ibHRyIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj4NCk9uIEphbiAyOCwgMjAy MCwgYXQgODoxMiBBTSwgRGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7IHdy b3RlOjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj5XaGF0IGRvIHlvdSBzZWUgYXMgbGFja2luZyBpbiB0aGUg T0lEQyBjbGFpbXM/PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_3BA85F104D244682BC97AA8954CA24A5amazoncom_-- From nobody Tue Jan 28 09:05: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 87DB9120120 for ; Tue, 28 Jan 2020 09:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 3XYs2dVQo_Gk for ; Tue, 28 Jan 2020 09:05:25 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9BA61200E5 for ; Tue, 28 Jan 2020 09:05:24 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id v17so15492675ljg.4 for ; Tue, 28 Jan 2020 09:05: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 :cc; bh=yuM+gqRKeAyRuKZJPwm62f7Mz9X5sp1G7lpD9w14poY=; b=MxpbkRHIt53ZixMNjOH4MPkO4214EmVFDjK418rEArXjgGwhteSsyUvJe8HRJoMxsg 33s+SyQp0PjJ1tYd5tbyppST5m7MRO+FUuN7NnHuDG4wEa+b+CiEbS2GTwpsWCPDlfxv f4kNejszFfTyPPrNyIyRGEKLWYoDzJ+ZZnckvj5YTOEyAaaI8d3f3Ui/M8J6roqyMDr0 iVSZoCi2QfSPx1G7Yq3MXAaOoV1z7hQCc3BqXlE5qC3vIXR7F1G+KOqFSSbk+OQAQH4T hzq2lGPusrVYTzgedHXjbukGwWkSnKpQbqEGVXta7hMILpwwHX6gw6jSSoVb1xYpkesQ DmsQ== 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=yuM+gqRKeAyRuKZJPwm62f7Mz9X5sp1G7lpD9w14poY=; b=DOvJxgjbVM3dgi0KtGQ4J9YtMhp/6XEYAwNdEAxF7A1buXcj9IB9lycMrqyt+jNmgd Y8eDHJNOp/NQvS3oQBpmxZSmUzr7A8G8TZkbHU/QbV9CR1qoj8cLM57QJMQgNkeJo1Yq TfwOKdtYwZgzC8W+B1DO6d7MY7R0yHAEhKBpRCeiLQ1dH/kQHYZCL9F98eoYlT5SlzJT Mgniw9pzIyeCkI85NrJmR4CA/brVlMyxxYJ3hAYdVyRnc4G6He74U7i1lvrXVibHKHCN CojNhnanD3FNcUK9G6lmNg3g7Kpz0ukl7+tfBWcslhqPplBUgin1UO8WpoL0LQYC6wqY PMeQ== X-Gm-Message-State: APjAAAV43lEPGinaqzS1w+Hvpe3DJ9LVEkZMYChVVPi57l+NrCJOqwfZ ObsPMS0jgkjHhA3cJX2R5O9+E9SJ7eplxZjThvE= X-Google-Smtp-Source: APXvYqys57Tz06v8UX02Xm6DA2lSmIhWQD1/3dVIHka6w8hVCarJnYEfI6YgEmqHY93ziybLhxlw7kJIm2gN5SebYuk= X-Received: by 2002:a2e:580c:: with SMTP id m12mr14029720ljb.150.1580231122839; Tue, 28 Jan 2020 09:05:22 -0800 (PST) MIME-Version: 1.0 References: <4EBBC47D-8EF1-46F2-9623-89070428FA25@mit.edu> <9403A1A5-8D3F-4425-8447-4A40FF7AB8FD@mit.edu> In-Reply-To: <9403A1A5-8D3F-4425-8447-4A40FF7AB8FD@mit.edu> From: Dick Hardt Date: Tue, 28 Jan 2020 09:05:11 -0800 Message-ID: To: Justin Richer Cc: Kim , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bd6d81059d363af1" Archived-At: Subject: Re: [Txauth] Questions on the 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: Tue, 28 Jan 2020 17:05:28 -0000 --000000000000bd6d81059d363af1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agreed. Not having subject be a globally unique identifier, nor defining a concatenation mechanism has been a developer issue. On Tue, Jan 28, 2020 at 8:57 AM Justin Richer wrote: > The claims in OIDC aren=E2=80=99t just JSON, many of them are JWT payload > elements, which need to be compact so that it could fit better into brows= er > redirects and places like that. I contend that we are not bound by the sa= me > restrictions, so just like with the SAML translations of =E2=80=9C=E2=80=9D to > =E2=80=9Ciss=E2=80=9D we should consider what we really need in the new s= pace even if it=E2=80=99s > the same concepts translated over. > > We=E2=80=99d be foolish to ignore them, but also nearly as foolish to tak= e them > just because they exist and it=E2=80=99s the world we know. For instance,= we know > that the OIDC separation of issuer and subject into a pair of values is > really confusing to developers and leads to people using email address, > username, or other incorrect fields as a universal identifier. There are > some things that we got right, though, such as the flat namespace-less JS= ON > data model that allows domain extensions. > > So just as with anything else in this proposed new work, I am arguing tha= t > we should take OIDC claims as an influencing input to be evaluated in the > context of what we=E2=80=99re trying to do. =E2=80=9CWe did it this way i= n OIDC=E2=80=9D is not a > sufficient argument for its inclusion in TxAuth, and therefore I agree th= at > it does not belong anywhere in the charter. But we also need to look at > what we did do in OIDC and figure out how and if it fits as we=E2=80=99re= figuring > out solutions. > > =E2=80=94 Justin > > On Jan 28, 2020, at 5:11 PM, Dick Hardt wrote: > > Kim: are you suggesting that supporting OIDC claims be in the charter? > > While I think that supporting OIDC claims is desirable, I don't think tha= t > belongs in the charter. > > Justin: OIDC claims inherently had to be different from SAML as the synta= x > was JSON vs XML. > > Are you suggesting that a different document format be used than JSON? > > What do you see as lacking in the OIDC claims? > > > > > > > On Tue, Jan 28, 2020 at 3:30 AM Justin Richer wrote: > >> Hi Kim, thanks for the feedback. Answers inline, below. >> >> On Jan 28, 2020, at 1:57 AM, Kim wrote: >> >> Dear Justin, >> >> The current wording of the draft charter raised questions for me that >> others might share. Clarifying these would help those of us not familiar >> with the work to date. >> >> > This group is chartered to develop a delegation protocol for >> authorization, identity, and API access. >> >> Can you please expand on what you mean by delegation of identity and >> whether that leverages claims and tokens as defined in OpenID Connect? >> >> >> We would not necessarily be using the exact claims and mechanisms in OID= C. >> >> > The use cases supported by this protocol will include widely deployed >> use cases currently supported by OAuth 2.0 and OpenID Connect (an extens= ion >> of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0. >> >> I understand and support the motivations to rework the authorization >> flows. However, the identity representations in OpenID Connect have >> already shown themselves to work well in conveying the identity of the e= nd >> user. It seems prudent to avoid the confusion and complexity that would >> result from introducing new mechanisms to do the same thing. Will the >> enhancements to the authorization leverage what already works and has >> become a unifying technology? >> >> >> And when OIDC was invented, SAML had already been shown to work well in >> conveying the identity of an end user. I believe we can make a similar l= eap >> forward here. This is not just a new conveyance mechanism for OIDC, but = it >> will certainly learn from it as OIDC learned from SAML and other things >> that came before. >> >> > This protocol will allow an authorizing party to delegate access to >> client software through an authorization server=E2=80=A6 >> >> > The client and AS will involve the authorizing party as necessary >> through interaction mechanisms indicated by the protocol. >> >> What is the authorizing party? Is that one of the roles in the protocol? >> Is it the end user? >> >> >> It=E2=80=99s the OAuth/UMA =E2=80=9CResource Owner=E2=80=9D, which might= be the user using the >> client software and might be someone else that the AS can contact throug= h >> other means. >> >> > Approval of AS attestation to identity claims >> >> Does this mean that the AS is approving of the claims and conveying that >> approval to another party (and what party would that be)? >> >> No, the authorizing party is approving the claims and the AS is conveyin= g >> the identity claims and the delegated access token to the client. >> >> By identity claims are you leveraging claims as defined in OpenID Connec= t? >> >> >> Not necessarily, but they=E2=80=99re on the table as items to consider. >> >> Are the identity claims about the end user =E2=80=93 or other subjects a= s well? >> >> >> Generally speaking yes, though in the multi-user case (CIBA, UMA, and >> some device-flow use cases today), the claims of the authorizing party a= re >> being conveyed to the end user of the client, who might be a different >> party. This is an advanced use case, though, so I see it as something we >> can enable but not likely to be the most common use case, which is >> conveying the current user=E2=80=99s claims to a piece of software that = they=E2=80=99re >> using. >> >> > Mechanisms for providing user, software, organization, and other piece= s >> of information used in authorization decisions =E2=80=93 >> >> Could you elaborate on what information about users would be supplementa= l >> to those expressed as claims? Also, would information about software an= d >> organization be expressed as claims? >> >> >> How the user logged in today, how the user was proofed when they got the >> account, the status of the client software that was making the request a= t >> the time, etc. So yes, software and organization could also be represent= ed >> as claims, though I can also imagine those being in different data >> structures. >> >> > Optimization of information and API access beyond identity through the >> delegation process >> >> Could you please explain what is meant by this goal and how it relates t= o >> identity? >> >> >> At its core this isn=E2=80=99t an identity protocol, but a delegation pr= otocol. >> One of the core things that it can delegate is knowledge of the identity= of >> the user. This is how OIDC is built on top of OAuth 2, and we=E2=80=99re= looking at >> repeating that kind of layering but in a more direct way as possible. >> >> =E2=80=94 Justin >> >> Thanks! >> >> Kim Cameron >> >> >> >> >> -- >> 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 >> > > --000000000000bd6d81059d363af1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed.

=
Not having subject be a globally unique identifier, nor d= efining a concatenation mechanism =C2=A0has been a developer issue.

On Tue, Jan 28, 2020 at 8:57 AM Justin Richer <jricher@mit.edu> wrote:
The claims in OIDC aren=E2=80=99t just JSON, many of = them are JWT payload elements, which need to be compact so that it could fi= t better into browser redirects and places like that. I contend that we are= not bound by the same restrictions, so just like with the SAML translation= s of =E2=80=9C<saml:Issuer>=E2=80=9D to =E2=80=9Ciss=E2=80=9D we shou= ld consider what we really need in the new space even if it=E2=80=99s the s= ame concepts translated over.

We=E2=80=99d be foolish to= ignore them, but also nearly as foolish to take them just because they exi= st and it=E2=80=99s the world we know. For instance, we know that the OIDC = separation of issuer and subject into a pair of values is really confusing = to developers and leads to people using email address, username, or other i= ncorrect fields as a universal identifier. There are some things that we go= t right, though, such as the flat namespace-less JSON data model that allow= s domain extensions.

So just as with anything else= in this proposed new work, I am arguing that we should take OIDC claims as= an influencing input to be evaluated in the context of what we=E2=80=99re = trying to do. =E2=80=9CWe did it this way in OIDC=E2=80=9D is not a suffici= ent argument for its inclusion in TxAuth, and therefore I agree that it doe= s not belong anywhere in the charter. But we also need to look at what we d= id do in OIDC and figure out how and if it fits as we=E2=80=99re figuring o= ut solutions.

=C2=A0=E2=80=94 Justin

On Jan 28, 2020, at 5:11 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Kim: are you suggesting that s= upporting OIDC claims be in the charter?

While I think t= hat supporting OIDC claims is desirable, I don't think that belongs in = the charter.

Justin: OIDC claims inherently had to= be different from SAML as the syntax was JSON vs XML.

=
Are you suggesting that a different document format be used than JSON?=

What do you see as lacking in the OIDC claims?

=C2=A0



<= /div>

On Tue, Jan 28, 2020 at 3:30 AM Justin Richer <jricher@mit.edu> wrote:
Hi Kim, thanks for the= feedback. Answers inline, below.

On Jan 28, 2020, at 1:57 AM, Kim <kim@identityblog.com> wrote:

Dear Justin,

The = current wording of the draft charter raised questions for me that others mi= ght share. Clarifying these would help those of us not familiar with the wo= rk to date.

> This group is charte= red to develop a delegation protocol for authorization, identity, and API a= ccess.

Can you please expand on what you me= an by delegation of identity and whether that leverages claims and tokens a= s defined in OpenID Connect?


We would not necessarily be using the exact claims and mechanisms = in OIDC.

> The use cases sup= ported by this protocol will include widely deployed use cases currently su= pported by OAuth 2.0 and OpenID Connect (an extension of OAuth 2.0) as well= as new use cases not enabled by OAuth 2.0.

I understand and support the motivations to rework the authorization flows= .=C2=A0 However, the identity representations in OpenID Connect have alread= y shown themselves to work well in conveying the identity of the end user. = It seems prudent to avoid the confusion and complexity that would result fr= om introducing new mechanisms to do the same thing. Will the enhancements t= o the authorization leverage what already works and has become a unifying t= echnology?


And when = OIDC was invented, SAML had already been shown to work well in conveying th= e identity of an end user. I believe we can make a similar leap forward her= e. This is not just a new conveyance mechanism for OIDC, but it will certai= nly learn from it as OIDC learned from SAML and other things that came befo= re.

> This protocol will all= ow an authorizing party to delegate access to client software through an au= thorization server=E2=80=A6=C2=A0

> The client and AS will involve the authorizing party as nece= ssary through interaction mechanisms indicated by the protocol.=C2=A0=

<= span style=3D"font-size:10.5pt;line-height:14.7px;font-family:Consolas;colo= r:rgb(33,37,41);background-color:white">What is the authorizing party? Is t= hat one of the roles in the protocol?=C2=A0 Is it the end user?

<= /div>

It=E2=80=99s the OAuth/UMA =E2= =80=9CResource Owner=E2=80=9D, which might be the user using the client sof= tware and might be someone else that the AS can contact through other means= .=C2=A0

= > Approval of AS attestation to= identity claims

Does this mean that the AS= is approving of the claims and conveying that approval to another party (a= nd what party would that be)?=C2=A0

No, the authorizing party is approving the claims and the AS is conveying = the identity claims and the delegated access token to the client.=C2=A0

By identity claims are you leveraging cl= aims as defined in OpenID Connect?

=
Not necessarily, but they=E2=80=99re on the table as items to con= sider.

Are the identity claims about the en= d user =E2=80=93 or other subjects as well?


Generally speaking yes, though in the multi-user ca= se (CIBA, UMA, and some device-flow use cases today), the claims of the aut= horizing party are being conveyed to the end user of the client, who might = be a different party. This is an advanced use case, though, so I see it as = something we can enable but not likely to be the most common use case, whic= h is conveying the current user=E2=80=99s claims to a piece of software tha= t they=E2=80=99re using.

> Mechanisms f= or providing user, software, organization, and other pieces of information = used in authorization decisions =E2=80=93=C2=A0<= /span>

Could you elaborate on what information about users would= be supplemental to those expressed as claims?=C2=A0 Also, would informatio= n about software and organization be expressed as claims?=C2=A0


How the user logge= d in today, how the user was proofed when they got the account, the status = of the client software that was making the request at the time, etc. So yes= , software and organization could also be represented as claims, though I c= an also imagine those being in different data structures.=C2=A0

> Optimization of information and API access beyond i= dentity through the delegation process

Coul= d you please explain what is meant by this goal and how it relates to ident= ity?


At its core thi= s isn=E2=80=99t an identity protocol, but a delegation protocol. One of the= core things that it can delegate is knowledge of the identity of the user.= This is how OIDC is built on top of OAuth 2, and we=E2=80=99re looking at = repeating that kind of layering but in a more direct way as possible.
=

=C2=A0=E2=80=94 Justin

Thanks!

Kim Cameron

=C2=A0

=C2=A0

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

--000000000000bd6d81059d363af1-- From nobody Tue Jan 28 09:11: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 8B08E12002E for ; Tue, 28 Jan 2020 09:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Qzn6KhDvHXa2 for ; Tue, 28 Jan 2020 09:11:23 -0800 (PST) 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 05A29120024 for ; Tue, 28 Jan 2020 09:11:23 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id a13so15476465ljm.10 for ; Tue, 28 Jan 2020 09:11:22 -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=HitvU/6+kEU/J+EI4o1fS9WcTxs7qL+/HP5V+dpLZCA=; b=fwd0gwjNGVyk7D8OaWAGmw209w95683xfACmoFPQIAVkOI/rC71q1QQ0p7CjVFSg/H zOSzwzl3BAWP1WrRdm4QeT2RP3LBcRNJSQBVrBjnsPrUTI9VF3NoxyL8qHLpvCpdeimn rwBy6XWDzrgWl78mHxZUbX/KF86ChebHnMBco3lu7xg1ISUYTt4biLUpc7o2xuHHsfct ScO3Ek8NJV9lk8LX8Jx5XRBm2FXvKYCFy3DmFtFYo19DTbg7MfKrgSU7+AtE+ef6UxSg QugNJ8DgfDdt9x815hNOA9Lu2zk1dw4CBuPJQ31ZfNyWWcapVfHCJ2QRgIIMN0IGhEh9 jRzQ== 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=HitvU/6+kEU/J+EI4o1fS9WcTxs7qL+/HP5V+dpLZCA=; b=fUnyqvtFvtL/ICAKONm5+ByMYZJKSK8eCa0DLvvIrW5k7oxtzO5547yAlKciOB5FqF aKKoWNbTcl/xqQBnaOXGRHzbKIdCz4vm4jXzx6dV8KLUcBjlNvXiorS2hcUwVq3iwU+X xk94UKXdG94bYTAAA7NwdbmJ7tCJ4T32xkZ20brGhUkbVfuydtHDu+yRqdGpN1iZ1XT4 gGR7zDrhLr2QRPi8bJWpTtx05bv0apL+sAfuQdU5yHRvM2+9qOEtFb23jfiuKFdpBeDG G2ZRxKrui085F80MMm9oiIXU+XOFNejCDHhLyMDrZ1ilQuUwtESYPwTz6CRzSxeorGQU gypg== X-Gm-Message-State: APjAAAU7qPoatOMUmIMafoA7uwaC3C51c6H9Iz8ce4ejkBpmv0eL+I3w wNL/y8k10wff/a7Qyp2yeTvuFSHC+Ko+Z4mOo+Q= X-Google-Smtp-Source: APXvYqw7NVf7UXnUvovH2Z6ewCNJzD3XoikM+0qDJCQWJKzsUAZzJ7mFSi6qtAWxPRN0jgVQjEnpf2lt1BpV1n717fA= X-Received: by 2002:a2e:9d89:: with SMTP id c9mr6401292ljj.212.1580231481111; Tue, 28 Jan 2020 09:11:21 -0800 (PST) MIME-Version: 1.0 References: <4EBBC47D-8EF1-46F2-9623-89070428FA25@mit.edu> <3BA85F10-4D24-4682-BC97-AA8954CA24A5@amazon.com> In-Reply-To: <3BA85F10-4D24-4682-BC97-AA8954CA24A5@amazon.com> From: Dick Hardt Date: Tue, 28 Jan 2020 09:11:10 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: Justin Richer , Kim , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000183878059d3650c6" Archived-At: Subject: Re: [Txauth] Questions on the 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: Tue, 28 Jan 2020 17:11:28 -0000 --000000000000183878059d3650c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Annabelle. Schema has always been difficult in identity. We can get it more right this time, but I think the right extensibility is important to enable continual improvement. Comments inserted ... On Tue, Jan 28, 2020 at 9:00 AM Richard Backman, Annabelle < richanna@amazon.com> wrote: > OIDC claims got a lot right, but they aren=E2=80=99t perfect. Here are a = few issues > with them: > > - The only defined values for gender are male and female. > > agreed =E2=80=94 in fairness the awareness is much greater now > > - > - The ..._name claims encourage designs that cater to Western naming > conventions. > > agreed > > - > - The ..._verified claims don=E2=80=99t define how or when verificatio= n > occurred. > > agreed > > - > - Poor support for multiple email addresses or phone numbers. > > has this been an issue? > > - > - No mechanism for specifying a required value for part of a complex > claim (e.g., requiring an address in a particular country). > > interesting > > - > - The picture claim is unnecessarily constrained to be a photo of the > end user. > > agreed > > - > - The semantic difference between a claim about a subject and > resources owned by a subject is lost on developers, leading to custom > claims that don=E2=80=99t really make sense as claims. > > would you elaborate or provide examples? > > - > > On Jan 28, 2020, at 8:12 AM, Dick Hardt wrote: > > What do you see as lacking in the OIDC claims? > > --000000000000183878059d3650c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Annabelle. Schema has always been difficult i= n identity. We can get it more right this time, but I think the right exten= sibility is important to enable continual improvement.

Comments inserted ...

On Tue, Jan = 28, 2020 at 9:00 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:
OIDC claims got a lot rig= ht, but they aren=E2=80=99t perfect. Here are a few=C2=A0issues with= them:
  • The only defined values for gender are male and female.
=
agreed =E2=80=94 in fairness the= awareness is much greater now
  • The ..._name claims encour= age designs that cater to Western naming conventions.
=
agreed
  • The ..._verif= ied claims don=E2=80=99t define how or when verification occurred.
agreed
  • = Poor support for multiple email addresses or phone numbers.
=
has this been an issue?
  • No mechanism for specifying a required value for part of a comple= x claim (e.g., requiring an address in a particular country).
interesting
  • = The picture claim is unnecessarily constrained to be a photo of the end use= r.
agreed
  • The semantic difference between a claim about a subject and reso= urces owned by a subject is lost on developers, leading to custom claims th= at don=E2=80=99t really make sense as claims.
would you elaborate or provide examples?
=
    =
On Jan 28, 2020, at 8:12 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

What do you see as lacking in the OIDC claims?
--000000000000183878059d3650c6-- From nobody Tue Jan 28 09:33: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 B917B12022E for ; Tue, 28 Jan 2020 09:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 Dfe2mqEH7D9i for ; Tue, 28 Jan 2020 09:33:01 -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 A6BB812022D for ; Tue, 28 Jan 2020 09:33:01 -0800 (PST) Received: from [100.83.133.69] (static.kpn.net [217.166.240.200] (may be forged)) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00SHWqF3003805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Jan 2020 12:32:54 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8AFE685D-AA1D-41CF-ADDE-AEB5AFA4B427" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 28 Jan 2020 18:32:51 +0100 In-Reply-To: Cc: "Richard Backman, Annabelle" , Kim , "txauth@ietf.org" To: Dick Hardt References: <4EBBC47D-8EF1-46F2-9623-89070428FA25@mit.edu> <3BA85F10-4D24-4682-BC97-AA8954CA24A5@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Questions on the 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: Tue, 28 Jan 2020 17:33:05 -0000 --Apple-Mail=_8AFE685D-AA1D-41CF-ADDE-AEB5AFA4B427 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think =E2=80=9Cgetting it more right=E2=80=9D is exactly the goal. = OIDC=E2=80=99s schema is a much better starting point than SAMLs was, = but a starting point is not where we stop! =E2=80=94 Justin > On Jan 28, 2020, at 6:11 PM, Dick Hardt wrote: >=20 > Thanks Annabelle. Schema has always been difficult in identity. We can = get it more right this time, but I think the right extensibility is = important to enable continual improvement. >=20 > Comments inserted ... >=20 > On Tue, Jan 28, 2020 at 9:00 AM Richard Backman, Annabelle = > wrote: > OIDC claims got a lot right, but they aren=E2=80=99t perfect. Here are = a few issues with them: > The only defined values for gender are male and female. > agreed =E2=80=94 in fairness the awareness is much greater now > The ..._name claims encourage designs that cater to Western naming = conventions. > agreed > The ..._verified claims don=E2=80=99t define how or when verification = occurred. > agreed > Poor support for multiple email addresses or phone numbers. > has this been an issue? > No mechanism for specifying a required value for part of a complex = claim (e.g., requiring an address in a particular country). > interesting > The picture claim is unnecessarily constrained to be a photo of the = end user. > agreed > The semantic difference between a claim about a subject and resources = owned by a subject is lost on developers, leading to custom claims that = don=E2=80=99t really make sense as claims. > would you elaborate or provide examples? >> On Jan 28, 2020, at 8:12 AM, Dick Hardt > wrote: >>=20 >> What do you see as lacking in the OIDC claims? --Apple-Mail=_8AFE685D-AA1D-41CF-ADDE-AEB5AFA4B427 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think =E2=80=9Cgetting it more right=E2=80=9D is exactly the goal. = OIDC=E2=80=99s schema is a much better starting point than SAMLs was, = but a starting point is not where we stop!

 =E2=80=94 Justin

On Jan 28, 2020, at 6:11 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Thanks = Annabelle. Schema has always been difficult in identity. We can get it = more right this time, but I think the right extensibility is important = to enable continual improvement.

Comments inserted = ...

On Tue, Jan = 28, 2020 at 9:00 AM Richard Backman, Annabelle <richanna@amazon.com>= wrote:
OIDC claims got = a lot right, but they aren=E2=80=99t perfect. Here are a = few issues with them:
  • The only defined values for gender are male and = female.
agreed =E2=80=94 in fairness the awareness is much greater = now
  • The ..._name claims encourage designs = that cater to Western naming = conventions.
agreed
  • The ..._verified claims don=E2=80=99t = define how or when verification = occurred.
agreed
  • Poor support for multiple email addresses = or phone numbers.
has this been an issue?
  • No mechanism for specifying a required value for part of a = complex claim (e.g., requiring an address in a particular = country).
interesting
  • The picture claim is unnecessarily constrained to be a photo = of the end user.
agreed
  • The semantic difference between a claim about a subject and = resources owned by a subject is lost on developers, leading to custom = claims that don=E2=80=99t really make sense as = claims.
would you elaborate or provide examples?
On Jan 28, 2020, at 8:12 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

What do you see as lacking in the OIDC = claims?

= --Apple-Mail=_8AFE685D-AA1D-41CF-ADDE-AEB5AFA4B427-- From nobody Tue Jan 28 10:58: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 45DB5120033 for ; Tue, 28 Jan 2020 10:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ypussajilVoA for ; Tue, 28 Jan 2020 10:58:39 -0800 (PST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B63120026 for ; Tue, 28 Jan 2020 10:58:38 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id g19so11552131eds.11 for ; Tue, 28 Jan 2020 10:58:38 -0800 (PST) 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 :cc; bh=InSOQLoHoGFjouNk9eCrGRrKlvHiOowbAlNkF0YY4Qc=; b=bE3o8ad5HDVGj+ptT1lOuJqy35TXTuIey5Gz4GQOQefYUAkEonX5ZNjTkcq0PAp4RI VTNJH/aAJS7P3R3CdQeFXgoNu6kMuVbyPww1v74hEuYuszy/F8R+CCBLtl1hkyF1GmkY f771GR5rC7ZTShbLaVdXPDt0PWWsOxEovVHerVqdplKiuRF8K9WTJXuHTWd9X/+Ya0aK pYXudnr9vKpaAOH2p17hdJCFVjmGxrzUjCJqVs9H6yiba+i7VQmk/HTVJZ7376l0Qhzl Zu5+HQ7v1IeAOVvCWXU71rtAfOvo3eXJUqIkJzQ4oR6tBCa+nfERLnr43nE68Tuj6UXL wtMg== 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=InSOQLoHoGFjouNk9eCrGRrKlvHiOowbAlNkF0YY4Qc=; b=Gpv5HummJcgVhLKS50VE5nGtosSm9ps3sU59FpifDpoV0fWCzTXrlpVEX17z32lt5g irSou8AfXTrEjNzQqH8vKhNHpruN9ZRZoFb24InQfvs3EyweraYeN/Uc683Kt9OhRhFa MEdvHa2DbZPnUMurfPkPs95O7lsp0wxS93jvpyzm7a7KHMOSeSbWOZH0ZUcOOvNh+fKq ZKeKNgsuVmFVxqIl4oz1+cD3fuwn1lXs22ArTK4ACcnF5cJ67+jNiCskxhYygjzvDxgO NSLhlMHKB1eU6hWWbCytD4c2RDXHMmNVwEaPZe2bbhjq3aTtzXJEbj1Tdqc72MTaDnSJ lupg== X-Gm-Message-State: APjAAAX2ZgGW7p0J99fLTaxH3SBrtN8jvNNglZzy+XNbLjT8i3N5A4Ez bNiE66lQZEb8c/fdT1o5oFwQB4ksr/yGdXTQ4TSAmg== X-Google-Smtp-Source: APXvYqxGCAeo0Xp3Im3w0Jb0CtS5EZYLE6OCCv/42uzjL617KS4tmBVcOQOQhLmq5oH3byu6InMzzIOgnqD8/YpU+Tw= X-Received: by 2002:aa7:c5d2:: with SMTP id h18mr4565561eds.182.1580237917279; Tue, 28 Jan 2020 10:58:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Matthew De Haast Date: Tue, 28 Jan 2020 20:58:26 +0200 Message-ID: To: Dick Hardt Cc: txauth@ietf.org, Roman Danyliw , Yaron Sheffer , Benjamin Kaduk , Justin Richer Content-Type: multipart/alternative; boundary="000000000000b868b9059d37cff2" Archived-At: Subject: Re: [Txauth] XAuth - a revision 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, 28 Jan 2020 18:58:41 -0000 --000000000000b868b9059d37cff2 Content-Type: text/plain; charset="UTF-8" Hi Dick, Can you clarify the relation between this and the TxAuth Charter. Are you proposing not to charter TXAuth and rather propose xauth as an extension of Oauth2? Is it an and/or scenario or do you see this being worked on in conjunction with TxAuth? Matt On Tue, Jan 28, 2020 at 12:05 AM Dick Hardt wrote: > Hello! > > I riffed on Justin's draft and have created an alternative that has the > same core concept of secure communication of all parameters between the > Client and the AS. > > https://tools.ietf.org/html/draft-hardt-xauth-protocol-00 > > A goal of this document was to be as self contained as possible. > Everything needed to implement is included if an implementor is are > already familiar with OAuth 2.0 or OpenID Connect, and wants to migrate to > XAuth. > > To meet that goal, JOSE was chosen as the default mechanism for the Client > to authenticate to the AS, and to perform PoP access to a resource. The > JOSE specific aspects are in one section, so that an extension can easily > specify other Client authentication mechanisms. > > There are likely numerous editorial and syntactical errors, and as we all > know -- naming is hard -- so feel free to suggest better names. > > There are lots of issues with normative language, many of which I am not > aware of yet! > > I've revised the document a number of times, and may have old terms > dangling around. Please let me know if there is something confusing, or > contradictory! > > /Dick > > > > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000b868b9059d37cff2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,

Can you clari= fy the relation between this and the TxAuth Charter. Are you proposing not = to charter TXAuth and rather propose xauth as an extension=C2=A0of=C2=A0Oau= th2? Is it an and/or scenario or do you see this being worked on in conjunc= tion with TxAuth?

Matt

On Tue, Jan 28, 2020= at 12:05 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hello!
I riffed on Justin's draft and have created an alternative = that has the same core concept of secure communication of all parameters be= tween the Client and the AS.


A goal of this document was to be as self contained as possible.
Everything needed to implement is included if an implementor is are= already familiar with OAuth 2.0 or OpenID Connect, and wants to migrate to= XAuth.=C2=A0

To meet that goal, JOSE was chosen a= s the default mechanism for the Client to authenticate to the AS, and to pe= rform PoP access to a resource. The JOSE specific aspects are in one sectio= n, so that an extension can easily specify other Client authentication mech= anisms.

There are likely numerous editorial and sy= ntactical errors, and as we all know -- naming is hard -- so feel free to s= uggest better names.

There are lots of issues with= normative language, many of which I am not aware of yet!

I've revised the document a number of times, and may have old t= erms dangling around. Please let=C2=A0me know if there is something confusi= ng, or contradictory!

/Dick






--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000b868b9059d37cff2-- From nobody Tue Jan 28 11:02: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 BF1DD120033 for ; Tue, 28 Jan 2020 11:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeEswJlnpkp3 for ; Tue, 28 Jan 2020 11:01:57 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D57120026 for ; Tue, 28 Jan 2020 11:01:57 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id v201so9919533lfa.11 for ; Tue, 28 Jan 2020 11:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Hji6ALEVfjZuQ2d/IH2YGFb4MzTr23VimBbSQtFypEE=; b=X8/RObjyW41cOe3IP0Mr2QIF3MZe+GfY1LvTyjWJGScz6/OU6Sf1XdRAyQWpy2vjXU QsZEyQrApUW0dpABFZzegkKIKnKBwtIzmBDSHemX9YzBnRG1pXzYnTqnjzGaB2+Zko0c jehLPsba2WKdxFAy1bUMY9aFwrhS48PNt6kC+52Uu4HEP8hIAA60IA9SGjZ/UzRMPQeJ 67lnP/fldPCQTVkF46sWseNXg9kEBoXQb3CQIJ+ynHOJKa2QmXdAetUZmzIbPIphCbmZ s88cDgoz+Imfw2Ge42klqYPfsTqtCCC6Ki24gaG1I8gu/tu4u7o2saI/hBK+mz9vfmBA 9mVg== 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=Hji6ALEVfjZuQ2d/IH2YGFb4MzTr23VimBbSQtFypEE=; b=aipqIlzV8D00wnK21lc/B5khiMmzDg3ROLR5MaIEOk1gXb48b0OunNiVeHpLtGEP/5 VhGMMA5Vqo6EJ1tlqjngNugI8VYb7CFM0mdJihCa+sNwhnt/ZqE2lDlKFUvne7P4LGgV FRel5qjXtsyKakrW4F6BROjVuVdnzf5Pe2nWtv4O3S8IHJ0hpAC76MKYUknC9Pegr6h1 j4/JipJNxd3YsbeArcrumgF+oskD/8glxHfmZVer1ruR+Ow2eOftjpKAfQfPFKBa2BOC RhgX26nkguD5LqIhrZ/tS62PG1kD9R72RjQChJrhDhdOLQ0QW/yOP6O7qCAOOJ0mB/fg EvMg== X-Gm-Message-State: APjAAAUGYAMw4n66KQZH81bUMqcmdcJ2IJKVnF5ZWWM8nI1ExgLXhXeQ qAExUFznSfak/jyRqRsKMCEBvpCfHcKiXxoEMn0= X-Google-Smtp-Source: APXvYqwOuhrY67XJlmWBViHssrqJrusTb5/YfDl/Q2Nwui3SFP2EQ1d34P2mq5WamHykc+USzOHrBwsCjJuzLeSOvUg= X-Received: by 2002:ac2:5f65:: with SMTP id c5mr3258410lfc.207.1580238115437; Tue, 28 Jan 2020 11:01:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 28 Jan 2020 11:01:44 -0800 Message-ID: To: Matthew De Haast Cc: txauth@ietf.org, Roman Danyliw , Yaron Sheffer , Benjamin Kaduk , Justin Richer Content-Type: multipart/alternative; boundary="000000000000880220059d37db27" Archived-At: Subject: Re: [Txauth] XAuth - a revision 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, 28 Jan 2020 19:02:01 -0000 --000000000000880220059d37db27 Content-Type: text/plain; charset="UTF-8" I intended XAuth to meet the TxAuth Charter. The sequence is pretty much the same as the TxAuth ID that Justin proposed. On Tue, Jan 28, 2020 at 10:58 AM Matthew De Haast wrote: > Hi Dick, > > Can you clarify the relation between this and the TxAuth Charter. Are you > proposing not to charter TXAuth and rather propose xauth as an > extension of Oauth2? Is it an and/or scenario or do you see this being > worked on in conjunction with TxAuth? > > Matt > > On Tue, Jan 28, 2020 at 12:05 AM Dick Hardt wrote: > >> Hello! >> >> I riffed on Justin's draft and have created an alternative that has the >> same core concept of secure communication of all parameters between the >> Client and the AS. >> >> https://tools.ietf.org/html/draft-hardt-xauth-protocol-00 >> >> A goal of this document was to be as self contained as possible. >> Everything needed to implement is included if an implementor is are >> already familiar with OAuth 2.0 or OpenID Connect, and wants to migrate to >> XAuth. >> >> To meet that goal, JOSE was chosen as the default mechanism for the >> Client to authenticate to the AS, and to perform PoP access to a resource. >> The JOSE specific aspects are in one section, so that an extension can >> easily specify other Client authentication mechanisms. >> >> There are likely numerous editorial and syntactical errors, and as we all >> know -- naming is hard -- so feel free to suggest better names. >> >> There are lots of issues with normative language, many of which I am not >> aware of yet! >> >> I've revised the document a number of times, and may have old terms >> dangling around. Please let me know if there is something confusing, or >> contradictory! >> >> /Dick >> >> >> >> >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000880220059d37db27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I intended XAuth to meet the TxAuth Charter.

The sequence is pretty much the same as the TxAuth ID that Justin pro= posed.

On Tue, Jan 28, 2020 at 10:58 AM Matthew De Haast <matt@coil.com> wrote:
Hi= Dick,

Can you clarify the relation between this and the= TxAuth Charter. Are you proposing not to charter TXAuth and rather propose= xauth as an extension=C2=A0of=C2=A0Oauth2? Is it an and/or scenario or do = you see this being worked on in conjunction with TxAuth?

Matt

On Tue, Jan 28, 2020 at 12:05 AM Dick Hardt <dick.hardt@gmail.com>= ; wrote:
Hello!

I riffed on Justin's dra= ft and have created an alternative that has the same core concept of secure= communication of all parameters between the Client and the AS.
<= br>

A goal of this document was to b= e as self contained as possible.
Everything needed to implement i= s included if an implementor is are already familiar with OAuth 2.0 or Open= ID Connect, and wants to migrate to XAuth.=C2=A0

T= o meet that goal, JOSE was chosen as the default mechanism for the Client t= o authenticate to the AS, and to perform PoP access to a resource. The JOSE= specific aspects are in one section, so that an extension can easily speci= fy other Client authentication mechanisms.

There a= re likely numerous editorial and syntactical errors, and as we all know -- = naming is hard -- so feel free to suggest better names.

There are lots of issues with normative language, many of which I am = not aware of yet!

I've revised the document a = number of times, and may have old terms dangling around. Please let=C2=A0me= know if there is something confusing, or contradictory!

/Dick






--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000880220059d37db27-- From nobody Tue Jan 28 11:47: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 657AC120033 for ; Tue, 28 Jan 2020 11:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.79 X-Spam-Level: X-Spam-Status: No, score=-11.79 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 LS5rj2kVuYGC for ; Tue, 28 Jan 2020 11:47:45 -0800 (PST) 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 4BEF1120024 for ; Tue, 28 Jan 2020 11:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1580240865; x=1611776865; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7MtyYhrxesLcFIU7cbG852tRszQzeTstcasQncLFeos=; b=upDGpg+YfqTowVMYKBsYTSzcG5Q4oyKOBzOaVaF88+APjcArcVDvKN9M vjJVRKpIyd/BUF10rD1fqHTNmgzsQHdYjmbZApKz+BFzKZZ+u0HTFrjhm Lf+VCGGyWTVPXbnXLahREnG8TspQ7qCRu4bIKzFzhitHrQq9TXr0svcEG U=; IronPort-SDR: V7vDTMuj37P8MqZRRwj02nSi2MGnrV0r/LdQFHN0fXLlGwRu6vE57JuBnsqDkt/b+8etqnYhY7 92iELpss9EgQ== X-IronPort-AV: E=Sophos; i="5.70,375,1574121600"; d="scan'208,217"; a="15170858" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1d-5dd976cd.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 28 Jan 2020 19:47:44 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1d-5dd976cd.us-east-1.amazon.com (Postfix) with ESMTPS id 05EA7A1900; Tue, 28 Jan 2020 19:47:42 +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; Tue, 28 Jan 2020 19:47:42 +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.1367.3; Tue, 28 Jan 2020 19:47:41 +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.1367.000; Tue, 28 Jan 2020 19:47:41 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt CC: Justin Richer , Kim , "txauth@ietf.org" Thread-Topic: [Txauth] Questions on the TxAuth charter Thread-Index: AdXVdev1XhtwHfEhQu6tUSp4GGwQ5gAWC08AAAnkTQAAAa+NOQAAYb4A//+lnoA= Date: Tue, 28 Jan 2020 19:47:41 +0000 Message-ID: <036AB02A-DE48-443E-B39A-55AF4A11EB90@amazon.com> References: <4EBBC47D-8EF1-46F2-9623-89070428FA25@mit.edu> <3BA85F10-4D24-4682-BC97-AA8954CA24A5@amazon.com> 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.101] Content-Type: multipart/alternative; boundary="_000_036AB02ADE48443EB39A55AF4A11EB90amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Questions on the 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: Tue, 28 Jan 2020 19:47:47 -0000 --_000_036AB02ADE48443EB39A55AF4A11EB90amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVnYXJkaW5nIG11bHRpcGxlIGVtYWlsIGFkZHJlc3NlcyBvciBwaG9uZSBudW1iZXJzIChvciBh ZGRyZXNzZXMsIHdoaWNoIEkgbGVmdCBvdXQgaW4gbXkgZWFybGllciBlbWFpbCksIHRoZXJlIGFy ZSBjYXNlcyB3aGVyZSBwZW9wbGUgYXJlIGFza2VkIHRvIHByb3ZpZGUgbXVsdGlwbGUgcGhvbmUg bnVtYmVycyBvciBlbWFpbCBhZGRyZXNzZXMgKGUuZy4sIHBhdGllbnQgaW50YWtlIGZvcm1zKS4g V2l0aCBPSURDLCB5b3XigJlkIGhhdmUgdG8gZGVmaW5lIHNlcGFyYXRlIGNsYWltcyAoZS5nLiwg bW9iaWxlX3Bob25lLCBvZmZpY2VfcGhvbmUpIGFuZCBvZiBjb3Vyc2UgaXTigJlzIG5vdCBjbGVh ciBob3cganVzdCBwbGFpbiDigJxwaG9uZV9udW1iZXLigJ0gd291bGQgZml0IGluIHdpdGggdGhh dC4gRXZlbiBpZiBhbGwgdGhlIGNsaWVudCB3YW50cyBpcyBvbmUgdmFsdWUsIGl0IGNhbiBiZSBo ZWxwZnVsIHRvIGtub3cgd2hpY2ggb25lIChlLmcuLCBhIG1vYmlsZSBhcHAgbmVlZHMgYSBtb2Jp bGUgcGhvbmUgbnVtYmVyLCBub3QgYSBsYW5kbGluZTsgYSBkaWdpdGFsIG11c2ljIHN0b3JlIG5l ZWRzIGEgYmlsbGluZyBhZGRyZXNzLCBidXQgbm90IGEgc2hpcHBpbmcgYWRkcmVzcykuDQoNClJl Z2FyZGluZyBjbGFpbXMgdnMuIHJlc291cmNlcywgSeKAmXZlIHNlZW4gZGV2ZWxvcGVycyB3YW50 IHRvIHVzZSBjbGFpbXMgYXMgYSBidWNrZXQgZm9yIGluY2x1ZGluZyBkYXRhIHJlbGF0ZWQgdG8g c2NvcGVzIGluIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3RzLCB3aGVuIHdoYXQgdGhleSByZWFsbHkg bmVlZGVkIHdhcyBSQVIgb3Igc29tZXRoaW5nIGxpa2UgaXQuIEZvciBMb2dpbiB3aXRoIEFtYXpv biwgd2UgYWRkZWQgYSBwcm9wcmlldGFyeSDigJxzY29wZV9kYXRh4oCdIHBhcmFtZXRlciAoc2lu Y2UgUkFSIGRpZG7igJl0IGV4aXN0IGF0IHRoZSB0aW1lKS4gT24gdGhlIHJldmVyc2UgZW5kLCBJ 4oCZdmUgc2VlbiBkZXZlbG9wZXJzIHdhbnQgdG8gYWRkIHZhcmlvdXMgcmVzb3VyY2VzIGFzIGNs YWltcyBpbiBvcmRlciB0byBvcHRpbWl6ZSB0aGUgY2xpZW50IGV4cGVyaWVuY2UuIFdoeSBzaG91 bGQgd2UgbWFrZSB0aGUgY2xpZW50IGRvIGFub3RoZXIgcm91bmQgdHJpcCBpZiB3ZSBhbHJlYWR5 IGtub3cgd2hhdCB0aGV5IHdpbGwgYXNrIGZvciBhbmQgd2hhdCB3ZeKAmWxsIHJldHVybj8gVGhp cyBjb21lcyB1cCBwYXJ0aWN1bGFybHkgaW4gc2l0dWF0aW9ucyB3aGVyZSB0aGUgZW5kIHVzZXIg aXMgYXV0aG9yaXppbmcgYSBzcGVjaWZpYyBvcGVyYXRpb24gKGUuZy4sIGEgc2luZ2xlIHBheW1l bnQsIHJldHJpZXZhbCBvZiBhIHNwZWNpZmljIGltYWdlL2RvY3VtZW50KS4NCg0K4oCTDQpBbm5h YmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBEaWNrIEhhcmR0 IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT4NCkRhdGU6IFR1ZXNkYXksIEphbnVhcnkgMjgsIDIwMjAg YXQgOToxMiBBTQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFt YXpvbi5jb20+DQpDYzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiwgS2ltIDxraW1A aWRlbnRpdHlibG9nLmNvbT4sICJ0eGF1dGhAaWV0Zi5vcmciIDx0eGF1dGhAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW1R4YXV0aF0gUXVlc3Rpb25zIG9uIHRoZSBUeEF1dGggY2hhcnRlcg0KDQpU aGFua3MgQW5uYWJlbGxlLiBTY2hlbWEgaGFzIGFsd2F5cyBiZWVuIGRpZmZpY3VsdCBpbiBpZGVu dGl0eS4gV2UgY2FuIGdldCBpdCBtb3JlIHJpZ2h0IHRoaXMgdGltZSwgYnV0IEkgdGhpbmsgdGhl IHJpZ2h0IGV4dGVuc2liaWxpdHkgaXMgaW1wb3J0YW50IHRvIGVuYWJsZSBjb250aW51YWwgaW1w cm92ZW1lbnQuDQoNCkNvbW1lbnRzIGluc2VydGVkIC4uLg0KDQpPbiBUdWUsIEphbiAyOCwgMjAy MCBhdCA5OjAwIEFNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24u Y29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4gd3JvdGU6DQpPSURDIGNsYWltcyBnb3Qg YSBsb3QgcmlnaHQsIGJ1dCB0aGV5IGFyZW7igJl0IHBlcmZlY3QuIEhlcmUgYXJlIGEgZmV3IGlz c3VlcyB3aXRoIHRoZW06DQoNCiAgKiAgIFRoZSBvbmx5IGRlZmluZWQgdmFsdWVzIGZvciBnZW5k ZXIgYXJlIG1hbGUgYW5kIGZlbWFsZS4NCmFncmVlZCDigJQgaW4gZmFpcm5lc3MgdGhlIGF3YXJl bmVzcyBpcyBtdWNoIGdyZWF0ZXIgbm93DQoNCiAgKg0KICAqICAgVGhlIC4uLl9uYW1lIGNsYWlt cyBlbmNvdXJhZ2UgZGVzaWducyB0aGF0IGNhdGVyIHRvIFdlc3Rlcm4gbmFtaW5nIGNvbnZlbnRp b25zLg0KYWdyZWVkDQoNCiAgKg0KICAqICAgVGhlIC4uLl92ZXJpZmllZCBjbGFpbXMgZG9u4oCZ dCBkZWZpbmUgaG93IG9yIHdoZW4gdmVyaWZpY2F0aW9uIG9jY3VycmVkLg0KYWdyZWVkDQoNCiAg Kg0KICAqICAgUG9vciBzdXBwb3J0IGZvciBtdWx0aXBsZSBlbWFpbCBhZGRyZXNzZXMgb3IgcGhv bmUgbnVtYmVycy4NCmhhcyB0aGlzIGJlZW4gYW4gaXNzdWU/DQoNCiAgKg0KICAqICAgTm8gbWVj aGFuaXNtIGZvciBzcGVjaWZ5aW5nIGEgcmVxdWlyZWQgdmFsdWUgZm9yIHBhcnQgb2YgYSBjb21w bGV4IGNsYWltIChlLmcuLCByZXF1aXJpbmcgYW4gYWRkcmVzcyBpbiBhIHBhcnRpY3VsYXIgY291 bnRyeSkuDQppbnRlcmVzdGluZw0KDQogICoNCiAgKiAgIFRoZSBwaWN0dXJlIGNsYWltIGlzIHVu bmVjZXNzYXJpbHkgY29uc3RyYWluZWQgdG8gYmUgYSBwaG90byBvZiB0aGUgZW5kIHVzZXIuDQph Z3JlZWQNCg0KICAqDQogICogICBUaGUgc2VtYW50aWMgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgY2xh aW0gYWJvdXQgYSBzdWJqZWN0IGFuZCByZXNvdXJjZXMgb3duZWQgYnkgYSBzdWJqZWN0IGlzIGxv c3Qgb24gZGV2ZWxvcGVycywgbGVhZGluZyB0byBjdXN0b20gY2xhaW1zIHRoYXQgZG9u4oCZdCBy ZWFsbHkgbWFrZSBzZW5zZSBhcyBjbGFpbXMuDQp3b3VsZCB5b3UgZWxhYm9yYXRlIG9yIHByb3Zp ZGUgZXhhbXBsZXM/DQoNCiAgKg0KT24gSmFuIDI4LCAyMDIwLCBhdCA4OjEyIEFNLCBEaWNrIEhh cmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3 cm90ZToNCldoYXQgZG8geW91IHNlZSBhcyBsYWNraW5nIGluIHRoZSBPSURDIGNsYWltcz8NCg== --_000_036AB02ADE48443EB39A55AF4A11EB90amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0 IDIgNSA4IDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEwMjk2MDE2 OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjA3NTU1MDI3NDt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NDEwMjc3MDA0Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMTgyOTEwNTczMDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxp c3QtaWQ6NTQyMzMzNDI0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMjcwMzU4OTc2O30NCkBs aXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDo3ODQ0NjY5NzU7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi0xNTQ3NjU0MTcyO30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMzpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsNA0KCXttc28tbGlzdC1pZDoxMDk4OTE0ODk0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoz OTYzODYxNDt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0 OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6MTQ0 NTczMTQzMTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIxMjc2ODA5NjA7fQ0KQGxpc3QgbDU6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGw1OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGw2DQoJe21zby1saXN0LWlkOjE3MDUwNTM1NTQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi0yNDg3MTQwNjY7fQ0KQGxpc3QgbDY6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsNjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw2OmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGw2OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2 OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGw2OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3DQoJ e21zby1saXN0LWlkOjIwODc5OTAzMzU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjQ1MjkxMDU0 Njt9DQpAbGlzdCBsNzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDc6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDc6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDc6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRpbmcgbXVsdGlwbGUgZW1haWwgYWRkcmVz c2VzIG9yIHBob25lIG51bWJlcnMgKG9yIGFkZHJlc3Nlcywgd2hpY2ggSSBsZWZ0IG91dCBpbiBt eSBlYXJsaWVyIGVtYWlsKSwgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIHBlb3BsZSBhcmUgYXNrZWQg dG8gcHJvdmlkZSBtdWx0aXBsZSBwaG9uZSBudW1iZXJzIG9yIGVtYWlsIGFkZHJlc3NlcyAoZS5n LiwgcGF0aWVudCBpbnRha2UgZm9ybXMpLiBXaXRoIE9JREMsDQogeW914oCZZCBoYXZlIHRvIGRl ZmluZSBzZXBhcmF0ZSBjbGFpbXMgKGUuZy4sIG1vYmlsZV9waG9uZSwgb2ZmaWNlX3Bob25lKSBh bmQgb2YgY291cnNlIGl04oCZcyBub3QgY2xlYXIgaG93IGp1c3QgcGxhaW4g4oCccGhvbmVfbnVt YmVy4oCdIHdvdWxkIGZpdCBpbiB3aXRoIHRoYXQuIEV2ZW4gaWYgYWxsIHRoZSBjbGllbnQgd2Fu dHMgaXMgb25lIHZhbHVlLCBpdCBjYW4gYmUgaGVscGZ1bCB0byBrbm93IHdoaWNoIG9uZSAoZS5n LiwgYSBtb2JpbGUgYXBwIG5lZWRzDQogYSBtb2JpbGUgcGhvbmUgbnVtYmVyLCBub3QgYSBsYW5k bGluZTsgYSBkaWdpdGFsIG11c2ljIHN0b3JlIG5lZWRzIGEgYmlsbGluZyBhZGRyZXNzLCBidXQg bm90IGEgc2hpcHBpbmcgYWRkcmVzcykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZGlu ZyBjbGFpbXMgdnMuIHJlc291cmNlcywgSeKAmXZlIHNlZW4gZGV2ZWxvcGVycyB3YW50IHRvIHVz ZSBjbGFpbXMgYXMgYSBidWNrZXQgZm9yIGluY2x1ZGluZyBkYXRhIHJlbGF0ZWQgdG8gc2NvcGVz IGluIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3RzLCB3aGVuIHdoYXQgdGhleSByZWFsbHkgbmVlZGVk IHdhcyBSQVIgb3Igc29tZXRoaW5nIGxpa2UgaXQuIEZvciBMb2dpbiB3aXRoIEFtYXpvbiwgd2Ug YWRkZWQNCiBhIHByb3ByaWV0YXJ5IOKAnHNjb3BlX2RhdGHigJ0gcGFyYW1ldGVyIChzaW5jZSBS QVIgZGlkbuKAmXQgZXhpc3QgYXQgdGhlIHRpbWUpLiBPbiB0aGUgcmV2ZXJzZSBlbmQsIEnigJl2 ZSBzZWVuIGRldmVsb3BlcnMgd2FudCB0byBhZGQgdmFyaW91cyByZXNvdXJjZXMgYXMgY2xhaW1z IGluIG9yZGVyIHRvIG9wdGltaXplIHRoZSBjbGllbnQgZXhwZXJpZW5jZS4gV2h5IHNob3VsZCB3 ZSBtYWtlIHRoZSBjbGllbnQgZG8gYW5vdGhlciByb3VuZCB0cmlwIGlmIHdlDQogYWxyZWFkeSBr bm93IHdoYXQgdGhleSB3aWxsIGFzayBmb3IgYW5kIHdoYXQgd2XigJlsbCByZXR1cm4/IFRoaXMg Y29tZXMgdXAgcGFydGljdWxhcmx5IGluIHNpdHVhdGlvbnMgd2hlcmUgdGhlIGVuZCB1c2VyIGlz IGF1dGhvcml6aW5nIGEgc3BlY2lmaWMgb3BlcmF0aW9uIChlLmcuLCBhIHNpbmdsZSBwYXltZW50 LCByZXRyaWV2YWwgb2YgYSBzcGVjaWZpYyBpbWFnZS9kb2N1bWVudCkuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+4oCTPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZy b206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PkRpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5UdWVzZGF5LCBKYW51YXJ5IDI4LCAyMDIwIGF0IDk6MTIgQU08YnI+DQo8Yj5UbzogPC9iPiZx dW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDtyaWNoYW5uYUBhbWF6b24u Y29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+SnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1 Jmd0OywgS2ltICZsdDtraW1AaWRlbnRpdHlibG9nLmNvbSZndDssICZxdW90O3R4YXV0aEBpZXRm Lm9yZyZxdW90OyAmbHQ7dHhhdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5S ZTogW1R4YXV0aF0gUXVlc3Rpb25zIG9uIHRoZSBUeEF1dGggY2hhcnRlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YW5rcyBBbm5hYmVsbGUuIFNjaGVtYSBoYXMgYWx3YXlzIGJlZW4gZGlmZmljdWx0IGluIGlkZW50 aXR5LiBXZSBjYW4gZ2V0IGl0IG1vcmUgcmlnaHQgdGhpcyB0aW1lLCBidXQgSSB0aGluayB0aGUg cmlnaHQgZXh0ZW5zaWJpbGl0eSBpcyBpbXBvcnRhbnQgdG8gZW5hYmxlIGNvbnRpbnVhbCBpbXBy b3ZlbWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Q29tbWVudHMgaW5zZXJ0ZWQgLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEphbiAyOCwgMjAyMCBhdCA5 OjAwIEFNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmlj aGFubmFAYW1hem9uLmNvbSI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9JREMgY2xhaW1zIGdvdCBhIGxv dCByaWdodCwgYnV0IHRoZXkgYXJlbuKAmXQgcGVyZmVjdC4gSGVyZSBhcmUgYSBmZXcmbmJzcDs8 L3NwYW4+aXNzdWVzIHdpdGggdGhlbToNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjx1bCB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDcgbGV2ZWwxIGxmbzEi Pg0KVGhlIG9ubHkgZGVmaW5lZCB2YWx1ZXMgZm9yIGdlbmRlciBhcmUgbWFsZSBhbmQgZmVtYWxl LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFncmVlZCDigJQgaW4gZmFpcm5lc3Mg dGhlIGF3YXJlbmVzcyBpcyBtdWNoIGdyZWF0ZXIgbm93PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjxvOnA+Jm5ic3A7 PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8y Ij4NClRoZSAuLi5fbmFtZSBjbGFpbXMgZW5jb3VyYWdlIGRlc2lnbnMgdGhhdCBjYXRlciB0byBX ZXN0ZXJuIG5hbWluZyBjb252ZW50aW9ucy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5hZ3JlZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDYgbGV2ZWwxIGxmbzMiPg0KPG86cD4mbmJzcDs8L286cD48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDYgbGV2ZWwxIGxmbzMiPg0KVGhlIC4uLl92ZXJpZmllZCBjbGFp bXMgZG9u4oCZdCBkZWZpbmUgaG93IG9yIHdoZW4gdmVyaWZpY2F0aW9uIG9jY3VycmVkLjxvOnA+ PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFncmVlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvNCI+DQo8bzpwPiZuYnNw OzwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZv NCI+DQpQb29yIHN1cHBvcnQgZm9yIG11bHRpcGxlIGVtYWlsIGFkZHJlc3NlcyBvciBwaG9uZSBu dW1iZXJzLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmhhcyB0aGlzIGJlZW4gYW4g aXNzdWU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 Omw1IGxldmVsMSBsZm81Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0Omw1IGxldmVsMSBsZm81Ij4NCk5vIG1lY2hhbmlzbSBmb3Igc3BlY2lm eWluZyBhIHJlcXVpcmVkIHZhbHVlIGZvciBwYXJ0IG9mIGEgY29tcGxleCBjbGFpbSAoZS5nLiwg cmVxdWlyaW5nIGFuIGFkZHJlc3MgaW4gYSBwYXJ0aWN1bGFyIGNvdW50cnkpLjxvOnA+PC9vOnA+ PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmludGVyZXN0aW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm82Ij4NCjxvOnA+Jm5ic3A7 PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm82 Ij4NClRoZSBwaWN0dXJlIGNsYWltIGlzIHVubmVjZXNzYXJpbHkgY29uc3RyYWluZWQgdG8gYmUg YSBwaG90byBvZiB0aGUgZW5kIHVzZXIuPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ YWdyZWVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 Omw0IGxldmVsMSBsZm83Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0Omw0IGxldmVsMSBsZm83Ij4NClRoZSBzZW1hbnRpYyBkaWZmZXJlbmNl IGJldHdlZW4gYSBjbGFpbSBhYm91dCBhIHN1YmplY3QgYW5kIHJlc291cmNlcyBvd25lZCBieSBh IHN1YmplY3QgaXMgbG9zdCBvbiBkZXZlbG9wZXJzLCBsZWFkaW5nIHRvIGN1c3RvbSBjbGFpbXMg dGhhdCBkb27igJl0IHJlYWxseSBtYWtlIHNlbnNlIGFzIGNsYWltcy48bzpwPjwvbzpwPjwvbGk+ PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj53b3VsZCB5b3UgZWxhYm9yYXRlIG9yIHByb3ZpZGUgZXhhbXBsZXM/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxl dmVsMSBsZm84Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiBKYW4gMjgsIDIwMjAsIGF0IDg6MTIg QU0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldoYXQgZG8geW91IHNlZSBhcyBsYWNraW5nIGluIHRoZSBPSURDIGNsYWltcz88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_036AB02ADE48443EB39A55AF4A11EB90amazoncom_-- From nobody Tue Jan 28 12: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 2E1FF12004D for ; Tue, 28 Jan 2020 12:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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, 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 kk-4tLIrEqRN for ; Tue, 28 Jan 2020 12:35:38 -0800 (PST) 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 E1DC31200A3 for ; Tue, 28 Jan 2020 12:35:37 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id q8so11990715ljb.2 for ; Tue, 28 Jan 2020 12:35:37 -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=+Y5K8UsJrhE9ULUOSBuBErzpjoCkvFRl7Nbkced+6/g=; b=Qbyuk8CdNYtCaT9J/ZiXtkjjWYnNLUzwfmJkceabCqRjxGC5HjmiZfWfKL36Qc9G+y dmyuPBW7VjkmCTvpTyRjH2uhNyQQ5Ka8c2NKzmMpSqm1a+qRRWb3z5jCbDkRnOoidyr4 YKJIInw0nzD2NP+j15ObunZTDnk74/NRVSiacnktMxTn0Iu4satoqhK+kwfNiTolrpTq Rak2EMS6jH2N+FPHNE8h3Coh6ozEsCJqAdz83hHVbzERZo7ova9ZO3qeIhMdNCrXidG1 PUTsqV9VfBIVahMj5vgDiFZSArnXR3ySzcqTjBEnFiM71FdduMBvrtMu28IZMt9T67Jz ziog== 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=+Y5K8UsJrhE9ULUOSBuBErzpjoCkvFRl7Nbkced+6/g=; b=WWnVg8PbeV9YFqbHL6cElCVSPMK7u2LacxvW4hf4WQHZLvs4UG/DvJHX8iPkJxwLBn nUYA/s/81gfYFKADVxHv7lLM2JJX3i1hfYsTbhKJYapeviXsBoZztrmV0Jd/ejpjFQ8I a5e8t04X7j2DcP/Hf3mbEf8t+bcSD/yrZPoP1d8Je0/bRN3Rn1a6PL7kPojZ5JhX1pZ7 WYBL1r5hkdFImnOpjc9wf4b6uLftbk6pMexCNHzCNytrIwJyFuoiXu5NJN50pISOpfP0 qpjitNmioEqdnWJgO4Go+BxdU/LWH6dqtGSDyEoHiIn/cVP4PKiBR1tzdC6/tMEfmLKd 4yjg== X-Gm-Message-State: APjAAAUPemY3SUyL94kaBBpUdjrSXMNKOGf8vgzs/KQxFMB1hatHOSYr AbLna65ljiCG/dRI2guxEmeKMKcTamW4A/lkHko78YRc X-Google-Smtp-Source: APXvYqxaUYX3OhP/Hyb51axqmIkikkj8cVs0LtKxZpzgyR4gxQ6MVpO8SFDkB1wkfzLrx1E8/Fhs1qCO70vrtIQsZ5Y= X-Received: by 2002:a2e:808a:: with SMTP id i10mr14331661ljg.151.1580243735818; Tue, 28 Jan 2020 12:35:35 -0800 (PST) MIME-Version: 1.0 References: <4EBBC47D-8EF1-46F2-9623-89070428FA25@mit.edu> <3BA85F10-4D24-4682-BC97-AA8954CA24A5@amazon.com> <036AB02A-DE48-443E-B39A-55AF4A11EB90@amazon.com> In-Reply-To: <036AB02A-DE48-443E-B39A-55AF4A11EB90@amazon.com> From: Dick Hardt Date: Tue, 28 Jan 2020 12:35:24 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: Justin Richer , Kim , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000883811059d392ab5" Archived-At: Subject: Re: [Txauth] Questions on the 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: Tue, 28 Jan 2020 20:35:41 -0000 --000000000000883811059d392ab5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 28, 2020 at 11:47 AM Richard Backman, Annabelle < richanna@amazon.com> wrote: > Regarding multiple email addresses or phone numbers (or addresses, which = I > left out in my earlier email), there are cases where people are asked to > provide multiple phone numbers or email addresses (e.g., patient intake > forms). With OIDC, you=E2=80=99d have to define separate claims (e.g., > mobile_phone, office_phone) and of course it=E2=80=99s not clear how just= plain > =E2=80=9Cphone_number=E2=80=9D would fit in with that. Even if all the cl= ient wants is one > value, it can be helpful to know which one (e.g., a mobile app needs a > mobile phone number, not a landline; a digital music store needs a billin= g > address, but not a shipping address). > I've viewed the value of unverified claims is making it easier for a user form fill at Client. There will often be additional information the Client needs that is fairly Client specific. I worry about the extra complexity that supporting multiple email/phone/address would add to the developer of the AS and the Client, as well as the extra UX for a User to understand at an AS, for an infrequent use case. Additionally, in the consumer space, most OIDC providers usually only have one email or phone. > > > Regarding claims vs. resources, I=E2=80=99ve seen developers want to use = claims as > a bucket for including data related to scopes in authentication requests, > when what they really needed was RAR or something like it. For Login with > Amazon, we added a proprietary =E2=80=9Cscope_data=E2=80=9D parameter (si= nce RAR didn=E2=80=99t > exist at the time). > Sorry, I still don't understand this use case. > On the reverse end, I=E2=80=99ve seen developers want to add various reso= urces as > claims in order to optimize the client experience. > For example? Is what you are describing what is below? > Why should we make the client do another round trip if we already know > what they will ask for and what we=E2=80=99ll return? This comes up parti= cularly in > situations where the end user is authorizing a specific operation (e.g., = a > single payment, retrieval of a specific image/document). > Is this covered by RAR? > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Dick Hardt > *Date: *Tuesday, January 28, 2020 at 9:12 AM > *To: *"Richard Backman, Annabelle" > *Cc: *Justin Richer , Kim , " > txauth@ietf.org" > *Subject: *Re: [Txauth] Questions on the TxAuth charter > > > > Thanks Annabelle. Schema has always been difficult in identity. We can ge= t > it more right this time, but I think the right extensibility is important > to enable continual improvement. > > > > Comments inserted ... > > > > On Tue, Jan 28, 2020 at 9:00 AM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > OIDC claims got a lot right, but they aren=E2=80=99t perfect. Here are a = few issues > with them: > > - The only defined values for gender are male and female. > > agreed =E2=80=94 in fairness the awareness is much greater now > > > - > - The ..._name claims encourage designs that cater to Western naming > conventions. > > agreed > > > - > - The ..._verified claims don=E2=80=99t define how or when verificatio= n > occurred. > > agreed > > > - > - Poor support for multiple email addresses or phone numbers. > > has this been an issue? > > > - > - No mechanism for specifying a required value for part of a complex > claim (e.g., requiring an address in a particular country). > > interesting > > > - > - The picture claim is unnecessarily constrained to be a photo of the > end user. > > agreed > > > - > - The semantic difference between a claim about a subject and > resources owned by a subject is lost on developers, leading to custom > claims that don=E2=80=99t really make sense as claims. > > would you elaborate or provide examples? > > > - > > On Jan 28, 2020, at 8:12 AM, Dick Hardt wrote: > > What do you see as lacking in the OIDC claims? > > =E1=90=A7 --000000000000883811059d392ab5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 28, 2020 at 11:47 AM Rich= ard Backman, Annabelle <richanna@amazon.com> wrote:

Regarding multiple email addresses or phone numbers = (or addresses, which I left out in my earlier email), there are cases where= people are asked to provide multiple phone numbers or email addresses (e.g= ., patient intake forms). With OIDC, you=E2=80=99d have to define separate claims (e.g., mobile_phone, office_p= hone) and of course it=E2=80=99s not clear how just plain =E2=80=9Cphone_nu= mber=E2=80=9D would fit in with that. Even if all the client wants is one v= alue, it can be helpful to know which one (e.g., a mobile app needs a mobile phone number, not a landline; a digital music store needs a billi= ng address, but not a shipping address).

<= br>
I've viewed the value of unverified claims is making it e= asier for a user form fill at Client. There will often be additional inform= ation the Client needs that is fairly Client specific.=C2=A0
I wo= rry about the extra complexity that supporting multiple email/phone/address= would add to the developer of the AS and the Client, as well as the extra = UX for a User to understand at an AS, for an infrequent use case. Additiona= lly, in the consumer space, most OIDC providers usually only have one email= or phone.
=C2=A0

=C2=A0

Regarding claims vs. resources, I=E2=80=99ve seen de= velopers want to use claims as a bucket for including data related to scope= s in authentication requests, when what they really needed was RAR or somet= hing like it. For Login with Amazon, we added a proprietary =E2=80=9Cscope_data=E2=80=9D parameter (since RAR didn=E2=80= =99t exist at the time).


S= orry, I still don't understand this use case.
=C2=A0

On the reverse end, I=E2=80=99ve seen developers want t= o add various resources as claims in order to optimize the client experienc= e.


For example? Is what yo= u are describing what is below?
=C2=A0

Why should we make the client do another round trip if we already know what they will ask for and what we=E2=80=99ll return? This co= mes up particularly in situations where the end user is authorizing a speci= fic operation (e.g., a single payment, retrieval of a specific image/docume= nt).


Is this covered by RAR= ?

=C2=A0

=C2=A0

=E2=80=93

Annabelle Richard Bac= kman

AWS Identity

=C2=A0

=C2=A0

From: = Dick Hardt <dick.hardt@gmail.com>
Date: Tuesday, January 28, 2020 at 9:12 AM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: Justin Richer <jricher@mit.edu>, Kim <kim@identityblog.com>, "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] Questions on the TxAuth charter<= /span>

=C2=A0

Thanks Annabelle. Schema has always been difficult i= n identity. We can get it more right this time, but I think the right exten= sibility is important to enable continual improvement.

=C2=A0

Comments inserted ...

=C2=A0

On Tue, Jan 28, 2020 at 9:00 AM Richard Backman, Ann= abelle <richann= a@amazon.com> wrote:

OIDC claims got a lot ri= ght, but they aren=E2=80=99t perfect. Here are a few=C2=A0issues wit= h them:

  • The only defined values for gender are male and female.
    • <= /ul>

agreed =E2=80=94 in fairness the awareness is much g= reater now

  • =C2=A0
  • The ..._name claims encourage designs that cater to Western naming conventi= ons.

agreed

  • =C2=A0
  • The ..._verified claims don=E2=80=99t define how or when verification occur= red.

agreed

  • =C2=A0
  • Poor support for multiple email addresses or phone numbers.

has this been an issue?

  • =C2=A0
  • No mechanism for specifying a required value for part of a complex claim (e= .g., requiring an address in a particular country).

interesting

  • =C2=A0
  • The picture claim is unnecessarily constrained to be a photo of the end use= r.

agreed

  • =C2=A0
  • The semantic difference between a claim about a subject and resources owned= by a subject is lost on developers, leading to custom claims that don=E2= =80=99t really make sense as claims.

would you elaborate or provide examples?

  • =C2=A0

On Jan 28, 2020, at 8:1= 2 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

What do you see as lacking in the OIDC claims?

3D""= =E1=90=A7
--000000000000883811059d392ab5-- From nobody Tue Jan 28 14:46: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 EC08012006D for ; Tue, 28 Jan 2020 14:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 uQvzl0XCjKhA for ; Tue, 28 Jan 2020 14:46:20 -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 12B5B1200EF for ; Tue, 28 Jan 2020 14:46:19 -0800 (PST) Received: from [100.83.133.69] (static.kpn.net [217.166.240.200] (may be forged)) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00SMk9GC029489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Jan 2020 17:46:10 -0500 From: Justin Richer Message-Id: <8EEEEF6C-305B-4556-B4D3-F25954B4A102@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_D8A28032-D41F-45EE-B4C5-DCC851943444" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 28 Jan 2020 23:46:08 +0100 In-Reply-To: Cc: Matthew De Haast , txauth@ietf.org, "rdd@cert.org" , Yaron Sheffer , Benjamin Kaduk To: Dick Hardt References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XAuth - a revision 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, 28 Jan 2020 22:46:22 -0000 --Apple-Mail=_D8A28032-D41F-45EE-B4C5-DCC851943444 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would not go so far as to call it =E2=80=9Cpretty much the same=E2=80=9D= as there are a number of key differences.=20 But that said, while I disagree with a lot of the details of Dick=E2=80=99= s proposal, I think it=E2=80=99s worthy input to what the group decides = to work on. =E2=80=94 Justin > On Jan 28, 2020, at 8:01 PM, Dick Hardt wrote: >=20 > I intended XAuth to meet the TxAuth Charter. >=20 > The sequence is pretty much the same as the TxAuth ID that Justin = proposed. >=20 > On Tue, Jan 28, 2020 at 10:58 AM Matthew De Haast > wrote: > Hi Dick, >=20 > Can you clarify the relation between this and the TxAuth Charter. Are = you proposing not to charter TXAuth and rather propose xauth as an = extension of Oauth2? Is it an and/or scenario or do you see this being = worked on in conjunction with TxAuth? >=20 > Matt >=20 > On Tue, Jan 28, 2020 at 12:05 AM Dick Hardt > wrote: > Hello! >=20 > I riffed on Justin's draft and have created an alternative that has = the same core concept of secure communication of all parameters between = the Client and the AS. >=20 > https://tools.ietf.org/html/draft-hardt-xauth-protocol-00 = >=20 > A goal of this document was to be as self contained as possible. > Everything needed to implement is included if an implementor is are = already familiar with OAuth 2.0 or OpenID Connect, and wants to migrate = to XAuth.=20 >=20 > To meet that goal, JOSE was chosen as the default mechanism for the = Client to authenticate to the AS, and to perform PoP access to a = resource. The JOSE specific aspects are in one section, so that an = extension can easily specify other Client authentication mechanisms. >=20 > There are likely numerous editorial and syntactical errors, and as we = all know -- naming is hard -- so feel free to suggest better names. >=20 > There are lots of issues with normative language, many of which I am = not aware of yet! >=20 > I've revised the document a number of times, and may have old terms = dangling around. Please let me know if there is something confusing, or = contradictory! >=20 > /Dick >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_D8A28032-D41F-45EE-B4C5-DCC851943444 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = would not go so far as to call it =E2=80=9Cpretty much the same=E2=80=9D = as there are a number of key differences. 

But that said, while I disagree with a = lot of the details of Dick=E2=80=99s proposal, I think it=E2=80=99s = worthy input to what the group decides to work on.

 =E2=80=94 = Justin

On Jan 28, 2020, at 8:01 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:

I intended XAuth to meet the = TxAuth Charter.

The = sequence is pretty much the same as the TxAuth ID that Justin = proposed.

On Tue, Jan 28, 2020 at 10:58 AM = Matthew De Haast <matt@coil.com> wrote:
Hi Dick,

Can you clarify the relation between this and the TxAuth = Charter. Are you proposing not to charter TXAuth and rather propose = xauth as an extension of Oauth2? Is it an and/or scenario or = do you see this being worked on in conjunction with TxAuth?

Matt

On Tue, Jan 28, 2020 at 12:05 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hello!

I riffed on Justin's draft and have created an alternative = that has the same core concept of secure communication of all parameters = between the Client and the AS.

https://tools.ietf.org/html/draft-hardt-xauth-protocol-00

A = goal of this document was to be as self contained as possible.
Everything needed to implement is included if an implementor = is are already familiar with OAuth 2.0 or OpenID Connect, and wants to = migrate to XAuth. 

To meet that goal, JOSE was chosen as the default mechanism = for the Client to authenticate to the AS, and to perform PoP access to a = resource. The JOSE specific aspects are in one section, so that an = extension can easily specify other Client authentication = mechanisms.

There are likely numerous editorial and syntactical errors, = and as we all know -- naming is hard -- so feel free to suggest better = names.

There = are lots of issues with normative language, many of which I am not aware = of yet!

I've = revised the document a number of times, and may have old terms dangling = around. Please let me know if there is something confusing, or = contradictory!

/Dick






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

= --Apple-Mail=_D8A28032-D41F-45EE-B4C5-DCC851943444-- From nobody Tue Jan 28 16:13: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 24FF71200EF for ; Tue, 28 Jan 2020 16:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRzmfh32ideo for ; Tue, 28 Jan 2020 16:13:49 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A161200B7 for ; Tue, 28 Jan 2020 16:13:49 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 00T0Dmva033159 for ; Tue, 28 Jan 2020 19:13:48 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 00T0Dmva033159 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1580256828; bh=6g1TOYJwWpcuDrino2OQJYT8n2UN357RN5lHta/ADXU=; h=From:To:Subject:Date:References:In-Reply-To:From; b=tumdncUH6opOb65w8CYKmrN3cYwb36XF6NDxumxm2vAKQLj6TKLvagjpe5n8JNMCZ RCK4VJ9Lczb3NgbSnloniDxUuSbirQVw7V1+cwO/Uh/CgR00YwB/dX9ET4WgqX8sX3 m+wfhaGl1VuTF9MVtYhOWBlBb5UoT7DEI1CYPqqA= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 00T0Di4V026392 for ; Tue, 28 Jan 2020 19:13:44 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Tue, 28 Jan 2020 19:13:44 -0500 From: Roman Danyliw To: "txauth@ietf.org" Thread-Topic: [Txauth] TxAuth Charter (Take 3.5) Thread-Index: AdXWN/J4UErM8Xu+S0Oa4ahuXDKSvgAAASAQ Date: Wed, 29 Jan 2020 00:13:44 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0216F15F4E@marchand> References: <359EC4B99E040048A7131E0F4E113AFC0216F15F2E@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0216F15F2E@marchand> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 29 Jan 2020 00:13:51 -0000 Hi! > -----Original Message----- > From: TxAuth On Behalf of Justin Richer > Sent: Sat, 18 January 2020 14:15 UTCShow > To: IETF TxAuth > Subject: [Txauth] TxAuth Charter (Take 3.5) >=20 [snip] > I would really appreciate the security AD's weighing in at this stage. Th= anks > again everyone! The Sec ADs have reviewed the charter (as of v3.5) and at a high level beli= eve the scope could use a bit more precision. If there was no prior work, = the situation would be different. However, in this case, relationships wit= h the existing OAuth WG needs to be navigated. Topics that require discuss= ion and clarity include: ** is TxAuth intended to solve all existing OAuth use cases (i.e., is TxAut= h is a superset of OAuth) in a new, non-backward compatible way? If not al= l, which would not be addressed? ** what new use cases would TxAuth address (that aren't in scope for OAuth)= ? ** given a new use case requirement for delegated authorization/identity, w= hat would be the decision process to decide to which WG or WGs it would go? ** notional milestones (not the dates, but the deliverables) In the details of the text: (1) Distinguish what's new (instance #1): OLD: This group is chartered to develop a delegation protocol for authorization,= identity, and API access. NEW: This group is chartered to develop a fine-grained delegation protocol for a= uthorization, identity, and API access. (2) Distinguish what's new (instance #2): OLD: The use cases supported by this protocol will include widely deployed use c= ases currently supported by OAuth 2.0 and OpenID Connect (an extension of O= Auth 2.0) as well as new use cases not enabled by OAuth 2.0. NEW: It will expand upon the uses cases currently supported by OAuth 2.0 and Ope= nID Connect (itself an extension of OAuth 2.0) to support authorizations sc= oped as narrowly as a single transaction, provide a clear framework for int= eraction among all parties involved in the protocol flow, and remove unnece= ssary dependence on a browser or user-agent for coordinating interactions. (3) Style Nit: OLD: Web, mobile, single-page, interaction-constrained, and other types of clien= t applications NEW:=20 A variety of client applications, including Web, mobile, single-page, and i= nteraction-constrained applications (4) Per "Token presentation mechanisms and key bindings", perhaps it might = be clearer to say "Mechanisms for presenting tokens to resource servers and= binding resource requests to cryptographic keys" (5) Per "Mechanisms for providing user, software ...", perhaps it might be = clearer to say "Mechanism for conveying user, software ..." (6) Per "Optimization of information and API access beyond identity through= the delegation process", is this suggesting the need for optimizing access= to TxAuth information for use cases beyond identity? Or the inclusion of i= nformation that isn't identity information into the delegation process? =20 (7) Refine the protocol focus: OLD: While the initial work will focus on using HTTP for communication between t= he client and the authorization server, the working group will seek to take= advantage of optimization features of HTTP2 and HTTP3 where possible, and = will strive to enable simple mapping to other protocols such as COAP. NEW: 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. Regards, Roman and Ben From nobody Tue Jan 28 17: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 95A021200EC for ; Tue, 28 Jan 2020 17:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 QCrPGKPscFjM for ; Tue, 28 Jan 2020 17:13:25 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46AA01200B3 for ; Tue, 28 Jan 2020 17:13:25 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id v201so10584783lfa.11 for ; Tue, 28 Jan 2020 17:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qKXArOjkgght1MCZgfbETIKajPzHhO4znbpPwPMiuzQ=; b=vJ37f8PaL4E31r+KrxQGI3LDYbv5HYx6Ac7XcL+Gn/U36h/k96jC2Qgp9WqlTn2jZX Y12IyW+iEi8cU3Uj1KAWwZmftDQ2xJ7z0hojsxM4VnswJsq/PTGnDSrxLMe6EvcGhoRU ery6JTJSCNIsQwWSdP+vZBocduLy7nfKPg9V29ae9OyLUguk+lmtxEZbIifqlNI00Rcj uKDW+psAb2rIfjhWYigiXu/4k/RFbDhmjp3yr2p0VMfQielqLzJKl8at0uaqmxcw91D2 VcRT0vKR263bPhj0hNI2EwiL35kgSH3C7NZOg4zm6w14CUN7cxuBWFzQXAGX1rWxhNA+ 6xNQ== 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=qKXArOjkgght1MCZgfbETIKajPzHhO4znbpPwPMiuzQ=; b=pq/SEc0kLlNoJCkxaPMQ07Jrudjlu46AtNANSwoNRH7aPbJdca+clH5FIJIuXF2nnq dwAAcjDE7pld1KnXjtEQWI6anC+j0fZL29/cwsSat5Mrz+wa4PXqnb+19V0w6lSiPa9s 5NggTa0ls3rQFfiCYUwC7JkZ9CzFPird3/ANO+M663GNvVLEWYLa9/me2SzFmAB/BGOh medml020T7IzcyUgZ0mJwb/ZT2pOIcDuU2JbHNqRWuohLmkZooV0tfFqHV2hRXW60VQw h9XK5tUdwqtrad5GAeWd+xZzIZTi4s9ILl50EfmdHZ/FPSpyBoViseRBVkkJCjc4pUeE Yyhw== X-Gm-Message-State: APjAAAW6FtkOLGvk3Z3y9ckW1RLUgcN7bYL2paEQGJ2sV4csyWDhGO66 aUB1omobAdotmeUccac1A1YnobxBNCndDZGsckHwBF6syr8= X-Google-Smtp-Source: APXvYqxf8o+vnqlALFq4xrry5uitOWjYj4VV5gQDwfEAZN1AzJpmnFKu/KdblRG5lOPq1l3PUs3STL+jAHekahaFiSc= X-Received: by 2002:a19:7711:: with SMTP id s17mr4009086lfc.164.1580260403303; Tue, 28 Jan 2020 17:13:23 -0800 (PST) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC0216F15F2E@marchand> <359EC4B99E040048A7131E0F4E113AFC0216F15F4E@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0216F15F4E@marchand> From: Dick Hardt Date: Tue, 28 Jan 2020 17:13:11 -0800 Message-ID: To: Roman Danyliw Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fddb4c059d3d0b37" Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 29 Jan 2020 01:13:29 -0000 --000000000000fddb4c059d3d0b37 Content-Type: text/plain; charset="UTF-8" I'll take a stab at answering your questions: The Sec ADs have reviewed the charter (as of v3.5) and at a high level > believe the scope could use a bit more precision. If there was no prior > work, the situation would be different. However, in this case, > relationships with the existing OAuth WG needs to be navigated. Topics > that require discussion and clarity include: > ** is TxAuth intended to solve all existing OAuth use cases (i.e., is > TxAuth is a superset of OAuth) in a new, non-backward compatible way? > Yes. See below for non-backward compatibility. > ** what new use cases would TxAuth address (that aren't in scope for > OAuth)? > All identity claim use cases. A set of these are solved by OpenID Connect, which is an extension to OAuth 2.0. TxAuth would also be a superset of OpenID Connect in addition to OAuth. > ** given a new use case requirement for delegated authorization/identity, > what would be the decision process to decide to which WG or WGs it would go? Identity claim use cases would be in the TxAuth WG, as identity claims are not in the latest OAuth WG charter. Some new authorization use cases will be applicable to both, where there is a desire for the use case to be supported by both protocols. In situations where the same document can be used by both OAuth and TxAuth such as the Rich Authorization Request work, I would suggest it be done in the OAuth WG. Other use cases will require different mechanisms, as the protocols are different, and work will happen in both. *How are OAuth 2.0 and TxAuth different?* OAuth 2.0 uses browser redirects, and query parameters for the Client and Authorization Server to communicate initially, and then the Client makes a form encoded POST to the Authorization Server. Extensions to OAuth 2.0 have added additional parameters, but have been limited by what can be added to a URL redirect, and the name / value pair constraints of a form encoded POST. In contrast, TxAuth uses JSON to encode messages between the Client and the Authorization Server, and the Client starts the the protocol sending a rich JSON message to the Authorization Server. TxAuth is a new protocol. Just as OAuth 2.0 was incompatible with OAuth 1.0, TxAuth is incompatible with OAuth 2.0. If the work was done in the OAuth WG, it would likely be called OAuth 3.0. To do that, the OAuth WG Charter would need to be updated, as identity claims are not in scope. Excerpts from the OAuth WG Charter https://tools.ietf.org/wg/oauth/charters The Web Authorization (OAuth) protocol allows a user to grant a third-party web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. The ongoing standardization efforts within the OAuth working group focus on increasing interoperability of OAuth deployments and to improve security. On Tue, Jan 28, 2020 at 4:13 PM Roman Danyliw wrote: > Hi! > > > -----Original Message----- > > From: TxAuth On Behalf of Justin Richer > > Sent: Sat, 18 January 2020 14:15 UTCShow > > To: IETF TxAuth > > Subject: [Txauth] TxAuth Charter (Take 3.5) > > > > [snip] > > I would really appreciate the security AD's weighing in at this stage. > Thanks > > again everyone! > > The Sec ADs have reviewed the charter (as of v3.5) and at a high level > believe the scope could use a bit more precision. If there was no prior > work, the situation would be different. However, in this case, > relationships with the existing OAuth WG needs to be navigated. Topics > that require discussion and clarity include: > > ** is TxAuth intended to solve all existing OAuth use cases (i.e., is > TxAuth is a superset of OAuth) in a new, non-backward compatible way? If > not all, which would not be addressed? > ** what new use cases would TxAuth address (that aren't in scope for > OAuth)? > ** given a new use case requirement for delegated authorization/identity, > what would be the decision process to decide to which WG or WGs it would go? > ** notional milestones (not the dates, but the deliverables) > > In the details of the text: > > (1) Distinguish what's new (instance #1): > OLD: > This group is chartered to develop a delegation protocol for > authorization, identity, and API access. > > NEW: > This group is chartered to develop a fine-grained delegation protocol for > authorization, identity, and API access. > > (2) Distinguish what's new (instance #2): > OLD: > The use cases supported by this protocol will include widely deployed use > cases currently supported by OAuth 2.0 and OpenID Connect (an extension of > OAuth 2.0) as well as new use cases not enabled by OAuth 2.0. > > NEW: > 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. > > (3) Style Nit: > OLD: > Web, mobile, single-page, interaction-constrained, and other types of > client applications > > NEW: > A variety of client applications, including Web, mobile, single-page, and > interaction-constrained applications > > (4) Per "Token presentation mechanisms and key bindings", perhaps it might > be clearer to say "Mechanisms for presenting tokens to resource servers and > binding resource requests to cryptographic keys" > > (5) Per "Mechanisms for providing user, software ...", perhaps it might be > clearer to say "Mechanism for conveying user, software ..." > > (6) Per "Optimization of information and API access beyond identity > through the delegation process", is this suggesting the need for optimizing > access to TxAuth information for use cases beyond identity? Or the > inclusion of information that isn't identity information into the > delegation process? > > (7) Refine the protocol focus: > OLD: > While the initial work will focus on using HTTP for communication between > the client and the authorization server, the working group will seek to > take advantage of optimization features of HTTP2 and HTTP3 where possible, > and will strive to enable simple mapping to other protocols such as COAP. > > NEW: > 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. > > Regards, > Roman and Ben > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000fddb4c059d3d0b37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0I'll take a stab at answering you= r=C2=A0questions:

The Sec ADs have reviewed the charter (as of v3.5) and at a hi= gh level believe the scope could use a bit more precision.=C2=A0 If there w= as no prior work, the situation would be different.=C2=A0 However, in this = case, relationships with the existing OAuth WG needs to be navigated.=C2=A0= Topics that require discussion and clarity include:
** is TxAuth intend= ed to solve all existing OAuth use cases (i.e., is TxAuth is a superset of = OAuth) in a new, non-backward compatible way?=C2=A0
Yes. See below for non-backward compatibility.
=C2= =A0
** what new = use cases would TxAuth address (that aren't in scope for OAuth)?

All identity claim use cases. A set of these = are solved by OpenID Connect, which is an extension to OAuth 2.0. TxAuth wo= uld also be a superset of OpenID Connect in addition to OAuth.
= =C2=A0
** given a ne= w use case requirement for delegated authorization/identity, what would be = the decision process to decide to which WG or WGs it would go?
=

Identity claim use cases would be in the TxAuth WG= , as identity claims are not in the latest OAuth WG charter.

Some new authorization use cases will be applic= able to both, where there is a desire for the use case to be supported by b= oth protocols. In situations where the same document can be used by both OA= uth and TxAuth such as the Rich Authorization Request work, I would suggest= it be done in the OAuth WG.

Other use cases will = require different mechanisms, as the protocols are different, and work will= happen in both.

How are OAuth 2.0 and TxAuth d= ifferent?

OAuth 2.0 uses browser redirec= ts, and query parameters for the Client and Authorization Server to communi= cate initially, and then the Client makes a form encoded POST to the Author= ization Server.

Extensions to OAuth 2.0 have added= additional parameters, but have been limited by what can be added to a URL= redirect, and the name / value pair constraints of a form encoded POST.

In contrast, TxAuth uses JSON to encode messages bet= ween the Client and the Authorization Server, and the Client starts the the= protocol sending a rich JSON message to the Authorization Server. TxAuth i= s a new protocol.=C2=A0

Just as OAuth 2.0 was inco= mpatible with OAuth 1.0, TxAuth is incompatible with OAuth 2.0. If the work= was done in the OAuth WG, it would likely be called OAuth 3.0. To do that,= the OAuth WG Charter would need to be updated, as identity claims are not = in scope. Excerpts from the OAuth WG Charter=C2=A0https://tools.ietf.org/wg/oauth/charters=C2= =A0

  The Web Authorization (OAuth) protocol allows a user to grant a
  third-party web site or application access to the user's protected
  resources, without necessarily revealing their long-term credentials,
  or even their identity. 
<snip>
 =
 The ongoing standardization efforts within the OAuth working group
  focus on increasing interoperability of OAuth deployments and to
  improve security.


On = Tue, Jan 28, 2020 at 4:13 PM Roman Danyliw <rdd@cert.org> wrote:
Hi!

> -----Original Message-----
> From: TxAuth <txauth-bounces@ietf.org> On Behalf of Justin Richer
> Sent: Sat, 18 January 2020 14:15 UTCShow
> To: IETF TxAuth <txauth@ietf.org>
> Subject: [Txauth] TxAuth Charter (Take 3.5)
>

[snip]
> I would really appreciate the security AD's weighing in at this st= age. Thanks
> again everyone!

The Sec ADs have reviewed the charter (as of v3.5) and at a high level beli= eve the scope could use a bit more precision.=C2=A0 If there was no prior w= ork, the situation would be different.=C2=A0 However, in this case, relatio= nships with the existing OAuth WG needs to be navigated.=C2=A0 Topics that = require discussion and clarity include:

** is TxAuth intended to solve all existing OAuth use cases (i.e., is TxAut= h is a superset of OAuth) in a new, non-backward compatible way?=C2=A0 If n= ot all, which would not be addressed?
** what new use cases would TxAuth address (that aren't in scope for OA= uth)?
** given a new use case requirement for delegated authorization/identity, w= hat would be the decision process to decide to which WG or WGs it would go?=
** notional milestones (not the dates, but the deliverables)

In the details of the text:

(1) Distinguish what's new (instance #1):
OLD:
This group is chartered to develop a delegation protocol for authorization,= identity, and API access.

NEW:
This group is chartered to develop a fine-grained delegation protocol for a= uthorization, identity, and API access.

(2) Distinguish what's new (instance #2):
OLD:
The use cases supported by this protocol will include widely deployed use c= ases currently supported by OAuth 2.0 and OpenID Connect (an extension of O= Auth 2.0) as well as new use cases not enabled by OAuth 2.0.

NEW:
It will expand upon the uses cases currently supported by OAuth 2.0 and Ope= nID Connect (itself an extension of OAuth 2.0) to support authorizations sc= oped as narrowly as a single transaction, provide a clear framework for int= eraction among all parties involved in the protocol flow, and remove unnece= ssary dependence on a browser or user-agent for coordinating interactions.<= br>
(3) Style Nit:
OLD:
Web, mobile, single-page, interaction-constrained, and other types of clien= t applications

NEW:
A variety of client applications, including Web, mobile, single-page, and i= nteraction-constrained applications

(4) Per "Token presentation mechanisms and key bindings", perhaps= it might be clearer to say "Mechanisms for presenting tokens to resou= rce servers and binding resource requests to cryptographic keys"

(5) Per "Mechanisms for providing user, software ...", perhaps it= might be clearer to say "Mechanism for conveying user, software ...&q= uot;

(6) Per "Optimization of information and API access beyond identity th= rough the delegation process", is this suggesting the need for optimiz= ing access to TxAuth information for use cases beyond identity? Or the incl= usion of information that isn't identity information into the delegatio= n process?=C2=A0

(7) Refine the protocol focus:
OLD:
While the initial work will focus on using HTTP for communication between t= he client and the authorization server, the working group will seek to take= advantage of optimization features of HTTP2 and HTTP3 where possible, and = will strive to enable simple mapping to other protocols such as COAP.

NEW:
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.

Regards,
Roman and Ben

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000fddb4c059d3d0b37-- From nobody Tue Jan 28 21:09: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 27AA51201E5 for ; Tue, 28 Jan 2020 21:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 lKmayZys3vW8 for ; Tue, 28 Jan 2020 21:09:08 -0800 (PST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF29120142 for ; Tue, 28 Jan 2020 21:09:08 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id m10so3234076wmc.0 for ; Tue, 28 Jan 2020 21:09:08 -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=3QFHahLCOL0TXfKfoaDKfp/asCisbjlsxOjEA1vlcMc=; b=OnhpjVBXZlDa4uYiMGgW4oeyyzbod/nOHVIdqz7Hq9VlmmrhLhGAgEaSw0pPQ9dm4z LmA3JFFZoY8exhlvy1EG/acmfx1nNi57z2lqW1s68TUkXRHFLxl9oWgizS4VoUdqL9IP Wa/1AUXhod99MUhjIlmQcfL3uMfQhnrm/TpU3/3ZFKMXo8Mw0Caf+M95kF6DmBOvZC7h NXV5XWEITb+/hS776g5Wlaa757mp0ViBHHRYABeAacrS+o276qQ7zjNBda8Sx62GUpim Yu+8ymIVlrmwonXR4x4qR9G01plR94JHJ5IfzAGXcGlgYDhO3E7jqI1zK/dU/3riWvov 8D5A== 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=3QFHahLCOL0TXfKfoaDKfp/asCisbjlsxOjEA1vlcMc=; b=S9gfrbAGwNjHf+22B1U3p8ji9h1cGQdudShBbBlPl1eBasvfzx+j3wkoKmtLiHeAxG lw6F5Ggr6lNaLHSI91hgNUM7hK7+NDdqpoZhJDDQuk0Hvo07dM8OOaSnZX+w5sYtC1lW +5bfenSZErtSJ9om2crBUFF1SC5fZthDzDX2CBfVoDmpJBMh/eMFbAbZdYUNQYRjIk4Z e+auX/Ig4Aq5JA/YAsCfJ3XBrzfbpy+w8c+bKRn4nbQ2Z3u6M0ilqi3ZjPwcv3k+YEAT E/5a0mGT3wMnFbbkNci/t5uABoIaH1LPHe2bFpOXNQdeeXR52NfISMgD0IvtpHkJQHUO qFWQ== X-Gm-Message-State: APjAAAUdaEUH7GkvhkwmGOJHQSOn2M4hkgfNO376V6YWvcF/WxxIssZb CecJdKICP9q1rOuSJtlMfUq9+U1zO2Li/m2w X-Google-Smtp-Source: APXvYqyXFzSEP1qKom6iVRNnTRp2wy7+E5WgKsgDwg4kNMhgwN8kzRg4HiMkccH4IQqoBrABrpSt+g== X-Received: by 2002:a05:600c:21ce:: with SMTP id x14mr8922714wmj.120.1580274545661; Tue, 28 Jan 2020 21:09:05 -0800 (PST) Received: from [192.168.44.74] ([77.247.85.102]) by smtp.gmail.com with ESMTPSA id w13sm1296306wru.38.2020.01.28.21.09.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jan 2020 21:09:05 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-969D22F2-5D81-4D80-9DBB-43ADCB608A62; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Wed, 29 Jan 2020 06:09:03 +0100 Message-Id: <11F2690A-E36E-4877-B2B3-15ECB6812214@lodderstedt.net> References: Cc: Roman Danyliw , "txauth@ietf.org" In-Reply-To: To: Dick Hardt X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 29 Jan 2020 05:09:10 -0000 --Apple-Mail-969D22F2-5D81-4D80-9DBB-43ADCB608A62 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 29.01.2020 um 02:13 schrieb Dick Hardt : >=20 > All identity claim use cases. A set of these are solved by OpenID Connect,= which is an extension to OAuth 2.0. TxAuth would also be a superset of Open= ID Connect in addition to OAuth. Don=E2=80=99t you think this would make TxAuth a bit complicated? What would= be the benefit?= --Apple-Mail-969D22F2-5D81-4D80-9DBB-43ADCB608A62 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBTYw ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDGCA8cwggPDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0 aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAesw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTI5MDUwOTAzWjAv BgkqhkiG9w0BCQQxIgQgIBmHWff3GS9b7ZhCNHsDT0IJscu4DSq7UogV5WEySm4wgb0GCSsGAQQB gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQAb3XWZ aKcJiBKyU7yQ4QKTgQdNU8sDk5VBexY8jmoUheRykijZkmWd3ml8+FGF8jUPMC/42pFHa/qWSV0o fLDF2ZI4UfpBHboErA/JWE0qhKu5tLnr+eGkA8wsN0EDBEoelOf+lrByJ+WwC7ObXGs3Pu7xS5w4 RlRCaO/hZFXBCrGVKqhKLq4xvS7W8u7otxJ6WOIBx+kJL+NHxvFgdFIqlJ8Kn+GRtoTZIML0rCRB TmagWbf5+HI+HItE2xxgt+oHn1O8pISG3h8+IzhNvOMz3BEF2htiVQHdnmWQOgyqgsmIbsO+zUfX TarWvIe9ElXDIWjx0kpC7fry6nK5tDOaAAAAAAAA --Apple-Mail-969D22F2-5D81-4D80-9DBB-43ADCB608A62-- From nobody Tue Jan 28 21: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 1739112022E for ; Tue, 28 Jan 2020 21:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=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 lvPkEIntztDp for ; Tue, 28 Jan 2020 21:13:44 -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 A5DD5120219 for ; Tue, 28 Jan 2020 21:13:43 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id p9so4819424wmc.2 for ; Tue, 28 Jan 2020 21:13:43 -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=ViqDM/iizwnQ7T8b6DBPgLlNIR3iCVhXyH7pnjLi2zM=; b=3s8fYkD/IUkIfC+jqoBb5uA3G91ePZD9SWASfEIe9qHebdVYb7930AsAIpa1jLidSU /K5jEqCKLbel+5xfhc+jAdd9aLhL/3A6w0UXRkMoNQZWhuVxNaJPrDJL2xKPaAdVT6/u D31hHNDDf45QMYO87S5esIngDAv9iu7tHMYs9v3GfIchB1hMt3C4sXH/Y9I0ry7o3rWs mWvcQUF52szwM8NPtQSoBythyjLSChuI/D0eEGVZe3NH669iLSkanx/T+RQiGCCA5fiI 8mBeOCy2s6LqMbxDKTEsafZHYehgRrRqf5EEs+8kEFHsBSGxRkW1psmykOnbndcSPNLl 0RHA== 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=ViqDM/iizwnQ7T8b6DBPgLlNIR3iCVhXyH7pnjLi2zM=; b=mA8fNTUQ7RGf8AMySe8o7ZlimfE2kzCsrg0VX6hQi2FsHhKzgHwTrme92WAyCFhqRK J14pA4R32uQtfA2xrM3f4yNe3UP4PHm3zI2Mzy63Pec3xT7h1m09kgFw4Dkcaehbux6Z w+adDx2GTKNVPYPTaLzEEjsqGcSbvyuGKYa53jTJ9h707nOCMc4UI+0HNcJ6brpTQtsl 2iVIwKrYz7XfThuKxYW2dMJd6DiUsm1xVYBjJGIYF+6+v/7ne3n5bfjK+WDr/VH5U44f xcKBTZPBMQcAzqbA9po+zRRw7Xtyfkqu37kKCLFgP8xcnhUTVK+aBELlLVC6d7+q6ioU bdQQ== X-Gm-Message-State: APjAAAXqxLs4naE1KrEIR5nJz0joBsGlwjEkd/7+TouViwr+j8I69o2O wQHZMUfDvJc8cUiDaVApmdpa21SyiLEAbQVW X-Google-Smtp-Source: APXvYqxx1UxJXahcJpdopaBFG/rTBNPSm3s4irNTsyWU/0A1vscLAGPUVc4tyo5sws4ysCHALdccBA== X-Received: by 2002:a1c:41c4:: with SMTP id o187mr8821766wma.24.1580274822178; Tue, 28 Jan 2020 21:13:42 -0800 (PST) Received: from [192.168.44.74] ([77.247.85.102]) by smtp.gmail.com with ESMTPSA id v5sm1321906wrv.86.2020.01.28.21.13.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jan 2020 21:13:41 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-1409C5AE-5D7E-46A5-BCEB-2CEB6B647548; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Wed, 29 Jan 2020 06:13:39 +0100 Message-Id: References: <3BA85F10-4D24-4682-BC97-AA8954CA24A5@amazon.com> Cc: Dick Hardt , Kim , "txauth@ietf.org" , Justin Richer In-Reply-To: <3BA85F10-4D24-4682-BC97-AA8954CA24A5@amazon.com> To: "Richard Backman, Annabelle" X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [Txauth] Questions on the 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: Wed, 29 Jan 2020 05:13:46 -0000 --Apple-Mail-1409C5AE-5D7E-46A5-BCEB-2CEB6B647548 Content-Type: multipart/alternative; boundary=Apple-Mail-277887CD-B829-475A-A66D-9D6D3BE59826 Content-Transfer-Encoding: 7bit --Apple-Mail-277887CD-B829-475A-A66D-9D6D3BE59826 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle : >=20 > The ..._verified claims don=E2=80=99t define how or when verification occu= rred. Sure, they do. Look at the time and method fields.=20 Since OpenId Connect for Identity Assurance (aka verified_claims) is ongoing= work feel free to contribute. https://openid.net/wg/ekyc-ida/= --Apple-Mail-277887CD-B829-475A-A66D-9D6D3BE59826 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Am 28.01.2020 um 18:00 schrieb Richard Backma= n, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:

The ..._verified claim= s don=E2=80=99t define how or when verification occurred.
=
Sure, they do. Look at the time and method fields. 
=
Since OpenId Connect for Identity Assurance (aka verified_cla= ims) is ongoing work feel free to contribute.

https://openid.net/wg/ekyc-ida/= --Apple-Mail-277887CD-B829-475A-A66D-9D6D3BE59826-- --Apple-Mail-1409C5AE-5D7E-46A5-BCEB-2CEB6B647548 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBTYw ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDGCA8cwggPDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0 aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAesw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTI5MDUxMzM5WjAv BgkqhkiG9w0BCQQxIgQgC1j3eDUWs517qUCOGI0hf1MI0Ru1Ta4Xkh+MBZRUcB0wgb0GCSsGAQQB gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQCDcWc7 HcSw2w3/CUcIk+wCWRkQgm2meJw40lNcCH9EY26RfObL1NRPs6NAmipEDWlDNfU3XTc6bsXHE8wN Lz2/dz7+yVKi5PkWk44dvjJLOymqrTXbT9FxmZE29nJ6A8nmVFI6V6AxbadINOuyVb8n13b/7dUw hXfMkOUhNV39cqEvwuGw1QyRiQUnnvbWPIYITBGqTAvJol/10IelkM74uZkCpFSdpGafsqTqVd7e CKMJorVw02rYbmjL2UXrudmLrFJyyA1Pb+B5Yl/eSFmqvaZloBI7orSky9JkVydCe3Alu2tZvYqc 2GtjeN2htQZ0HGhBtldW8Mw/cuDO+ciEAAAAAAAA --Apple-Mail-1409C5AE-5D7E-46A5-BCEB-2CEB6B647548-- From nobody Tue Jan 28 21:16: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 4F3951201E5 for ; Tue, 28 Jan 2020 21:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mV7o_a2FZQNa for ; Tue, 28 Jan 2020 21:16:08 -0800 (PST) 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 875D312016E for ; Tue, 28 Jan 2020 21:16:07 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id z7so18611083wrl.13 for ; Tue, 28 Jan 2020 21:16:07 -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=h1f0OelhZvxlFhpbSPTyq/hs5XhCFUoFE4JNilQLQbI=; b=3YvEwXf+L6N45+cZeKnKU3xdTFFtkNoS19Vs32raBWSLO7xfeKnOaT8++nARrbILD7 xtrigWzwyt0zf3gt3B/03r98WoFv/JHx+d2S6PUb5HiYmbRnO/zemdulASC1yQT4bQLC D9pxj0cIMrPdsKFwO9cWr9Z+/uc3jPqqdj0GtF9JpJzJAmrccfbvf6fgNdEDy6z0fVHO PpZAfsdprJmDhONGhy4w1rtOG5HP4AjIUBJSFOcF4ZgapuAt6l0wwm1sYELkB9eqWomd DgzypEeVrH6EyvOhU8GNIkz8qEuaf5n8W0e9eRS4SIOMkEQw36zSsTf7FrctQp+uCrVR ULXQ== 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=h1f0OelhZvxlFhpbSPTyq/hs5XhCFUoFE4JNilQLQbI=; b=aGCF5liI+xvVP1DV+MbgZHmBum3PEAluZNX0xFTmNzysiRv7L8JhFD9nT30LO4K8tX fTi+gNGYtF8zjdAd2IhqHUbmIuS+SBJTcnylt/zZoZxGVbIuOKVD0m+rpWzgJ+bDrkkr apD7RYerCWDXZpDk8L8qrujkqKMpzcLJL2IGcx/putDCzrd/fFm+HvooHHrYj72O7jvV +iL367LPndx4awfxbud8ZyHCS9fQIcOvq5VeTh7k9gICvbfQ0c02rouH0qGZvghPa+qO q8dvFJYmqFyqSrOH6j/6GEWJMgCapE3vgOb46n6ijbJmV0e54cDX4yEbOQq4CQuvZwkI gg3A== X-Gm-Message-State: APjAAAUoRZQo8HCk/0SUWiSAtYRlFwSxvHHK3wkvHOi2rFopqLqksnb9 u6sqocV0Y3golIGDkgFo/LIvhWiPip5pIuvw X-Google-Smtp-Source: APXvYqxv66zrncHCVz46ebTVvnxdtBIu/LV90puvD103hANCDPguhtKbhRfygK/pmhIuAawrhW6Frw== X-Received: by 2002:a5d:6406:: with SMTP id z6mr32854022wru.294.1580274965917; Tue, 28 Jan 2020 21:16:05 -0800 (PST) Received: from [192.168.44.74] ([77.247.85.102]) by smtp.gmail.com with ESMTPSA id l7sm1304513wrq.61.2020.01.28.21.16.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jan 2020 21:16:04 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-E1BFC4B1-5264-4222-B22E-9E314F6A32C3; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Wed, 29 Jan 2020 06:16:01 +0100 Message-Id: <463BD43E-27AD-4599-8226-55B753CCCA5E@lodderstedt.net> References: Cc: Justin Richer , Kim , "txauth@ietf.org" In-Reply-To: To: Dick Hardt X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [Txauth] Questions on the 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: Wed, 29 Jan 2020 05:16:13 -0000 --Apple-Mail-E1BFC4B1-5264-4222-B22E-9E314F6A32C3 Content-Type: multipart/alternative; boundary=Apple-Mail-61E0502D-886D-4777-8644-95B2CCC86812 Content-Transfer-Encoding: 7bit --Apple-Mail-61E0502D-886D-4777-8644-95B2CCC86812 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 28.01.2020 um 18:05 schrieb Dick Hardt : >=20 > =EF=BB=BF > Agreed. >=20 > Not having subject be a globally unique identifier, nor defining a concate= nation mechanism has been a developer issue. Do you really think that is the reason people use email addresses? BTW: I have even seen OPs using phone numbers (or hashes thereof) as sub val= ues. I think that=E2=80=99s an issue with knowledge/education. >=20 >> On Tue, Jan 28, 2020 at 8:57 AM Justin Richer wrote: >> The claims in OIDC aren=E2=80=99t just JSON, many of them are JWT payload= elements, which need to be compact so that it could fit better into browser= redirects and places like that. I contend that we are not bound by the same= restrictions, so just like with the SAML translations of =E2=80=9C=E2=80=9D to =E2=80=9Ciss=E2=80=9D we should consider what we really nee= d in the new space even if it=E2=80=99s the same concepts translated over. >>=20 >> We=E2=80=99d be foolish to ignore them, but also nearly as foolish to tak= e them just because they exist and it=E2=80=99s the world we know. For insta= nce, we know that the OIDC separation of issuer and subject into a pair of v= alues is really confusing to developers and leads to people using email addr= ess, username, or other incorrect fields as a universal identifier. There ar= e some things that we got right, though, such as the flat namespace-less JSO= N data model that allows domain extensions. >>=20 >> So just as with anything else in this proposed new work, I am arguing tha= t we should take OIDC claims as an influencing input to be evaluated in the c= ontext of what we=E2=80=99re trying to do. =E2=80=9CWe did it this way in OI= DC=E2=80=9D is not a sufficient argument for its inclusion in TxAuth, and th= erefore I agree that it does not belong anywhere in the charter. But we also= need to look at what we did do in OIDC and figure out how and if it fits as= we=E2=80=99re figuring out solutions. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jan 28, 2020, at 5:11 PM, Dick Hardt wrote: >>>=20 >>> Kim: are you suggesting that supporting OIDC claims be in the charter? >>>=20 >>> While I think that supporting OIDC claims is desirable, I don't think th= at belongs in the charter. >>>=20 >>> Justin: OIDC claims inherently had to be different from SAML as the synt= ax was JSON vs XML. >>>=20 >>> Are you suggesting that a different document format be used than JSON? >>>=20 >>> What do you see as lacking in the OIDC claims? >>>=20 >>> =20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Tue, Jan 28, 2020 at 3:30 AM Justin Richer wrote: >>>> Hi Kim, thanks for the feedback. Answers inline, below. >>>>=20 >>>>>> On Jan 28, 2020, at 1:57 AM, Kim wrote: >>>>>>=20 >>>>>> Dear Justin, >>>>>>=20 >>>>>> The current wording of the draft charter raised questions for me that= others might share. Clarifying these would help those of us not familiar wi= th the work to date. >>>>>>=20 >>>>>> > This group is chartered to develop a delegation protocol for author= ization, identity, and API access. >>>>>>=20 >>>>>> Can you please expand on what you mean by delegation of identity and w= hether that leverages claims and tokens as defined in OpenID Connect? >>>>>>=20 >>>>>=20 >>>>> We would not necessarily be using the exact claims and mechanisms in O= IDC. >>>>>=20 >>>>> > The use cases supported by this protocol will include widely deploye= d use cases currently supported by OAuth 2.0 and OpenID Connect (an extensio= n of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0. >>>>>=20 >>>>> I understand and support the motivations to rework the authorization f= lows.. However, the identity representations in OpenID Connect have already= shown themselves to work well in conveying the identity of the end user. It= seems prudent to avoid the confusion and complexity that would result from i= ntroducing new mechanisms to do the same thing. Will the enhancements to the= authorization leverage what already works and has become a unifying technol= ogy? >>>>>=20 >>>>=20 >>>> And when OIDC was invented, SAML had already been shown to work well in= conveying the identity of an end user. I believe we can make a similar leap= forward here. This is not just a new conveyance mechanism for OIDC, but it w= ill certainly learn from it as OIDC learned from SAML and other things that c= ame before. >>>>=20 >>>>> > This protocol will allow an authorizing party to delegate access to c= lient software through an authorization server=E2=80=A6=20 >>>>>=20 >>>>> > The client and AS will involve the authorizing party as necessary th= rough interaction mechanisms indicated by the protocol.=20 >>>>>=20 >>>>> What is the authorizing party? Is that one of the roles in the protoco= l? Is it the end user? >>>>>=20 >>>>=20 >>>> It=E2=80=99s the OAuth/UMA =E2=80=9CResource Owner=E2=80=9D, which migh= t be the user using the client software and might be someone else that the A= S can contact through other means..=20 >>>>=20 >>>>> > Approval of AS attestation to identity claims >>>>>=20 >>>>> Does this mean that the AS is approving of the claims and conveying th= at approval to another party (and what party would that be)?=20 >>>>>=20 >>>> No, the authorizing party is approving the claims and the AS is conveyi= ng the identity claims and the delegated access token to the client.=20 >>>>=20 >>>>> By identity claims are you leveraging claims as defined in OpenID Conn= ect? >>>>>=20 >>>>=20 >>>> Not necessarily, but they=E2=80=99re on the table as items to consider.= >>>>=20 >>>>> Are the identity claims about the end user =E2=80=93 or other subjects= as well? >>>>>=20 >>>>=20 >>>> Generally speaking yes, though in the multi-user case (CIBA, UMA, and s= ome device-flow use cases today), the claims of the authorizing party are be= ing conveyed to the end user of the client, who might be a different party. T= his is an advanced use case, though, so I see it as something we can enable b= ut not likely to be the most common use case, which is conveying the current= user=E2=80=99s claims to a piece of software that they=E2=80=99re using. >>>>=20 >>>>> > Mechanisms for providing user, software, organization, and other pie= ces of information used in authorization decisions =E2=80=93=20 >>>>>=20 >>>>> Could you elaborate on what information about users would be supplemen= tal to those expressed as claims? Also, would information about software an= d organization be expressed as claims?=20 >>>>>=20 >>>>=20 >>>> How the user logged in today, how the user was proofed when they got th= e account, the status of the client software that was making the request at t= he time, etc. So yes, software and organization could also be represented as= claims, though I can also imagine those being in different data structures.= =20 >>>>> > Optimization of information and API access beyond identity through t= he delegation process >>>>>=20 >>>>> Could you please explain what is meant by this goal and how it relates= to identity? >>>>>=20 >>>>=20 >>>> At its core this isn=E2=80=99t an identity protocol, but a delegation p= rotocol. One of the core things that it can delegate is knowledge of the ide= ntity of the user. This is how OIDC is built on top of OAuth 2, and we=E2=80= =99re looking at repeating that kind of layering but in a more direct way as= possible. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> Thanks! >>>>>=20 >>>>> Kim Cameron >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =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-61E0502D-886D-4777-8644-95B2CCC86812 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Am 28.01.2020 um 18:05 schrieb Dick Hardt <= ;dick.hardt@gmail.com>:

=EF=BB=BF
Agreed.
=

Not having subject be a global= ly unique identifier, nor defining a concatenation mechanism  has been a= developer issue.

Do you really= think that is the reason people use email addresses?

BTW= : I have even seen OPs using phone numbers (or hashes thereof) as sub values= . I think that=E2=80=99s an issue with knowledge/education.

On Tue, Jan 28, 2020 at 8:57 AM Justin Riche= r <jricher@mit.edu> wrote:
The claims in OIDC aren=E2=80=99t j= ust JSON, many of them are JWT payload elements, which need to be compact so= that it could fit better into browser redirects and places like that. I con= tend that we are not bound by the same restrictions, so just like with the S= AML translations of =E2=80=9C<saml:Issuer>=E2=80=9D to =E2=80=9Ciss=E2= =80=9D we should consider what we really need in the new space even if it=E2= =80=99s the same concepts translated over.

We=E2=80=99d b= e foolish to ignore them, but also nearly as foolish to take them just becau= se they exist and it=E2=80=99s the world we know. For instance, we know that= the OIDC separation of issuer and subject into a pair of values is really c= onfusing to developers and leads to people using email address, username, or= other incorrect fields as a universal identifier. There are some things tha= t we got right, though, such as the flat namespace-less JSON data model that= allows domain extensions.

So just as with anything= else in this proposed new work, I am arguing that we should take OIDC claim= s as an influencing input to be evaluated in the context of what we=E2=80=99= re trying to do. =E2=80=9CWe did it this way in OIDC=E2=80=9D is not a suffi= cient argument for its inclusion in TxAuth, and therefore I agree that it do= es not belong anywhere in the charter. But we also need to look at what we d= id do in OIDC and figure out how and if it fits as we=E2=80=99re figuring ou= t solutions.

 =E2=80=94 Justin


Kim: are you suggesting that supporti= ng OIDC claims be in the charter?

While I think that supp= orting OIDC claims is desirable, I don't think that belongs in the charter.<= /div>

Justin: OIDC claims inherently had to be different f= rom SAML as the syntax was JSON vs XML.

Are you sug= gesting that a different document format be used than JSON?

What do you see as lacking in the OIDC claims?

=
 




On Tue, Jan 28,= 2020 at 3:30 AM Justin Richer <jricher@mit.edu> wrote:
Hi Kim, thanks for the feedback. Answers inlin= e, below.

On Jan 28, 2020, at 1:5= 7 AM, Kim <kim@= identityblog.com> wrote:

Dear Ju= stin,

The current wording of the draft charter r= aised questions for me that others might share. Clarifying these would help t= hose of us not familiar with the work to date.

> This group is chartered to develop a delegation protocol for auth= orization, identity, and API access.

Can you pl= ease expand on what you mean by delegation of identity and whether that leve= rages claims and tokens as defined in OpenID Connect?

=

We would not necessarily be using the exact= claims and mechanisms in OIDC.

> The u= se cases supported by this protocol will include widely deployed use cases c= urrently supported by OAuth 2.0 and OpenID Connect (an extension of OAuth 2.= 0) as well as new use cases not enabled by OAuth 2.0.

I understand and support the motivations to rework the authorization f= lows..  However, the identity representations in OpenID Connect have al= ready shown themselves to work well in conveying the identity of the end use= r. It seems prudent to avoid the confusion and complexity that would result f= rom introducing new mechanisms to do the same thing. Will the enhancements t= o the authorization leverage what already works and has become a unifying te= chnology?


And when OI= DC was invented, SAML had already been shown to work well in conveying the i= dentity of an end user. I believe we can make a similar leap forward here. T= his is not just a new conveyance mechanism for OIDC, but it will certainly l= earn from it as OIDC learned from SAML and other things that came before.

> This protocol will allow an authorizing p= arty to delegate access to client software through an authorization server=E2= =80=A6 

> The client= and AS will involve the authorizing party as necessary through interaction m= echanisms indicated by the protocol. =

What is the authorizing party? Is that one of the roles in the prot= ocol?  Is it the end user?


=
It=E2=80=99s the OAuth/UMA =E2=80=9CResource Owner=E2=80=9D, whic= h might be the user using the client software and might be someone else that= the AS can contact through other means.. 

> A= pproval of AS attestation to identity claims

Do= es this mean that the AS is approving of the claims and conveying that appro= val to another party (and what party would that be)? 

<= /div>
No, the authorizing party is approving the claims and= the AS is conveying the identity claims and the delegated access token to t= he client. 

By identity claims are you leve= raging claims as defined in OpenID Connect?


Not necessarily, but they=E2=80=99re on the table as items= to consider.

Are the identity claims about the end us= er =E2=80=93 or other subjects as well?

<= div>
Generally speaking yes, though in the multi-user case (CI= BA, UMA, and some device-flow use cases today), the claims of the authorizin= g party are being conveyed to the end user of the client, who might be a dif= ferent party. This is an advanced use case, though, so I see it as something= we can enable but not likely to be the most common use case, which is conve= ying the current user=E2=80=99s claims to a piece of software that they=E2=80= =99re using.

=

> Mechanisms for providing user, softw= are, organization, and other pieces of information used in authorization dec= isions =E2=80=93 

Could you e= laborate on what information about users would be supplemental to those expr= essed as claims?  Also, would information about software and organizati= on be expressed as claims? 


How the user logged in today, how the user was proo= fed when they got the account, the status of the client software that was ma= king the request at the time, etc. So yes, software and organization could a= lso be represented as claims, though I can also imagine those being in diffe= rent data structures. 

> Optimization of informati= on and API access beyond identity through the delegation process

Could you please explain what is meant by this goal and ho= w it relates to identity?


=
At its core this isn=E2=80=99t an identity protocol, but a delegation p= rotocol. One of the core things that it can delegate is knowledge of the ide= ntity of the user. This is how OIDC is built on top of OAuth 2, and we=E2=80= =99re looking at repeating that kind of layering but in a more direct way as= possible.

 =E2=80=94 Justin

Thanks!

Kim Cameron

 

 

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

--
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-61E0502D-886D-4777-8644-95B2CCC86812-- --Apple-Mail-E1BFC4B1-5264-4222-B22E-9E314F6A32C3 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBTYw ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDGCA8cwggPDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0 aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAesw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTI5MDUxNjAxWjAv BgkqhkiG9w0BCQQxIgQgwRKHPykOivcZLojuVUFtrI2mMM6X62xS2w30xPq6Ue4wgb0GCSsGAQQB gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQDQfrZm gvil2dCJ2nuVNcNGdpyAFPXEkp1WHHtqdlzSw+dxVPF/qS4kZu+/Byhfyudhu54fAVBxEeWkPqTw bYnbQV0Zc/aiHwqgQmGRQLPeazJ7xdH9uLgxHebKi/HiBa1cSQKa5S8atc4N7zUOSi+gf6qO1wZj WnUSJx4uEoR9ypmjEsOj5Pp+pfIZTpKm0KnGMsFTZZnr1im5Fko2h+F4pQstJ3kHGUag8Dxmnj4L KKhnFXdE+9AL8IMarPsoqGL0VRKLLVByacvCwUAKBbh+AvZUOLr9ASdzZi9euxNEvOZIE6MlxHd2 N94h8uvdRirppiP0y9WQXiY92ayu+8A6AAAAAAAA --Apple-Mail-E1BFC4B1-5264-4222-B22E-9E314F6A32C3-- From nobody Tue Jan 28 21:57: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 7B0B51200EF for ; Tue, 28 Jan 2020 21:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 EvMYILGr1XBK for ; Tue, 28 Jan 2020 21:57:34 -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 6CF39120130 for ; Tue, 28 Jan 2020 21:57:33 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id x7so17083751ljc.1 for ; Tue, 28 Jan 2020 21:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r2YbVo4P/KlUlJi3EdZJ1/hf/PfZC0f1w1dphCVeAt8=; b=GIduo3KYTk2oRAoC5nhiSD6To2eqQyeyP+xxTusuebajqLq9ezgc0xwVzrb45sgwBm 5DFO2SQKMl62ibhKA8i+hjdPIPj4bVRNWbQbQYcOkhGaTlK3/WknJ5A0Qn1jf0+j1rcE iYiiDtSpRt5psdupBEctCDLPNWX1nTTS9dCJA1PCOQPPi9VTU7YIVIvr/AR08mDKW/Pi ZiQRvlcxAIGE7NY7MwnvNU8fC5xYRfSM3fhnYY05iKQ6yGZzMjUnxYnmqQ3/Y+nEd9Py +xq18cSIyGiAJUvHxOwj8YeRqb4TTcV9m0BTP7ItEHhoQQ4degyd7m/NX316qqJ80Umz XZ5A== 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=r2YbVo4P/KlUlJi3EdZJ1/hf/PfZC0f1w1dphCVeAt8=; b=hx6c+aLZf/U5O1fgIu5a1no84XYIEPfKzxv+T4657Fwvkpud3q7fK8rT5hdxYOtqo/ pUXlWFpkv/OUAqeThbDAbnmKQEyFXeGIgGm0mmSNWQ4tOTwibM7sT/zZeBOuEgOLvdR4 GoycQpnh1Pg//SN5vKqiWcWFNStmd0t5atpIUzMJpjt/ic7QkLFWS7QYHXr8oVXR9uKk ZRMMvy8WnA/AivlWqa6LJsxjzUbMC3HRt0grAkrxosaGbQIp6g/w/J+Mk6X16KpGRaIu 0pt2zGzIKqirpfAflKaPtKA33kxKfU/YuSNLq1iy+Fj+xjl4T99A7qR+giX7JCZFFVfv UR1A== X-Gm-Message-State: APjAAAUS3mNZA7W+783KaVJyGYhOua42Fcylx7AdJX9sjKnx1P5E3NdE 2wfO3yAtveALnSkEY0OGik7ZOmnxUCyIKy+A9so= X-Google-Smtp-Source: APXvYqxv7A39BW+XZJmN2RoxcsPdNu5Cc0eiC4ANNSYezFDVdL8LvqG/dchJVEoGfrJRhjNTFOHeKHJQgHM5uG/pgco= X-Received: by 2002:a2e:9d89:: with SMTP id c9mr7917641ljj.212.1580277451510; Tue, 28 Jan 2020 21:57:31 -0800 (PST) MIME-Version: 1.0 References: <463BD43E-27AD-4599-8226-55B753CCCA5E@lodderstedt.net> In-Reply-To: <463BD43E-27AD-4599-8226-55B753CCCA5E@lodderstedt.net> From: Dick Hardt Date: Tue, 28 Jan 2020 21:57:20 -0800 Message-ID: To: Torsten Lodderstedt Cc: Justin Richer , Kim , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000024d751059d410464" Archived-At: Subject: Re: [Txauth] Questions on the 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: Wed, 29 Jan 2020 05:57:39 -0000 --00000000000024d751059d410464 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 28, 2020 at 9:16 PM Torsten Lodderstedt wrote: > > > Am 28.01.2020 um 18:05 schrieb Dick Hardt : > > =EF=BB=BF > Agreed. > > Not having subject be a globally unique identifier, nor defining a > concatenation mechanism has been a developer issue. > > > Do you really think that is the reason people use email addresses? > I have heard that from a number of product PMs. Email has its own desirable features, but is a poor identifier as it makes it harder to change. Most sophisticated implementations have some private key, and the id_token ids index to it. > BTW: I have even seen OPs using phone numbers (or hashes thereof) as sub > values. I think that=E2=80=99s an issue with knowledge/education. > > > On Tue, Jan 28, 2020 at 8:57 AM Justin Richer wrote: > >> The claims in OIDC aren=E2=80=99t just JSON, many of them are JWT payloa= d >> elements, which need to be compact so that it could fit better into brow= ser >> redirects and places like that. I contend that we are not bound by the s= ame >> restrictions, so just like with the SAML translations of =E2=80=9C=E2=80=9D to >> =E2=80=9Ciss=E2=80=9D we should consider what we really need in the new = space even if it=E2=80=99s >> the same concepts translated over. >> >> We=E2=80=99d be foolish to ignore them, but also nearly as foolish to ta= ke them >> just because they exist and it=E2=80=99s the world we know. For instance= , we know >> that the OIDC separation of issuer and subject into a pair of values is >> really confusing to developers and leads to people using email address, >> username, or other incorrect fields as a universal identifier. There are >> some things that we got right, though, such as the flat namespace-less J= SON >> data model that allows domain extensions. >> >> So just as with anything else in this proposed new work, I am arguing >> that we should take OIDC claims as an influencing input to be evaluated = in >> the context of what we=E2=80=99re trying to do. =E2=80=9CWe did it this = way in OIDC=E2=80=9D is not >> a sufficient argument for its inclusion in TxAuth, and therefore I agree >> that it does not belong anywhere in the charter. But we also need to loo= k >> at what we did do in OIDC and figure out how and if it fits as we=E2=80= =99re >> figuring out solutions. >> >> =E2=80=94 Justin >> >> On Jan 28, 2020, at 5:11 PM, Dick Hardt wrote: >> >> Kim: are you suggesting that supporting OIDC claims be in the charter? >> >> While I think that supporting OIDC claims is desirable, I don't think >> that belongs in the charter. >> >> Justin: OIDC claims inherently had to be different from SAML as the >> syntax was JSON vs XML. >> >> Are you suggesting that a different document format be used than JSON? >> >> What do you see as lacking in the OIDC claims? >> >> >> >> >> >> >> On Tue, Jan 28, 2020 at 3:30 AM Justin Richer wrote: >> >>> Hi Kim, thanks for the feedback. Answers inline, below. >>> >>> On Jan 28, 2020, at 1:57 AM, Kim wrote: >>> >>> Dear Justin, >>> >>> The current wording of the draft charter raised questions for me that >>> others might share. Clarifying these would help those of us not familia= r >>> with the work to date. >>> >>> > This group is chartered to develop a delegation protocol for >>> authorization, identity, and API access. >>> >>> Can you please expand on what you mean by delegation of identity and >>> whether that leverages claims and tokens as defined in OpenID Connect? >>> >>> >>> We would not necessarily be using the exact claims and mechanisms in >>> OIDC. >>> >>> > The use cases supported by this protocol will include widely deployed >>> use cases currently supported by OAuth 2.0 and OpenID Connect (an exten= sion >>> of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0. >>> >>> I understand and support the motivations to rework the authorization >>> flows.. However, the identity representations in OpenID Connect have >>> already shown themselves to work well in conveying the identity of the = end >>> user. It seems prudent to avoid the confusion and complexity that would >>> result from introducing new mechanisms to do the same thing. Will the >>> enhancements to the authorization leverage what already works and has >>> become a unifying technology? >>> >>> >>> And when OIDC was invented, SAML had already been shown to work well in >>> conveying the identity of an end user. I believe we can make a similar = leap >>> forward here. This is not just a new conveyance mechanism for OIDC, but= it >>> will certainly learn from it as OIDC learned from SAML and other things >>> that came before. >>> >>> > This protocol will allow an authorizing party to delegate access to >>> client software through an authorization server=E2=80=A6 >>> >>> > The client and AS will involve the authorizing party as necessary >>> through interaction mechanisms indicated by the protocol. >>> >>> What is the authorizing party? Is that one of the roles in the >>> protocol? Is it the end user? >>> >>> >>> It=E2=80=99s the OAuth/UMA =E2=80=9CResource Owner=E2=80=9D, which migh= t be the user using the >>> client software and might be someone else that the AS can contact throu= gh >>> other means.. >>> >> >>> > Approval of AS attestation to identity claims >>> >>> Does this mean that the AS is approving of the claims and conveying tha= t >>> approval to another party (and what party would that be)? >>> >>> No, the authorizing party is approving the claims and the AS is >>> conveying the identity claims and the delegated access token to the cli= ent. >>> >>> By identity claims are you leveraging claims as defined in OpenID >>> Connect? >>> >>> >>> Not necessarily, but they=E2=80=99re on the table as items to consider. >>> >>> Are the identity claims about the end user =E2=80=93 or other subjects = as well? >>> >>> >>> Generally speaking yes, though in the multi-user case (CIBA, UMA, and >>> some device-flow use cases today), the claims of the authorizing party = are >>> being conveyed to the end user of the client, who might be a different >>> party. This is an advanced use case, though, so I see it as something w= e >>> can enable but not likely to be the most common use case, which is >>> conveying the current user=E2=80=99s claims to a piece of software that= they=E2=80=99re >>> using. >>> >>> > Mechanisms for providing user, software, organization, and other >>> pieces of information used in authorization decisions =E2=80=93 >>> >>> Could you elaborate on what information about users would be >>> supplemental to those expressed as claims? Also, would information abo= ut >>> software and organization be expressed as claims? >>> >>> >>> How the user logged in today, how the user was proofed when they got th= e >>> account, the status of the client software that was making the request = at >>> the time, etc. So yes, software and organization could also be represen= ted >>> as claims, though I can also imagine those being in different data >>> structures. >>> >>> > Optimization of information and API access beyond identity through th= e >>> delegation process >>> >>> Could you please explain what is meant by this goal and how it relates >>> to identity? >>> >>> >>> At its core this isn=E2=80=99t an identity protocol, but a delegation p= rotocol. >>> One of the core things that it can delegate is knowledge of the identit= y of >>> the user. This is how OIDC is built on top of OAuth 2, and we=E2=80=99r= e looking at >>> repeating that kind of layering but in a more direct way as possible. >>> >>> =E2=80=94 Justin >>> >>> Thanks! >>> >>> Kim Cameron >>> >>> >>> >>> >>> -- >>> 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 > > --00000000000024d751059d410464 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 28, 2020 at 9:16 PM Torsten Lodderstedt <torsten@lodderstedt.net> wro= te:


Am 28.01.2020 = um 18:05 schrieb Dick Hardt <dick.hardt@gmail.com>:

=EF=BB=BF
Agreed.

Not havin= g subject be a globally unique identifier, nor defining a concatenation mec= hanism =C2=A0has been a developer issue.

Do you really think that is the reason people use email addresse= s?

I have h= eard that from a number of product PMs.

Email has its own desirable features, but is a poor identif= ier as it makes it harder to change. Most sophisticated implementations =C2= =A0have some private key, and the id_token ids index to it.

<= br>
BTW: I have even seen OPs using phone numbers (or hashes ther= eof) as sub values. I think that=E2=80=99s an issue with knowledge/educatio= n.

On Tue, Jan 28, 2020= at 8:57 AM Justin Richer <jricher@mit.edu> wrote:
The cl= aims in OIDC aren=E2=80=99t just JSON, many of them are JWT payload element= s, which need to be compact so that it could fit better into browser redire= cts and places like that. I contend that we are not bound by the same restr= ictions, so just like with the SAML translations of =E2=80=9C<saml:Issue= r>=E2=80=9D to =E2=80=9Ciss=E2=80=9D we should consider what we really n= eed in the new space even if it=E2=80=99s the same concepts translated over= .

We=E2=80=99d be foolish to ignore them, but also nearl= y as foolish to take them just because they exist and it=E2=80=99s the worl= d we know. For instance, we know that the OIDC separation of issuer and sub= ject into a pair of values is really confusing to developers and leads to p= eople using email address, username, or other incorrect fields as a univers= al identifier. There are some things that we got right, though, such as the= flat namespace-less JSON data model that allows domain extensions.

So just as with anything else in this proposed new work, = I am arguing that we should take OIDC claims as an influencing input to be = evaluated in the context of what we=E2=80=99re trying to do. =E2=80=9CWe di= d it this way in OIDC=E2=80=9D is not a sufficient argument for its inclusi= on in TxAuth, and therefore I agree that it does not belong anywhere in the= charter. But we also need to look at what we did do in OIDC and figure out= how and if it fits as we=E2=80=99re figuring out solutions.

=C2=A0=E2=80=94 Justin

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

=
Kim: are you suggesting that supporting OIDC claims be in = the charter?

While I think that supporting OIDC claims i= s desirable, I don't think that belongs in the charter.

<= /div>
Justin: OIDC claims inherently had to be different from SAML as t= he syntax was JSON vs XML.

Are you suggesting that= a different document format be used than JSON?

Wh= at do you see as lacking in the OIDC claims?

=C2= =A0




On Tue, Jan 28, 2020= at 3:30 AM Justin Richer <jricher@mit.edu> wrote:
Hi Kim, thanks for the feedback. Answers inline= , below.

On Jan 28, 2020, at 1:5= 7 AM, Kim <kim= @identityblog.com> wrote:

Dear Justin,

The current wording of the dr= aft charter raised questions for me that others might share. Clarifying the= se would help those of us not familiar with the work to date.=

> This group is chartered to develop a delegati= on protocol for authorization, identity, and API access.

Can you please expand on what you mean by delegation of ident= ity and whether that leverages claims and tokens as defined in OpenID Conne= ct?


We would not nec= essarily be using the exact claims and mechanisms in OIDC.

> Th= e use cases supported by this protocol will include widely deployed use cas= es currently supported by OAuth 2.0 and OpenID Connect (an extension of OAu= th 2.0) as well as new use cases not enabled by OAuth 2.0.

I understand and support the motivations to rework the auth= orization flows..=C2=A0 However, the identity representations in OpenID Con= nect have already shown themselves to work well in conveying the identity o= f the end user. It seems prudent to avoid the confusion and complexity that= would result from introducing new mechanisms to do the same thing. Will th= e enhancements to the authorization leverage what already works and has bec= ome a unifying technology?


And when OIDC was invented, SAML had already been shown to work well= in conveying the identity of an end user. I believe we can make a similar = leap forward here. This is not just a new conveyance mechanism for OIDC, bu= t it will certainly learn from it as OIDC learned from SAML and other thing= s that came before.

> This p= rotocol will allow an authorizing party to delegate access to client softwa= re through an authorization server=E2=80=A6=C2=A0

> The client and AS will involve the authorizi= ng party as necessary through interaction mechanisms indicated by the proto= col.=C2=A0

What is the authori= zing party? Is that one of the roles in the protocol?=C2=A0 Is it the end u= ser?


It=E2=80=99s th= e OAuth/UMA =E2=80=9CResource Owner=E2=80=9D, which might be the user using= the client software and might be someone else that the AS can contact thro= ugh other means..=C2=A0
=

> Approv= al of AS attestation to identity claims

Doe= s this mean that the AS is approving of the claims and conveying that appro= val to another party (and what party would that be)?=C2=A0

=
No, the authorizing party is approving the claims a= nd the AS is conveying the identity claims and the delegated access token t= o the client.=C2=A0

By identity claim= s are you leveraging claims as defined in OpenID Connect?

<= /div>

Not necessarily, but they=E2=80=99re on th= e table as items to consider.

=

Are the iden= tity claims about the end user =E2=80=93 or other subjects as well?<= /p>


Generally speaking yes, tho= ugh in the multi-user case (CIBA, UMA, and some device-flow use cases today= ), the claims of the authorizing party are being conveyed to the end user o= f the client, who might be a different party. This is an advanced use case,= though, so I see it as something we can enable but not likely to be the mo= st common use case, which is conveying the current user=E2=80=99s claims to= a piece of software that they=E2=80=99re using.

> Mechanisms for providing user, software, organization, and oth= er pieces of information used in authorization decisions =E2=80=93=C2= =A0

Could you elaborate on what information about users= would be supplemental to those expressed as claims?=C2=A0 Also, would info= rmation about software and organization be expressed as claims?=C2=A0=


How the user= logged in today, how the user was proofed when they got the account, the s= tatus of the client software that was making the request at the time, etc. = So yes, software and organization could also be represented as claims, thou= gh I can also imagine those being in different data structures.=C2=A0
=

<= /span>

> Optimization of information and API access bey= ond identity through the delegation process

Could you please explain what is meant by this goal and how it relates to = identity?


At its cor= e this isn=E2=80=99t an identity protocol, but a delegation protocol. One o= f the core things that it can delegate is knowledge of the identity of the = user. This is how OIDC is built on top of OAuth 2, and we=E2=80=99re lookin= g at repeating that kind of layering but in a more direct way as possible.<= /div>

=C2=A0=E2=80=94 Justin

Thanks!

Kim Cameron

=C2=A0

=C2=A0

--=C2=A0
Txauth mailing list
Txauth@ietf.org<= /a>
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
--00000000000024d751059d410464-- From nobody Tue Jan 28 22:01: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 20A3712009C for ; Tue, 28 Jan 2020 22:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 T0Ce7ThnvyMN for ; Tue, 28 Jan 2020 22:01:34 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D6F1200EF for ; Tue, 28 Jan 2020 22:01:34 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id r19so17154189ljg.3 for ; Tue, 28 Jan 2020 22:01:34 -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=bHoSLks/BlTCqrjkuC/D6xkY07KwkolAdNRghqPBJhc=; b=Sn3j0hkTFGVQtxZlQW4KZy6qfAl14faao7tehwNrFvwzFzhzjbz1uZT93D3ZqRH21j npXUljcOBmDc9uz6etypi7X1+YDf6cLPhdxB4gxlLbDFxzmcZRRmjQlmc+SNlmRe9bQR i5vAEEBgkN3o6zhvoNhf1mntDgeMbhsFIfRp80NuNZ0J/YSGgSdOPSJXJjidullqkQaY Kk5f1Kqx4oNdmcXEYmYVU0WUDIe5nUVkK373DVat5g90wHouhIagiT6RhUISjtDXsD7j nQs336rzaRPsDlyq4Lv6t728wH5YDmZXcDBqecy9WR/xe86MjwWCojmK3+1hwJL0Lm9B NWKQ== 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=bHoSLks/BlTCqrjkuC/D6xkY07KwkolAdNRghqPBJhc=; b=h8qBnMHakZd57J/8O3RmUryrFJS7w/zHhQp1sBiXxfffr14Qhl3TpqgFZMZGAOQ2Ak m3C4SpO7+MsQp7oujhwoV+zRGGXHHMX7q3iln1LgcNMdlmU9H6bqqc1SiHXq/223Rimg M6sG0yvEA4lVYa08S2Fvj0IbFtOf9KW3+5KOYRKqTF5MGDOl34egZ2sRrurDNLypO50E KTItXVgD9gkmcYDMvyl0oiFkT+lzOSvXlyYF2lPsP50F5gTgY2jquhNqQ0mRj5DtgMQr zL40hnc9xRpaVxwu1LQE+lsq/ks/LgcMoPqIWB58+1BmAw4d39FnG19ls+nEobrJUD+x 0ygw== X-Gm-Message-State: APjAAAVVNAt1igNSwV6TmrgIodwOW+snnjNq8oTrSqySmn+SEnRitMHv P6OU0/hBDzJpn6ddfkAokFg+xcPkhf0Bj8vai60= X-Google-Smtp-Source: APXvYqwHN2DqiQifOGbf3FkTPMLxar5JEC7CetnAYncpJdythnII1MWqiSnDZr1MAwzWSMButGRsu+Hn7Lh+X+BjCIU= X-Received: by 2002:a2e:84d0:: with SMTP id q16mr15555636ljh.138.1580277692318; Tue, 28 Jan 2020 22:01:32 -0800 (PST) MIME-Version: 1.0 References: <11F2690A-E36E-4877-B2B3-15ECB6812214@lodderstedt.net> In-Reply-To: <11F2690A-E36E-4877-B2B3-15ECB6812214@lodderstedt.net> From: Dick Hardt Date: Tue, 28 Jan 2020 22:01:20 -0800 Message-ID: To: Torsten Lodderstedt Cc: Roman Danyliw , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007f49dd059d411260" Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 29 Jan 2020 06:01:36 -0000 --0000000000007f49dd059d411260 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 28, 2020 at 9:09 PM Torsten Lodderstedt wrote: > > > > Am 29.01.2020 um 02:13 schrieb Dick Hardt : > > > > All identity claim use cases. A set of these are solved by OpenID > Connect, which is an extension to OAuth 2.0. TxAuth would also be a > superset of OpenID Connect in addition to OAuth. > > Don=E2=80=99t you think this would make TxAuth a bit complicated? What wo= uld be > the benefit? Not any more than today, as many consumer IdPs have both in the same flows, and that is what is in the proposed charter. Having the information all in one document would make it simpler to implement and understand. Did you have chance to look at XAuth Torsten? --0000000000007f49dd059d411260 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 28, 2020 at 9:09 PM Torsten Lodd= erstedt <to= rsten@lodderstedt.net> wrote:
dick.hardt@gmail.com>:
>
> All identity claim use cases. A set of these are solved by OpenID Conn= ect, which is an extension to OAuth 2.0. TxAuth would also be a superset of= OpenID Connect in addition to OAuth.

Don=E2=80=99t you think this would make TxAuth a bit complicated? What woul= d be the benefit?

Not any more than today, as many consumer IdPs have both in the same flows= , and that is what is in the proposed charter.=C2=A0

Having the information all in one document would make it si= mpler to implement and understand.

Did you have ch= ance to look at XAuth Torsten?

--0000000000007f49dd059d411260-- From nobody Tue Jan 28 22:34: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 261CC1201DB for ; Tue, 28 Jan 2020 22:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 lWYdjmM9wr3N for ; Tue, 28 Jan 2020 22:34:43 -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 211DC120142 for ; Tue, 28 Jan 2020 22:34:43 -0800 (PST) Received: from [100.83.133.69] (static.kpn.net [217.166.240.200] (may be forged)) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00T6YI5g015020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jan 2020 01:34:33 -0500 From: Justin Richer Message-Id: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_00031185-91DC-4765-B03B-9265FF150A25" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 29 Jan 2020 07:33:56 +0100 In-Reply-To: Cc: "Richard Backman, Annabelle" , Dick Hardt , Kim , "txauth@ietf.org" To: Torsten Lodderstedt References: <3BA85F10-4D24-4682-BC97-AA8954CA24A5@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Questions on the 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: Wed, 29 Jan 2020 06:34:44 -0000 --Apple-Mail=_00031185-91DC-4765-B03B-9265FF150A25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think the ekyc work is great for what it is, but again we have an = opportunity to take a step beyond it. In my view, we=E2=80=99d be better = off defining a means of specifying field metadata a la NIST IR 8112 as = part of the schema instead of patching the existing OIDC fields. = https://pages.nist.gov/NISTIR-8112/ =E2=80=94 Justin > On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt = wrote: >=20 >=20 >=20 >> Am 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle = : >>=20 >> The ..._verified claims don=E2=80=99t define how or when verification = occurred. >=20 > Sure, they do. Look at the time and method fields.=20 >=20 > Since OpenId Connect for Identity Assurance (aka verified_claims) is = ongoing work feel free to contribute. >=20 > https://openid.net/wg/ekyc-ida/ --Apple-Mail=_00031185-91DC-4765-B03B-9265FF150A25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think the ekyc work is great for what it is, but again we have an = opportunity to take a step beyond it. In my view, we=E2=80=99d be better = off defining a means of specifying field metadata a la NIST IR 8112 as = part of the schema instead of patching the existing OIDC fields. https://pages.nist.gov/NISTIR-8112/

 =E2=80=94 Justin

On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:



Am 28.01.2020 um 18:00 schrieb Richard Backman, = Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:

The ..._verified claims don=E2=80=99= t define how or when verification occurred.

Sure, they do. Look at the time and method = fields. 

Since OpenId Connect for Identity Assurance (aka = verified_claims) is ongoing work feel free to contribute.

https://openid.net/wg/ekyc-ida/

= --Apple-Mail=_00031185-91DC-4765-B03B-9265FF150A25-- From nobody Tue Jan 28 23:04: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 E52F11201DB for ; Tue, 28 Jan 2020 23:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=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 VhFc1tn_8DnG for ; Tue, 28 Jan 2020 23:04:23 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4BBD120142 for ; Tue, 28 Jan 2020 23:04:22 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id t2so18856250wrr.1 for ; Tue, 28 Jan 2020 23:04:22 -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=1SbJmTonTFqR1byt4t4fFwhVNvIp7xKAMIcYUZaFPxU=; b=pV0phzMUyDg+DM4J21JOqtLjw5aLsvVzK9gu5St8px6nY2Hh7goRH4vUiv4T2y6si7 6NXfPh6x4+OzNIOOrepMdf3neAQf9/TgIZgJkjT1ObC/0iMSNGQjslR5le6qJHKWrkyG jE1A2QIKkZG90Q1ALK50Y+YUV+q95JeguQc8dHZMmYZ2/2Oak2bOAQYeGq5a6U9m/ShR xpnUxE8cfY2NjW+zj0M3tIFLiufw9GOZ0y8jA8q8QUkMyUtZkE7sbk70rcSKqk5AxTrX LNqMjc5s3fgh77btuuDsTBzMhtmU4sENG7E28SvWp+20IfuRTyQAzvvgsTOG/rhmtnbB PM/w== 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=1SbJmTonTFqR1byt4t4fFwhVNvIp7xKAMIcYUZaFPxU=; b=Gxhwa1uzds6mOjIPoXKGiePk3/I+pB2GCAYJfT7dXTb0Z0vzzjk7ff6a0/r3OxhCRZ 00SoRkIa4ha+jELnHbf9OOp69gGqic5zeEAjOCqfMdaBdXA1rb30d/GnNG2J+HW6S+Ac fKWzluGXagROer/aNgzXUSJdRar2TF7wc0BEZfizGyfN0dM6NgqxGoeSZh5p6LxAjNTX jO7zje+RZWnMQooiRGcayEmZ8817XKYTGJFieZ2TGCR6D8u6eDa/ucfL5kJ3gHCKMYmZ Bxx8ACNKVBbV5daafZz8zKcgjmeWhG/P73Lhju0wub7FXVviSuzcVW8yBRB9n5kljlWx S8IQ== X-Gm-Message-State: APjAAAVDZMMLbDo0DoFUAIgpJew+YfdARm1d1DigZfZLdQoESlyh8uHq yo2kqeccI4mrPVupWEtFKtOsHw== X-Google-Smtp-Source: APXvYqx8LRpijMYzl0ekGoX2GCIgoI5iy3UVY7jQDtxJrV0QcoCiV/lRdtpyHgr3n/rDdiIpZa2IPQ== X-Received: by 2002:adf:8041:: with SMTP id 59mr32946570wrk.257.1580281461270; Tue, 28 Jan 2020 23:04:21 -0800 (PST) Received: from [192.168.71.107] (p549EEE29.dip0.t-ipconnect.de. [84.158.238.41]) by smtp.gmail.com with ESMTPSA id 124sm1179206wmc.29.2020.01.28.23.04.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jan 2020 23:04:20 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-F1E3D992-0A84-4D3D-8BEC-E1FDE8890F7B; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Wed, 29 Jan 2020 08:04:18 +0100 Message-Id: <7ED74044-CA39-437C-8844-1C16DB3B1EC7@lodderstedt.net> References: Cc: Roman Danyliw , "txauth@ietf.org" In-Reply-To: To: Dick Hardt X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 29 Jan 2020 07:04:25 -0000 --Apple-Mail-F1E3D992-0A84-4D3D-8BEC-E1FDE8890F7B Content-Type: multipart/alternative; boundary=Apple-Mail-67A0060F-16AA-4285-AD06-2C6B17BAFBFC Content-Transfer-Encoding: 7bit --Apple-Mail-67A0060F-16AA-4285-AD06-2C6B17BAFBFC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 29.01.2020 um 07:01 schrieb Dick Hardt : >=20 > =EF=BB=BF >=20 >=20 >> On Tue, Jan 28, 2020 at 9:09 PM Torsten Lodderstedt wrote: >>=20 >>=20 >> > Am 29.01.2020 um 02:13 schrieb Dick Hardt : >> >=20 >> > All identity claim use cases. A set of these are solved by OpenID Conne= ct, which is an extension to OAuth 2.0. TxAuth would also be a superset of O= penID Connect in addition to OAuth. >>=20 >> Don=E2=80=99t you think this would make TxAuth a bit complicated? What wo= uld be the benefit? >=20 > Not any more than today, as many consumer IdPs have both in the same flows= , and that is what is in the proposed charter.=20 >=20 > Having the information all in one document would make it simpler to implem= ent and understand. >=20 I doubt. If i calculate the size of all relevant oauth specs + all relevant o= penid connect specs (including verified claims), that will most likely be a m= ulti 100 pages spec that few people will fully understand and be able to rev= iew/contribute to and fully & correctly implement. Modularity and extensibility is key to success of this initiative. > Did you have chance to look at XAuth Torsten? Not in detail. >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail-67A0060F-16AA-4285-AD06-2C6B17BAFBFC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Am 29.01.2020 um 07:01 schrieb Dick Hardt <= ;dick.hardt@gmail.com>:

=EF=BB=BF


On Tue, Jan 28, 2= 020 at 9:09 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


> Am 29.01.2020 um 02:13 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> All identity claim use cases. A set of these are solved by OpenID Conne= ct, which is an extension to OAuth 2.0. TxAuth would also be a superset of O= penID Connect in addition to OAuth.

Don=E2=80=99t you think this would make TxAuth a bit complicated? What would= be the benefit?

N= ot any more than today, as many consumer IdPs have both in the same flows, a= nd that is what is in the proposed charter. 
Having the information all in one document would make it simpler= to implement and understand.


I doubt. If i calculate the size of all relevant o= auth specs + all relevant openid connect specs (including verified claims), t= hat will most likely be a multi 100 pages spec that few people will fully un= derstand and be able to review/contribute to and fully & correctly imple= ment.

Modularity and extensibility is key to success of t= his initiative.

=
Did you have chance to= look at XAuth Torsten?

<= /div>Not in detail.


--
Txauth mailing list
Txauth@ietf.or= g
https://www.ietf.org/mailman/listinfo/txauth
= --Apple-Mail-67A0060F-16AA-4285-AD06-2C6B17BAFBFC-- --Apple-Mail-F1E3D992-0A84-4D3D-8BEC-E1FDE8890F7B Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBTYw ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDGCA8cwggPDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0 aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAesw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTI5MDcwNDE4WjAv BgkqhkiG9w0BCQQxIgQguOAKmgYxIUlCq5TAqw6P9cV7S9MwC77RwQWL5wc4tMcwgb0GCSsGAQQB gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQBPtP0M n+Ljffk5wrHLCtz9Ko40Jhql5UtHwiHu8WsWxGND26C2Wy2m3az0BDzyErlXoaMozoXgwULGjee+ c9ehdsWQiE+cPDCE6gpTszkea/xw9fNpGVi0F4YLMARoyxwB3lj17zPaMekoYNvOFBtnHL70+N06 YRmomUJKKu6GgEUCSbKPoeCVq/L7MOUbba3+uyViPY5SXfsG9uu27TdDCo0jW+kxcNeHiZd6MSyy 4YuHGWsxADp2RkIl3NWvE6BN9+Zdhi3uHvNNdemlNsOtCmEnCmq3bGzPFvqY1aEKuo3QDyXqA3jt fq6zuOq9BYgT+Zzo/gX2EuqfewPXqVitAAAAAAAA --Apple-Mail-F1E3D992-0A84-4D3D-8BEC-E1FDE8890F7B-- From nobody Tue Jan 28 23:06: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 513A9120219 for ; Tue, 28 Jan 2020 23:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=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 rgXkUI1Ye8P7 for ; Tue, 28 Jan 2020 23:06:28 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975D7120142 for ; Tue, 28 Jan 2020 23:06:28 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id w15so18909172wru.4 for ; Tue, 28 Jan 2020 23:06:28 -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=vwthO1G64vMx4v3ga44SdUsUJ8HLzlvmyZsm559RTOg=; b=oTI7NO+ALLCwFO5ERw5XSqd/0YWXOe+atY7V9IUcZGckT86kRB2FAmHna3LbU8PBSU WrDB023n1uYY7jCR6QCOm9P/JIxP2FSVBwH5VFYLCCiMLkBxcff3CFy/IeSVWcVPYaNT 18FetcODpGSF3wma6InQdq2aQaxwy6lNRL8eTVK8K/sGuwW/Rwp5xse1OBKrCq3G1c9G TktF5Sm1fec2uPkjt1JNi/D6JzFz3eAOJ43xw5Jui9kEOq0qcCMjs07IZWbvtIIo+0Cf icU+cFVR8Cv/cBmzU4Dr6SQpxLcDl5tp1NNjJjtz221WPS/HxZspcuLvt/4ywCFywVRp 8KAQ== 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=vwthO1G64vMx4v3ga44SdUsUJ8HLzlvmyZsm559RTOg=; b=uQ0yLPF7nq53p6DSFCIGpwCGCyAj6b1aiSsqltdEKICrSATvVkDYmr1CSGBidyOUYj U0azg4GnPfU71kWWqrLtaHF+huzSRlbZZOGss+39hIsGYebP/yO2O4yhQzeu0q7xz4Ij BwcgQpm6vZu0KlYGsiAQnON0oU8aAt6mXkPgQnZMZytwhDRKLScLbFFwHbdI6qmbgCS2 c6uzuDYnSHEJCFWpldNSq90hg4WVHQnnBPnmcKSm4emagPqxcvA5IHy4A0+LecB08KWs R+z9KDpKowML/m4YXo7UPkh3FssMvbPNcC0Ug5srHhtS11axfNdrz/fuKXbwFC26Ktd6 jHtw== X-Gm-Message-State: APjAAAWOdkx1k20fariy+oekj+UadV1WoVm4NSafycWMAK4qY/2YKu+i ns6UNDtV8AV17kLrp45genrFY8k9hTXnVz6C X-Google-Smtp-Source: APXvYqxUUlDvQLO9A6t415gE6AOAjn6JdzF3ND/+eRq1JBq4n+2PwyGOU4wKNvrX2cmmIhCj5dS6WA== X-Received: by 2002:a5d:4e0a:: with SMTP id p10mr35676575wrt.229.1580281587020; Tue, 28 Jan 2020 23:06:27 -0800 (PST) Received: from [192.168.71.107] (p549EEE29.dip0.t-ipconnect.de. [84.158.238.41]) by smtp.gmail.com with ESMTPSA id z3sm1604193wrs.94.2020.01.28.23.06.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jan 2020 23:06:25 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-DF81D938-BBD4-4F01-939F-A428B1F1D11D; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Wed, 29 Jan 2020 08:06:24 +0100 Message-Id: <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> Cc: "Richard Backman, Annabelle" , Dick Hardt , Kim , "txauth@ietf.org" In-Reply-To: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> To: Justin Richer X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [Txauth] Questions on the 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: Wed, 29 Jan 2020 07:06:30 -0000 --Apple-Mail-DF81D938-BBD4-4F01-939F-A428B1F1D11D Content-Type: multipart/alternative; boundary=Apple-Mail-270C3065-8538-4632-AB01-493295B9050E Content-Transfer-Encoding: 7bit --Apple-Mail-270C3065-8538-4632-AB01-493295B9050E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 29.01.2020 um 07:34 schrieb Justin Richer : >=20 > =EF=BB=BFI think the ekyc work is great for what it is, but again we have a= n opportunity to take a step beyond it. In my view, we=E2=80=99d be better o= ff defining a means of specifying field metadata a la NIST IR 8112 as part o= f the schema instead of patching the existing OIDC fields. https://pages.nis= t.gov/NISTIR-8112/ We tried and it did not fulfill our requirements. verified_claims is by no m= eans a patch, it=E2=80=99s a viable solution. >=20 > =E2=80=94 Justin >=20 >>> On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt wrote: >>>=20 >>>=20 >>>=20 >>>> Am 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle : >>>>=20 >>> The ..._verified claims don=E2=80=99t define how or when verification oc= curred. >>=20 >> Sure, they do. Look at the time and method fields.=20 >>=20 >> Since OpenId Connect for Identity Assurance (aka verified_claims) is ongo= ing work feel free to contribute. >>=20 >> https://openid.net/wg/ekyc-ida/ >=20 --Apple-Mail-270C3065-8538-4632-AB01-493295B9050E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Am 29.01.2020 um 07:34 schrieb Justin Richer &= lt;jricher@mit.edu>:

=
=EF=BB=BFI think the ekyc work is great for what it is, but ag= ain we have an opportunity to take a step beyond it. In my view, we=E2=80=99= d be better off defining a means of specifying field metadata a la NIST IR 8= 112 as part of the schema instead of patching the existing OIDC fields. = ;https://pages.ni= st.gov/NISTIR-8112/

We tried and it did= not fulfill our requirements. verified_claims is by no means a patch, it=E2= =80=99s a viable solution.


 =E2=80=94 Justi= n

On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt <torsten@lodderstedt.net> w= rote:

<= div dir=3D"auto" class=3D"">


Am 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle <richanna=3D40amazo= n.com@dmarc.ietf.org>:

The ..._v= erified claims don=E2=80=99t define how or when verification occurred.
=

Sure, they do. Look at the time a= nd method fields. 

Since OpenId Connect for Identity Assurance (aka verified_claims) is o= ngoing work feel free to contribute.

ht= tps://openid.net/wg/ekyc-ida/

= --Apple-Mail-270C3065-8538-4632-AB01-493295B9050E-- --Apple-Mail-DF81D938-BBD4-4F01-939F-A428B1F1D11D Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBTYw ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDGCA8cwggPDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0 aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAesw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTI5MDcwNjI0WjAv BgkqhkiG9w0BCQQxIgQg0KANmM/tGot1sVigLJIgDCxk+UiXlKvOcSLFvo5cMzswgb0GCSsGAQQB gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQDOPsmz y7vtgaifGyJBYMaRcfRFBC4qtXPKVwrkmTTlIK9gr84Wn5mwA+/roacYCbTAIpXMyKY6UPLn9mAZ 7dfTH4I7wR9KogRMCDv9LgDkF8ye+qyhkU4A0m1vaNGhEwOXWMoVCkASKP9CJj5EsqRUYa92a1Z1 4BafvPhvP+e4lXx6UWIMO25EVZpO6OqjD3aXEoTk1LipkuFDH33drNb8RI7hRB+AuXb0tCXCLLip cRubiGcqz+QtdYOJxwbDJ6M27g2KIOWvq00CZlG9q24KCaqPFYbilLUpjIJjRmMDDGGB7qCzP//U PYa2j7sO6k4Co1omC/VppLhkdXguuRdoAAAAAAAA --Apple-Mail-DF81D938-BBD4-4F01-939F-A428B1F1D11D-- From nobody Wed Jan 29 00:41: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 E0B79120241 for ; Wed, 29 Jan 2020 00:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 w77-phjvbk_C for ; Wed, 29 Jan 2020 00:41:19 -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 DB06912022D for ; Wed, 29 Jan 2020 00:41:18 -0800 (PST) Received: from [10.38.98.116] ([83.219.75.72]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00T8fB11006615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jan 2020 03:41:13 -0500 From: Justin Richer Message-Id: <73C0643D-F020-4354-9591-EBB05D161669@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_AD850734-7B70-4E97-91FE-F75F51ADF6D7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 29 Jan 2020 09:41:04 +0100 In-Reply-To: <7ED74044-CA39-437C-8844-1C16DB3B1EC7@lodderstedt.net> Cc: Dick Hardt , "rdd@cert.org" , "txauth@ietf.org" To: Torsten Lodderstedt References: <7ED74044-CA39-437C-8844-1C16DB3B1EC7@lodderstedt.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 29 Jan 2020 08:41:21 -0000 --Apple-Mail=_AD850734-7B70-4E97-91FE-F75F51ADF6D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I completely agree that modularity of the documents is key, but keep in = mind that the charter specifies only the total end result and not how = the documents are split up. How we slice things is a key decision that = the working group needs to make. I don=E2=80=99t think we=E2=80=99ll see = everything in in a single document, but I do think we=E2=80=99ll see a = lot more in a =E2=80=9Ccore=E2=80=9D document than is in OAuth 2 today.=20= We aren=E2=80=99t setting out to just mash together OAuth 2 and all of = its extensions, including OIDC =E2=80=94 anything like that would = clearly be suited for the OAuth WG.=20 I think that if we=E2=80=99re careful and deliberate, especially if = we=E2=80=99re not dragging legacy decisions =E2=80=9Cjust because=E2=80=9D= , then we have a chance to make things really work here without getting = overly complex. Much of OIDC=E2=80=99s complexity stems from it adding = functionality to OAuth 2 or overcoming limitations in OAuth 2. A lot of = that can go away if we are building these aspects together from the = start.=20 =E2=80=94 Justin > On Jan 29, 2020, at 8:04 AM, Torsten Lodderstedt = wrote: >=20 >=20 >=20 >> Am 29.01.2020 um 07:01 schrieb Dick Hardt : >>=20 >> =EF=BB=BF >>=20 >>=20 >> On Tue, Jan 28, 2020 at 9:09 PM Torsten Lodderstedt = > wrote: >>=20 >>=20 >> > Am 29.01.2020 um 02:13 schrieb Dick Hardt >: >> >=20 >> > All identity claim use cases. A set of these are solved by OpenID = Connect, which is an extension to OAuth 2.0. TxAuth would also be a = superset of OpenID Connect in addition to OAuth. >>=20 >> Don=E2=80=99t you think this would make TxAuth a bit complicated? = What would be the benefit? >>=20 >> Not any more than today, as many consumer IdPs have both in the same = flows, and that is what is in the proposed charter.=20 >>=20 >> Having the information all in one document would make it simpler to = implement and understand. >>=20 >=20 > I doubt. If i calculate the size of all relevant oauth specs + all = relevant openid connect specs (including verified claims), that will = most likely be a multi 100 pages spec that few people will fully = understand and be able to review/contribute to and fully & correctly = implement. >=20 > Modularity and extensibility is key to success of this initiative. >=20 >> Did you have chance to look at XAuth Torsten? >=20 > Not in detail. >=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=_AD850734-7B70-4E97-91FE-F75F51ADF6D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = completely agree that modularity of the documents is key, but keep in = mind that the charter specifies only the total end result and not how = the documents are split up. How we slice things is a key decision that = the working group needs to make. I don=E2=80=99t think we=E2=80=99ll see = everything in in a single document, but I do think we=E2=80=99ll see a = lot more in a =E2=80=9Ccore=E2=80=9D document than is in OAuth 2 = today. 

We = aren=E2=80=99t setting out to just mash together OAuth 2 and all of its = extensions, including OIDC =E2=80=94 anything like that would clearly be = suited for the OAuth WG. 

I think that if we=E2=80=99re careful = and deliberate, especially if we=E2=80=99re not dragging legacy = decisions =E2=80=9Cjust because=E2=80=9D, then we have a chance to make = things really work here without getting overly complex. Much of OIDC=E2=80= =99s complexity stems from it adding functionality to OAuth 2 or = overcoming limitations in OAuth 2. A lot of that can go away if we are = building these aspects together from the start. 

 =E2=80=94 = Justin

On Jan 29, 2020, at 8:04 AM, Torsten = Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> = wrote:



Am 29.01.2020 um 07:01 = schrieb Dick Hardt <dick.hardt@gmail.com>:

=EF=BB=BF


On Tue, Jan 28, 2020 at 9:09 PM Torsten Lodderstedt = <torsten@lodderstedt.net> wrote:


> Am 29.01.2020 um 02:13 schrieb Dick Hardt = <dick.hardt@gmail.com>:
> 
> All = identity claim use cases. A set of these are solved by OpenID Connect, = which is an extension to OAuth 2.0. TxAuth would also be a superset of = OpenID Connect in addition to OAuth.

Don=E2=80= =99t you think this would make TxAuth a bit complicated? What would be = the benefit?

Not any more than today, = as many consumer IdPs have both in the same flows, and that is what is = in the proposed charter. 

Having the information all in one = document would make it simpler to implement and understand.


I doubt. If i = calculate the size of all relevant oauth specs + all relevant openid = connect specs (including verified claims), that will most likely be a = multi 100 pages spec that few people will fully understand and be able = to review/contribute to and fully & correctly implement.

Modularity and extensibility is key to success of this = initiative.

Did you have chance to look at = XAuth Torsten?

Not in detail.


-- 
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=_AD850734-7B70-4E97-91FE-F75F51ADF6D7-- From nobody Wed Jan 29 00:46: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 E591A120271 for ; Wed, 29 Jan 2020 00:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 6fs-E0VyAOqI for ; Wed, 29 Jan 2020 00:46:37 -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 1D82A120251 for ; Wed, 29 Jan 2020 00:46:37 -0800 (PST) Received: from [10.38.98.116] ([83.219.75.72]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00T8kKwc007603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jan 2020 03:46:29 -0500 From: Justin Richer Message-Id: <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_559A8EB8-2C23-47A4-BEF6-9E9CC39AA46A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 29 Jan 2020 09:46:20 +0100 In-Reply-To: <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> Cc: "Richard Backman, Annabelle" , Dick Hardt , Kim , "txauth@ietf.org" To: Torsten Lodderstedt References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Questions on the 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: Wed, 29 Jan 2020 08:46:39 -0000 --Apple-Mail=_559A8EB8-2C23-47A4-BEF6-9E9CC39AA46A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I didn=E2=80=99t mean =E2=80=9Cpatch=E2=80=9D to sound disparaging, = sorry if it came across as such. What I mean by =E2=80=9Cpatching=E2=80=9D= here is that it is adding functionality to an existing set of claims = and schema. If you are using that schema as a base, it makes sense as a = viable solution in that space. I, however, am bringing up the question = of whether we are using that schema as our base at all. I=E2=80=99ll note that 8112 doesn=E2=80=99t define a schema or syntax, = both of which are required. But if we were starting OIDC today with = EKYC=E2=80=99s requirements, I=E2=80=99m not convinced we=E2=80=99d end = up with the same structure.=20 As with everything, it=E2=80=99s a very important input into what = we=E2=80=99re trying to solve, especially influencing what=E2=80=99s = extensible and how. =E2=80=94 Justin > On Jan 29, 2020, at 8:06 AM, Torsten Lodderstedt = wrote: >=20 >=20 >=20 >> Am 29.01.2020 um 07:34 schrieb Justin Richer : >>=20 >> =EF=BB=BFI think the ekyc work is great for what it is, but again we = have an opportunity to take a step beyond it. In my view, we=E2=80=99d = be better off defining a means of specifying field metadata a la NIST IR = 8112 as part of the schema instead of patching the existing OIDC fields. = https://pages.nist.gov/NISTIR-8112/ = > We tried and it did not fulfill our requirements. verified_claims is = by no means a patch, it=E2=80=99s a viable solution. >=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt = > wrote: >>>=20 >>>=20 >>>=20 >>>> Am 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle = >: >>>>=20 >>>> The ..._verified claims don=E2=80=99t define how or when = verification occurred. >>>=20 >>> Sure, they do. Look at the time and method fields.=20 >>>=20 >>> Since OpenId Connect for Identity Assurance (aka verified_claims) is = ongoing work feel free to contribute. >>>=20 >>> https://openid.net/wg/ekyc-ida/ --Apple-Mail=_559A8EB8-2C23-47A4-BEF6-9E9CC39AA46A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = didn=E2=80=99t mean =E2=80=9Cpatch=E2=80=9D to sound disparaging, sorry = if it came across as such. What I mean by =E2=80=9Cpatching=E2=80=9D = here is that it is adding functionality to an existing set of claims and = schema. If you are using that schema as a base, it makes sense as a = viable solution in that space. I, however, am bringing up the question = of whether we are using that schema as our base at all.
I=E2=80=99ll note that 8112 doesn=E2=80=99= t define a schema or syntax, both of which are required. But if we were = starting OIDC today with EKYC=E2=80=99s requirements, I=E2=80=99m not = convinced we=E2=80=99d end up with the same structure. 

As with everything, = it=E2=80=99s a very important input into what we=E2=80=99re trying to = solve, especially influencing what=E2=80=99s extensible and = how.

 =E2=80= =94 Justin

On Jan 29, 2020, at 8:06 AM, = Torsten Lodderstedt <torsten@lodderstedt.net> wrote:



Am 29.01.2020 um 07:34 schrieb Justin Richer = <jricher@mit.edu>:

=EF=BB=BFI think the ekyc work = is great for what it is, but again we have an opportunity to take a step = beyond it. In my view, we=E2=80=99d be better off defining a means of = specifying field metadata a la NIST IR 8112 as part of the schema = instead of patching the existing OIDC fields. https://pages.nist.gov/NISTIR-8112/

We tried and it did not fulfill our = requirements. verified_claims is by no means a patch, it=E2=80=99s a = viable solution.


 =E2=80=94 Justin

On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:



Am 28.01.2020 um 18:00 schrieb Richard Backman, = Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:

The ..._verified claims don=E2=80=99= t define how or when verification occurred.

Sure, they do. Look at the time and method = fields. 

Since OpenId Connect for Identity Assurance (aka = verified_claims) is ongoing work feel free to contribute.

https://openid.net/wg/ekyc-ida/

<= br class=3D"">= --Apple-Mail=_559A8EB8-2C23-47A4-BEF6-9E9CC39AA46A-- From nobody Wed Jan 29 00:50: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 16EBB120271 for ; Wed, 29 Jan 2020 00:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6bgTyqD4yArW for ; Wed, 29 Jan 2020 00:50:25 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640105.outbound.protection.outlook.com [40.107.64.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9333612026E for ; Wed, 29 Jan 2020 00:50:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hgMHaRSc/VYst0k+zDOKJ680qFXcz5G/kmATw27NluEWEZt0ew/8BMt9GND0iiSZK36X2b/swhCJg95gQLcCp9YXVGshSn7AyekvzpJUDfx84amkoUsMaMFPQBmRTbs8stB+pgxKdsLyuFP88c/dghdVS2GZcwzzIpYbTNCO6KnthxipZNes99OyEpCvlOvGtqTGiJyRD2cFMEP2Vstr/pT77tIaTyg/uH0DdAQjQGPrTzZN3z7eBLYIafEyd7MuGDcsKTtrqgbuS30s0AUnN86JwU7AQjpDh9/K49odkJtdB3JPWfqWyjr06wl7LUx9+sPmejU5AXhGBuj0b1m9nw== 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=HL5K0zW9kEr5ZykeVzml6httvJhVN7IgkoQEFkhnQ+Q=; b=B/p8oeGpmu5cQ6/9lJQ/4GQL8neSW6TjqC63JdT6L4mi8GWS5Q6pUfF2M/bZP8ZXsQYhFgYad0nI6Ik/qaQhV5viGna1K/vcrr6alZCGpc4M7OTeh6vg0R1dcIHfF0rSix5hgn87fHG474Ht5BhOZkAPaF2X9RDJUI6o71m96bMPtUvcsKCEu4ULujn8qbwillwXvHJB1sIJ/WwbxrJUcumgDwfrVvPuRExXq4nTJywbZnWiFVoVfuGJAYuuVpkOtUbgu/n34TT46dD5zmSWErbBcyXfWlrcu41/t1N+rcQsxib2Xnrx1wq7dGFh/f9HWJZtMoI+Y3ab9ITGz6NCMA== 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=HL5K0zW9kEr5ZykeVzml6httvJhVN7IgkoQEFkhnQ+Q=; b=GDcten54RmMoHfjkqmDQDS8dJfLkN7HyoYfm/BMl2BcvuMweW+I5cmsP66JRp4ptTfgl7CJmtywOOFbL7eYpeQ5/IbiCJuXpxjTVrw5quVUuNZfgx+3J6cGNvJh9hqqjtayUJOnCzUSqCYhux0DUPIUylBRNUmucmHOTT9+X4Kw= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (20.180.16.71) by CH2PR00MB0678.namprd00.prod.outlook.com (20.180.6.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2722.0; Wed, 29 Jan 2020 08:50:22 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::e5be:2af2:696e:5cd0]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::e5be:2af2:696e:5cd0%5]) with mapi id 15.20.2725.000; Wed, 29 Jan 2020 08:50:22 +0000 From: Mike Jones To: Justin Richer , Torsten Lodderstedt CC: Kim , Dick Hardt , "txauth@ietf.org" , "Richard Backman, Annabelle" Thread-Topic: [EXTERNAL] Re: [Txauth] Questions on the TxAuth charter Thread-Index: AQHV1fyR3i5snWffhUqUiZ5DATZj8agBGcKAgAAWbgCAAAkSAIAAG+wAgAAAY0A= Date: Wed, 29 Jan 2020 08:50:22 +0000 Message-ID: References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> In-Reply-To: <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> 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=69d4799e-d65f-40eb-ac78-0000a2606667; 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-01-29T08:47:44Z; 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: [83.219.75.72] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 45ebcb38-0608-4f4e-847b-08d7a49846d3 x-ms-traffictypediagnostic: CH2PR00MB0678: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(4636009)(376002)(366004)(39860400002)(136003)(396003)(346002)(189003)(199004)(9686003)(54906003)(6506007)(55016002)(8990500004)(71200400001)(33656002)(26005)(7696005)(110136005)(52536014)(81166006)(8676002)(8936002)(81156014)(186003)(5660300002)(53546011)(2906002)(10290500003)(66446008)(478600001)(86362001)(316002)(66556008)(66476007)(76116006)(966005)(66946007)(64756008)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0678; H:CH2PR00MB0679.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; 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: Q0DzX/NKUvFTRMQGHfQnrXKsghyAmQEGxuMkiiBeXAxWJ8gsRWGQpLdtJl/mJYB5x0L7d16zSBcGVyTVqFrpPu2Yec6dh0eb6lv+Hy5VtGtybQa9m3Dzoa+aAYZiZZ5haOmojQjyUr6UT6Hek7FR57i76beaxVTysH8z7tcz+5TSEzu3ZGJ7thSydynpeh7xEvN/oFq0nQLtVme5m4UtgAKkmUhhcgsaCR5h0asY36C/Z7+ooa1R727ibnZk5wdOCiV9O0G4faoRMszOPAnkUEqu7sLuFcvyVyVNbCAj3/1sTOh1+kuT5DmfDPnwVtKmhROyEQyYboaRnQGmRzMXAYN3XuXuWuouilCxu+Vo5PRtzprQiTZDeuZjnQs/gPlUN8pCCBCTGsDtURxO0dFzumuhPvnsmGZTD8OhQ4WJEL1ewHAaa2bM56YLCq/tqppaH3BlY2EmjAunN8dYSHQanYlH+xh8fIrmrdrQXVRRzBqgs8PphK9kF38pONKlZhK6HqeOz/atqyf5lyYwxD4bZA== x-ms-exchange-antispam-messagedata: rsP5fdaZmGO80aoG60XkBmTqdiRL1mtfkUY96OK1A6sZWwS/G/zpPlt6jLR3+PVvfHF/uWF4SEZZm97UJPv26J8mt78o2GUWdSobjWM68KSlgzWHW+AvoBq28+iFhYq8dlO0TwC2Z8yMuP+nxp3i6g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0679A3CE293D3DAF20A640E2F5050CH2PR00MB0679namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 45ebcb38-0608-4f4e-847b-08d7a49846d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 08:50:22.5520 (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: MNjzSTasbk/F+P919TJM14ZHbu5hD+HbjYZzYu22LJlj65nL8oocjjKGffxXms9AuYt6RxZziHs/hLgMUYhVWQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0678 Archived-At: Subject: Re: [Txauth] [EXTERNAL] Re: Questions on the 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: Wed, 29 Jan 2020 08:50:29 -0000 --_000_CH2PR00MB0679A3CE293D3DAF20A640E2F5050CH2PR00MB0679namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB3cml0aW5nIHRoZXNlIGRldGFpbGVkIHF1ZXN0aW9ucywgS2ltLiAgSSBiZWxp ZXZlIHRoYXQgdGhleSBwb2ludCBvdXQgYSBudW1iZXIgb2YgcGxhY2VzIHdoZXJlIGV2ZW4gZXhw ZXJ0cyBpbiB0aGUgZmllbGQsIHN1Y2ggYXMgeW91cnNlbGYsIGN1cnJlbnRseSBoYXZlIHRyb3Vi bGUgdW5kZXJzdGFuZGluZyBwYXJ0cyBvZiB3aGF0IHRoZSBjaGFydGVyIGlzIHByb3Bvc2luZyB0 aGF0IHdlIGRvIOKAkyBwYXJ0aWFsbHkgYmVjYXVzZSB0ZXJtaW5vbG9neSBpcyB1c2VkIHRoYXQg aXNu4oCZdCBjb21tb25seSB1bmRlcnN0b29kLiAgSSBob3BlIHRoYXQgdGhlIGRyYWZ0IGNoYXJ0 ZXIgd2lsbCBiZSByZXZpc2VkIHRvIG1ha2UgdGhlIGludGVudCBhbmQgdGhlIGdvYWxzIG1vcmUg YWNjZXNzaWJsZSBhbmQgbGVzcyBhbWJpZ3VvdXMuDQoNClJlc3BvbmRpbmcgdG8gdGhlIGRpc2N1 c3Npb24gb24gd2hldGhlciBleGlzdGluZyBKV1QgaWRlbnRpdHkgY2xhaW1zIHdpbGwgZG8gdGhl IGpvYiBvciBub3QsIGZvcnR1bmF0ZWx5LCBldmVuIGlmIHRoZXkgZG9u4oCZdCwgdGhlcmXigJlz IGEgbWVjaGFuaXNtIHRvIGFkZCBvbmVzIHRoYXQgZG86IHRoZSBJQU5BIEpTT04gV2ViIFRva2Vu IENsYWltcyByZWdpc3RyeSBhdCBodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9qd3Qv and0LnhodG1sI2NsYWltcy4gIEZvciBpbnN0YW5jZSwgYW4g4oCcZW1haWxfYWRkcmVzc2Vz4oCd IGNsYWltIHRoYXQgaXMgYXJyYXktdmFsdWVkIGNvdWxkIGJlIGRlZmluZWQgYW5kIHJlZ2lzdGVy ZWQgaWYgdGhlcmXigJlzIGEgbmVlZCB0byByZXByZXNlbnQgbXVsdGlwbGUgZS1tYWlsIGFkZHJl c3NlcywgcGVyIEFubmFiZWxsZeKAmXMgZXhhbXBsZS4gIFRoZSBmdXJ0aGVyIGdvb2QgbmV3cyBp cyB0aGF0IGlmIHRoZSB3b3JraW5nIGdyb3VwIGRlZmluZXMgbmV3IGNsYWltcyB0aGF0IGFyZSBy ZWdpc3RlcmVkLCB0aGV5IGNhbiBiZSByZXVzZWQgYnkgb3RoZXJzIGFsc28gdXNpbmcgSldUcyDi gJMganVzdCBsaWtlIHRoaXMgd29ya2luZyBncm91cCBjYW4gcmV1c2UgY2xhaW1zIGRlZmluZWQg Ynkgb3RoZXJzLg0KDQpBbHNvIG9uIHRoZSBzdWJqZWN0IG9mIEpXVHMsIEkgd291bGQgc3VnZ2Vz dCB0aGF0IHRoZSBjaGFydGVyIGJlIHVwZGF0ZWQgdG8gZXhwbGljaXRseSBjYWxsIG91dCB0aGF0 IEpXVHMgd2lsbCBiZSB0aGUgd29ya2luZyBncm91cOKAmXMgcHJlZmVycmVkIHJlcHJlc2VudGF0 aW9uIHNpZ25lZCBhbmQvb3IgZW5jcnlwdGVkIGNsYWltcy4NCg0KRmluYWxseSwgSSBhbHNvIHRo aW5rIHRoYXQgdGhlIGNoYXJ0ZXIgd291bGQgYmVuZWZpdCBmcm9tIGV4cGxpY2l0bHkgbGlzdGlu ZyB0aGluZ3MgdGhhdCBhcmUgb3V0IG9mIHNjb3BlICh3aGljaCBpcyBvZnRlbiBkb25lIGluIGNo YXJ0ZXJzKS4NCg0KVGhhbmtzIGFnYWluIGZvciBwcm9tcHRpbmcgdGhpcyB1c2VmdWwgZGlzY3Vz c2lvbiwgS2ltLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBUeGF1dGggPHR4YXV0aC1ib3VuY2VzQGlldGYu b3JnPiBPbiBCZWhhbGYgT2YgSnVzdGluIFJpY2hlcg0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5 IDI5LCAyMDIwIDEyOjQ2IEFNDQpUbzogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2Rk ZXJzdGVkdC5uZXQ+DQpDYzogS2ltIDxraW1AaWRlbnRpdHlibG9nLmNvbT47IERpY2sgSGFyZHQg PGRpY2suaGFyZHRAZ21haWwuY29tPjsgdHhhdXRoQGlldGYub3JnOyBSaWNoYXJkIEJhY2ttYW4s IEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPg0KU3ViamVj dDogW0VYVEVSTkFMXSBSZTogW1R4YXV0aF0gUXVlc3Rpb25zIG9uIHRoZSBUeEF1dGggY2hhcnRl cg0KDQpJIGRpZG7igJl0IG1lYW4g4oCccGF0Y2jigJ0gdG8gc291bmQgZGlzcGFyYWdpbmcsIHNv cnJ5IGlmIGl0IGNhbWUgYWNyb3NzIGFzIHN1Y2guIFdoYXQgSSBtZWFuIGJ5IOKAnHBhdGNoaW5n 4oCdIGhlcmUgaXMgdGhhdCBpdCBpcyBhZGRpbmcgZnVuY3Rpb25hbGl0eSB0byBhbiBleGlzdGlu ZyBzZXQgb2YgY2xhaW1zIGFuZCBzY2hlbWEuIElmIHlvdSBhcmUgdXNpbmcgdGhhdCBzY2hlbWEg YXMgYSBiYXNlLCBpdCBtYWtlcyBzZW5zZSBhcyBhIHZpYWJsZSBzb2x1dGlvbiBpbiB0aGF0IHNw YWNlLiBJLCBob3dldmVyLCBhbSBicmluZ2luZyB1cCB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciB3 ZSBhcmUgdXNpbmcgdGhhdCBzY2hlbWEgYXMgb3VyIGJhc2UgYXQgYWxsLg0KDQpJ4oCZbGwgbm90 ZSB0aGF0IDgxMTIgZG9lc27igJl0IGRlZmluZSBhIHNjaGVtYSBvciBzeW50YXgsIGJvdGggb2Yg d2hpY2ggYXJlIHJlcXVpcmVkLiBCdXQgaWYgd2Ugd2VyZSBzdGFydGluZyBPSURDIHRvZGF5IHdp dGggRUtZQ+KAmXMgcmVxdWlyZW1lbnRzLCBJ4oCZbSBub3QgY29udmluY2VkIHdl4oCZZCBlbmQg dXAgd2l0aCB0aGUgc2FtZSBzdHJ1Y3R1cmUuDQoNCkFzIHdpdGggZXZlcnl0aGluZywgaXTigJlz IGEgdmVyeSBpbXBvcnRhbnQgaW5wdXQgaW50byB3aGF0IHdl4oCZcmUgdHJ5aW5nIHRvIHNvbHZl LCBlc3BlY2lhbGx5IGluZmx1ZW5jaW5nIHdoYXTigJlzIGV4dGVuc2libGUgYW5kIGhvdy4NCg0K IOKAlCBKdXN0aW4NCg0KDQpPbiBKYW4gMjksIDIwMjAsIGF0IDg6MDYgQU0sIFRvcnN0ZW4gTG9k ZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldD4+IHdyb3RlOg0KDQoNCg0KDQpBbSAyOS4wMS4yMDIwIHVtIDA3OjM0IHNjaHJpZWIg SnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PjoN Cu+7v0kgdGhpbmsgdGhlIGVreWMgd29yayBpcyBncmVhdCBmb3Igd2hhdCBpdCBpcywgYnV0IGFn YWluIHdlIGhhdmUgYW4gb3Bwb3J0dW5pdHkgdG8gdGFrZSBhIHN0ZXAgYmV5b25kIGl0LiBJbiBt eSB2aWV3LCB3ZeKAmWQgYmUgYmV0dGVyIG9mZiBkZWZpbmluZyBhIG1lYW5zIG9mIHNwZWNpZnlp bmcgZmllbGQgbWV0YWRhdGEgYSBsYSBOSVNUIElSIDgxMTIgYXMgcGFydCBvZiB0aGUgc2NoZW1h IGluc3RlYWQgb2YgcGF0Y2hpbmcgdGhlIGV4aXN0aW5nIE9JREMgZmllbGRzLiBodHRwczovL3Bh Z2VzLm5pc3QuZ292L05JU1RJUi04MTEyLzxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZwYWdlcy5uaXN0LmdvdiUyRk5JU1RJ Ui04MTEyJTJGJmRhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdD OWZhZTUwMzY2OWY0NDNhMDk2ODMwOGQ3YTQ5N2M0NWYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTU4ODQ0MDQ5MzM4MzQ0JnNkYXRhPXJPckthTzdNdkRE S0x5ZkIyUWl2YlZUY2o1RW1SU0oxblJYWHMzMGpFejAlM0QmcmVzZXJ2ZWQ9MD4NCg0KV2UgdHJp ZWQgYW5kIGl0IGRpZCBub3QgZnVsZmlsbCBvdXIgcmVxdWlyZW1lbnRzLiB2ZXJpZmllZF9jbGFp bXMgaXMgYnkgbm8gbWVhbnMgYSBwYXRjaCwgaXTigJlzIGEgdmlhYmxlIHNvbHV0aW9uLg0KDQoN Cg0KIOKAlCBKdXN0aW4NCg0KDQpPbiBKYW4gMjksIDIwMjAsIGF0IDY6MTMgQU0sIFRvcnN0ZW4g TG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldD4+IHdyb3RlOg0KDQoNCg0KDQpBbSAyOC4wMS4yMDIwIHVtIDE4OjAwIHNjaHJp ZWIgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFy Yy5pZXRmLm9yZzxtYWlsdG86cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPj46 DQpUaGUgLi4uX3ZlcmlmaWVkIGNsYWltcyBkb27igJl0IGRlZmluZSBob3cgb3Igd2hlbiB2ZXJp ZmljYXRpb24gb2NjdXJyZWQuDQoNClN1cmUsIHRoZXkgZG8uIExvb2sgYXQgdGhlIHRpbWUgYW5k IG1ldGhvZCBmaWVsZHMuDQoNClNpbmNlIE9wZW5JZCBDb25uZWN0IGZvciBJZGVudGl0eSBBc3N1 cmFuY2UgKGFrYSB2ZXJpZmllZF9jbGFpbXMpIGlzIG9uZ29pbmcgd29yayBmZWVsIGZyZWUgdG8g Y29udHJpYnV0ZS4NCg0KaHR0cHM6Ly9vcGVuaWQubmV0L3dnL2VreWMtaWRhLzxodHRwczovL25h bTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZv cGVuaWQubmV0JTJGd2clMkZla3ljLWlkYSUyRiZkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVz JTQwbWljcm9zb2Z0LmNvbSU3QzlmYWU1MDM2NjlmNDQzYTA5NjgzMDhkN2E0OTdjNDVmJTdDNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE1ODg0NDA0OTMzODM0 NCZzZGF0YT1wZzh1cHd5TiUyQlhLZWFGWmFLRXZSJTJCVEVQc0tnamVKdGRId1BNMWZlJTJGeG5j JTNEJnJlc2VydmVkPTA+DQoNCg0K --_000_CH2PR00MB0679A3CE293D3DAF20A640E2F5050CH2PR00MB0679namp_ 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 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPlRoYW5rcyBmb3Igd3JpdGluZyB0aGVzZSBkZXRhaWxlZCBxdWVzdGlvbnMs IEtpbS4mbmJzcDsgSSBiZWxpZXZlIHRoYXQgdGhleSBwb2ludCBvdXQgYSBudW1iZXIgb2YgcGxh Y2VzIHdoZXJlIGV2ZW4gZXhwZXJ0cyBpbiB0aGUgZmllbGQsIHN1Y2ggYXMgeW91cnNlbGYsIGN1 cnJlbnRseSBoYXZlIHRyb3VibGUgdW5kZXJzdGFuZGluZyBwYXJ0cyBvZiB3aGF0IHRoZSBjaGFy dGVyDQogaXMgcHJvcG9zaW5nIHRoYXQgd2UgZG8g4oCTIHBhcnRpYWxseSBiZWNhdXNlIHRlcm1p bm9sb2d5IGlzIHVzZWQgdGhhdCBpc27igJl0IGNvbW1vbmx5IHVuZGVyc3Rvb2QuJm5ic3A7IEkg aG9wZSB0aGF0IHRoZSBkcmFmdCBjaGFydGVyIHdpbGwgYmUgcmV2aXNlZCB0byBtYWtlIHRoZSBp bnRlbnQgYW5kIHRoZSBnb2FscyBtb3JlIGFjY2Vzc2libGUgYW5kIGxlc3MgYW1iaWd1b3VzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+UmVzcG9uZGluZyB0byB0aGUgZGlz Y3Vzc2lvbiBvbiB3aGV0aGVyIGV4aXN0aW5nIEpXVCBpZGVudGl0eSBjbGFpbXMgd2lsbCBkbyB0 aGUgam9iIG9yIG5vdCwgZm9ydHVuYXRlbHksIGV2ZW4gaWYgdGhleSBkb27igJl0LCB0aGVyZeKA mXMgYSBtZWNoYW5pc20gdG8gYWRkIG9uZXMgdGhhdCBkbzogdGhlIElBTkEgSlNPTiBXZWIgVG9r ZW4gQ2xhaW1zIHJlZ2lzdHJ5IGF0DQo8YSBocmVmPSJodHRwczovL3d3dy5pYW5hLm9yZy9hc3Np Z25tZW50cy9qd3Qvand0LnhodG1sI2NsYWltcyI+aHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdu bWVudHMvand0L2p3dC54aHRtbCNjbGFpbXM8L2E+LiZuYnNwOyBGb3IgaW5zdGFuY2UsIGFuIOKA nGVtYWlsX2FkZHJlc3Nlc+KAnSBjbGFpbSB0aGF0IGlzIGFycmF5LXZhbHVlZCBjb3VsZCBiZSBk ZWZpbmVkIGFuZCByZWdpc3RlcmVkIGlmIHRoZXJl4oCZcyBhIG5lZWQgdG8gcmVwcmVzZW50IG11 bHRpcGxlDQogZS1tYWlsIGFkZHJlc3NlcywgcGVyIEFubmFiZWxsZeKAmXMgZXhhbXBsZS4mbmJz cDsgVGhlIGZ1cnRoZXIgZ29vZCBuZXdzIGlzIHRoYXQgaWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGVm aW5lcyBuZXcgY2xhaW1zIHRoYXQgYXJlIHJlZ2lzdGVyZWQsIHRoZXkgY2FuIGJlIHJldXNlZCBi eSBvdGhlcnMgYWxzbyB1c2luZyBKV1RzIOKAkyBqdXN0IGxpa2UgdGhpcyB3b3JraW5nIGdyb3Vw IGNhbiByZXVzZSBjbGFpbXMgZGVmaW5lZCBieSBvdGhlcnMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj5BbHNvIG9uIHRoZSBzdWJqZWN0IG9mIEpXVHMsIEkgd291bGQgc3Vn Z2VzdCB0aGF0IHRoZSBjaGFydGVyIGJlIHVwZGF0ZWQgdG8gZXhwbGljaXRseSBjYWxsIG91dCB0 aGF0IEpXVHMgd2lsbCBiZSB0aGUgd29ya2luZyBncm91cOKAmXMgcHJlZmVycmVkIHJlcHJlc2Vu dGF0aW9uIHNpZ25lZCBhbmQvb3IgZW5jcnlwdGVkIGNsYWltcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPkZpbmFsbHksIEkgYWxzbyB0aGluayB0aGF0IHRoZSBjaGFydGVy IHdvdWxkIGJlbmVmaXQgZnJvbSBleHBsaWNpdGx5IGxpc3RpbmcgdGhpbmdzIHRoYXQgYXJlIG91 dCBvZiBzY29wZSAod2hpY2ggaXMgb2Z0ZW4gZG9uZSBpbiBjaGFydGVycykuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGFua3MgYWdhaW4gZm9yIHByb21wdGluZyB0aGlz IHVzZWZ1bCBkaXNjdXNzaW9uLCBLaW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFR4YXV0 aCAmbHQ7dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZg0KPC9iPkp1 c3RpbiBSaWNoZXI8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDI5LCAyMDIw IDEyOjQ2IEFNPGJyPg0KPGI+VG86PC9iPiBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDt0b3JzdGVu QGxvZGRlcnN0ZWR0Lm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IEtpbSAmbHQ7a2ltQGlkZW50aXR5 YmxvZy5jb20mZ3Q7OyBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs7IHR4 YXV0aEBpZXRmLm9yZzsgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hPTQw YW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVS TkFMXSBSZTogW1R4YXV0aF0gUXVlc3Rpb25zIG9uIHRoZSBUeEF1dGggY2hhcnRlcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkaWRu4oCZdCBtZWFuIOKAnHBhdGNo 4oCdIHRvIHNvdW5kIGRpc3BhcmFnaW5nLCBzb3JyeSBpZiBpdCBjYW1lIGFjcm9zcyBhcyBzdWNo LiBXaGF0IEkgbWVhbiBieSDigJxwYXRjaGluZ+KAnSBoZXJlIGlzIHRoYXQgaXQgaXMgYWRkaW5n IGZ1bmN0aW9uYWxpdHkgdG8gYW4gZXhpc3Rpbmcgc2V0IG9mIGNsYWltcyBhbmQgc2NoZW1hLiBJ ZiB5b3UgYXJlIHVzaW5nIHRoYXQgc2NoZW1hIGFzIGEgYmFzZSwgaXQgbWFrZXMgc2Vuc2UNCiBh cyBhIHZpYWJsZSBzb2x1dGlvbiBpbiB0aGF0IHNwYWNlLiBJLCBob3dldmVyLCBhbSBicmluZ2lu ZyB1cCB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhhdCBzY2hlbWEgYXMg b3VyIGJhc2UgYXQgYWxsLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SeKAmWxsIG5vdGUgdGhhdCA4MTEyIGRvZXNu4oCZdCBkZWZpbmUgYSBzY2hlbWEgb3Ig c3ludGF4LCBib3RoIG9mIHdoaWNoIGFyZSByZXF1aXJlZC4gQnV0IGlmIHdlIHdlcmUgc3RhcnRp bmcgT0lEQyB0b2RheSB3aXRoIEVLWUPigJlzIHJlcXVpcmVtZW50cywgSeKAmW0gbm90IGNvbnZp bmNlZCB3ZeKAmWQgZW5kIHVwIHdpdGggdGhlIHNhbWUgc3RydWN0dXJlLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyB3aXRoIGV2 ZXJ5dGhpbmcsIGl04oCZcyBhIHZlcnkgaW1wb3J0YW50IGlucHV0IGludG8gd2hhdCB3ZeKAmXJl IHRyeWluZyB0byBzb2x2ZSwgZXNwZWNpYWxseSBpbmZsdWVuY2luZyB3aGF04oCZcyBleHRlbnNp YmxlIGFuZCBob3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKYW4gMjksIDIwMjAsIGF0IDg6MDYgQU0sIFRvcnN0 ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l dCI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPkFtIDI5LjAxLjIwMjAgdW0gMDc6MzQgc2NocmllYiBKdXN0aW4gUmljaGVyICZsdDs8 YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1Ij5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0Ozo8 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+77u/SSB0aGluayB0aGUgZWt5YyB3b3JrIGlzIGdyZWF0IGZvciB3aGF0IGl0 IGlzLCBidXQgYWdhaW4gd2UgaGF2ZSBhbiBvcHBvcnR1bml0eSB0byB0YWtlIGEgc3RlcCBiZXlv bmQgaXQuIEluIG15IHZpZXcsIHdl4oCZZCBiZSBiZXR0ZXIgb2ZmIGRlZmluaW5nIGEgbWVhbnMg b2Ygc3BlY2lmeWluZyBmaWVsZCBtZXRhZGF0YSBhIGxhIE5JU1QgSVIgODExMiBhcyBwYXJ0IG9m IHRoZSBzY2hlbWEgaW5zdGVhZCBvZiBwYXRjaGluZw0KIHRoZSBleGlzdGluZyBPSURDIGZpZWxk cy4mbmJzcDs8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZwYWdlcy5uaXN0LmdvdiUyRk5JU1RJUi04MTEyJTJG JmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzlmYWU1 MDM2NjlmNDQzYTA5NjgzMDhkN2E0OTdjNDVmJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN0MxJTdDMCU3QzYzNzE1ODg0NDA0OTMzODM0NCZhbXA7c2RhdGE9ck9yS2FPN012RERL THlmQjJRaXZiVlRjajVFbVJTSjFuUlhYczMwakV6MCUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6 Ly9wYWdlcy5uaXN0Lmdvdi9OSVNUSVItODExMi88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgdHJpZWQgYW5kIGl0IGRp ZCBub3QgZnVsZmlsbCBvdXIgcmVxdWlyZW1lbnRzLiB2ZXJpZmllZF9jbGFpbXMgaXMgYnkgbm8g bWVhbnMgYSBwYXRjaCwgaXTigJlzIGEgdmlhYmxlIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3Rpbjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSmFuIDI5LCAy MDIwLCBhdCA2OjEzIEFNLCBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiPnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BbSAyOC4wMS4yMDIwIHVtIDE4OjAwIHNjaHJp ZWIgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5u YT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmciPnJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFy Yy5pZXRmLm9yZzwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgLi4uX3ZlcmlmaWVkIGNsYWltcyBk b27igJl0IGRlZmluZSBob3cgb3Igd2hlbiB2ZXJpZmljYXRpb24gb2NjdXJyZWQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cmUsIHRoZXkg ZG8uIExvb2sgYXQgdGhlIHRpbWUgYW5kIG1ldGhvZCBmaWVsZHMuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbmNlIE9wZW5JZCBD b25uZWN0IGZvciBJZGVudGl0eSBBc3N1cmFuY2UgKGFrYSB2ZXJpZmllZF9jbGFpbXMpIGlzIG9u Z29pbmcgd29yayBmZWVsIGZyZWUgdG8gY29udHJpYnV0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGb3Blbmlk Lm5ldCUyRndnJTJGZWt5Yy1pZGElMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMl NDBtaWNyb3NvZnQuY29tJTdDOWZhZTUwMzY2OWY0NDNhMDk2ODMwOGQ3YTQ5N2M0NWYlN0M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTU4ODQ0MDQ5MzM4MzQ0 JmFtcDtzZGF0YT1wZzh1cHd5TiUyQlhLZWFGWmFLRXZSJTJCVEVQc0tnamVKdGRId1BNMWZlJTJG eG5jJTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwczovL29wZW5pZC5uZXQvd2cvZWt5Yy1pZGEvPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CH2PR00MB0679A3CE293D3DAF20A640E2F5050CH2PR00MB0679namp_-- From nobody Wed Jan 29 01:04:38 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 4F1391207FE for ; Wed, 29 Jan 2020 01:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[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 VNe1MInW4x37 for ; Wed, 29 Jan 2020 01:04:34 -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 66D3712022D for ; Wed, 29 Jan 2020 01:04:34 -0800 (PST) Received: from [10.38.98.116] ([83.219.75.72]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00T94RWA011046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jan 2020 04:04:31 -0500 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: <359EC4B99E040048A7131E0F4E113AFC0216F15F4E@marchand> Date: Wed, 29 Jan 2020 10:04:26 +0100 Cc: "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <359EC4B99E040048A7131E0F4E113AFC0216F15F2E@marchand> <359EC4B99E040048A7131E0F4E113AFC0216F15F4E@marchand> To: "rdd@cert.org" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 29 Jan 2020 09:04:37 -0000 Hi Roman, thanks for the review. I=E2=80=99ll respond to the questions = in line. > On Jan 29, 2020, at 1:13 AM, Roman Danyliw wrote: >=20 > Hi! >=20 >> -----Original Message----- >> From: TxAuth On Behalf of Justin Richer >> Sent: Sat, 18 January 2020 14:15 UTCShow >> To: IETF TxAuth >> Subject: [Txauth] TxAuth Charter (Take 3.5) >>=20 >=20 > [snip] >> I would really appreciate the security AD's weighing in at this = stage. Thanks >> again everyone! >=20 > The Sec ADs have reviewed the charter (as of v3.5) and at a high level = believe the scope could use a bit more precision. If there was no prior = work, the situation would be different. However, in this case, = relationships with the existing OAuth WG needs to be navigated. =20 That makes a lot of senes, and I appreciate the drive to clarity. > Topics that require discussion and clarity include: >=20 > ** is TxAuth intended to solve all existing OAuth use cases (i.e., is = TxAuth is a superset of OAuth) in a new, non-backward compatible way? = If not all, which would not be addressed? Yes, it is my perspective that we would be working on a superset of = OAuth use cases. However, that does not mean that we would be replicated = OAuth functionality exactly =E2=80=94 there will be things that we solve = in fairly different ways (like single-page apps, for example). If this were happening in the OAuth WG, this work would likely be called = OAuth 3.0, and that might still be the final name at some point in the = future.=20 How would you recommend we communicate that in the charter? Should we = explicitly call out coordination with OAuth WG? > ** what new use cases would TxAuth address (that aren't in scope for = OAuth)? Identity is a big one, which is what OIDC currently layers on top of = OAuth 2. We=E2=80=99d also be looking at user-to-user delegation (the = UMA and CIBA use cases). We=E2=80=99re also looking at cases that = involve non-web interaction with users (like the DID/VC work, or = app-to-app communication on devices). All of these are listed in the = proposed text, do they need to be called out as being beyond OAuth 2? > ** given a new use case requirement for delegated = authorization/identity, what would be the decision process to decide to = which WG or WGs it would go? These are different protocols, so a large part of it would be what = context is it being solved in? If =E2=80=9Cusing OAuth 2=E2=80=9D is a = requirement, which is going to be the case for a lot of people for a = while yet, then the OAuth WG would pick it up. That=E2=80=99s why = we=E2=80=99re still doing PAR, JAR, RAR, and the like over there. If you = don=E2=80=99t have to use OAuth 2 or OIDC as your base, or if you need = behaviors that are outside the OAuth 2, then you direct the work here.=20= Or you bring the use case to both spaces, and maybe there=E2=80=99s an = OAuth 2 and a TxAuth version of what you=E2=80=99re after, and these = solutions are coordinated as much as makes sense.=20 What should the charter say to address this information routing = question? > ** notional milestones (not the dates, but the deliverables) Is this a proposed document list? I had thought we=E2=80=99d already = kinda covered this in the extant text, but I=E2=80=99m taking this = comment that we need something that=E2=80=99s more specific.=20 >=20 > In the details of the text: >=20 > (1) Distinguish what's new (instance #1): > OLD: > This group is chartered to develop a delegation protocol for = authorization, identity, and API access. >=20 > NEW: > This group is chartered to develop a fine-grained delegation protocol = for authorization, identity, and API access. >=20 That works for me. > (2) Distinguish what's new (instance #2): > OLD: > The use cases supported by this protocol will include widely deployed = use cases currently supported by OAuth 2.0 and OpenID Connect (an = extension of OAuth 2.0) as well as new use cases not enabled by OAuth = 2.0. >=20 > NEW: > 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 I like this, thanks. > (3) Style Nit: > OLD: > Web, mobile, single-page, interaction-constrained, and other types of = client applications >=20 > NEW:=20 > A variety of client applications, including Web, mobile, single-page, = and interaction-constrained applications >=20 Works for me. > (4) Per "Token presentation mechanisms and key bindings", perhaps it = might be clearer to say "Mechanisms for presenting tokens to resource = servers and binding resource requests to cryptographic keys=E2=80=9D >=20 That works, though probably =E2=80=9Cbinding resource requests to tokens = and associated cryptographic keys" > (5) Per "Mechanisms for providing user, software ...", perhaps it = might be clearer to say "Mechanism for conveying user, software =E2=80=A6"= Sounds good. >=20 > (6) Per "Optimization of information and API access beyond identity = through the delegation process", is this suggesting the need for = optimizing access to TxAuth information for use cases beyond identity? = Or the inclusion of information that isn't identity information into the = delegation process? =20 It=E2=80=99s the latter =E2=80=94 there=E2=80=99s been stated interest = in including information beyond just an access token in the response. = Identity is the first clear use case of this, but I think we can treat = identity information as a specific case of a more generic response. >=20 > (7) Refine the protocol focus: > OLD: > While the initial work will focus on using HTTP for communication = between the client and the authorization server, the working group will = seek to take advantage of optimization features of HTTP2 and HTTP3 where = possible, and will strive to enable simple mapping to other protocols = such as COAP. >=20 > NEW: > 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. I like this wording, thanks. >=20 > Regards, > Roman and Ben >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Wed Jan 29 01:05: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 BBD581207FE for ; Wed, 29 Jan 2020 01:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, 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 rTgYMlS-_C-9 for ; Wed, 29 Jan 2020 01:05:54 -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 0AEEE12022D for ; Wed, 29 Jan 2020 01:05:53 -0800 (PST) Received: from [10.38.98.116] ([83.219.75.72]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00T95jHM011291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jan 2020 04:05:46 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E5965FB9-FEC1-4CF8-8BE9-FFC119020AD9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 29 Jan 2020 10:05:44 +0100 In-Reply-To: Cc: Torsten Lodderstedt , Kim , Dick Hardt , "txauth@ietf.org" , "Richard Backman, Annabelle" To: Mike Jones References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] [EXTERNAL] Re: Questions on the 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: Wed, 29 Jan 2020 09:05:57 -0000 --Apple-Mail=_E5965FB9-FEC1-4CF8-8BE9-FFC119020AD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I strongly object to calling out JWTs as the preferred solution for = signed and encrypted claims within this working group. =E2=80=94 Justin > On Jan 29, 2020, at 9:50 AM, Mike Jones = wrote: >=20 > Thanks for writing these detailed questions, Kim. I believe that they = point out a number of places where even experts in the field, such as = yourself, currently have trouble understanding parts of what the charter = is proposing that we do =E2=80=93 partially because terminology is used = that isn=E2=80=99t commonly understood. I hope that the draft charter = will be revised to make the intent and the goals more accessible and = less ambiguous. > =20 > Responding to the discussion on whether existing JWT identity claims = will do the job or not, fortunately, even if they don=E2=80=99t, = there=E2=80=99s a mechanism to add ones that do: the IANA JSON Web Token = Claims registry at https://www.iana.org/assignments/jwt/jwt.xhtml#claims = . For instance, = an =E2=80=9Cemail_addresses=E2=80=9D claim that is array-valued could be = defined and registered if there=E2=80=99s a need to represent multiple = e-mail addresses, per Annabelle=E2=80=99s example. The further good = news is that if the working group defines new claims that are = registered, they can be reused by others also using JWTs =E2=80=93 just = like this working group can reuse claims defined by others. > =20 > Also on the subject of JWTs, I would suggest that the charter be = updated to explicitly call out that JWTs will be the working group=E2=80=99= s preferred representation signed and/or encrypted claims. > =20 > Finally, I also think that the charter would benefit from explicitly = listing things that are out of scope (which is often done in charters). > =20 > Thanks again for prompting this useful discussion, Kim. > =20 > -- Mike > =20 > From: Txauth > On Behalf Of Justin Richer > Sent: Wednesday, January 29, 2020 12:46 AM > To: Torsten Lodderstedt > > Cc: Kim >; Dick = Hardt >; = txauth@ietf.org ; Richard Backman, Annabelle = > > Subject: [EXTERNAL] Re: [Txauth] Questions on the TxAuth charter > =20 > I didn=E2=80=99t mean =E2=80=9Cpatch=E2=80=9D to sound disparaging, = sorry if it came across as such. What I mean by =E2=80=9Cpatching=E2=80=9D= here is that it is adding functionality to an existing set of claims = and schema. If you are using that schema as a base, it makes sense as a = viable solution in that space. I, however, am bringing up the question = of whether we are using that schema as our base at all. > =20 > I=E2=80=99ll note that 8112 doesn=E2=80=99t define a schema or syntax, = both of which are required. But if we were starting OIDC today with = EKYC=E2=80=99s requirements, I=E2=80=99m not convinced we=E2=80=99d end = up with the same structure.=20 > =20 > As with everything, it=E2=80=99s a very important input into what = we=E2=80=99re trying to solve, especially influencing what=E2=80=99s = extensible and how. > =20 > =E2=80=94 Justin >=20 >=20 > On Jan 29, 2020, at 8:06 AM, Torsten Lodderstedt = > wrote: > =20 > =20 >=20 >=20 > Am 29.01.2020 um 07:34 schrieb Justin Richer >: >=20 > =EF=BB=BFI think the ekyc work is great for what it is, but again we = have an opportunity to take a step beyond it. In my view, we=E2=80=99d = be better off defining a means of specifying field metadata a la NIST IR = 8112 as part of the schema instead of patching the existing OIDC fields. = https://pages.nist.gov/NISTIR-8112/ = > =20 > We tried and it did not fulfill our requirements. verified_claims is = by no means a patch, it=E2=80=99s a viable solution. >=20 >=20 > =20 > =E2=80=94 Justin >=20 >=20 > On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt = > wrote: > =20 > =20 >=20 >=20 > Am 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle = >: >=20 > The ..._verified claims don=E2=80=99t define how or when verification = occurred. > =20 > Sure, they do. Look at the time and method fields.=20 > =20 > Since OpenId Connect for Identity Assurance (aka verified_claims) is = ongoing work feel free to contribute. > =20 > https://openid.net/wg/ekyc-ida/ = --Apple-Mail=_E5965FB9-FEC1-4CF8-8BE9-FFC119020AD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = strongly object to calling out JWTs as the preferred solution for signed = and encrypted claims within this working group.

= --Apple-Mail=_E5965FB9-FEC1-4CF8-8BE9-FFC119020AD9-- From nobody Wed Jan 29 01:40: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 1E6AF12026E for ; Wed, 29 Jan 2020 01:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 L5nnh5EF5c8F for ; Wed, 29 Jan 2020 01:40:40 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0: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 6F456120130 for ; Wed, 29 Jan 2020 01:40:40 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id 59so14918892otp.12 for ; Wed, 29 Jan 2020 01:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KXh/MLjS5vPmQ7Q6yIXcNpwuhSoUCGKVQNfticXtwS4=; b=Yo0tBCfIzbGQq8m12GSm2keR28WrFiJZZTYVlZttypgyNqNkLXgVgbdjdqTPPrKl4v OzbysLlo1vnJwjVxlXBFs7ziWODajReHkwg7xz8M6hXq1Y7RZSgumJMaFE6vBRkmvCg7 58b4Uz7GrCAA77hv52HNgxPzHtitAh08+XoVo= 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=KXh/MLjS5vPmQ7Q6yIXcNpwuhSoUCGKVQNfticXtwS4=; b=FmsTFvsyry01zB/PEosmQ7hn1l3Kv1SapUNfyMJa8zwHFlrr+4pCSSctX15DsUUc31 a7HIuDc6N1n/Vt+cBoxubvWAGqYvQAw6Z/J1wPpYi3FU45pSA6a6y8FZ9vjtpAVPwmVV 8/YfLfkg+DXUdI/R5qlp5xR+6PvSfp7IhRQgT7HQvVCr4WNYC5pzwdCg0Y/QUzWz/EOq hBjjx5ioZsOG4DxItzO+N34U8cqxp0Hbrnqbm+vRkZBrHtjMotOsAznGmrb+pq8n6Ddy iD/0Pld5yI9m1p7ku87brCWYsIq82Y/gtthCP/KMSrJmfLQLrJjjdzTa252ZjzeRvNRX 4eIQ== X-Gm-Message-State: APjAAAVF1//PlvS/2QIqlPXx5eiu0GeuUO05wCpI3wSzyITEJ6VJgSCc qSIB+FiDB+0VTtdwqv3n0DJMAiPT5wD2pWoPcwoL9yRJat/r/w== X-Google-Smtp-Source: APXvYqyWmervTYCnL1NCRbhmxhBAz7fZgw05UniA8WPr6ch9gCqOBKSsi73FDFOxcDHEIqtIqW914YPLLd2s/bPmlzM= X-Received: by 2002:a05:6830:15d7:: with SMTP id j23mr8398457otr.357.1580290839567; Wed, 29 Jan 2020 01:40:39 -0800 (PST) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC0216F15F2E@marchand> <359EC4B99E040048A7131E0F4E113AFC0216F15F4E@marchand> In-Reply-To: From: Adrian Hope-Bailie Date: Wed, 29 Jan 2020 11:40:28 +0200 Message-ID: To: Justin Richer Cc: "rdd@cert.org" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000227770059d4422f2" Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 29 Jan 2020 09:40:43 -0000 --000000000000227770059d4422f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 29 Jan 2020 at 11:04, Justin Richer wrote: > Hi Roman, thanks for the review. I=E2=80=99ll respond to the questions in= line. > > > On Jan 29, 2020, at 1:13 AM, Roman Danyliw wrote: > > > > Hi! > > > >> -----Original Message----- > >> From: TxAuth On Behalf of Justin Richer > >> Sent: Sat, 18 January 2020 14:15 UTCShow > >> To: IETF TxAuth > >> Subject: [Txauth] TxAuth Charter (Take 3.5) > >> > > > > [snip] > >> I would really appreciate the security AD's weighing in at this stage. > Thanks > >> again everyone! > > > > The Sec ADs have reviewed the charter (as of v3.5) and at a high level > believe the scope could use a bit more precision. If there was no prior > work, the situation would be different. However, in this case, > relationships with the existing OAuth WG needs to be navigated. > > That makes a lot of senes, and I appreciate the drive to clarity. > > > Topics that require discussion and clarity include: > > > > ** is TxAuth intended to solve all existing OAuth use cases (i.e., is > TxAuth is a superset of OAuth) in a new, non-backward compatible way? If > not all, which would not be addressed? > > Yes, it is my perspective that we would be working on a superset of OAuth > use cases. However, that does not mean that we would be replicated OAuth > functionality exactly =E2=80=94 there will be things that we solve in fai= rly > different ways (like single-page apps, for example). > > If this were happening in the OAuth WG, this work would likely be called > OAuth 3.0, and that might still be the final name at some point in the > future. > > How would you recommend we communicate that in the charter? Should we > explicitly call out coordination with OAuth WG? > > > ** what new use cases would TxAuth address (that aren't in scope for > OAuth)? > > Identity is a big one, which is what OIDC currently layers on top of OAut= h > 2. We=E2=80=99d also be looking at user-to-user delegation (the UMA and C= IBA use > cases). We=E2=80=99re also looking at cases that involve non-web interact= ion with > users (like the DID/VC work, or app-to-app communication on devices). All > of these are listed in the proposed text, do they need to be called out a= s > being beyond OAuth 2? > We are most interested in payments use cases. Specifically we find the use of OAuth 2.0 for delegated access to financial accounts very limited, forcing us into using things like the "Lodging Intents Pattern". I think Torsten has made the point well in his blogs on the topic ( https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-t= hink-oauth-scopes-2326e2038948 ). I believe this can be broadened to include any use case where the authorization flow involves the user/RO giving consent to a client to perform a specific transaction (as opposed to simply get access to a resource or API) and the need for the AS to have the details of this prior to authorization so the details can be properly presented to the user. > > > ** given a new use case requirement for delegated > authorization/identity, what would be the decision process to decide to > which WG or WGs it would go? > > These are different protocols, so a large part of it would be what contex= t > is it being solved in? If =E2=80=9Cusing OAuth 2=E2=80=9D is a requiremen= t, which is going > to be the case for a lot of people for a while yet, then the OAuth WG wou= ld > pick it up. That=E2=80=99s why we=E2=80=99re still doing PAR, JAR, RAR, a= nd the like over > there. If you don=E2=80=99t have to use OAuth 2 or OIDC as your base, or = if you > need behaviors that are outside the OAuth 2, then you direct the work her= e. > > Or you bring the use case to both spaces, and maybe there=E2=80=99s an OA= uth 2 and > a TxAuth version of what you=E2=80=99re after, and these solutions are co= ordinated > as much as makes sense. > > What should the charter say to address this information routing question? > > > ** notional milestones (not the dates, but the deliverables) > > Is this a proposed document list? I had thought we=E2=80=99d already kind= a covered > this in the extant text, but I=E2=80=99m taking this comment that we need= something > that=E2=80=99s more specific. > > > > > In the details of the text: > > > > (1) Distinguish what's new (instance #1): > > OLD: > > This group is chartered to develop a delegation protocol for > authorization, identity, and API access. > > > > NEW: > > This group is chartered to develop a fine-grained delegation protocol > for authorization, identity, and API access. > > > > That works for me. > > > (2) Distinguish what's new (instance #2): > > OLD: > > The use cases supported by this protocol will include widely deployed > use cases currently supported by OAuth 2.0 and OpenID Connect (an extensi= on > of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0. > > > > NEW: > > 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 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 > unnecessary dependence on a browser or user-agent for coordinating > interactions. > > > > I like this, thanks. > > > (3) Style Nit: > > OLD: > > Web, mobile, single-page, interaction-constrained, and other types of > client applications > > > > NEW: > > A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > > > Works for me. > > > (4) Per "Token presentation mechanisms and key bindings", perhaps it > might be clearer to say "Mechanisms for presenting tokens to resource > servers and binding resource requests to cryptographic keys=E2=80=9D > > > > That works, though probably =E2=80=9Cbinding resource requests to tokens = and > associated cryptographic keys" > > > (5) Per "Mechanisms for providing user, software ...", perhaps it might > be clearer to say "Mechanism for conveying user, software =E2=80=A6" > > Sounds good. > > > > > (6) Per "Optimization of information and API access beyond identity > through the delegation process", is this suggesting the need for optimizi= ng > access to TxAuth information for use cases beyond identity? Or the > inclusion of information that isn't identity information into the > delegation process? > > It=E2=80=99s the latter =E2=80=94 there=E2=80=99s been stated interest in= including information > beyond just an access token in the response. Identity is the first clear > use case of this, but I think we can treat identity information as a > specific case of a more generic response. > > > > > (7) Refine the protocol focus: > > OLD: > > While the initial work will focus on using HTTP for communication > between the client and the authorization server, the working group will > seek to take advantage of optimization features of HTTP2 and HTTP3 where > possible, and will strive to enable simple mapping to other protocols suc= h > as COAP. > > > > NEW: > > 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. > > I like this wording, thanks. > > > > > Regards, > > Roman and 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 > --000000000000227770059d4422f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 29 Jan 2020 at 11:04, Justin = Richer <jricher@mit.edu> wrote= :
Hi Roman, than= ks for the review. I=E2=80=99ll respond to the questions in line.

> On Jan 29, 2020, at 1:13 AM, Roman Danyliw <rdd@cert.org> wrote:
>
> Hi!
>
>> -----Original Message-----
>> From: TxAuth <txauth-bounces@ietf.org> On Behalf of Justin Richer
>> Sent: Sat, 18 January 2020 14:15 UTCShow
>> To: IETF TxAuth <txauth@ietf.org>
>> Subject: [Txauth] TxAuth Charter (Take 3.5)
>>
>
> [snip]
>> I would really appreciate the security AD's weighing in at thi= s stage. Thanks
>> again everyone!
>
> The Sec ADs have reviewed the charter (as of v3.5) and at a high level= believe the scope could use a bit more precision.=C2=A0 If there was no pr= ior work, the situation would be different.=C2=A0 However, in this case, re= lationships with the existing OAuth WG needs to be navigated.=C2=A0

That makes a lot of senes, and I appreciate the drive to clarity.

> Topics that require discussion and clarity include:
>
> ** is TxAuth intended to solve all existing OAuth use cases (i.e., is = TxAuth is a superset of OAuth) in a new, non-backward compatible way?=C2=A0= If not all, which would not be addressed?

Yes, it is my perspective that we would be working on a superset of OAuth u= se cases. However, that does not mean that we would be replicated OAuth fun= ctionality exactly =E2=80=94 there will be things that we solve in fairly d= ifferent ways (like single-page apps, for example).

If this were happening in the OAuth WG, this work would likely be called OA= uth 3.0, and that might still be the final name at some point in the future= .

How would you recommend we communicate that in the charter? Should we expli= citly call out coordination with OAuth WG?

> ** what new use cases would TxAuth address (that aren't in scope f= or OAuth)?

Identity is a big one, which is what OIDC currently layers on top of OAuth = 2. We=E2=80=99d also be looking at user-to-user delegation (the UMA and CIB= A use cases). We=E2=80=99re also looking at cases that involve non-web inte= raction with users (like the DID/VC work, or app-to-app communication on de= vices). All of these are listed in the proposed text, do they need to be ca= lled out as being beyond OAuth 2?

We ar= e most interested in payments use cases. Specifically we find the use of OA= uth 2.0 for delegated access to financial accounts very limited, forcing us= into using things like the "Lodging Intents Pattern". I think To= rsten has made the point well in his blogs on the topic (https://medium.com/oauth-2/transaction-authorizati= on-or-why-we-need-to-re-think-oauth-scopes-2326e2038948).
I believe this can be broadened to include any use case where t= he authorization flow involves the user/RO giving consent to a client to pe= rform a specific transaction (as opposed to simply get access to a resource= or API) and the need for the AS to have the details of this prior to autho= rization so the details can be properly presented to the user.
= =C2=A0

> ** given a new use case requirement for delegated authorization/identi= ty, what would be the decision process to decide to which WG or WGs it woul= d go?

These are different protocols, so a large part of it would be what context = is it being solved in? If =E2=80=9Cusing OAuth 2=E2=80=9D is a requirement,= which is going to be the case for a lot of people for a while yet, then th= e OAuth WG would pick it up. That=E2=80=99s why we=E2=80=99re still doing P= AR, JAR, RAR, and the like over there. If you don=E2=80=99t have to use OAu= th 2 or OIDC as your base, or if you need behaviors that are outside the OA= uth 2, then you direct the work here.

Or you bring the use case to both spaces, and maybe there=E2=80=99s an OAut= h 2 and a TxAuth version of what you=E2=80=99re after, and these solutions = are coordinated as much as makes sense.

What should the charter say to address this information routing question?
> ** notional milestones (not the dates, but the deliverables)

Is this a proposed document list? I had thought we=E2=80=99d already kinda = covered this in the extant text, but I=E2=80=99m taking this comment that w= e need something that=E2=80=99s more specific.

>
> In the details of the text:
>
> (1) Distinguish what's new (instance #1):
> OLD:
> This group is chartered to develop a delegation protocol for authoriza= tion, identity, and API access.
>
> NEW:
> This group is chartered to develop a fine-grained delegation protocol = for authorization, identity, and API access.
>

That works for me.

> (2) Distinguish what's new (instance #2):
> OLD:
> The use cases supported by this protocol will include widely deployed = use cases currently supported by OAuth 2.0 and OpenID Connect (an extension= of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0.
>
> NEW:
> It will expand upon the uses cases currently supported by OAuth 2.0 an= d OpenID Connect (itself an extension of OAuth 2.0) to support authorizatio= ns scoped as narrowly as a single transaction, provide a clear framework fo= r interaction among all parties involved in the protocol flow, and remove u= nnecessary dependence on a browser or user-agent for coordinating interacti= ons.
>

I like this, thanks.

> (3) Style Nit:
> OLD:
> Web, mobile, single-page, interaction-constrained, and other types of = client applications
>
> NEW:
> A variety of client applications, including Web, mobile, single-page, = and interaction-constrained applications
>

Works for me.

> (4) Per "Token presentation mechanisms and key bindings", pe= rhaps it might be clearer to say "Mechanisms for presenting tokens to = resource servers and binding resource requests to cryptographic keys=E2=80= =9D
>

That works, though probably =E2=80=9Cbinding resource requests to tokens an= d associated cryptographic keys"

> (5) Per "Mechanisms for providing user, software ...", perha= ps it might be clearer to say "Mechanism for conveying user, software = =E2=80=A6"

Sounds good.

>
> (6) Per "Optimization of information and API access beyond identi= ty through the delegation process", is this suggesting the need for op= timizing access to TxAuth information for use cases beyond identity? Or the= inclusion of information that isn't identity information into the dele= gation process?=C2=A0

It=E2=80=99s the latter =E2=80=94 there=E2=80=99s been stated interest in i= ncluding information beyond just an access token in the response. Identity = is the first clear use case of this, but I think we can treat identity info= rmation as a specific case of a more generic response.

>
> (7) Refine the protocol focus:
> OLD:
> While the initial work will focus on using HTTP for communication betw= een the client and the authorization server, the working group will seek to= take advantage of optimization features of HTTP2 and HTTP3 where possible,= and will strive to enable simple mapping to other protocols such as COAP.<= br> >
> NEW:
> 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.

I like this wording, thanks.

>
> Regards,
> Roman and 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
--000000000000227770059d4422f2-- From nobody Wed Jan 29 02:23: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 80963120825 for ; Wed, 29 Jan 2020 02:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fgVsu-FMMi-J for ; Wed, 29 Jan 2020 02:23:01 -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 B5A7B1207FB for ; Wed, 29 Jan 2020 02:23:01 -0800 (PST) Received: from [10.38.98.116] ([83.219.75.72]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00TAMa60026046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jan 2020 05:22:51 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3E4CDC09-2637-4061-8D15-886F26F56515" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 29 Jan 2020 11:22:35 +0100 In-Reply-To: Cc: "rdd@cert.org" , "txauth@ietf.org" To: Adrian Hope-Bailie References: <359EC4B99E040048A7131E0F4E113AFC0216F15F2E@marchand> <359EC4B99E040048A7131E0F4E113AFC0216F15F4E@marchand> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 29 Jan 2020 10:23:04 -0000 --Apple-Mail=_3E4CDC09-2637-4061-8D15-886F26F56515 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 29, 2020, at 10:40 AM, Adrian Hope-Bailie = wrote: >=20 >=20 >=20 > > ** what new use cases would TxAuth address (that aren't in scope for = OAuth)? >=20 > Identity is a big one, which is what OIDC currently layers on top of = OAuth 2. We=E2=80=99d also be looking at user-to-user delegation (the = UMA and CIBA use cases). We=E2=80=99re also looking at cases that = involve non-web interaction with users (like the DID/VC work, or = app-to-app communication on devices). All of these are listed in the = proposed text, do they need to be called out as being beyond OAuth 2? >=20 > We are most interested in payments use cases. Specifically we find the = use of OAuth 2.0 for delegated access to financial accounts very = limited, forcing us into using things like the "Lodging Intents = Pattern". I think Torsten has made the point well in his blogs on the = topic = (https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re= -think-oauth-scopes-2326e2038948 = ). >=20 > I believe this can be broadened to include any use case where the = authorization flow involves the user/RO giving consent to a client to = perform a specific transaction (as opposed to simply get access to a = resource or API) and the need for the AS to have the details of this = prior to authorization so the details can be properly presented to the = user. > =20 Exactly =E2=80=94 because OAuth forces this information to go through = the browser to get to the authorization page, it=E2=80=99s a bad fit for = this type of use where you=E2=80=99re putting potentially sensitive = information as inputs to the decision (which account to choose, for = instance) that you don=E2=80=99t want leaked through the browser.=20 TxAuth is based on the lodging intent pattern from the start. PAR does a = great job of back porting this functionality to OAuth 2, but there are = limitations and awkwardness to this approach that TxAuth can avoid. =E2=80=94 Justin --Apple-Mail=_3E4CDC09-2637-4061-8D15-886F26F56515 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 29, 2020, at 10:40 AM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:



> ** what new use cases would TxAuth address (that aren't in scope = for OAuth)?

Identity is a big one, which is what OIDC currently layers on top of = OAuth 2. We=E2=80=99d also be looking at user-to-user delegation (the = UMA and CIBA use cases). We=E2=80=99re also looking at cases that = involve non-web interaction with users (like the DID/VC work, or = app-to-app communication on devices). All of these are listed in the = proposed text, do they need to be called out as being beyond OAuth 2?

We are most interested in payments use cases. Specifically we = find the use of OAuth 2.0 for delegated access to financial accounts = very limited, forcing us into using things like the "Lodging Intents = Pattern". I think Torsten has made the point well in his blogs on the = topic (https://medium.com/oauth-2/transaction-authorization-or-why-we-= need-to-re-think-oauth-scopes-2326e2038948).

I believe this can be broadened to = include any use case where the authorization flow involves the user/RO = giving consent to a client to perform a specific transaction (as opposed = to simply get access to a resource or API) and the need for the AS to = have the details of this prior to authorization so the details can be = properly presented to the user.
 


Exactly =E2=80=94 = because OAuth forces this information to go through the browser to get = to the authorization page, it=E2=80=99s a bad fit for this type of use = where you=E2=80=99re putting potentially sensitive information as inputs = to the decision (which account to choose, for instance) that you don=E2=80= =99t want leaked through the browser. 

TxAuth is based on the lodging intent pattern from = the start. PAR does a great job of back porting this functionality to = OAuth 2, but there are limitations and awkwardness to this approach that = TxAuth can avoid.


 =E2=80=94 Justin

= --Apple-Mail=_3E4CDC09-2637-4061-8D15-886F26F56515-- From nobody Wed Jan 29 02:34: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 DA47A120133 for ; Wed, 29 Jan 2020 02:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 MqYIAtWmjYnz for ; Wed, 29 Jan 2020 02:34:55 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369B8120130 for ; Wed, 29 Jan 2020 02:34:55 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id p9so5621902wmc.2 for ; Wed, 29 Jan 2020 02:34:55 -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=H1Q/4Kdu1oucacTnPRfTSN5mjAbhNfgpqRUCcBrbTq0=; b=THsQ50Oa2xCD1LutlYUTrmg+DeQXXJ4qLREp33Z13M3Fv2jWPSn8d+g/UHO5VdFoVZ LwNNhI2UVFKcOPTkIkgk2M2SG/Ap0m/pDlEdjUWnT9q9FcfBxjDRy0/QWKDayhBDs0La OdfKL7G1xBYjwfWYxZgW2+wdsBJWWWa2WgeMdd7yEV8hk/KPY/HvSQwvC1k3VCcmNayK /3jpNVxkbWhJ15uzYe2wNDC4obhFAKd7VgPsvm4XCHbWRKIZXAupSmwnOpdiPhhq8MwV 7FDpOJMaxuU7v2c96tMazDEdkn8B3JugD9XEkWSLKRjjDwCr7/l9cuE8SfejC+/8RydR BUsw== 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=H1Q/4Kdu1oucacTnPRfTSN5mjAbhNfgpqRUCcBrbTq0=; b=h9HGmdPX4jWngArIngGgBlglRu/hvwtcWWsFxQKoICJBaZ42eB1d1VYFgyaWfwheAg JSqFNkgF7N5LV4CLlwlq+0Csyw5wv6jlJiFr6sueetvp4V/pS1kjjc6oPjkM6etX8qPX ccuRAq+QXsZk3LcM76EVyYHaelfyL0qIRE1biQPshV8INMBJn4tQ40hwCZjfJlavcJEx MPtavuBT28kIc25Kcv+FgMvGB1+Nt+WtB9kRr5NU/Jxcyk6mCel75cmghuiPtB7uWcM8 Mf4Q9aFrtuBxjmd4+AAIRg4/Dc1OUZF8vwjlQ503L/9SPgIbMkZgB/iy9oH42Cqu3C+d WP+w== X-Gm-Message-State: APjAAAWIC+ZpadC+7SqFSiRNdDPASs5eLfKG97QFo3VN86HVAoTcYGzS mK3hYzJxM/VVL3B+SoaXaT59hZNxsB+FEWBw X-Google-Smtp-Source: APXvYqzmlJfsxhOuN4VOIuXd15ZcZCI5UOhTnGrJX9SVhExp1U4m/MjjsOVb0+4Y+yJBSvIbp9fSrw== X-Received: by 2002:a05:600c:2c13:: with SMTP id q19mr10959413wmg.144.1580294093680; Wed, 29 Jan 2020 02:34:53 -0800 (PST) Received: from [10.150.31.198] (tmo-112-213.customers.d1-online.com. [80.187.112.213]) by smtp.gmail.com with ESMTPSA id y139sm1821411wmd.24.2020.01.29.02.34.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jan 2020 02:34:53 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-CEE150D7-5A66-49B7-B18E-F3B5B91FE925; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Wed, 29 Jan 2020 11:34:18 +0100 Message-Id: <012164E1-A88F-47E5-AF95-95B98C7C3374@lodderstedt.net> References: <73C0643D-F020-4354-9591-EBB05D161669@mit.edu> Cc: Dick Hardt , "rdd@cert.org" , "txauth@ietf.org" In-Reply-To: <73C0643D-F020-4354-9591-EBB05D161669@mit.edu> To: Justin Richer X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 29 Jan 2020 10:34:57 -0000 --Apple-Mail-CEE150D7-5A66-49B7-B18E-F3B5B91FE925 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 29.01.2020 um 09:41 schrieb Justin Richer : >=20 > Much of OIDC=E2=80=99s complexity stems from it adding functionality to OA= uth 2 or overcoming limitations in OAuth 2. Mind to share examples? I only see the hybrid response types. Anything else?= --Apple-Mail-CEE150D7-5A66-49B7-B18E-F3B5B91FE925 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBTYw ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDGCA8cwggPDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0 aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAesw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTI5MTAzNDE4WjAv BgkqhkiG9w0BCQQxIgQgLzaS1XiZF35okzAi+AUec/bBBJGDfY0XkWDQnFfk4D0wgb0GCSsGAQQB gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQBVzo/s 7dgzc6xYKzasinQRMKFvCkNqmErEePuxFWX1rhkdjJZGnHeLFSapPQz+EMXIyazxsqwaerU/2GBM 67UoIUwofC1tXPb52gH8jr96EvG8qtnL3LohBpFQUjkbQ8B2nq24J6VUmK7qDnchs+LcACvmFptn 8H74bUOCFadsSNa/W9iQVJ/wJiUnOF89mt1I7NwhO2sHlKwZ0rfskku8lmlSZA8a/3eRO1fd5izL PkbQbPfz2/YrHEe41Ocbq020iujlbL/VOO2rq4l8EEcHE9+z3jsvKHyPnzhUJoF0t8flWWTCeX5j ZkmTVkhnj7J4HkXfVHqItnCmGWsVl+RpAAAAAAAA --Apple-Mail-CEE150D7-5A66-49B7-B18E-F3B5B91FE925-- From nobody Wed Jan 29 03:37: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 ECB38120835 for ; Wed, 29 Jan 2020 03:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 fuBV8-L9tBUq for ; Wed, 29 Jan 2020 03:37:12 -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 0D7ED120834 for ; Wed, 29 Jan 2020 03:37:11 -0800 (PST) Received: from [10.38.98.116] ([83.219.75.72]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00TBaVCk008275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jan 2020 06:37:03 -0500 From: Justin Richer Message-Id: <585BCD70-6B64-4058-AC70-B677695DB391@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_DB236AF7-5E43-4A65-AA4C-DBF644E89944" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 29 Jan 2020 12:36:27 +0100 In-Reply-To: Cc: Kim , Torsten Lodderstedt , "Richard Backman, Annabelle" , Dick Hardt , Mike Jones To: "txauth@ietf.org" References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] [EXTERNAL] Re: Questions on the 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: Wed, 29 Jan 2020 11:37:15 -0000 --Apple-Mail=_DB236AF7-5E43-4A65-AA4C-DBF644E89944 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I got a chance to chat with Mike and I wanted to expand my off-the-cuff = response (below) with some more detail than I was able to write in the = moment, because I don=E2=80=99t think that we=E2=80=99re actually that = far apart.=20 To start, it wasn=E2=80=99t obvious to me (and might not have been to = others) the specific precision of Mike=E2=80=99s statement below. He = clarified to me that what he means is that where user claims are signed = or encrypted, then JWT provides an obvious way to do it. In other words, = =E2=80=9Cdon=E2=80=99t re-invent the ID Token with new crypto=E2=80=9D. = There are several things to address here with that in mind. First, I don=E2=80=99t believe there are going to be many, if any, cases = where we need user claims to be signed and encrypted separately from the = core transaction messages. Even in OIDC, the ID Token is allowed to be = unsigned when it is retrieved from the token endpoint directly using the = code flow. The equivalent of this is the only place that TxAuth would be = sending back user claims directly. We no longer have a need to protect = things as they travel through the front channel on a redirect, and we no = longer have a need to use the user=E2=80=99s claims as an artifact for = things like session management (we can define a new artifact for that = purpose that fits better). This effectively means that we don=E2=80=99t = need to redefine the ID Token because we don=E2=80=99t need the = equivalent of the ID token in the same way. For the cases that we do = need to define user claims, we should be defining them as a JSON object = model. And I also believe that this JSON data model should not be = intertwined with or constrained by the JWT claims registry. The OIDC = claims registry can serve as influence and input to our user claims set = if we choose, but I don=E2=80=99t think we should be intertwined with = that either. Second, in spite of the success of OIDC, there are several formats out = there for user claims beyond JWT and JOSE. Verifiable Credentials (VC, = https://www.w3.org/TR/vc-data-model/) is one that has several different = formats, and we are also seeing systems built up around COSE and CBOR = (like IPLD, https://ipld.io/). Or you could even use a SAML document. I = don=E2=80=99t think TxAuth should pick just one of these. Instead, I = want TxAuth to define places to put these formats in requests and = responses. In my draft there=E2=80=99s a spot for an OIDC style ID Token = or a VC document, if you have one. Within each of these, by all means, = let=E2=80=99s lock them down and say that the =E2=80=9Coidc_id_token=E2=80= =9D field is a JWT in compact format that MUST be signed, etc. And I = think it makes little sense to invent our own custom format to do = exactly that kind of thing.=20 Third, I agree that we shouldn=E2=80=99t re-invent an existing crypto = format, and I=E2=80=99ll go further that we shouldn=E2=80=99t be = inventing crypto at all. This doesn=E2=80=99t mean we have to pick one = and only one, because this is one of the spaces that we can (and I argue = should) have some agility. We can define the protocol in terms of JSON = and then have a suite of cryptographic carriers that protect that JSON, = including JOSE, HTTP Message Signatures, and Mutual TLS. There are a = bunch of others out there as well, like the DPoP key presentation coming = out of OAuth 2 right now, that should be switchable as options here = because they=E2=80=99re going to apply to different use cases and = deployments. Plus, that JSON could be translated to CBOR (without data = or structure loss) and protected by COSE =E2=80=94 even if we don=E2=80=99= t define that ourselves, the fact that we=E2=80=99re building our = structure on raw JSON means that it can be translated more easily later. Fourth, I am very sensitive to calling out preferred crypto solutions = because I believe that lends to us using that as an excuse to use that = particular hammer to solve all the problems. There have been proposals = to make the entire protocol JWTs in all directions, for instance, that I = think are really problematic because of the limits that it places on = expression of items outside of the payload itself. This is not what Mike = is suggesting below, but it=E2=80=99s a potential fallout from what he = does propose. In conclusion, JOSE and JWT are fantastic and they solve a lot of = problems in an elegant way. But I think we need to question whether we = need their solutions at all, and where we do, if we want to enable other = solutions as well. In my view, we don=E2=80=99t need JOSE/JWT because we = avoid the problems that they solve, and the places that we do want to = use them I strongly believe there are already other alternatives that we = want to have as options.=20 So I want to have JOSE, but it needs to be in the right places and I do = not want it to be a dependency on all implementations. I think that we = can do that without saying JWT is a preferred format. I think it=E2=80=99s= more important that the charter incorporate specific text of what=E2=80=99= s out of scope, including defining a cryptographic protection mechanism.=20= One of the hardest things for a standard to do is determine where the = flexibility should be. My stance is that we should have a structural = format based on JSON but that the contents of that JSON are extensible = but that each portion and extension are very strict about what=E2=80=99s = there. Another key flexible point is that the content of the JSON-based = payloads can be protected in a variety of ways. Choice can be = debilitating, but it can also be freeing. Pinning everything to JOSE = would do us a disservice.=20 =E2=80=94 Justin > On Jan 29, 2020, at 10:05 AM, Justin Richer wrote: >=20 > I strongly object to calling out JWTs as the preferred solution for = signed and encrypted claims within this working group. >=20 > =E2=80=94 Justin >=20 >> On Jan 29, 2020, at 9:50 AM, Mike Jones > wrote: >>=20 >> Thanks for writing these detailed questions, Kim. I believe that = they point out a number of places where even experts in the field, such = as yourself, currently have trouble understanding parts of what the = charter is proposing that we do =E2=80=93 partially because terminology = is used that isn=E2=80=99t commonly understood. I hope that the draft = charter will be revised to make the intent and the goals more accessible = and less ambiguous. >> =20 >> Responding to the discussion on whether existing JWT identity claims = will do the job or not, fortunately, even if they don=E2=80=99t, = there=E2=80=99s a mechanism to add ones that do: the IANA JSON Web Token = Claims registry at https://www.iana.org/assignments/jwt/jwt.xhtml#claims = . For instance, = an =E2=80=9Cemail_addresses=E2=80=9D claim that is array-valued could be = defined and registered if there=E2=80=99s a need to represent multiple = e-mail addresses, per Annabelle=E2=80=99s example. The further good = news is that if the working group defines new claims that are = registered, they can be reused by others also using JWTs =E2=80=93 just = like this working group can reuse claims defined by others. >> =20 >> Also on the subject of JWTs, I would suggest that the charter be = updated to explicitly call out that JWTs will be the working group=E2=80=99= s preferred representation signed and/or encrypted claims. >> =20 >> Finally, I also think that the charter would benefit from explicitly = listing things that are out of scope (which is often done in charters). >> =20 >> Thanks again for prompting this useful discussion, Kim. >> =20 >> -- Mike >> =20 >> From: Txauth > On Behalf Of Justin Richer >> Sent: Wednesday, January 29, 2020 12:46 AM >> To: Torsten Lodderstedt > >> Cc: Kim >; Dick = Hardt >; = txauth@ietf.org ; Richard Backman, Annabelle = > >> Subject: [EXTERNAL] Re: [Txauth] Questions on the TxAuth charter >> =20 >> I didn=E2=80=99t mean =E2=80=9Cpatch=E2=80=9D to sound disparaging, = sorry if it came across as such. What I mean by =E2=80=9Cpatching=E2=80=9D= here is that it is adding functionality to an existing set of claims = and schema. If you are using that schema as a base, it makes sense as a = viable solution in that space. I, however, am bringing up the question = of whether we are using that schema as our base at all. >> =20 >> I=E2=80=99ll note that 8112 doesn=E2=80=99t define a schema or = syntax, both of which are required. But if we were starting OIDC today = with EKYC=E2=80=99s requirements, I=E2=80=99m not convinced we=E2=80=99d = end up with the same structure.=20 >> =20 >> As with everything, it=E2=80=99s a very important input into what = we=E2=80=99re trying to solve, especially influencing what=E2=80=99s = extensible and how. >> =20 >> =E2=80=94 Justin >>=20 >>=20 >> On Jan 29, 2020, at 8:06 AM, Torsten Lodderstedt = > wrote: >> =20 >> =20 >>=20 >>=20 >> Am 29.01.2020 um 07:34 schrieb Justin Richer >: >>=20 >> =EF=BB=BFI think the ekyc work is great for what it is, but again we = have an opportunity to take a step beyond it. In my view, we=E2=80=99d = be better off defining a means of specifying field metadata a la NIST IR = 8112 as part of the schema instead of patching the existing OIDC fields. = https://pages.nist.gov/NISTIR-8112/ = >> =20 >> We tried and it did not fulfill our requirements. verified_claims is = by no means a patch, it=E2=80=99s a viable solution. >>=20 >>=20 >> =20 >> =E2=80=94 Justin >>=20 >>=20 >> On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt = > wrote: >> =20 >> =20 >>=20 >>=20 >> Am 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle = >: >>=20 >> The ..._verified claims don=E2=80=99t define how or when verification = occurred. >> =20 >> Sure, they do. Look at the time and method fields.=20 >> =20 >> Since OpenId Connect for Identity Assurance (aka verified_claims) is = ongoing work feel free to contribute. >> =20 >> https://openid.net/wg/ekyc-ida/ = > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_DB236AF7-5E43-4A65-AA4C-DBF644E89944 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = got a chance to chat with Mike and I wanted to expand my off-the-cuff = response (below) with some more detail than I was able to write in the = moment, because I don=E2=80=99t think that we=E2=80=99re actually that = far apart. 

To = start, it wasn=E2=80=99t obvious to me (and might not have been to = others) the specific precision of Mike=E2=80=99s statement below. He = clarified to me that what he means is that where user claims are signed = or encrypted, then JWT provides an obvious way to do it. In other words, = =E2=80=9Cdon=E2=80=99t re-invent the ID Token with new crypto=E2=80=9D. = There are several things to address here with that in mind.

First, I don=E2=80=99t = believe there are going to be many, if any, cases where we need user = claims to be signed and encrypted separately from the core transaction = messages. Even in OIDC, the ID Token is allowed to be unsigned when it = is retrieved from the token endpoint directly using the code flow. The = equivalent of this is the only place that TxAuth would be sending back = user claims directly. We no longer have a need to protect things as they = travel through the front channel on a redirect, and we no longer have a = need to use the user=E2=80=99s claims as an artifact for things like = session management (we can define a new artifact for that purpose that = fits better). This effectively means that we don=E2=80=99t need to = redefine the ID Token because we don=E2=80=99t need the equivalent of = the ID token in the same way. For the cases that we do need to define = user claims, we should be defining them as a JSON object model. And I = also believe that this JSON data model should not be intertwined with or = constrained by the JWT claims registry. The OIDC claims registry can = serve as influence and input to our user claims set if we choose, but I = don=E2=80=99t think we should be intertwined with that either.

Second, in spite of the = success of OIDC, there are several formats out there for user claims = beyond JWT and JOSE. Verifiable Credentials (VC, https://www.w3.org/TR/vc-data-model/) is one that has = several different formats, and we are also seeing systems built up = around COSE and CBOR (like IPLD, https://ipld.io/). Or you could even use a SAML document. = I don=E2=80=99t think TxAuth should pick just one of these. Instead, I = want TxAuth to define places to put these formats in requests and = responses. In my draft there=E2=80=99s a spot for an OIDC style ID Token = or a VC document, if you have one. Within each of these, by all means, = let=E2=80=99s lock them down and say that the =E2=80=9Coidc_id_token=E2=80= =9D field is a JWT in compact format that MUST be signed, etc. And I = think it makes little sense to invent our own custom format to do = exactly that kind of thing. 

Third, I agree that we shouldn=E2=80=99t = re-invent an existing crypto format, and I=E2=80=99ll go further that we = shouldn=E2=80=99t be inventing crypto at all. This doesn=E2=80=99t mean = we have to pick one and only one, because this is one of the spaces that = we can (and I argue should) have some agility. We can define the = protocol in terms of JSON and then have a suite of cryptographic = carriers that protect that JSON, including JOSE, HTTP Message = Signatures, and Mutual TLS. There are a bunch of others out there as = well, like the DPoP key presentation coming out of OAuth 2 right now, = that should be switchable as options here because they=E2=80=99re going = to apply to different use cases and deployments. Plus, that JSON could = be translated to CBOR (without data or structure loss) and protected by = COSE =E2=80=94 even if we don=E2=80=99t define that ourselves, the fact = that we=E2=80=99re building our structure on raw JSON means that it can = be translated more easily later.

Fourth, I am very sensitive to calling = out preferred crypto solutions because I believe that lends to us using = that as an excuse to use that particular hammer to solve all the = problems. There have been proposals to make the entire protocol JWTs in = all directions, for instance, that I think are really problematic = because of the limits that it places on expression of items outside of = the payload itself. This is not what Mike is suggesting below, but = it=E2=80=99s a potential fallout from what he does propose.



In conclusion, JOSE and = JWT are fantastic and they solve a lot of problems in an elegant way. = But I think we need to question whether we need their solutions at all, = and where we do, if we want to enable other solutions as well. In my = view, we don=E2=80=99t need JOSE/JWT because we avoid the problems that = they solve, and the places that we do want to use them I strongly = believe there are already other alternatives that we want to have as = options. 

So I want to have JOSE, but it needs to be in the right = places and I do not want it to be a dependency on all implementations. I = think that we can do that without saying JWT is a preferred format. I = think it=E2=80=99s more important that the charter incorporate specific = text of what=E2=80=99s out of scope, including defining a cryptographic = protection mechanism. 

One of the hardest things for a standard to do is determine = where the flexibility should be. My stance is that we should have a = structural format based on JSON but that the contents of that JSON are = extensible but that each portion and extension are very strict about = what=E2=80=99s there. Another key flexible point is that the content of = the JSON-based payloads can be protected in a variety of ways. Choice = can be debilitating, but it can also be freeing. Pinning everything to = JOSE would do us a disservice. 

 =E2=80=94 Justin

On Jan 29, 2020, at 10:05 AM, Justin Richer <jricher@mit.edu> = wrote:

I strongly object to = calling out JWTs as the preferred solution for signed and encrypted = claims within this working group.

 =E2=80=94 Justin

On Jan = 29, 2020, at 9:50 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for writing these = detailed questions, Kim.  I believe that they point out a number of = places where even experts in the field, such as yourself, currently have = trouble understanding parts of what the charter is proposing that we do = =E2=80=93 partially because terminology is used that isn=E2=80=99t = commonly understood.  I hope that the draft charter will be revised = to make the intent and the goals more accessible and less ambiguous.
 
Responding = to the discussion on whether existing JWT identity claims will do the = job or not, fortunately, even if they don=E2=80=99t, there=E2=80=99s a = mechanism to add ones that do: the IANA JSON Web Token Claims registry = at https://www.iana.org/assignments/jwt/jwt.xhtml#claims. = ; For instance, an =E2=80=9Cemail_addresses=E2=80=9D claim that is = array-valued could be defined and registered if there=E2=80=99s a need = to represent multiple e-mail addresses, per Annabelle=E2=80=99s = example.  The further good news is that if the working group = defines new claims that are registered, they can be reused by others = also using JWTs =E2=80=93 just like this working group can reuse claims = defined by others.
 
Also on the = subject of JWTs, I would suggest that the charter be updated to = explicitly call out that JWTs will be the working group=E2=80=99s = preferred representation signed and/or encrypted claims.
 
Finally, I = also think that the charter would benefit from explicitly listing things = that are out of scope (which is often done in charters).
 
Thanks = again for prompting this useful discussion, Kim.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Justin = Richer
Sent: Wednesday, January 29, 2020 = 12:46 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>Cc: Kim <kim@identityblog.com>; = Dick Hardt <dick.hardt@gmail.com>; txauth@ietf.org; Richard Backman, Annabelle = <richanna=3D40amazon.com@dmarc.ietf.org>
Subject: [EXTERNAL] Re: [Txauth] = Questions on the TxAuth charter
 
I didn=E2=80=99t mean =E2=80=9Cpatch=E2=80=9D to sound = disparaging, sorry if it came across as such. What I mean by = =E2=80=9Cpatching=E2=80=9D here is that it is adding functionality to an = existing set of claims and schema. If you are using that schema as a = base, it makes sense as a viable solution in that space. I, however, am = bringing up the question of whether we are using that schema as our base = at all.
 
I=E2=80=99ll note that 8112 doesn=E2=80=99= t define a schema or syntax, both of which are required. But if we were = starting OIDC today with EKYC=E2=80=99s requirements, I=E2=80=99m not = convinced we=E2=80=99d end up with the same structure. 
 
As with everything, it=E2=80=99s a very = important input into what we=E2=80=99re trying to solve, especially = influencing what=E2=80=99s extensible and how.
 
 =E2=80=94 Justin


On Jan 29, 2020, at 8:06 AM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:
 
 


Am = 29.01.2020 um 07:34 schrieb Justin Richer <jricher@mit.edu>:

=EF=BB=BFI think the ekyc work is great for what it is, but = again we have an opportunity to take a step beyond it. In my view, = we=E2=80=99d be better off defining a means of specifying field metadata = a la NIST IR 8112 as part of the schema instead of patching the existing = OIDC fields. https://pages.nist.gov/NISTIR-8112/
 
We tried and it did not fulfill our requirements. = verified_claims is by no means a patch, it=E2=80=99s a viable = solution.


 
 =E2=80=94 Justin


On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:
 
 


Am = 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:

The ..._verified claims don=E2=80=99t define how or when = verification occurred.
 
Sure, they do. Look at the = time and method fields. 
 
Since OpenId Connect for Identity Assurance (aka = verified_claims) is ongoing work feel free to contribute.
 
https://openid.net/wg/ekyc-ida/

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

= --Apple-Mail=_DB236AF7-5E43-4A65-AA4C-DBF644E89944-- From nobody Wed Jan 29 04:32: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 74CE912010F for ; Wed, 29 Jan 2020 04:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 3woYRSUH7fvc for ; Wed, 29 Jan 2020 04:32:16 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2D5120108 for ; Wed, 29 Jan 2020 04:32:16 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id n18so18232656ljo.7 for ; Wed, 29 Jan 2020 04:32:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YB1+0i8xQWp3pscCHzuSwukwaZ4KPs2FdDS1du9eXuk=; b=bzf6/374ORJggGjtWcWRUorWsUYNP97gdkIcdNQp3CXjr06li80yqYKkOqqh9Bo4kJ JHbhIeezF/6se6L0pEvgPbMHlWjY6WgPgmVyZCJGFLzuEoitNuUji9sm4edSSGlEvImO eDKGqy73u1OkaS9QXIrf6GDPWahHP+Z1s17A1hF8valdA1/v8QI2S1w3go+pqx24N1D/ 8OCQITIdCO4OFmbfxEKLdiW/vjYbnoiqItjS9J5bKVIou+RLetzG3U2vRQFkVHRbDztc GftkUHMJbeCwgANIsgDl+JNDUwiUpj4+Spk5Yz8Vd3Z3XLR58DQk+iMlo4QKRRFGXkKF zFmg== 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=YB1+0i8xQWp3pscCHzuSwukwaZ4KPs2FdDS1du9eXuk=; b=b1vRe//exJR6JSNuJVYwdf0aCP7dmLI5wPyS1JWJUjsyWXI4TLOgRz125PeG0c6fY0 ULVFFYFIk1NQc0FDzAImKO2Nfi3ahaqeYm+HlZrBHNREOaaw26qHSYOlttjIpU1ZrHCZ 3K74Hm3yPdkOKdkuSlIdZf2Os+sCs3bpCA0YRFmrIn+xUFK4lLtrhKg7sy6esALKi1xr nAj2Bq+/Ez2UY+uf82cxc7ePT5qcBqIIPcbX8LQQ5xnOKAL3blitAh+dEl5gn41cHtKW zJaGBYjE4Dz1SSJotANcfehhHg+1weBJzCcNiK6KtwqndBh8/BKMqfNlrA8FNAXDXqd8 AwoQ== X-Gm-Message-State: APjAAAWOSL3ioC2PB7CVfYGzKvIgvnUbw8BbXD6nfUVb2F15p1hD2755 60L7EeMMHBKbf+1Jrf0LlrV3kYx/jUoBvjRliEI= X-Google-Smtp-Source: APXvYqxzjkhQ91Lh/62BpxHwvEqwWcFxHex+k+k/KX/FOAdJ9nUK07/jnIYWIxrZLzLLbDS2RcXkMRPpGBcJoshVvHA= X-Received: by 2002:a2e:84d0:: with SMTP id q16mr16488605ljh.138.1580301134256; Wed, 29 Jan 2020 04:32:14 -0800 (PST) MIME-Version: 1.0 References: <7ED74044-CA39-437C-8844-1C16DB3B1EC7@lodderstedt.net> In-Reply-To: <7ED74044-CA39-437C-8844-1C16DB3B1EC7@lodderstedt.net> From: Dick Hardt Date: Wed, 29 Jan 2020 04:32:03 -0800 Message-ID: To: Torsten Lodderstedt Cc: Roman Danyliw , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bedf67059d4687e2" Archived-At: Subject: Re: [Txauth] TxAuth Charter (Take 3.5) 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, 29 Jan 2020 12:32:18 -0000 --000000000000bedf67059d4687e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Let me know your thoughts after you have read it. :) On Tue, Jan 28, 2020 at 11:04 PM Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > > > Am 29.01.2020 um 07:01 schrieb Dick Hardt : > > =EF=BB=BF > > > On Tue, Jan 28, 2020 at 9:09 PM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> >> >> > Am 29.01.2020 um 02:13 schrieb Dick Hardt : >> > >> > All identity claim use cases. A set of these are solved by OpenID >> Connect, which is an extension to OAuth 2.0. TxAuth would also be a >> superset of OpenID Connect in addition to OAuth. >> >> Don=E2=80=99t you think this would make TxAuth a bit complicated? What w= ould be >> the benefit? > > > Not any more than today, as many consumer IdPs have both in the same > flows, and that is what is in the proposed charter. > > Having the information all in one document would make it simpler to > implement and understand. > > > I doubt. If i calculate the size of all relevant oauth specs + all > relevant openid connect specs (including verified claims), that will most > likely be a multi 100 pages spec that few people will fully understand an= d > be able to review/contribute to and fully & correctly implement. > > Modularity and extensibility is key to success of this initiative. > > Did you have chance to look at XAuth Torsten? > > > Not in detail. > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --000000000000bedf67059d4687e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Let me know your thoughts after you have read it. :)=

On Tue, Jan 28, 2020 at 11:04 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:<= br>
=

Am 29.01.2020 um 0= 7:01 schrieb Dick Hardt <dick.hardt@gmail.com>:

=EF=BB=BF


On Tue, Jan 28, 2020 at 9:09 PM Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:


> Am 29.01.2020 um 02:13 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> All identity claim use cases. A set of these are solved by OpenID Conn= ect, which is an extension to OAuth 2.0. TxAuth would also be a superset of= OpenID Connect in addition to OAuth.

Don=E2=80=99t you think this would make TxAuth a bit complicated? What woul= d be the benefit?

Not any more than today, as many consumer IdPs have both in the same flows= , and that is what is in the proposed charter.=C2=A0

Having the information all in one document would make it si= mpler to implement and understand.


I doubt. If i calculate the size of all rel= evant oauth specs + all relevant openid connect specs (including verified c= laims), that will most likely be a multi 100 pages spec that few people wil= l fully understand and be able to review/contribute to and fully & corr= ectly implement.

Modularity and extensibility is key to = success of this initiative.

Did you = have chance to look at XAuth Torsten?

Not in detail.
--000000000000bedf67059d4687e2-- From nobody Wed Jan 29 08:26: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 90F8A1200B8 for ; Wed, 29 Jan 2020 08:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ivpPBDUniTtx for ; Wed, 29 Jan 2020 08:26:28 -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 21019120088 for ; Wed, 29 Jan 2020 08:26:28 -0800 (PST) Received: from [10.38.98.116] ([83.219.75.72]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00TGQJnx031660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jan 2020 11:26:22 -0500 From: Justin Richer Message-Id: <05467DBA-1B21-4F05-94EC-833C6E3FEBFB@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_885217E2-3882-4478-9E97-B2C9559C4FBD" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 29 Jan 2020 17:26:15 +0100 In-Reply-To: Cc: txauth@ietf.org, Benjamin Kaduk , "rdd@cert.org" , Yaron Sheffer To: Dick Hardt References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XAuth - a revision 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, 29 Jan 2020 16:26:34 -0000 --Apple-Mail=_885217E2-3882-4478-9E97-B2C9559C4FBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As Dick has mentioned, I gave him some early feedback on this draft = before publication, and he=E2=80=99s asked me to write up my thoughts = and responses on the current XAuth proposal that=E2=80=99s published = here. 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 The short version is that I think that both XYZ and XAuth should be seen = as inputs to TxAuth, but I prefer and recommend XYZ for a number of = specific reasons and differences. I also do not see XAuth and XYZ as the = same, as stated in a previous email on this thread. I think XAuth has an interesting take on the problem space that TxAuth = is looking to solve, but in my opinion it generally veers too closely to = OAuth2/OIDC/JWT in its solution approach. It=E2=80=99s got some good = ideas, though, and things that we should consider, as well as a lot of = things that I don=E2=80=99t think are good ideas, or are regressions to = old ideas that I specifically think we should move beyond.=20 I=E2=80=99ll start with things that I like and that we should look at: 1. XAuth returns a follow-up URL (actually two) with a transaction. This = is something I considered with XYZ specifically to deal with revocation. = This is something that I think is tractable if we do it right, and = we=E2=80=99ll have to be careful about the privacy and security = implications of this. Also, just like XYZ, calling this endpoint has to = require the client to authenticate in the same way (ie, with the same = key and method) that it used to start the request with. 2. XAuth has a separate request mechanism for user claims. I have been = struggling with a way to have a request that results in an access token = (the classical OAuth 2 model) and something that extends the request and = response in a parallel way is a good thing. I like this more than what = OIDC does, which is extend the =E2=80=9Cscope=E2=80=9D field.=20 But there are a lot more things that I think it doesn=E2=80=99t get = quite right. These aren=E2=80=99t just syntactical or = normative-reference issues, as I believe they speak to a very different = underlying model and set of assumptions.=20 1. XAuth removes =E2=80=9Chandles=E2=80=9D as stand-ins for various = elements. In XYZ, the =E2=80=9Chandle=E2=80=9D concept is a key = abstraction point with specific semantics. A =E2=80=9Chandle=E2=80=9D is = an identifier to a specific instantiation of a JSON object structure. = Using the =E2=80=9Chandle=E2=80=9D for Keys, for Resources, and even the = whole Transaction lets you do a lot of core things in a parallel and = reusable way. XAuth re-invents a few of these as separate items, listed = below, and I see this as a regression. 2. XAuth uses a Client ID from OAuth 2. I removed Client IDs from XYZ = because I realized that you don=E2=80=99t need them anymore. The client = ID tells the AS which client is talking in the front channel because the = client can=E2=80=99t authenticate. In the back channel, the key (or = secret) identifier is enough to identify the client =E2=80=94 that=E2=80=99= s the Key Handle in XYZ that can be passed in lieu of the key itself. = The argument that it=E2=80=99s helpful to have an identifier for doing = developer support and managing registrations is spurious, since this is = an internal identifier that never needs to be exposed by the protocol. = Additionally, a client ID assumes a registration-based model. There are = ephemeral and per-device client instances like SPA=E2=80=99s and mobile = apps that don=E2=80=99t really fit the client ID model very well. = Pushing this requirement on all clients is bad, as we=E2=80=99ve seen in = OAuth 1 and OAuth 2. XAuth tries to manage this by splitting clients = into two camps, but I=E2=80=99m saying that no client needs and external = client ID. 3. XAuth uses a =E2=80=9Ctype=E2=80=9D field for interaction. This means = the client can only do one type of interaction for any given = transaction. XYZ started like this, but we moved away from it because we = realized we could have a client app that could handle multiple types = without that kind of dispatch. In XYZ the client sends over flags for = each kind of interaction it can do: send the user to an arbitrary URL, = give the user a code, get a callback from a browser, etc. Combining = these in specific ways addresses all of the different methods that XAuth = identifies as its types while also allowing additional things. The AS = picks from the client=E2=80=99s list based on what the AS can support as = well as what makes sense for the policies governing the requested = access. 4. XAuth allows OAuth-style scopes next to RAR-style data structures = (and next to OIDC claims structures). They are treated as completely = separate from each other. In OAuth 2, RAR is defined in the context of = scope (and resource and audience and other parameters), and this = combination is a matter of some debate still that needs to be solved. = However, it=E2=80=99s clear that they=E2=80=99re combined. In XYZ, the = only resource request defined is the object inside the resource request. = You can mimic =E2=80=9Cscope=E2=80=9D behavior by using a Resource = Handle, which again is defined as a single string that stands in for the = whole object and could be defined by the AS (or the API it=E2=80=99s = protecting).=20 5. The different kinds of authz requests in (4) create separate = tokens.This is very different from both OAuth 2 and XYZ, where you get = back a single access token. And in XAuth there is no way to get, for = example, two access tokens that are both described by RAR requests, so = this seems like a very arbitrary and syntactically-driven separation.=20 6. The assumption that JOSE will always be in the toolkit of the client = developer is not true. You can do an XYZ transaction without any JOSE = =E2=80=94 for example, using HTTP Sig or MTLS for key presentation.=20 7. The statement that =E2=80=9Cthere is no HTTP signing=E2=80=9D is = false, as this is being brought up to the HTTP WG right now (I=E2=80=99m = one of the co-authors). Yes, it=E2=80=99s not an RFC, but neither is = this. And if we=E2=80=99re doing agile signature methods, which I = contend is a required extension point, then we don=E2=80=99t have a = dependency requirement for it.=20 8. XAuth adds back in an explicit =E2=80=9Crefresh token=E2=80=9D. In = XYZ, we don=E2=80=99t have a refresh token because we can use the = transaction handle to continue the transaction after a token has been = issued. This has explicit and clear semantics that follows from what the = transaction handle is used for elsewhere in the protocol =E2=80=94 = continue this request that=E2=80=99s in some authorization state and = give me the results.=20 9. XAuth uses OIDC=E2=80=99s ID Token. As I=E2=80=99ve said on the other = thread, I don=E2=80=99t think we actually need a separately signed = assertion. I=E2=80=99d rather see a way to sign the entire response = which includes the user claims, if we want signature protection. 10. XAuth sends all the user=E2=80=99s claims on the login request =E2=80=94= or more precisely, this is the only mechanism specified and the = Rationale section claims this is a feature. This violates minimal = disclosure and privacy design guidelines, and this type of protocol has = been developed before with OpenID 1.x/2.x and SAML. The problem here = unfolds when you think about how it works: The RP needs to log in. If = this is the first time it=E2=80=99s seen this user, then it needs the = user=E2=80=99s profile info. If not, and the profile info hasn=E2=80=99t = changed, there=E2=80=99s no need for it and the AS shouldn=E2=80=99t = send it. So the RP can signal this, right? Except that the RP doesn=E2=80=99= t know who the user is yet (that=E2=80=99s why they=E2=80=99re making = this call!). Can the AS make this call? They won=E2=80=99t know if the = RP has cached the user=E2=80=99s info or not. And if we=E2=80=99re using = Client ID, then the AS can=E2=80=99t even be sure that this copy of the = client is the same as another copy of the client. I think TxAuth needs = to minimize the user claims sent back to being an identifier, = information about the authentication event that could change each time = anyway, and anything that would be needed to control a cache. Additional = fields can be pulled from the equivalent of a UserInfo Endpoint in a = two-stage process that both preserves privacy and optimizes for what=E2=80= =99s available from each party. 11. XAuth defines an explicit discovery step because the client now = needs to know several things about the server. The mix-up attack and a = few other attacks in OAuth 2 stem from this kind of process. In XYZ, the = client really only needs to know the transaction endpoint URL and it = learns everything else from that point. Yes, the client needs to = discover that someplace =E2=80=94 but it was a deliberate decision in = limiting the amount of upfront information that the client needs to get = started. I=E2=80=99ve played with the concept of a =E2=80=9Ccapabilities=E2= =80=9D list in XYZ, where the client would present a list of things it = can do and the AS trims that list to what it can also do. This type of = one-stage negotiation is really powerful and I think we can get a lot = from it here. All in all, thanks for the draft. I think it raises important questions = and the discussion of these questions will help us build the best system = we can. =E2=80=94 Justin > On Jan 27, 2020, at 11:04 PM, Dick Hardt wrote: >=20 > Hello! >=20 > I riffed on Justin's draft and have created an alternative that has = the same core concept of secure communication of all parameters between = the Client and the AS. >=20 > https://tools.ietf.org/html/draft-hardt-xauth-protocol-00 = >=20 > A goal of this document was to be as self contained as possible. > Everything needed to implement is included if an implementor is are = already familiar with OAuth 2.0 or OpenID Connect, and wants to migrate = to XAuth.=20 >=20 > To meet that goal, JOSE was chosen as the default mechanism for the = Client to authenticate to the AS, and to perform PoP access to a = resource. The JOSE specific aspects are in one section, so that an = extension can easily specify other Client authentication mechanisms. >=20 > There are likely numerous editorial and syntactical errors, and as we = all know -- naming is hard -- so feel free to suggest better names. >=20 > There are lots of issues with normative language, many of which I am = not aware of yet! >=20 > I've revised the document a number of times, and may have old terms = dangling around. Please let me know if there is something confusing, or = contradictory! >=20 > /Dick >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_885217E2-3882-4478-9E97-B2C9559C4FBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = Dick has mentioned, I gave him some early feedback on this draft before = publication, and he=E2=80=99s asked me to write up my thoughts and = responses on the current XAuth proposal that=E2=80=99s published = here.

To = disambiguate between different efforts, I=E2=80=99ll refer to Dick=E2=80=99= s draft as XAuth, my own draft as XYZ, and the proposed working group = work here (as in our eventual output) as TxAuth. 

The short version is = that I think that both XYZ and XAuth should be seen as inputs to TxAuth, = but I prefer and recommend XYZ for a number of specific reasons and = differences. I also do not see XAuth and XYZ as the same, as stated in a = previous email on this thread.

I think XAuth has an interesting take = on the problem space that TxAuth is looking to solve, but in my opinion = it generally veers too closely to OAuth2/OIDC/JWT in its solution = approach. It=E2=80=99s got some good ideas, though, and things that we = should consider, as well as a lot of things that I don=E2=80=99t think = are good ideas, or are regressions to old ideas that I specifically = think we should move beyond. 



I=E2=80=99ll start with things that I = like and that we should look at:

1. XAuth returns a follow-up URL = (actually two) with a transaction. This is something I considered with = XYZ specifically to deal with revocation. This is something that I think = is tractable if we do it right, and we=E2=80=99ll have to be careful = about the privacy and security implications of this. Also, just like = XYZ, calling this endpoint has to require the client to authenticate in = the same way (ie, with the same key and method) that it used to start = the request with.

2. XAuth has a separate request mechanism for user claims. I = have been struggling with a way to have a request that results in an = access token (the classical OAuth 2 model) and something that extends = the request and response in a parallel way is a good thing. I like this = more than what OIDC does, which is extend the =E2=80=9Cscope=E2=80=9D = field. 


But= there are a lot more things that I think it doesn=E2=80=99t get quite = right. These aren=E2=80=99t just syntactical or normative-reference = issues, as I believe they speak to a very different underlying model and = set of assumptions. 

1. XAuth removes =E2=80=9Chandles=E2=80=9D as stand-ins for = various elements. In XYZ, the =E2=80=9Chandle=E2=80=9D concept is a key = abstraction point with specific semantics. A =E2=80=9Chandle=E2=80=9D is = an identifier to a specific instantiation of a JSON object structure. = Using the =E2=80=9Chandle=E2=80=9D for Keys, for Resources, and even the = whole Transaction lets you do a lot of core things in a parallel and = reusable way. XAuth re-invents a few of these as separate items, listed = below, and I see this as a regression.

2. XAuth uses a Client ID from OAuth 2. = I removed Client IDs from XYZ because I realized that you don=E2=80=99t = need them anymore. The client ID tells the AS which client is talking in = the front channel because the client can=E2=80=99t authenticate. In the = back channel, the key (or secret) identifier is enough to identify the = client =E2=80=94 that=E2=80=99s the Key Handle in XYZ that can be passed = in lieu of the key itself. The argument that it=E2=80=99s helpful to = have an identifier for doing developer support and managing = registrations is spurious, since this is an internal identifier that = never needs to be exposed by the protocol. Additionally, a client ID = assumes a registration-based model. There are ephemeral and per-device = client instances like SPA=E2=80=99s and mobile apps that don=E2=80=99t = really fit the client ID model very well. Pushing this requirement on = all clients is bad, as we=E2=80=99ve seen in OAuth 1 and OAuth 2. XAuth = tries to manage this by splitting clients into two camps, but I=E2=80=99m = saying that no client needs and external client ID.

3. XAuth uses a = =E2=80=9Ctype=E2=80=9D field for interaction. This means the client can = only do one type of interaction for any given transaction. XYZ started = like this, but we moved away from it because we realized we could have a = client app that could handle multiple types without that kind of = dispatch. In XYZ the client sends over flags for each kind of = interaction it can do: send the user to an arbitrary URL, give the user = a code, get a callback from a browser, etc. Combining these in specific = ways addresses all of the different methods that XAuth identifies as its = types while also allowing additional things. The AS picks from the = client=E2=80=99s list based on what the AS can support as well as what = makes sense for the policies governing the requested access.

4. XAuth allows = OAuth-style scopes next to RAR-style data structures (and next to OIDC = claims structures). They are treated as completely separate from each = other. In OAuth 2, RAR is defined in the context of scope (and resource = and audience and other parameters), and this combination is a matter of = some debate still that needs to be solved. However, it=E2=80=99s clear = that they=E2=80=99re combined. In XYZ, the only resource request defined = is the object inside the resource request. You can mimic =E2=80=9Cscope=E2= =80=9D behavior by using a Resource Handle, which again is defined as a = single string that stands in for the whole object and could be defined = by the AS (or the API it=E2=80=99s protecting). 

5. The different kinds = of authz requests in (4) create separate tokens.This is very different = from both OAuth 2 and XYZ, where you get back a single access token. And = in XAuth there is no way to get, for example, two access tokens that are = both described by RAR requests, so this seems like a very arbitrary and = syntactically-driven separation. 

6. The assumption that JOSE will always = be in the toolkit of the client developer is not true. You can do an XYZ = transaction without any JOSE =E2=80=94 for example, using HTTP Sig or = MTLS for key presentation. 

7. The statement that =E2=80=9Cthere is = no HTTP signing=E2=80=9D is false, as this is being brought up to the = HTTP WG right now (I=E2=80=99m one of the co-authors). Yes, it=E2=80=99s = not an RFC, but neither is this. And if we=E2=80=99re doing agile = signature methods, which I contend is a required extension point, then = we don=E2=80=99t have a dependency requirement for it. 

8. XAuth adds back in an = explicit =E2=80=9Crefresh token=E2=80=9D. In XYZ, we don=E2=80=99t have = a refresh token because we can use the transaction handle to continue = the transaction after a token has been issued. This has explicit and = clear semantics that follows from what the transaction handle is used = for elsewhere in the protocol =E2=80=94 continue this request that=E2=80=99= s in some authorization state and give me the = results. 

9. XAuth uses = OIDC=E2=80=99s ID Token. As I=E2=80=99ve said on the other thread, I = don=E2=80=99t think we actually need a separately signed assertion. = I=E2=80=99d rather see a way to sign the entire response which includes = the user claims, if we want signature protection.

10. XAuth sends all the user=E2=80=99s claims on = the login request =E2=80=94 or more precisely, this is the only = mechanism specified and the Rationale section claims this is a feature. = This violates minimal disclosure and privacy design guidelines, and this = type of protocol has been developed before with OpenID 1.x/2.x and SAML. = The problem here unfolds when you think about how it works: The RP needs = to log in. If this is the first time it=E2=80=99s seen this user, then = it needs the user=E2=80=99s profile info. If not, and the profile info = hasn=E2=80=99t changed, there=E2=80=99s no need for it and the AS = shouldn=E2=80=99t send it. So the RP can signal this, right? Except that = the RP doesn=E2=80=99t know who the user is yet (that=E2=80=99s why = they=E2=80=99re making this call!). Can the AS make this call? They = won=E2=80=99t know if the RP has cached the user=E2=80=99s info or not. = And if we=E2=80=99re using Client ID, then the AS can=E2=80=99t even be = sure that this copy of the client is the same as another copy of the = client. I think TxAuth needs to minimize the user claims sent back to = being an identifier, information about the authentication event that = could change each time anyway, and anything that would be needed to = control a cache. Additional fields can be pulled from the equivalent of = a UserInfo Endpoint in a two-stage process that both preserves privacy = and optimizes for what=E2=80=99s available from each = party.

11. XAuth defines an explicit = discovery step because the client now needs to know several things about = the server. The mix-up attack and a few other attacks in OAuth 2 stem = from this kind of process. In XYZ, the client really only needs to know = the transaction endpoint URL and it learns everything else from that = point. Yes, the client needs to discover that someplace =E2=80=94 but it = was a deliberate decision in limiting the amount of upfront information = that the client needs to get started. I=E2=80=99ve played with the = concept of a =E2=80=9Ccapabilities=E2=80=9D list in XYZ, where the = client would present a list of things it can do and the AS trims that = list to what it can also do. This type of one-stage negotiation is = really powerful and I think we can get a lot from it here.


All in all, thanks for = the draft. I think it raises important questions and the discussion of = these questions will help us build the best system we can.

 =E2=80=94 Justin


On Jan 27, 2020, at 11:04 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:

Hello!

I riffed = on Justin's draft and have created an alternative that has the same core = concept of secure communication of all parameters between the Client and = the AS.

https://tools.ietf.org/html/draft-hardt-xauth-protocol-00

A = goal of this document was to be as self contained as possible.
Everything needed to implement is included if an implementor = is are already familiar with OAuth 2.0 or OpenID Connect, and wants to = migrate to XAuth. 

To meet that goal, JOSE was chosen as the default mechanism = for the Client to authenticate to the AS, and to perform PoP access to a = resource. The JOSE specific aspects are in one section, so that an = extension can easily specify other Client authentication = mechanisms.

There are likely numerous editorial and syntactical errors, = and as we all know -- naming is hard -- so feel free to suggest better = names.

There = are lots of issues with normative language, many of which I am not aware = of yet!

I've = revised the document a number of times, and may have old terms dangling = around. Please let me know if there is something confusing, or = contradictory!

/Dick







= --Apple-Mail=_885217E2-3882-4478-9E97-B2C9559C4FBD-- From nobody Wed Jan 29 10:49: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 9E1281208DA for ; Wed, 29 Jan 2020 10:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 mnTU9Sz74RKT for ; Wed, 29 Jan 2020 10:48:56 -0800 (PST) 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 8DAEF1208D1 for ; Wed, 29 Jan 2020 10:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1580323737; x=1611859737; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D4OgsYkwkpnbSICSutDoQCTaOSchE9jYTj4fH/UqxFc=; b=UxNZ4KnnuelKKazKqReeX/uQaBJq/Ueyof/j/x7DGcMqWu/h1NHvPPU2 EZOGpZfHo02wLe2f93Cch81QxKAv4ULn54gerkSUWeN5kDoxDngWlzwYo UGkEUUXg6u9OqO3rsbQEFfj9dGT8XBnK2kUTfhtuLWTdFhagZDIVBAIln U=; IronPort-SDR: T5/pc/lPWzvXKfyybky3D018BPDIsUbXnj39xx2AeuXNKw7PdvbSJT1ral7XWu3Nm4Ut0+4R21 SoWAhyxPHnIQ== X-IronPort-AV: E=Sophos; i="5.70,378,1574121600"; d="scan'208,217"; a="13468559" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1d-f273de60.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 29 Jan 2020 18:48:56 +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-f273de60.us-east-1.amazon.com (Postfix) with ESMTPS id 84E4DA2982; Wed, 29 Jan 2020 18:48:53 +0000 (UTC) Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 29 Jan 2020 18:48:52 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 29 Jan 2020 18:48:52 +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.1367.000; Wed, 29 Jan 2020 18:48:52 +0000 From: "Richard Backman, Annabelle" To: Torsten Lodderstedt , "Richard Backman, Annabelle" CC: Kim , "txauth@ietf.org" , "Justin Richer" , Dick Hardt Thread-Topic: [Txauth] Questions on the TxAuth charter Thread-Index: AdXVdev1XhtwHfEhQu6tUSp4GGwQ5gAWC08AAAnkTQAAAa+NOQAZnT+AAAu1EgA= Date: Wed, 29 Jan 2020 18:48:52 +0000 Message-ID: <7735E1FF-B2E1-4AAF-A5D3-60432B8411E1@amazon.com> References: <3BA85F10-4D24-4682-BC97-AA8954CA24A5@amazon.com> 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.74] Content-Type: multipart/alternative; boundary="_000_7735E1FFB2E14AAFA5D360432B8411E1amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Questions on the 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: Wed, 29 Jan 2020 18:49:01 -0000 --_000_7735E1FFB2E14AAFA5D360432B8411E1amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3YXMgcmVmZXJyaW5nIHRvIHRoZSBlbWFpbF92ZXJpZmllZCBhbmQgcGhvbmVfbnVtYmVyX3Zl cmlmaWVkIGNsYWltcyBkZWZpbmVkIGluIE9JREMgQ29yZS4gVGhlIG1lY2hhbmlzbXMgZGVmaW5l ZCBpbiBJQSBkb27igJl0IGFwcGVhciB0byBhcHBseSB0byB0aG9zZSBjbGFpbXMuIEFtIEkgbWlz c2luZyBzb21ldGhpbmc/DQoNCihJIGRvIGhhdmUgc29tZSBmZWVkYmFjayByZWdhcmRpbmcgY2xh aW1zIGluIElB4oCmZ2V0dGluZyBvbiB0aGUgSUEgd29ya2luZyBncm91cCBsaXN0IGFuZCBwcm92 aWRpbmcgaXQgaXMgb24gbXkgZmFyLXRvby1sb25nIHRvZG8gbGlzdOKApikNCuKAkw0KQW5uYWJl bGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogVHhhdXRoIDx0eGF1 dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRv cnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBUdWVzZGF5LCBK YW51YXJ5IDI4LCAyMDIwIGF0IDk6MTMgUE0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUiIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogS2ltIDxraW1A aWRlbnRpdHlibG9nLmNvbT4sICJ0eGF1dGhAaWV0Zi5vcmciIDx0eGF1dGhAaWV0Zi5vcmc+LCBK dXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+LCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdt YWlsLmNvbT4NClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBRdWVzdGlvbnMgb24gdGhlIFR4QXV0aCBj aGFydGVyDQoNCg0KDQoNCkFtIDI4LjAxLjIwMjAgdW0gMTg6MDAgc2NocmllYiBSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPjoN ClRoZSAuLi5fdmVyaWZpZWQgY2xhaW1zIGRvbuKAmXQgZGVmaW5lIGhvdyBvciB3aGVuIHZlcmlm aWNhdGlvbiBvY2N1cnJlZC4NCg0KU3VyZSwgdGhleSBkby4gTG9vayBhdCB0aGUgdGltZSBhbmQg bWV0aG9kIGZpZWxkcy4NCg0KU2luY2UgT3BlbklkIENvbm5lY3QgZm9yIElkZW50aXR5IEFzc3Vy YW5jZSAoYWthIHZlcmlmaWVkX2NsYWltcykgaXMgb25nb2luZyB3b3JrIGZlZWwgZnJlZSB0byBj b250cmlidXRlLg0KDQpodHRwczovL29wZW5pZC5uZXQvd2cvZWt5Yy1pZGEvDQo= --_000_7735E1FFB2E14AAFA5D360432B8411E1amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <56A0971E54DC4946B73369D39BF0BB91@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FzIHJl ZmVycmluZyB0byB0aGUgZW1haWxfdmVyaWZpZWQgYW5kIHBob25lX251bWJlcl92ZXJpZmllZCBj bGFpbXMgZGVmaW5lZCBpbiBPSURDIENvcmUuIFRoZSBtZWNoYW5pc21zIGRlZmluZWQgaW4gSUEg ZG9u4oCZdCBhcHBlYXIgdG8gYXBwbHkgdG8gdGhvc2UgY2xhaW1zLiBBbSBJIG1pc3Npbmcgc29t ZXRoaW5nPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oSSBkbyBoYXZlIHNvbWUgZmVlZGJhY2sg cmVnYXJkaW5nIGNsYWltcyBpbiBJQeKApmdldHRpbmcgb24gdGhlIElBIHdvcmtpbmcgZ3JvdXAg bGlzdCBhbmQgcHJvdmlkaW5nIGl0IGlzIG9uIG15IGZhci10b28tbG9uZyB0b2RvIGxpc3TigKYp PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ 4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPlR4YXV0aCAmbHQ7dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9u IGJlaGFsZiBvZiBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDt0b3JzdGVuPTQwbG9kZGVyc3RlZHQu bmV0QGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKYW51YXJ5 IDI4LCAyMDIwIGF0IDk6MTMgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O1JpY2hhcmQgQmFja21h biwgQW5uYWJlbGxlJnF1b3Q7ICZsdDtyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5LaW0gJmx0O2tpbUBpZGVudGl0eWJsb2cuY29tJmd0Oywg JnF1b3Q7dHhhdXRoQGlldGYub3JnJnF1b3Q7ICZsdDt0eGF1dGhAaWV0Zi5vcmcmZ3Q7LCBKdXN0 aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7LCBEaWNrIEhhcmR0ICZsdDtkaWNrLmhh cmR0QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtUeGF1dGhdIFF1ZXN0 aW9ucyBvbiB0aGUgVHhBdXRoIGNoYXJ0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ QW0gMjguMDEuMjAyMCB1bSAxODowMCBzY2hyaWViIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxl ICZsdDtyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgLi4uX3ZlcmlmaWVkIGNsYWltcyBkb27igJl0IGRlZmluZSBob3cgb3Igd2hlbiB2ZXJp ZmljYXRpb24gb2NjdXJyZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlN1cmUsIHRoZXkgZG8uIExvb2sgYXQgdGhlIHRpbWUgYW5kIG1ldGhv ZCBmaWVsZHMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNpbmNlIE9wZW5JZCBDb25uZWN0IGZvciBJZGVudGl0eSBBc3N1cmFuY2Ug KGFrYSB2ZXJpZmllZF9jbGFpbXMpIGlzIG9uZ29pbmcgd29yayBmZWVsIGZyZWUgdG8gY29udHJp YnV0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0iaHR0cHM6Ly9vcGVuaWQubmV0L3dnL2VreWMtaWRhLyI+aHR0cHM6Ly9vcGVu aWQubmV0L3dnL2VreWMtaWRhLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_7735E1FFB2E14AAFA5D360432B8411E1amazoncom_-- From nobody Wed Jan 29 11:45:38 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 01CA6120046 for ; Wed, 29 Jan 2020 11:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=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 vzge0bTVhR2j for ; Wed, 29 Jan 2020 11:45:31 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FD6120025 for ; Wed, 29 Jan 2020 11:45:31 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id a6so866068wrx.12 for ; Wed, 29 Jan 2020 11:45:30 -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=ye9dTYY5fNDQ+du7wD11/lOxur4UrB7Swda7k5XqCcQ=; b=by/0jn3G7gpEOdOfWt6aYypOoj4kHANaGvlvj0HRaRy/48FdN/fPD7gNwfklz/zm6e m8lHgO4LxWl8puJI4A+epWLFbqrmkcHNVER2Q0bUpX9fA8XsaWSu0vIjOWi1G4YmveEX hJy57dmVTz594M9r035D8ZEoieHcirCpZummp57uIg/4lQGiU1bt2qzb/SAKqTHGqheI 2XUHJXR00ExfNhNNYN+7F6mYvsFyOJ4PfMc86Hmts6q1A4NftIeviPo2SG7/8JuRlqZK upZomkJQcxoBBYoU3GyghYQfmZeZ6t+smAYaAE0c0xNSGHzrN+rLLxSNuGE3b+06Noxk qTiQ== 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=ye9dTYY5fNDQ+du7wD11/lOxur4UrB7Swda7k5XqCcQ=; b=X3j2YBg9x2crNnRJnloSbTL+x5OJmxaVMM1DCKXMnAAnnTioa4F31UCRsTYPPxx8pu oXqEldDdWCletmJxVt5rQqDhCABDSNI/c7BSWFyBQOdswbQhPgvYBGCzQsHk3yx7DD3j 1ptbUGObhC6KyUkvg47FKru0+Upd6xX/bVIDz2YUBD166mceH+95coSmfJkdy3wgWL0j FXBUhLpDo6kyMnRig8lxrPid5cTa0CSlaRNlGAjvLhhwbFVkY3A13M6SNfBe7I5NtAsY oxtEYTq/vePHb3Jv1Kk1WwPekQLV55lIBada0h9tJoTQil/ytLGSXJlfaQNxINTtM74p jN3g== X-Gm-Message-State: APjAAAWyXS95cjrrjz9EAo8tqnKQ2Wra1BA8rFp5iQeeTrmy7WEM4ZqE GiBwMiMLBVMbS7ozGZX0p5AhnLqARXUgWw== X-Google-Smtp-Source: APXvYqyG6G0hEZrgR2RYqAnDgp8SIv98a2MhINEcUAsq20eKqufLDnWkmwhnNM8Xse5oW5YTEaEziA== X-Received: by 2002:adf:cd92:: with SMTP id q18mr424308wrj.261.1580327129502; Wed, 29 Jan 2020 11:45:29 -0800 (PST) Received: from [192.168.71.107] (p549EEE29.dip0.t-ipconnect.de. [84.158.238.41]) by smtp.gmail.com with ESMTPSA id o7sm3423156wmh.11.2020.01.29.11.45.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jan 2020 11:45:28 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-3519BB70-AEA1-4B3A-9889-8E0C14CD98E4; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Wed, 29 Jan 2020 20:45:27 +0100 Message-Id: References: <7735E1FF-B2E1-4AAF-A5D3-60432B8411E1@amazon.com> Cc: Kim , "txauth@ietf.org" , Justin Richer , Dick Hardt In-Reply-To: <7735E1FF-B2E1-4AAF-A5D3-60432B8411E1@amazon.com> To: "Richard Backman, Annabelle" X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [Txauth] Questions on the 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: Wed, 29 Jan 2020 19:45:36 -0000 --Apple-Mail-3519BB70-AEA1-4B3A-9889-8E0C14CD98E4 Content-Type: multipart/alternative; boundary=Apple-Mail-14EFC6D7-349C-4574-BDDD-ABFD3B21DF75 Content-Transfer-Encoding: 7bit --Apple-Mail-14EFC6D7-349C-4574-BDDD-ABFD3B21DF75 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 29.01.2020 um 19:49 schrieb Richard Backman, Annabelle : >=20 > =EF=BB=BF > I was referring to the email_verified and phone_number_verified claims def= ined in OIDC Core. The mechanisms defined in IA don=E2=80=99t appear to appl= y to those claims. Am I missing something? Those claims pre-date OIDC4IDA. If they do not suite your needs, you may use= verified_claims to represent the verification status. It requires a trust f= ramework id determining the trust framework governing the verification along= with identifiers for verification methods etc. > =20 > (I do have some feedback regarding claims in IA=E2=80=A6getting on the IA w= orking group list and providing it is on my far-too-long todo list=E2=80=A6)= look forward to getting your feedback. > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: Txauth on behalf of Torsten Lodderstedt > Date: Tuesday, January 28, 2020 at 9:13 PM > To: "Richard Backman, Annabelle" > Cc: Kim , "txauth@ietf.org" , Justi= n Richer , Dick Hardt > Subject: Re: [Txauth] Questions on the TxAuth charter > =20 > =20 >=20 >=20 > Am 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle : >=20 > The ..._verified claims don=E2=80=99t define how or when verification occu= rred. > =20 > Sure, they do. Look at the time and method fields.=20 > =20 > Since OpenId Connect for Identity Assurance (aka verified_claims) is ongoi= ng work feel free to contribute. > =20 > https://openid.net/wg/ekyc-ida/ --Apple-Mail-14EFC6D7-349C-4574-BDDD-ABFD3B21DF75 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Am 29.01.2020 um 19:49 schrieb Richard Backma= n, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:

=EF=BB=BF

I was referring to the email_verified and phone_numbe= r_verified claims defined in OIDC Core. The mechanisms defined in IA don=E2=80= =99t appear to apply to those claims. Am I missing something?


Those claims pre-date OIDC4IDA. If they do not s= uite your needs, you may use verified_claims to represent the verification s= tatus. It requires a trust framework id determining the trust framework gove= rning the verification along with identifiers for verification methods etc.<= div>

 

(I do have some feedback regarding claims in IA=E2=80= =A6getting on the IA working group list and providing it is on my far-too-lo= ng todo list=E2=80=A6)


look forwa= rd to getting your feedback.

=

=E2=80=93 =

Annabelle Richard Ba= ckman

AWS Identity

 

 

From:= Txauth <txauth-b= ounces@ietf.org> on behalf of Torsten Lodderstedt <torsten=3D40lodders= tedt.net@dmarc.ietf.org>
Date: Tuesday, January 28, 2020 at 9:13 PM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ie= tf.org>
Cc: Kim <kim@identityblog.com>, "txauth@ietf.org" <txauth@ie= tf.org>, Justin Richer <jricher@mit.edu>, Dick Hardt <dick.hardt= @gmail.com>
Subject: Re: [Txauth] Questions on the TxAuth charter

 

 



Am 28.01.2020 um 18:00= schrieb Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.o= rg>:

The ..._verified claims don=E2=80=99t define how or w= hen verification occurred.

 

Sure, they do. Look at the time and method fields.&nb= sp;

 

Since OpenId Connect for Identity Assurance (aka veri= fied_claims) is ongoing work feel free to contribute.

 

= --Apple-Mail-14EFC6D7-349C-4574-BDDD-ABFD3B21DF75-- --Apple-Mail-3519BB70-AEA1-4B3A-9889-8E0C14CD98E4 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBTYw ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDGCA8cwggPDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0 aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAesw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTI5MTk0NTI3WjAv BgkqhkiG9w0BCQQxIgQgQ17Ky02Oxt2HN7ZYExU1jgHuNJy3M9c5fagWfyh4Lf4wgb0GCSsGAQQB gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQBTsjLn FNvJWNpOBnuw8H0WErO2sg9pPL5hgFUabJteQA3U5l6Exlb9v1WpWFHx5ajJwxX/uUiKZ2NWsCL5 BzKvVT+50WTDRlp3GQJhh3IP7ae/5pxU9QDuHNH32lbfqc0XzKpX0eT8Ri9QDI5MdVenTl2IzKhr HkUgQWxB7dCAMS/5l+ll0eNynk5fSCCFiuFcc/luC75ytfZ72Y9QWQ+EktsvygUbxMBik0cF/qdR pAhxhL6F2RI+QGsAQ5PD5DlEtl6fDas9QLUYLuF72LgIJ3JMQpjrq8vucA+xs+K3Ms8RMGJ1roPa lCoDBCiZn9rzGrOC70eOK2q6jk6wwIOcAAAAAAAA --Apple-Mail-3519BB70-AEA1-4B3A-9889-8E0C14CD98E4-- From nobody Wed Jan 29 12: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 19E831200E7 for ; Wed, 29 Jan 2020 12:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 nB7C-gYpP0Up for ; Wed, 29 Jan 2020 12:15:31 -0800 (PST) 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 8D0DB12008B for ; Wed, 29 Jan 2020 12:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1580328931; x=1611864931; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MtHSiyVpt373XOWd0nn4FOBTpJ+lneU83X+ZZYcWJaE=; b=K/XsjhF4j8WmGA6BX7+AaRsGTfTVnQq8GZLSXUdcAwfaY/x+NUBbaWCP E9W6XV11nybU9IJsSPMUp3aSQWSc+0IvLp87nXOvSQx5w5y8CdG798vBi paLFguTsovx8i5Gr/2xztEA4f46HiO6n1sf6n5IpjwiqCXxhfbmse5otz M=; IronPort-SDR: uHBBhj1oZtkjdvcQ9ylCKd1OTWeeBYY5oAKGLmNrZF4cRfvq5B96xZws1rXaPcIExMrIrggQ2y rlwQo4MNbEMQ== X-IronPort-AV: E=Sophos; i="5.70,379,1574121600"; d="scan'208,217"; a="21887042" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2b-a7fdc47a.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 29 Jan 2020 20:15:20 +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-a7fdc47a.us-west-2.amazon.com (Postfix) with ESMTPS id 6768DC2524; Wed, 29 Jan 2020 20:15:19 +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; Wed, 29 Jan 2020 20:15: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.1367.3; Wed, 29 Jan 2020 20:15: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.1367.000; Wed, 29 Jan 2020 20:15:18 +0000 From: "Richard Backman, Annabelle" To: Torsten Lodderstedt CC: Kim , "txauth@ietf.org" , "Justin Richer" , Dick Hardt Thread-Topic: [UNVERIFIED SENDER] Re: [Txauth] Questions on the TxAuth charter Thread-Index: AdXVdev1XhtwHfEhQu6tUSp4GGwQ5gAWC08AAAnkTQAAAa+NOQAZnT+AAAu1EgAAEr1tgP//gjoA Date: Wed, 29 Jan 2020 20:15:18 +0000 Message-ID: <981F5914-8757-4F76-8142-FD62A954F8C0@amazon.com> References: <7735E1FF-B2E1-4AAF-A5D3-60432B8411E1@amazon.com> 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.74] Content-Type: multipart/alternative; boundary="_000_981F591487574F768142FD62A954F8C0amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: Questions on the 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: Wed, 29 Jan 2020 20:15:34 -0000 --_000_981F591487574F768142FD62A954F8C0amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSB3ZWxsIGF3YXJlIG9mIHRoZSBmYWN0IHRoYXQgT0lEQyBDb3JlIHByZWRhdGVzIE9EQzRJ REEsIGFuZCB0aGF0IHRoZSBjbGFpbXMgSSBhbSByZWZlcnJpbmcgdG8gYXJlIGRlZmluZWQgaW4g dGhlIGZvcm1lciwgYXMgbm90ZWQgaW4gbXkgcHJldmlvdXMgbWVzc2FnZS4gVGVsbGluZyBtZSB0 byB1c2UgdmVyaWZpZWRfY2xhaW1zIGlzIG5vdCBoZWxwZnVsIHdoZW4gSeKAmXZlIGFscmVhZHkg c3RhdGVkIHRoYXQgSSBoYXZlIGxvb2tlZCBhdCB0aGF0IHNwZWMgYW5kIGl0IGRvZXMgbm90IGFw cGVhciB0byBhZGRyZXNzIG15IHVzZSBjYXNlLiBJ4oCZZCBhcHByZWNpYXRlIGxlc3MgY29uZGVz Y2Vuc2lvbiBhbmQgbW9yZSBhdHRlbnRpb24gdG8gbWVzc2FnZSBjb250ZW50LCB0aGFua3MuDQoN CuKAkw0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTog VG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRm Lm9yZz4NCkRhdGU6IFdlZG5lc2RheSwgSmFudWFyeSAyOSwgMjAyMCBhdCAxMTo0NSBBTQ0KVG86 ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb20+DQpDYzog S2ltIDxraW1AaWRlbnRpdHlibG9nLmNvbT4sICJ0eGF1dGhAaWV0Zi5vcmciIDx0eGF1dGhAaWV0 Zi5vcmc+LCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+LCBEaWNrIEhhcmR0IDxkaWNr LmhhcmR0QGdtYWlsLmNvbT4NClN1YmplY3Q6IFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtUeGF1 dGhdIFF1ZXN0aW9ucyBvbiB0aGUgVHhBdXRoIGNoYXJ0ZXINCg0KDQoNCg0KQW0gMjkuMDEuMjAy MCB1bSAxOTo0OSBzY2hyaWViIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00 MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+Og0K77u/DQpJIHdhcyByZWZlcnJpbmcgdG8gdGhl IGVtYWlsX3ZlcmlmaWVkIGFuZCBwaG9uZV9udW1iZXJfdmVyaWZpZWQgY2xhaW1zIGRlZmluZWQg aW4gT0lEQyBDb3JlLiBUaGUgbWVjaGFuaXNtcyBkZWZpbmVkIGluIElBIGRvbuKAmXQgYXBwZWFy IHRvIGFwcGx5IHRvIHRob3NlIGNsYWltcy4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KVGhv c2UgY2xhaW1zIHByZS1kYXRlIE9JREM0SURBLiBJZiB0aGV5IGRvIG5vdCBzdWl0ZSB5b3VyIG5l ZWRzLCB5b3UgbWF5IHVzZSB2ZXJpZmllZF9jbGFpbXMgdG8gcmVwcmVzZW50IHRoZSB2ZXJpZmlj YXRpb24gc3RhdHVzLiBJdCByZXF1aXJlcyBhIHRydXN0IGZyYW1ld29yayBpZCBkZXRlcm1pbmlu ZyB0aGUgdHJ1c3QgZnJhbWV3b3JrIGdvdmVybmluZyB0aGUgdmVyaWZpY2F0aW9uIGFsb25nIHdp dGggaWRlbnRpZmllcnMgZm9yIHZlcmlmaWNhdGlvbiBtZXRob2RzIGV0Yy4NCg0KDQoNCihJIGRv IGhhdmUgc29tZSBmZWVkYmFjayByZWdhcmRpbmcgY2xhaW1zIGluIElB4oCmZ2V0dGluZyBvbiB0 aGUgSUEgd29ya2luZyBncm91cCBsaXN0IGFuZCBwcm92aWRpbmcgaXQgaXMgb24gbXkgZmFyLXRv by1sb25nIHRvZG8gbGlzdOKApikNCg0KbG9vayBmb3J3YXJkIHRvIGdldHRpbmcgeW91ciBmZWVk YmFjay4NCg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0K DQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBU b3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYu b3JnPg0KRGF0ZTogVHVlc2RheSwgSmFudWFyeSAyOCwgMjAyMCBhdCA5OjEzIFBNDQpUbzogIlJp Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmll dGYub3JnPg0KQ2M6IEtpbSA8a2ltQGlkZW50aXR5YmxvZy5jb20+LCAidHhhdXRoQGlldGYub3Jn IiA8dHhhdXRoQGlldGYub3JnPiwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiwgRGlj ayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW1R4YXV0aF0gUXVl c3Rpb25zIG9uIHRoZSBUeEF1dGggY2hhcnRlcg0KDQoNCg0KDQoNCkFtIDI4LjAxLjIwMjAgdW0g MTg6MDAgc2NocmllYiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6 b24uY29tQGRtYXJjLmlldGYub3JnPjoNClRoZSAuLi5fdmVyaWZpZWQgY2xhaW1zIGRvbuKAmXQg ZGVmaW5lIGhvdyBvciB3aGVuIHZlcmlmaWNhdGlvbiBvY2N1cnJlZC4NCg0KU3VyZSwgdGhleSBk by4gTG9vayBhdCB0aGUgdGltZSBhbmQgbWV0aG9kIGZpZWxkcy4NCg0KU2luY2UgT3BlbklkIENv bm5lY3QgZm9yIElkZW50aXR5IEFzc3VyYW5jZSAoYWthIHZlcmlmaWVkX2NsYWltcykgaXMgb25n b2luZyB3b3JrIGZlZWwgZnJlZSB0byBjb250cmlidXRlLg0KDQpodHRwczovL29wZW5pZC5uZXQv d2cvZWt5Yy1pZGEvDQo= --_000_981F591487574F768142FD62A954F8C0amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0 IDIgNSA4IDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEwOTQwODQ3 NzU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE2MjEz NjExNjYgNTU5NDUyMzMwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSB3 ZWxsIGF3YXJlIG9mIHRoZSBmYWN0IHRoYXQgT0lEQyBDb3JlIHByZWRhdGVzIE9EQzRJREEsIGFu ZCB0aGF0IHRoZSBjbGFpbXMgSSBhbSByZWZlcnJpbmcgdG8gYXJlIGRlZmluZWQgaW4gdGhlIGZv cm1lciwgYXMgbm90ZWQgaW4gbXkgcHJldmlvdXMgbWVzc2FnZS4gVGVsbGluZyBtZSB0byB1c2Ug dmVyaWZpZWRfY2xhaW1zIGlzIG5vdCBoZWxwZnVsIHdoZW4gSeKAmXZlIGFscmVhZHkgc3RhdGVk IHRoYXQNCiBJIGhhdmUgbG9va2VkIGF0IHRoYXQgc3BlYyBhbmQgaXQgZG9lcyBub3QgYXBwZWFy IHRvIGFkZHJlc3MgbXkgdXNlIGNhc2UuIEnigJlkIGFwcHJlY2lhdGUgbGVzcyBjb25kZXNjZW5z aW9uIGFuZCBtb3JlIGF0dGVudGlvbiB0byBtZXNzYWdlIGNvbnRlbnQsIHRoYW5rcy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKAkyZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJv bTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ VG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5p ZXRmLm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKYW51YXJ5IDI5LCAyMDIw IGF0IDExOjQ1IEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFi ZWxsZSZxdW90OyAmbHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPktp bSAmbHQ7a2ltQGlkZW50aXR5YmxvZy5jb20mZ3Q7LCAmcXVvdDt0eGF1dGhAaWV0Zi5vcmcmcXVv dDsgJmx0O3R4YXV0aEBpZXRmLm9yZyZndDssIEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0 LmVkdSZndDssIERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5bVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbVHhhdXRoXSBRdWVzdGlvbnMg b24gdGhlIFR4QXV0aCBjaGFydGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkFtIDI5 LjAxLjIwMjAgdW0gMTk6NDkgc2NocmllYiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7 cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnJmd0Ozo8bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+77u/ IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgcmVmZXJyaW5nIHRv IHRoZSBlbWFpbF92ZXJpZmllZCBhbmQgcGhvbmVfbnVtYmVyX3ZlcmlmaWVkIGNsYWltcyBkZWZp bmVkIGluIE9JREMgQ29yZS4gVGhlIG1lY2hhbmlzbXMgZGVmaW5lZCBpbiBJQSBkb27igJl0IGFw cGVhciB0byBhcHBseSB0byB0aG9zZSBjbGFpbXMuIEFtIEkgbWlzc2luZyBzb21ldGhpbmc/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhvc2UgY2xhaW1zIHByZS1kYXRlIE9JREM0SURBLiBJZiB0aGV5IGRvIG5vdCBzdWl0ZSB5 b3VyIG5lZWRzLCB5b3UgbWF5IHVzZSB2ZXJpZmllZF9jbGFpbXMgdG8gcmVwcmVzZW50IHRoZSB2 ZXJpZmljYXRpb24gc3RhdHVzLiBJdCByZXF1aXJlcyBhIHRydXN0IGZyYW1ld29yayBpZCBkZXRl cm1pbmluZyB0aGUgdHJ1c3QgZnJhbWV3b3JrIGdvdmVybmluZyB0aGUgdmVyaWZpY2F0aW9uIGFs b25nIHdpdGggaWRlbnRpZmllcnMNCiBmb3IgdmVyaWZpY2F0aW9uIG1ldGhvZHMgZXRjLjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oSSBkbyBoYXZlIHNvbWUgZmVlZGJhY2sgcmVn YXJkaW5nIGNsYWltcyBpbiBJQeKApmdldHRpbmcgb24gdGhlIElBIHdvcmtpbmcgZ3JvdXAgbGlz dCBhbmQgcHJvdmlkaW5nIGl0IGlzIG9uIG15IGZhci10b28tbG9uZyB0b2RvIGxpc3TigKYpPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+bG9vayBmb3J3YXJkIHRvIGdldHRpbmcgeW91ciBmZWVkYmFjay48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJlbGxl IFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VHhhdXRoICZsdDt0eGF1dGgtYm91 bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3Rv cnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPlR1ZXNkYXksIEphbnVhcnkgMjgsIDIwMjAgYXQgOToxMyBQTTxicj4NCjxiPlRvOiA8L2I+ JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hPTQwYW1h em9uLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPktpbSAmbHQ7a2ltQGlk ZW50aXR5YmxvZy5jb20mZ3Q7LCAmcXVvdDt0eGF1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O3R4YXV0 aEBpZXRmLm9yZyZndDssIEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDssIERp Y2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5SZTogW1R4YXV0aF0gUXVlc3Rpb25zIG9uIHRoZSBUeEF1dGggY2hhcnRlcjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BbSAyOC4wMS4yMDIwIHVtIDE4OjAwIHNjaHJpZWIg UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFy Yy5pZXRmLm9yZyZndDs6PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSAuLi5fdmVyaWZpZWQgY2xhaW1zIGRvbuKA mXQgZGVmaW5lIGhvdyBvciB3aGVuIHZlcmlmaWNhdGlvbiBvY2N1cnJlZC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VyZSwgdGhleSBkby4g TG9vayBhdCB0aGUgdGltZSBhbmQgbWV0aG9kIGZpZWxkcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2UgT3BlbklkIENvbm5l Y3QgZm9yIElkZW50aXR5IEFzc3VyYW5jZSAoYWthIHZlcmlmaWVkX2NsYWltcykgaXMgb25nb2lu ZyB3b3JrIGZlZWwgZnJlZSB0byBjb250cmlidXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL29wZW5pZC5uZXQv d2cvZWt5Yy1pZGEvIj5odHRwczovL29wZW5pZC5uZXQvd2cvZWt5Yy1pZGEvPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_981F591487574F768142FD62A954F8C0amazoncom_-- From nobody Wed Jan 29 12: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 8D138120045 for ; Wed, 29 Jan 2020 12:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 ihggbKyc0HxK for ; Wed, 29 Jan 2020 12:50:24 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB12120024 for ; Wed, 29 Jan 2020 12:50:23 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id x7so922172ljc.1 for ; Wed, 29 Jan 2020 12:50: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=a/YoTWdto3+uDsrGugp4IQ+qUMlLlrSXNUDCR9AJKF4=; b=SA23bhk+yyoszBsxNhJowL9u2B60Fb1Ra3m8UgfrCKPFQpr7o+KMYh8GbgZAhnqjhP bAbhCc4veca1D87xBKgN+cZvlu7Tpk+tF/iqnz8KCaF0xLpkTXtivGUbgNir7h6P3yOZ j7nVYEru/+OwsQzUO+FJ2HInoZBO0Cz6znkOEW8sAcOD7iomR3H1eBxmysrVTjNamadC Z06OOTYV43dijgMpqZx0PIVyTlNb64SrC+4K1uIsERXphELBBxEucWvfzTgITA6TNbZL ncIVRbvP5pSbHA/QPKI2JyHMHM8CljaZphwGozo6PlM7Hcwe3wYs3022BZQtd9xy1vgt +gew== 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=a/YoTWdto3+uDsrGugp4IQ+qUMlLlrSXNUDCR9AJKF4=; b=rx+LmQmEXZZAbgHGfjXy8Pgl/jym+oOItzSSzf7RBDpsXV6wbHr3Y5hZFCIAFi8fcr ahtfH9R7Jxl3E0o8NDogl2VeX+SA+6hv4uCIY8u21AVXI7jW00j7N6L1zbS0gxGayqEz cpDodK6C+eZEf8ytoTSfNCLDPzcSpcC/n2Hi3g0iem2zfu/2JdMQUKJ6PnH/vUn7FkX7 ivTIO0PaC6SC6T24GTxdJO8XqdOBHhkdFiVY9t54qcZFbZCxAtHQCltEF+DWFTfFdM/z u5LaJv+qarkhzCsZmCkfV230x+ieIceLlYhHuP7rFOJkg4rwYxskAZf3tW1Ylfrvpcz8 4u5g== X-Gm-Message-State: APjAAAUDbr3d7ApeHWHA0FtRo0Xf3qXeDust59t8QnrYzaz7e7whnsK4 SPLNqfB7uNm5iYEfDXU31dBMjCFk0WR6MHagcvU= X-Google-Smtp-Source: APXvYqyNQiGg7sPz+LGNqc1116E11pBmK9ZAyk1T507DrkQJqF6irI0cYS6ILz4xMWiEZ8SxsIrdeXKiEUmoipsFlLc= X-Received: by 2002:a2e:580c:: with SMTP id m12mr639900ljb.150.1580331021806; Wed, 29 Jan 2020 12:50:21 -0800 (PST) MIME-Version: 1.0 References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> <585BCD70-6B64-4058-AC70-B677695DB391@mit.edu> In-Reply-To: <585BCD70-6B64-4058-AC70-B677695DB391@mit.edu> From: Dick Hardt Date: Wed, 29 Jan 2020 12:49:55 -0800 Message-ID: To: Justin Richer Cc: "txauth@ietf.org" , Kim , Torsten Lodderstedt , "Richard Backman, Annabelle" , Mike Jones Content-Type: multipart/alternative; boundary="0000000000002eb0bd059d4d7d6b" Archived-At: Subject: Re: [Txauth] [EXTERNAL] Re: Questions on the 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: Wed, 29 Jan 2020 20:50:30 -0000 --0000000000002eb0bd059d4d7d6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Justin that we choose JSON for the messages, but that we have flexibility in how to secure the messages, and flexibility in the claim formats that can be requested and returned. In contrast, we don't want to dictate JOSE for messages or JWT for claims. Justin gave me the feedback in earlier drafts of XAuth, and I (hopefully) factored out the JOSE aspects so that HTTP signing, MTLS, or something else could be used. I disagree with Justin's first point about the need for signed claims. I'll start another thread for that, as it is not relevant to this thread's charter discussion. /Dick On Wed, Jan 29, 2020 at 3:37 AM Justin Richer wrote: > I got a chance to chat with Mike and I wanted to expand my off-the-cuff > response (below) with some more detail than I was able to write in the > moment, because I don=E2=80=99t think that we=E2=80=99re actually that fa= r apart. > > To start, it wasn=E2=80=99t obvious to me (and might not have been to oth= ers) the > specific precision of Mike=E2=80=99s statement below. He clarified to me = that what > he means is that where user claims are signed or encrypted, then JWT > provides an obvious way to do it. In other words, =E2=80=9Cdon=E2=80=99t = re-invent the ID > Token with new crypto=E2=80=9D. There are several things to address here = with that > in mind. > > First, I don=E2=80=99t believe there are going to be many, if any, cases = where we > need user claims to be signed and encrypted separately from the core > transaction messages. Even in OIDC, the ID Token is allowed to be unsigne= d > when it is retrieved from the token endpoint directly using the code flow= . > The equivalent of this is the only place that TxAuth would be sending bac= k > user claims directly. We no longer have a need to protect things as they > travel through the front channel on a redirect, and we no longer have a > need to use the user=E2=80=99s claims as an artifact for things like sess= ion > management (we can define a new artifact for that purpose that fits > better). This effectively means that we don=E2=80=99t need to redefine th= e ID Token > because we don=E2=80=99t need the equivalent of the ID token in the same = way. For > the cases that we do need to define user claims, we should be defining th= em > as a JSON object model. And I also believe that this JSON data model shou= ld > not be intertwined with or constrained by the JWT claims registry. The OI= DC > claims registry can serve as influence and input to our user claims set i= f > we choose, but I don=E2=80=99t think we should be intertwined with that e= ither. > > Second, in spite of the success of OIDC, there are several formats out > there for user claims beyond JWT and JOSE. Verifiable Credentials (VC, > https://www.w3.org/TR/vc-data-model/) is one that has several different > formats, and we are also seeing systems built up around COSE and CBOR (li= ke > IPLD, https://ipld.io/). Or you could even use a SAML document. I don=E2= =80=99t > think TxAuth should pick just one of these. Instead, I want TxAuth to > define places to put these formats in requests and responses. In my draft > there=E2=80=99s a spot for an OIDC style ID Token or a VC document, if yo= u have > one. Within each of these, by all means, let=E2=80=99s lock them down and= say that > the =E2=80=9Coidc_id_token=E2=80=9D field is a JWT in compact format that= MUST be signed, > etc. And I think it makes little sense to invent our own custom format to > do exactly that kind of thing. > > Third, I agree that we shouldn=E2=80=99t re-invent an existing crypto for= mat, and > I=E2=80=99ll go further that we shouldn=E2=80=99t be inventing crypto at = all. This doesn=E2=80=99t > mean we have to pick one and only one, because this is one of the spaces > that we can (and I argue should) have some agility. We can define the > protocol in terms of JSON and then have a suite of cryptographic carriers > that protect that JSON, including JOSE, HTTP Message Signatures, and Mutu= al > TLS. There are a bunch of others out there as well, like the DPoP key > presentation coming out of OAuth 2 right now, that should be switchable a= s > options here because they=E2=80=99re going to apply to different use case= s and > deployments. Plus, that JSON could be translated to CBOR (without data or > structure loss) and protected by COSE =E2=80=94 even if we don=E2=80=99t = define that > ourselves, the fact that we=E2=80=99re building our structure on raw JSON= means > that it can be translated more easily later. > > Fourth, I am very sensitive to calling out preferred crypto solutions > because I believe that lends to us using that as an excuse to use that > particular hammer to solve all the problems. There have been proposals to > make the entire protocol JWTs in all directions, for instance, that I thi= nk > are really problematic because of the limits that it places on expression > of items outside of the payload itself. This is not what Mike is suggesti= ng > below, but it=E2=80=99s a potential fallout from what he does propose. > > > > In conclusion, JOSE and JWT are fantastic and they solve a lot of problem= s > in an elegant way. But I think we need to question whether we need their > solutions at all, and where we do, if we want to enable other solutions a= s > well. In my view, we don=E2=80=99t need JOSE/JWT because we avoid the pro= blems that > they solve, and the places that we do want to use them I strongly believe > there are already other alternatives that we want to have as options. > > So I want to have JOSE, but it needs to be in the right places and I do > not want it to be a dependency on all implementations. I think that we ca= n > do that without saying JWT is a preferred format. I think it=E2=80=99s mo= re > important that the charter incorporate specific text of what=E2=80=99s ou= t of > scope, including defining a cryptographic protection mechanism. > > One of the hardest things for a standard to do is determine where the > flexibility should be. My stance is that we should have a structural form= at > based on JSON but that the contents of that JSON are extensible but that > each portion and extension are very strict about what=E2=80=99s there. An= other key > flexible point is that the content of the JSON-based payloads can be > protected in a variety of ways. Choice can be debilitating, but it can al= so > be freeing. Pinning everything to JOSE would do us a disservice. > > =E2=80=94 Justin > > On Jan 29, 2020, at 10:05 AM, Justin Richer wrote: > > I strongly object to calling out JWTs as the preferred solution for signe= d > and encrypted claims within this working group. > > =E2=80=94 Justin > > On Jan 29, 2020, at 9:50 AM, Mike Jones > wrote: > > Thanks for writing these detailed questions, Kim. I believe that they > point out a number of places where even experts in the field, such as > yourself, currently have trouble understanding parts of what the charter = is > proposing that we do =E2=80=93 partially because terminology is used that= isn=E2=80=99t > commonly understood. I hope that the draft charter will be revised to ma= ke > the intent and the goals more accessible and less ambiguous. > > Responding to the discussion on whether existing JWT identity claims will > do the job or not, fortunately, even if they don=E2=80=99t, there=E2=80= =99s a mechanism to > add ones that do: the IANA JSON Web Token Claims registry at > https://www.iana.org/assignments/jwt/jwt.xhtml#claims. For instance, an > =E2=80=9Cemail_addresses=E2=80=9D claim that is array-valued could be def= ined and > registered if there=E2=80=99s a need to represent multiple e-mail address= es, per > Annabelle=E2=80=99s example. The further good news is that if the workin= g group > defines new claims that are registered, they can be reused by others also > using JWTs =E2=80=93 just like this working group can reuse claims define= d by > others. > > Also on the subject of JWTs, I would suggest that the charter be updated > to explicitly call out that JWTs will be the working group=E2=80=99s pref= erred > representation signed and/or encrypted claims. > > Finally, I also think that the charter would benefit from explicitly > listing things that are out of scope (which is often done in charters). > > Thanks again for prompting this useful discussion, Kim. > > -- Mike > > *From:* Txauth *On Behalf Of *Justin Richer > *Sent:* Wednesday, January 29, 2020 12:46 AM > *To:* Torsten Lodderstedt > *Cc:* Kim ; Dick Hardt ; > txauth@ietf.org; Richard Backman, Annabelle < > richanna=3D40amazon.com@dmarc.ietf.org> > *Subject:* [EXTERNAL] Re: [Txauth] Questions on the TxAuth charter > > I didn=E2=80=99t mean =E2=80=9Cpatch=E2=80=9D to sound disparaging, sorry= if it came across as > such. What I mean by =E2=80=9Cpatching=E2=80=9D here is that it is adding= functionality to > an existing set of claims and schema. If you are using that schema as a > base, it makes sense as a viable solution in that space. I, however, am > bringing up the question of whether we are using that schema as our base = at > all. > > I=E2=80=99ll note that 8112 doesn=E2=80=99t define a schema or syntax, bo= th of which are > required. But if we were starting OIDC today with EKYC=E2=80=99s requirem= ents, I=E2=80=99m > not convinced we=E2=80=99d end up with the same structure. > > As with everything, it=E2=80=99s a very important input into what we=E2= =80=99re trying to > solve, especially influencing what=E2=80=99s extensible and how. > > =E2=80=94 Justin > > > On Jan 29, 2020, at 8:06 AM, Torsten Lodderstedt > wrote: > > > > > Am 29.01.2020 um 07:34 schrieb Justin Richer : > > =EF=BB=BFI think the ekyc work is great for what it is, but again we have= an > opportunity to take a step beyond it. In my view, we=E2=80=99d be better = off > defining a means of specifying field metadata a la NIST IR 8112 as part o= f > the schema instead of patching the existing OIDC fields. > https://pages.nist.gov/NISTIR-8112/ > > > > We tried and it did not fulfill our requirements. verified_claims is by n= o > means a patch, it=E2=80=99s a viable solution. > > > > =E2=80=94 Justin > > > On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt > wrote: > > > > > Am 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle < > richanna=3D40amazon.com@dmarc.ietf.org>: > > The ..._verified claims don=E2=80=99t define how or when verification occ= urred. > > > Sure, they do. Look at the time and method fields. > > Since OpenId Connect for Identity Assurance (aka verified_claims) is > ongoing work feel free to contribute. > > https://openid.net/wg/ekyc-ida/ > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --0000000000002eb0bd059d4d7d6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Justin that we choose JSON for the messages, = but that we have flexibility in how to secure the messages, and flexibility= in the claim formats that can be requested and returned. In contrast, we d= on't want to dictate JOSE for messages or JWT for claims.

Justin gave me the feedback in earlier drafts of XAuth, and I (hopefu= lly) factored out the JOSE aspects so that HTTP signing, MTLS, or something= else could be used.

I disagree=C2=A0with Justin&#= 39;s first point about the need for signed claims. I'll start another t= hread for that, as it is not relevant=C2=A0to this thread's charter dis= cussion.

/Dick



On Wed, Jan 29, 2020 at 3:37 AM Justin Richer <jricher@mit.edu> wrote:
I go= t a chance to chat with Mike and I wanted to expand my off-the-cuff respons= e (below) with some more detail than I was able to write in the moment, bec= ause I don=E2=80=99t think that we=E2=80=99re actually that far apart.=C2= =A0

To start, it wasn=E2=80=99t obvious to me (and might= not have been to others) the specific precision of Mike=E2=80=99s statemen= t below. He clarified to me that what he means is that where user claims ar= e signed or encrypted, then JWT provides an obvious way to do it. In other = words, =E2=80=9Cdon=E2=80=99t re-invent the ID Token with new crypto=E2=80= =9D. There are several things to address here with that in mind.
=
First, I don=E2=80=99t believe there are going to be many, i= f any, cases where we need user claims to be signed and encrypted separatel= y from the core transaction messages. Even in OIDC, the ID Token is allowed= to be unsigned when it is retrieved from the token endpoint directly using= the code flow. The equivalent of this is the only place that TxAuth would = be sending back user claims directly. We no longer have a need to protect t= hings as they travel through the front channel on a redirect, and we no lon= ger have a need to use the user=E2=80=99s claims as an artifact for things = like session management (we can define a new artifact for that purpose that= fits better). This effectively means that we don=E2=80=99t need to redefin= e the ID Token because we don=E2=80=99t need the equivalent of the ID token= in the same way. For the cases that we do need to define user claims, we s= hould be defining them as a JSON object model. And I also believe that this= JSON data model should not be intertwined with or constrained by the JWT c= laims registry. The OIDC claims registry can serve as influence and input t= o our user claims set if we choose, but I don=E2=80=99t think we should be = intertwined with that either.

Second, in spite of = the success of OIDC, there are several formats out there for user claims be= yond JWT and JOSE. Verifiable Credentials (VC,=C2=A0https://www.w3.org/TR/vc-data-m= odel/) is one that has several different formats, and we are also seein= g systems built up around COSE and CBOR (like IPLD, https://ipld.io/). Or you could even use a SAML= document. I don=E2=80=99t think TxAuth should pick just one of these. Inst= ead, I want TxAuth to define places to put these formats in requests and re= sponses. In my draft there=E2=80=99s a spot for an OIDC style ID Token or a= VC document, if you have one. Within each of these, by all means, let=E2= =80=99s lock them down and say that the =E2=80=9Coidc_id_token=E2=80=9D fie= ld is a JWT in compact format that MUST be signed, etc. And I think it make= s little sense to invent our own custom format to do exactly that kind of t= hing.=C2=A0

Third, I agree that we shouldn=E2=80= =99t re-invent an existing crypto format, and I=E2=80=99ll go further that = we shouldn=E2=80=99t be inventing crypto at all. This doesn=E2=80=99t mean = we have to pick one and only one, because this is one of the spaces that we= can (and I argue should) have some agility. We can define the protocol in = terms of JSON and then have a suite of cryptographic carriers that protect = that JSON, including JOSE, HTTP Message Signatures, and Mutual TLS. There a= re a bunch of others out there as well, like the DPoP key presentation comi= ng out of OAuth 2 right now, that should be switchable as options here beca= use they=E2=80=99re going to apply to different use cases and deployments. = Plus, that JSON could be translated to CBOR (without data or structure loss= ) and protected by COSE =E2=80=94 even if we don=E2=80=99t define that ours= elves, the fact that we=E2=80=99re building our structure on raw JSON means= that it can be translated more easily later.

Four= th, I am very sensitive to calling out preferred crypto solutions because I= believe that lends to us using that as an excuse to use that particular ha= mmer to solve all the problems. There have been proposals to make the entir= e protocol JWTs in all directions, for instance, that I think are really pr= oblematic because of the limits that it places on expression of items outsi= de of the payload itself. This is not what Mike is suggesting below, but it= =E2=80=99s a potential fallout from what he does propose.



In conclusion, JOSE and JWT are fanta= stic and they solve a lot of problems in an elegant way. But I think we nee= d to question whether we need their solutions at all, and where we do, if w= e want to enable other solutions as well. In my view, we don=E2=80=99t need= JOSE/JWT because we avoid the problems that they solve, and the places tha= t we do want to use them I strongly believe there are already other alterna= tives that we want to have as options.=C2=A0

So I = want to have JOSE, but it needs to be in the right places and I do not want= it to be a dependency on all implementations. I think that we can do that = without saying JWT is a preferred format. I think it=E2=80=99s more importa= nt that the charter incorporate specific text of what=E2=80=99s out of scop= e, including defining a cryptographic protection mechanism.=C2=A0

One of the hardest things for a standard to do is determine= where the flexibility should be. My stance is that we should have a struct= ural format based on JSON but that the contents of that JSON are extensible= but that each portion and extension are very strict about what=E2=80=99s t= here. Another key flexible point is that the content of the JSON-based payl= oads can be protected in a variety of ways. Choice can be debilitating, but= it can also be freeing. Pinning everything to JOSE would do us a disservic= e.=C2=A0

=C2=A0=E2=80=94 Justin
On Jan 29, 2020, at 10:05 AM, Justin Richer= <jricher@mit.edu> wrote:

I strongly object to calling out = JWTs as the preferred solution for signed and encrypted claims within this = working group.

=C2=A0=E2=80=94 Justin


Thanks for writing these detailed questions= , Kim.=C2=A0 I believe that they point out a number of places where even ex= perts in the field, such as yourself, currently have trouble understanding = parts of what the charter is proposing that we do =E2=80=93 partially becau= se terminology is used that isn=E2=80=99t commonly understood.=C2=A0 I hope= that the draft charter will be revised to make the intent and the goals mo= re accessible and less ambiguous.
=C2=A0
= Responding to the discussion on whether = existing JWT identity claims will do the job or not, fortunately, even if t= hey don=E2=80=99t, there=E2=80=99s a mechanism to add ones that do: the IAN= A JSON Web Token Claims registry at=C2=A0https://www.iana.org/assignments/jwt/jwt= .xhtml#claims.=C2=A0 For instance, an =E2=80=9Cemail_addresses=E2=80=9D= claim that is array-valued could be defined and registered if there=E2=80= =99s a need to represent multiple e-mail addresses, per Annabelle=E2=80=99s= example.=C2=A0 The further good news is that if the working group defines = new claims that are registered, they can be reused by others also using JWT= s =E2=80=93 just like this working group can reuse claims defined by others= .
=C2=A0
Also on the subject of JWTs, I would suggest that the charter be updated t= o explicitly call out that JWTs will be the working group=E2=80=99s preferr= ed representation signed and/or encrypted claims.
=C2=A0
Finally, I also think that= the charter would benefit from explicitly listing things that are out of s= cope (which is often done in charters).
=C2=A0
Thanks again for prompting this usef= ul discussion, Kim.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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<= /div>
=C2=A0
From:= =C2=A0Txauth <txauth-b= ounces@ietf.org>=C2=A0On Behalf Of=C2=A0Justin Richer
Sent:=C2=A0Wednesday, January 29,= 2020 12:46 AM
To:=C2=A0Torsten Lodderstedt <torsten@lodderstedt.net>
Cc:<= span>=C2=A0Kim <kim@identityblog.co= m>; Dick Hardt <dick.hardt@gmail.co= m>;=C2=A0txauth@ietf.org; = Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>
Subject:= =C2=A0[EXTERNAL] Re: [Txauth] Questions on the TxAuth charter=
=C2=A0
I di= dn=E2=80=99t mean =E2=80=9Cpatch=E2=80=9D to sound disparaging, sorry if it= came across as such. What I mean by =E2=80=9Cpatching=E2=80=9D here is tha= t it is adding functionality to an existing set of claims and schema. If yo= u are using that schema as a base, it makes sense as a viable solution in t= hat space. I, however, am bringing up the question of whether we are using = that schema as our base at all.
= =C2=A0
I=E2=80=99ll note that 8112 doesn= =E2=80=99t define a schema or syntax, both of which are required. But if we= were starting OIDC today with EKYC=E2=80=99s requirements, I=E2=80=99m not= convinced we=E2=80=99d end up with the same structure.=C2=A0=
=C2=A0
= As with everything, it=E2=80=99s a very important input into what we=E2=80= =99re trying to solve, especially influencing what=E2=80=99s extensible and= how.
=C2=A0
=C2=A0=E2=80=94 Justin


On Jan 29, 2020, at 8:06 AM, Torsten Loddersted= t <torsten@lodderstedt.net> wrot= e:
=C2=A0
<= div>
=C2=A0


Am 29.01.2020 um 07:34 schrieb Justin Richer <jricher@mit.edu>:

= =EF=BB=BFI think the ekyc work is great for what it is, but again we have a= n opportunity to take a step beyond it. In my view, we=E2=80=99d be better = off defining a means of specifying field metadata a la NIST IR 8112 as part= of the schema instead of patching the existing OIDC fields.=C2=A0https://pages.nist.gov/NISTIR-8112/<= /div>
=C2=A0
We tried and it did not fulfill our requirements. verified_claims is = by no means a patch, it=E2=80=99s a viable solution.


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

On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=C2=A0
=C2=A0


Am 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.iet= f.org>:

The ..._verified claims don= =E2=80=99t define how or when verification occurred.
=C2=A0
Sure, th= ey do. Look at the time and method fields.=C2=A0
<= div>
=C2=A0
Since OpenId C= onnect for Identity Assurance (aka verified_claims) is ongoing work feel fr= ee to contribute.
=C2=A0<= /u>

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

= --0000000000002eb0bd059d4d7d6b-- From nobody Wed Jan 29 13:15: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 DF9E1120048 for ; Wed, 29 Jan 2020 13:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=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 3xn4IDnkWKkw for ; Wed, 29 Jan 2020 13:15:12 -0800 (PST) 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 C0897120045 for ; Wed, 29 Jan 2020 13:15:11 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id r19so985554ljg.3 for ; Wed, 29 Jan 2020 13:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/dtG1sqOLLVnGtXeWQe8O8/clMOr6nTJ7RrJcyB/eT4=; b=EVfIoVQE9a0wDU3GSpz4Rven+p/F/nWsSdbeGt112LtTxJdSXxb605kmk2c/QexJNE glrDPg9g0b2SSd6iQzFGkAK+mga2P6Mo/RVvicOBZwHwQDhiebAyF99VxZLWCOq2N936 hfYLxb0lgAU8O2CqZtrvBmZybcbTyQ6qom1wFetJ876wyj8aLDHYiWjuSORvtjnvkM5S mcB0G/gV6bm/cjCPHX4BSgpql/o+ZJjtOnhP7C2HsNAToyibNGqbdZSrrhd1kBnHoCXP nwMtnSfIei13Y2fFz/D/nj+fu3haSGZBViE+7J9lDDYtDgJGA/mdukhOC5SEJFSHDcB9 7edQ== 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=/dtG1sqOLLVnGtXeWQe8O8/clMOr6nTJ7RrJcyB/eT4=; b=LvSL0xRx7tmGy/4DmilhjWx32A/dE03C7Ca2+AVoaaMTUZSTgZWwq7koLJOy2/XEtF j1irrzSNLjmXkjeW2Ry2F1NE8SCM5gO0q9ZyBpOE97h0SXU82ef6DI92OU2aQq1Rw2eR axExU59vtLjCueA2Gyu1cQ7asIZFp+OoaneKWM2ZlulSl2yDkE8xaSZ+LyP51gsy2W2H TQl4ptrthcGg0OibWxJlKnWJ31ApMxjkszewojNduMzvdBoWP4ZRH4cnPudmPWtYaGst J+W0q8YKYHozGIXqWGKrj3BECIfNWAGoaPkYaWg2G6F0OHEhSV7lbBOJSGJ3ZqBNNfPp q74Q== X-Gm-Message-State: APjAAAVAcvwSrm/8Q6hcpDesPvqf2fG6h894pwafVz0Kd2xoqzh1+Xef cb72SPziHAWFhiQIpXWBxRkLhK2Z5g2+Sw2eUKg= X-Google-Smtp-Source: APXvYqxyFSxaGFyW++61/4yBoW0zU7ud95ap1psX7gNBOBjMXmyxBKzvP1ZZA0526lQiSpMRkMofMgOUTYC0cGQjmkQ= X-Received: by 2002:a2e:84d0:: with SMTP id q16mr702003ljh.138.1580332509940; Wed, 29 Jan 2020 13:15:09 -0800 (PST) MIME-Version: 1.0 References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> <585BCD70-6B64-4058-AC70-B677695DB391@mit.edu> In-Reply-To: <585BCD70-6B64-4058-AC70-B677695DB391@mit.edu> From: Dick Hardt Date: Wed, 29 Jan 2020 13:14:43 -0800 Message-ID: To: Justin Richer Cc: "txauth@ietf.org" , Kim , Torsten Lodderstedt , "Richard Backman, Annabelle" , Mike Jones Content-Type: multipart/alternative; boundary="000000000000e1cf11059d4dd5e9" Archived-At: Subject: [Txauth] The need for signed claims - providence 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, 29 Jan 2020 21:15:15 -0000 --000000000000e1cf11059d4dd5e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Forking the discussion to focus on signed claims On Wed, Jan 29, 2020 at 3:37 AM Justin Richer wrote: > First, I don=E2=80=99t believe there are going to be many, if any, cases = where we > need user claims to be signed and encrypted separately from the core > transaction messages. Even in OIDC, the ID Token is allowed to be unsigne= d > when it is retrieved from the token endpoint directly using the code flow= . > The equivalent of this is the only place that TxAuth would be sending bac= k > user claims directly. We no longer have a need to protect things as they > travel through the front channel on a redirect, and we no longer have a > need to use the user=E2=80=99s claims as an artifact for things like sess= ion > management (we can define a new artifact for that purpose that fits > better). This effectively means that we don=E2=80=99t need to redefine th= e ID Token > because we don=E2=80=99t need the equivalent of the ID token in the same = way. For > the cases that we do need to define user claims, we should be defining th= em > as a JSON object model. And I also believe that this JSON data model shou= ld > not be intertwined with or constrained by the JWT claims registry. The OI= DC > claims registry can serve as influence and input to our user claims set i= f > we choose, but I don=E2=80=99t think we should be intertwined with that e= ither. > I disagree. I think it is likely that we will see an increase in signed claims and messages. In my opinion, the providence of a claim or message is far more important than protection during transit. *Client / AS non-repudiation*: when sensitive operations are performed relying on the contents of a claim, the Client will want repudiation that the AS or claims issuer made a claim. *Separation of duties in complex systems*: In large organizations, a major security threat is a malicious insider. Once an organization reaches a certain size, you assume there are people employed at the company that do not have the firms best interests in mind. One mitigation of this threat is done by separating what different teams can do with customer / sensitive data, requiring collusion to access or modify the data. Signed messages and claims simplify different components being able to independently verify a message or claim. Similarly, a component issuing a claim, has assurance that other components in the same system are not modifying it. Large organizations wrap external systems that do not support this with their own security mechanism -- but not all organizations are this sophisticated, and as they grow, retrofitting is difficult. Enabling end to end providence is a best practice in my opinion. *User Consent Audit*: as privacy becomes a larger public topic, it is easy to imagine organizations wanting to prove that they obtained user information with consent. Rather than gathering user information directly from the user, a Client can acquire claims from the User's claims provider that asserts the user provided consent to the Client. The Client can then technically establish that all user data was gathered with consent, and the context of the consent. While the message containing the claims may be signed, having independent claims separately signed simplifies the least privilege tenet, where a component only has access to the user information it needs. /Dick --000000000000e1cf11059d4dd5e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000f64927059d55fb5d-- From nobody Wed Jan 29 23:07: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 27C721200C3 for ; Wed, 29 Jan 2020 23:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] 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 L5fII3JOmHJb for ; Wed, 29 Jan 2020 23:07:03 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C774312006B for ; Wed, 29 Jan 2020 23:07:02 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id q8so2086817ljj.11 for ; Wed, 29 Jan 2020 23:07:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nVUeLtqAeUJn6etOn4VpWrvngl+bphAZiA3HImkvYFA=; b=ddDYD6DYbHVwCIAByncpyjbdG6fweQFRPJIjNNZ0MM5bpsjkxZiSopsR+ob3KE9aOH ms/7/3dI/9a2a+lD1eQuDEy3mgY1CeWLUmyxolDN8QcmX1g3/led2Xwi329Vh8nrE5Lc I+u0CkSEoRClQuyNtC/CFb+Qb08cLA9ZnF9rmSOWfqS2zZkWYtYK5tBFfBYgxUlfTwnb 5tSNxJzLoqGPs9bD0pNqWe1Qlts4fadF5YtD3XOlleBpE+MmK72Uh72RfvSjusOcuXRg ftC4yu5x8pls743O+EQNGR0g3nqypPbsC3BzFRyFC6vM6sN+qQDYPVV4YqL2IQ/0adXL 0g5g== 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=nVUeLtqAeUJn6etOn4VpWrvngl+bphAZiA3HImkvYFA=; b=p5Efrnk3MG9SBlupKGO/GuC6ZGBUsQBsDjBZK+6e9gmQ1ehR4o4n2osWa9lYS8IzNf AebKOWhS4BCE+ro8Una/J1fYA7gML40JRRJnY3ISqeTTj1wiK5dCn/Lg5lA7DMLxmKeV hDMCa4jutsw6WiZTb68GPdW3ZsZYFGS9WFDZcePKhKLwLNKaGX2zwyOFwfAsIR79MIGT +eS012J3ZKfhEIbHVd5hxniiexTlIedlMQxDFFKU2U0TI6lOE3DpPTyVFdZricwLtwYw +r30S+HgVxxgJnoMFhHAKrfF2H9n8WDPPuQxOtFfWkB4zlA9nKHRKijUUcq5ZDKbYlh0 IxoQ== X-Gm-Message-State: APjAAAUoaaM3kqPEzX7dVNcN8jremRAiUQapeNlmAHkSWBF8Hn1JH65B TBvF8d1KpTpl1c5FrFrZfg4D/qBrB7XDui0ukE41SNiVyAs= X-Google-Smtp-Source: APXvYqwa6Fj30pq/B5XBSBkJ7CWHiOhXJ3ny62OlSPFyyDCJ3t5mm6k4toEeHcNerYcknaSs/qv4zk3vawdBKgTMtW0= X-Received: by 2002:a2e:84d0:: with SMTP id q16mr1925900ljh.138.1580368020824; Wed, 29 Jan 2020 23:07:00 -0800 (PST) MIME-Version: 1.0 From: Dick Hardt Date: Wed, 29 Jan 2020 23:06:35 -0800 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000007ee54b059d561ac4" Archived-At: Subject: [Txauth] XAuth-01 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, 30 Jan 2020 07:07:04 -0000 --0000000000007ee54b059d561ac4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For some reason, the IETF links for draft-hardt-xauth are broken in the data tracker, but are working in ietf tools. The latest version is still up at https://tools.ietf.org/id/draft-hardt-xauth-protocol-00.html But the 01 submission is stuck. You can see it here: https://dickhardt.github.io/hardt-xauth-protocol/draft-hardt-xauth-protocol= .html See the changelog for changes. The big change is letting the Client ask the AS to authenticate the User, and then return those results while the AS is still interacting with the User. The Client can then look up the User, and decide what identity claims and/or authorizations to request from the User, if any. The Client can then make another request for that information, or for nothing. New Users, or Users that have not provided the latest set of information, are prompted to release it, and the results are returned to the Client. Existing Users that have provided everything are not prompted. The sequence is a little more complicated, but looks to me like it solves the issue that Justin brought up in his critique. /Dick =E1=90=A7 --0000000000007ee54b059d561ac4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For some reason, the IETF links for draft-hardt-xauth are = broken in the data tracker, but are working in ietf tools.

The latest version is still up at=C2=A0https://tools.ietf.org/id/draft-har= dt-xauth-protocol-00.html

But the 01 submissio= n is stuck.

You can see it here:


See the ch= angelog for changes.

The big change is letting the= Client ask the AS to authenticate the User, and then return those results = while the AS is still interacting with the User. The Client can then look u= p the User, and decide what identity claims and/or authorizations to reques= t from the User, if any.

The Client can then make = another request for that information, or for nothing.

<= div>New Users, or Users that have not provided the latest set of informatio= n, are prompted to release it, and the results are returned to the Client. = Existing Users that have provided everything are not prompted.
The sequence is a little more complicated, but looks to me lik= e it solves the issue that Justin brought up in his critique.

/Dick
3D""=E1=90=A7
--0000000000007ee54b059d561ac4-- From nobody Wed Jan 29 23:55: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 85EF81200FF for ; Wed, 29 Jan 2020 23:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 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] 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 vCAqJ7j3eOMS for ; Wed, 29 Jan 2020 23:55:19 -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 4F2221200FA for ; Wed, 29 Jan 2020 23:55:19 -0800 (PST) Received: from [10.38.98.196] ([83.219.75.72]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00U7t8ji003180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jan 2020 02:55:10 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F818624E-E915-45F5-AC3E-A39B5473EE06" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 30 Jan 2020 08:55:08 +0100 In-Reply-To: Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" , Kim , Torsten Lodderstedt , Mike Jones To: Dick Hardt References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> <585BCD70-6B64-4058-AC70-B677695DB391@mit.edu> <7833DDB1-FB88-4151-84B6-8DABB6436B53@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: The need for signed claims - providence 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, 30 Jan 2020 07:55:25 -0000 --Apple-Mail=_F818624E-E915-45F5-AC3E-A39B5473EE06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I did: My response to your point was that we should enable this kind of = thing but not assume that user claims are going to be =E2=80=94 or need = to be =E2=80=94 in a signed payload. I think that what you=E2=80=99re = describing is a specific architecture decision which is not that common. = It shouldn=E2=80=99t be disallowed but I don=E2=80=99t think other = deployments should pay that cost.=20 Even in OIDC today, you=E2=80=99re allowed to ignore the signature on = the signed ID Token if it gets delivered on the back channel. In the = normal case, a JWT provides just an extra layer of wrapping without much = value. Please see Aaron=E2=80=99s post for a better writeup of that. So in the end, I think that plain JSON should be enabled for user claims = (which XAuth also has, I=E2=80=99ll note) along with any type of = packaged assertion like an ID Token (which I=E2=80=99ll note that XYZ = also has). =E2=80=94 Justin > On Jan 30, 2020, at 7:58 AM, Dick Hardt wrote: >=20 > Justin: would you respond to my critique of your statement? I was not = talking about SETs. >=20 > Tl;dr: multiple services in a pipeline in a complex app may need to = independently verify a claim.=20 > =E1=90=A7 >=20 > On Wed, Jan 29, 2020 at 10:19 PM Justin Richer > wrote: > I think the use cases for SET are very different from an = authentication assertion, which is consumed then discarded. Aaron = Parecki has written a good blog post that touches on this: >=20 > https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz = >=20 > If we need a persistent record then we can also send that =E2=80=94 = maybe it=E2=80=99s even a SET instead of an ID Token? I=E2=80=99m still = fine with enabling signed JWTs to carry information, but what I was = against was stating any assumption that they would always be signed or = encrypted, and that JWT would be the assumed carrier for that. >=20 > =E2=80=94 Justin >=20 >> On Jan 30, 2020, at 1:00 AM, Richard Backman, Annabelle = > wrote: >>=20 >> +1 to Dick=E2=80=99s counterpoints. The Security Considerations in = draft-ietf-secevent-http-push = = talk about validation of persisted SETs as one reason a deployment may = wish to transmit signed SETs even over a TLS-protected channel. The same = idea applies to identity claims or just about anything else, really. >> =20 >> =E2=80=93=20 >> Annabelle Richard Backman >> AWS Identity >> =20 >> =20 >> From: Dick Hardt > >> Date: Wednesday, January 29, 2020 at 2:16 PM >> To: Justin Richer > >> Cc: "txauth@ietf.org " >, Kim >, Torsten Lodderstedt = >, "Richard = Backman, Annabelle" >, = Mike Jones > >> Subject: [UNVERIFIED SENDER] Re: The need for signed claims - = providence >> =20 >> I forgot to include the reference to Annabelle calling this out = earlier >> =20 >> = https://mailarchive.ietf.org/arch/msg/txauth/0hR49OnE3oqNPuCIQ43fN1o886w = = >> =20 >> =20 >> On Wed, Jan 29, 2020 at 1:14 PM Dick Hardt > wrote: >>> Forking the discussion to focus on signed claims >>> =20 >>> On Wed, Jan 29, 2020 at 3:37 AM Justin Richer > wrote: >>> >>>> First, I don=E2=80=99t believe there are going to be many, if any, = cases where we need user claims to be signed and encrypted separately = from the core transaction messages. Even in OIDC, the ID Token is = allowed to be unsigned when it is retrieved from the token endpoint = directly using the code flow. The equivalent of this is the only place = that TxAuth would be sending back user claims directly. We no longer = have a need to protect things as they travel through the front channel = on a redirect, and we no longer have a need to use the user=E2=80=99s = claims as an artifact for things like session management (we can define = a new artifact for that purpose that fits better). This effectively = means that we don=E2=80=99t need to redefine the ID Token because we = don=E2=80=99t need the equivalent of the ID token in the same way.. For = the cases that we do need to define user claims, we should be defining = them as a JSON object model. And I also believe that this JSON data = model should not be intertwined with or constrained by the JWT claims = registry. The OIDC claims registry can serve as influence and input to = our user claims set if we choose, but I don=E2=80=99t think we should be = intertwined with that either. >>> =20 >>> I disagree. I think it is likely that we will see an increase in = signed claims and messages. >>> =20 >>> In my opinion, the providence of a claim or message is far more = important than protection during transit.=20 >>> =20 >>> Client / AS non-repudiation: when sensitive operations are performed = relying on the contents of a claim, the Client will want repudiation = that the AS or claims issuer made a claim. >>> =20 >>> Separation of duties in complex systems: In large organizations, a = major security threat is a malicious insider. Once an organization = reaches a certain size, you assume there are people employed at the = company that do not have the firms best interests in mind. One = mitigation of this threat is done by separating what different teams can = do with customer / sensitive data, requiring collusion to access or = modify the data. Signed messages and claims simplify different = components being able to independently verify a message or claim. = Similarly, a component issuing a claim, has assurance that other = components in the same system are not modifying it. Large organizations = wrap external systems that do not support this with their own security = mechanism -- but not all organizations are this sophisticated, and as = they grow, retrofitting is difficult. Enabling end to end providence is = a best practice in my opinion. >>> =20 >>> User Consent Audit: as privacy becomes a larger public topic, it is = easy to imagine organizations wanting to prove that they obtained user = information with consent. Rather than gathering user information = directly from the user, a Client can acquire claims from the User's = claims provider that asserts the user provided consent to the Client. = The Client can then technically establish that all user data was = gathered with consent, and the context of the consent. >>> =20 >>> While the message containing the claims may be signed, having = independent claims separately signed simplifies the least privilege = tenet, where a component only has access to the user information it = needs.. =20 >>> =20 >>> /Dick >=20 --Apple-Mail=_F818624E-E915-45F5-AC3E-A39B5473EE06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = did: My response to your point was that we should enable this kind of = thing but not assume that user claims are going to be =E2=80=94 or need = to be =E2=80=94 in a signed payload. I think that what you=E2=80=99re = describing is a specific architecture decision which is not that common. = It shouldn=E2=80=99t be disallowed but I don=E2=80=99t think other = deployments should pay that cost. 

Even in OIDC today, you=E2=80=99re = allowed to ignore the signature on the signed ID Token if it gets = delivered on the back channel. In the normal case, a JWT provides just = an extra layer of wrapping without much value. Please see Aaron=E2=80=99s = post for a better writeup of that.

So in the end, I think that plain JSON = should be enabled for user claims (which XAuth also has, I=E2=80=99ll = note) along with any type of packaged assertion like an ID Token (which = I=E2=80=99ll note that XYZ also has).

 =E2=80=94 Justin

On Jan 30, 2020, at 7:58 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin: would you respond to my = critique of your statement? I was not talking about SETs.

Tl;dr: multiple services = in a pipeline in a complex app may need to independently verify a = claim. 
3D""=E1=90=A7

On Wed, Jan = 29, 2020 at 10:19 PM Justin Richer <jricher@mit.edu> wrote:
I think the use cases for SET are very different = from an authentication assertion, which is consumed then discarded. = Aaron Parecki has written a good blog post that touches on this:

https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz

If we need = a persistent record then we can also send that =E2=80=94 maybe it=E2=80=99= s even a SET instead of an ID Token? I=E2=80=99m still fine with = enabling signed JWTs to carry information, but what I was against was = stating any assumption that they would always be signed or encrypted, = and that JWT would be the assumed carrier for that.

 =E2=80=94 Justin

On Jan 30, 2020, at 1:00 AM, Richard Backman, Annabelle = <richanna@amazon.com> wrote:

+1 to = Dick=E2=80=99s counterpoints. The Security Considerations in = draft-ietf-secevent-http-push talk = about validation of persisted SETs as one reason a deployment may wish = to transmit signed SETs even over a TLS-protected channel. The same idea = applies to identity claims or just about anything else, really.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: Dick Hardt <dick.hardt@gmail.com>
Date: Wednesday, January = 29, 2020 at 2:16 PM
To: Justin Richer <jricher@mit.edu>
Cc: "txauth@ietf.org" <txauth@ietf.org>, Kim <kim@identityblog.com>, Torsten Lodderstedt <torsten@lodderstedt.net>, "Richard Backman, Annabelle" = <richanna@amazon.com>, Mike Jones <Michael.Jones@microsoft.com>
Subject: [UNVERIFIED SENDER] = Re: The need for signed claims - providence
 
I = forgot to include the reference to Annabelle calling this out earlier
 
https://mailarchive.ietf.org/arch/msg/txauth/0hR49OnE3oqNPuCIQ4= 3fN1o886w
 
 
On = Wed, Jan 29, 2020 at 1:14 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Forking= the discussion to focus on signed claims
 
On = Wed, Jan 29, 2020 at 3:37 AM Justin Richer <jricher@mit.edu> wrote:
<snip>
First, = I don=E2=80=99t believe there are going to be many, if any, cases where = we need user claims to be signed and encrypted separately from the core = transaction messages. Even in OIDC, the ID Token is allowed to be = unsigned when it is retrieved from the token endpoint directly using the = code flow. The equivalent of this is the only place that TxAuth would be = sending back user claims directly. We no longer have a need to protect = things as they travel through the front channel on a redirect, and we no = longer have a need to use the user=E2=80=99s claims as an artifact for = things like session management (we can define a new artifact for that = purpose that fits better). This effectively means that we don=E2=80=99t = need to redefine the ID Token because we don=E2=80=99t need the = equivalent of the ID token in the same way.. For the cases that we do = need to define user claims, we should be defining them as a JSON object = model. And I also believe that this JSON data model should not be = intertwined with or constrained by the JWT claims registry. The OIDC = claims registry can serve as influence and input to our user claims set = if we choose, but I don=E2=80=99t think we should be intertwined with = that either.
 
I = disagree. I think it is likely that we will see an increase in signed = claims and messages.
 
In my = opinion, the providence of a claim or message is far more important than = protection during transit. 
 
Client / AS non-repudiation: when sensitive operations = are performed relying on the contents of a claim, the Client will want = repudiation that the AS or claims issuer made a claim.
 
Separation of duties in complex systems: In large = organizations, a major security threat is a malicious insider. Once an = organization reaches a certain size, you assume there are people = employed at the company that do not have the firms best interests in = mind. One mitigation of this threat is done by separating what different = teams can do with customer / sensitive data, requiring collusion to = access or modify the data. Signed messages and claims simplify different = components being able to independently verify a message or claim. = Similarly, a component issuing a claim, has assurance that other = components in the same system are not modifying it. Large organizations = wrap external systems that do not support this with their own security = mechanism -- but not all organizations are this sophisticated, and as = they grow, retrofitting is difficult. Enabling end to end providence is = a best practice in my opinion.
 
User Consent Audit: as privacy becomes a larger public = topic, it is easy to imagine organizations wanting to prove that they = obtained user information with consent. Rather than gathering user = information directly from the user, a Client can acquire claims from the = User's claims provider that asserts the user provided consent to the = Client. The Client can then technically establish that all user data was = gathered with consent, and the context of the consent.
 
While = the message containing the claims may be signed, having independent = claims separately signed simplifies the least privilege tenet, where a = component only has access to the user information it = needs..  
 
/Dick


= --Apple-Mail=_F818624E-E915-45F5-AC3E-A39B5473EE06-- From nobody Wed Jan 29 23:56: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 0D3E11200FF for ; Wed, 29 Jan 2020 23:56:36 -0800 (PST) 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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 lrM3Ew7dxqMH for ; Wed, 29 Jan 2020 23:56:34 -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 C3B581200FE for ; Wed, 29 Jan 2020 23:56:33 -0800 (PST) Received: from [10.38.98.196] ([83.219.75.72]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00U7uUkJ003422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jan 2020 02:56:31 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_19D29240-A0F7-48E5-827E-71F3C03A8534" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 30 Jan 2020 08:56:29 +0100 In-Reply-To: Cc: txauth@ietf.org To: Dick Hardt References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XAuth-01 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, 30 Jan 2020 07:56:36 -0000 --Apple-Mail=_19D29240-A0F7-48E5-827E-71F3C03A8534 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for this iteration. I think this is a much more complicated = approach than having a token-protected user information API, though. =E2=80=94 Justin > On Jan 30, 2020, at 8:06 AM, Dick Hardt wrote: >=20 > For some reason, the IETF links for draft-hardt-xauth are broken in = the data tracker, but are working in ietf tools. >=20 > The latest version is still up at = https://tools.ietf.org/id/draft-hardt-xauth-protocol-00.html = >=20 > But the 01 submission is stuck. >=20 > You can see it here: >=20 > = https://dickhardt.github.io/hardt-xauth-protocol/draft-hardt-xauth-protoco= l.html = >=20 > See the changelog for changes. >=20 > The big change is letting the Client ask the AS to authenticate the = User, and then return those results while the AS is still interacting = with the User. The Client can then look up the User, and decide what = identity claims and/or authorizations to request from the User, if any. >=20 > The Client can then make another request for that information, or for = nothing. >=20 > New Users, or Users that have not provided the latest set of = information, are prompted to release it, and the results are returned to = the Client. Existing Users that have provided everything are not = prompted. >=20 > The sequence is a little more complicated, but looks to me like it = solves the issue that Justin brought up in his critique. >=20 >=20 > /Dick > =E1=90=A7 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_19D29240-A0F7-48E5-827E-71F3C03A8534 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for this iteration. I think this is a much more = complicated approach than having a token-protected user information API, = though.

 =E2=80=94= Justin

On Jan 30, 2020, at 8:06 AM, Dick Hardt = <dick.hardt@gmail.com> wrote:

For some reason, the IETF links = for draft-hardt-xauth are broken in the data tracker, but are working in = ietf tools.

The = latest version is still up at https://tools.ietf.org/id/draft-hardt-xauth-protocol-00.html

But the 01 = submission is stuck.

You can see it here:

https://dickhardt.github.io/hardt-xauth-protocol/draft-hardt-xa= uth-protocol.html

See the changelog for = changes.

The = big change is letting the Client ask the AS to authenticate the User, = and then return those results while the AS is still interacting with the = User. The Client can then look up the User, and decide what identity = claims and/or authorizations to request from the User, if any.

The Client can then make = another request for that information, or for nothing.

New Users, or Users that = have not provided the latest set of information, are prompted to release = it, and the results are returned to the Client. Existing Users that have = provided everything are not prompted.

The sequence is a little more = complicated, but looks to me like it solves the issue that Justin = brought up in his critique.


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

= --Apple-Mail=_19D29240-A0F7-48E5-827E-71F3C03A8534-- From nobody Thu Jan 30 01:05: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 D480D120111 for ; Thu, 30 Jan 2020 01:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 RW7hlBu8plX5 for ; Thu, 30 Jan 2020 01:05:18 -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 BFF1812010F for ; Thu, 30 Jan 2020 01:05:17 -0800 (PST) Received: from [10.38.98.196] ([83.219.75.72]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00U9568L016227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jan 2020 04:05:08 -0500 From: Justin Richer Message-Id: <2E6A2343-3277-4090-AE7E-774158C08DB0@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_17BE1FB0-B578-49E7-9D1B-61F56F3A9619" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 30 Jan 2020 10:05:06 +0100 In-Reply-To: Cc: txauth@ietf.org, Benjamin Kaduk , "rdd@cert.org" , Yaron Sheffer To: Dick Hardt References: <05467DBA-1B21-4F05-94EC-833C6E3FEBFB@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XAuth - a revision 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: Thu, 30 Jan 2020 09:05:22 -0000 --Apple-Mail=_17BE1FB0-B578-49E7-9D1B-61F56F3A9619 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 30, 2020, at 12:25 AM, Dick Hardt wrote: >=20 >=20 >=20 > On Wed, Jan 29, 2020 at 8:26 AM Justin Richer > wrote: > As Dick has mentioned, I gave him some early feedback on this draft = before publication, and he=E2=80=99s asked me to write up my thoughts = and responses on the current XAuth proposal that=E2=80=99s published = here. >=20 > Thanks again for that feedback Justin. I was hoping to see your = responses before you posted so that I could clarify misconceptions, but = I'll do that now on the list. =3D) >=20 > Thanks for writing this up -- I believe it helps us identify the areas = for deeper discussion to reach rough consensus! > =20 >=20 > 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 >=20 > >=20 > I think XAuth has an interesting take on the problem space that TxAuth = is looking to solve, but in my opinion it generally veers too closely to = OAuth2/OIDC/JWT in its solution approach. >=20 > Reusing aspects of OAuth2/OIDC/JWT that are working fine for = deployments will minimize the migration effort for them to take = advantage of the security features of this work such as not using the = redirect for passing parameters. I think XAuth supports the following = clause of the current draft charter: "the group will attempt to simplify = porting from OAuth 2.0 and OpenID Connect to the new protocol where = possible.=E2=80=9D I understand the goals here, but I disagree that using the constructs as = directly as they have been here is the most appropriate approach. >=20 > > =20 > 1. XAuth removes =E2=80=9Chandles=E2=80=9D as stand-ins for various = elements. In XYZ, the =E2=80=9Chandle=E2=80=9D concept is a key = abstraction point with specific semantics. A =E2=80=9Chandle=E2=80=9D is = an identifier to a specific instantiation of a JSON object structure. = Using the =E2=80=9Chandle=E2=80=9D for Keys, for Resources, and even the = whole Transaction lets you do a lot of core things in a parallel and = reusable way. XAuth re-invents a few of these as separate items, listed = below, and I see this as a regression. >=20 > XAuth took the transaction handle and forked it into a completion = handle and a refresh handle so that it is clear what the Client is = wanting to happen. >=20 > It was not clear the value of the other handles that were listed in = XYZ.=20 I think this may be that you misunderstood the purposes of the handles, = as you=E2=80=99ve reinvented nearly all of them with different labels in = XAuth. :) > =20 >=20 > 2. XAuth uses a Client ID from OAuth 2. I removed Client IDs from XYZ = because I realized that you don=E2=80=99t need them anymore. The client = ID tells the AS which client is talking in the front channel because the = client can=E2=80=99t authenticate. In the back channel, the key (or = secret) identifier is enough to identify the client =E2=80=94 that=E2=80=99= s the Key Handle in XYZ that can be passed in lieu of the key itself. = The argument that it=E2=80=99s helpful to have an identifier for doing = developer support and managing registrations is spurious, since this is = an internal identifier that never needs to be exposed by the protocol. = Additionally, a client ID assumes a registration-based model. There are = ephemeral and per-device client instances like SPA=E2=80=99s and mobile = apps that don=E2=80=99t really fit the client ID model very well. = Pushing this requirement on all clients is bad, as we=E2=80=99ve seen in = OAuth 1 and OAuth 2. XAuth tries to manage this by splitting clients = into two camps, but I=E2=80=99m saying that no client needs and external = client ID. >=20 > I addressed this in = https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-12 = # = 7 >=20 > 7. *Why is there still a Client ID? Could we not use a fingerprint > of the public key to identify the Client?* >=20 > Some AS deployments do not allow calls from Registered = Clients, > and provide different functionality to different Clients. A > permanent identifier for the Client is needed for the Client > developer and the AS admin to ensure they are referring to the > same Client. The Client ID was used in OAuth 2.0, and it = served > the same purpose >=20 > Perhaps you did not see that? I did see that and I addressed it in my comment. The AS admin and = developer can still refer to an internal identifier without it being = exposed in the protocol.=20 >=20 > I agree that dynamic client IDs in OAuth 2 were problematic. In XAuth, = a Dynamic Client is identified by its key. >=20 > Would you clarify what is broken with Client IDs for Registered = Clients? It seems to working fine for registered clients in OAuth 2 / = OpenID Connect, and migrating those deployments will be simpler if we = keep the same concept. >=20 > The key handle seems problematic as it will change when keys are = rotated.=20 Why would the key handle change when the key is rotated? Nothing in XYZ = dictates how the key handle is generated by the AS or how the key handle = is mapped to a specific key. It=E2=80=99s not a key identifier, which is = why I haven=E2=80=99t called it a =E2=80=9Ckey id=E2=80=9D.=20 I don=E2=80=99t see why a registered client can=E2=80=99t be identified = by its key just like a dynamic client would be. What is the value in = this split? I think there=E2=80=99s value in treating all clients the = same and driving the differences in policy on the AS. Either I recognize = a key handle, or I am being given a public key (which I also might = recognize). In all of these cases the AS gets to run its policy against = the party identified by the key. > =20 >=20 > 3. XAuth uses a =E2=80=9Ctype=E2=80=9D field for interaction. This = means the client can only do one type of interaction for any given = transaction. XYZ started like this, but we moved away from it because we = realized we could have a client app that could handle multiple types = without that kind of dispatch. In XYZ the client sends over flags for = each kind of interaction it can do: send the user to an arbitrary URL, = give the user a code, get a callback from a browser, etc. Combining = these in specific ways addresses all of the different methods that XAuth = identifies as its types while also allowing additional things. The AS = picks from the client=E2=80=99s list based on what the AS can support as = well as what makes sense for the policies governing the requested = access. >=20 > Do you have a use case where the AS will want to pick from a list, = rather than supporting the one that the Client wants to use? The AS would return interaction responses that are the intersection of: - methods the client indicates it can do in the request - methods the AS knows it can support - methods allowed by the policy governing the request I don=E2=80=99t understand the second part of this question, because the = AS still =E2=80=9Csupports the one the client wants to use=E2=80=9D in = the XYZ model. As for a concrete example, look at how we handle the =E2=80=9Cqrcode=E2=80= =9D interaction case, based on OAuth 2=E2=80=99s device flow. In this, = you want to send a URI to the client that it can render as a QR code as = well as a code that the user can type into a page, in case they can=E2=80=99= t scan the QR code. OAuth 2 manages this by having a user code as well = as a pre-composed URL containing the code to be used for rendering. XYZ = used to have a mode for this similar to XAuth, but we realized that we = could describe this using two separate flags:=20 - I can communicate a short code that the user can type in at a static = URL - I can get the user to go to an arbitrary URL The second one is the same mechanism we can use for redirect-based auth.=20= >=20 > In the case where the AS interacts with an RO that is not the User, = there would be nothing the Client would need to do. Perhaps there is a = use case for something different? If so, please elaborate. > =20 >=20 > 4. XAuth allows OAuth-style scopes next to RAR-style data structures = (and next to OIDC claims structures). They are treated as completely = separate from each other. In OAuth 2, RAR is defined in the context of = scope (and resource and audience and other parameters), and this = combination is a matter of some debate still that needs to be solved. = However, it=E2=80=99s clear that they=E2=80=99re combined. In XYZ, the = only resource request defined is the object inside the resource request. = You can mimic =E2=80=9Cscope=E2=80=9D behavior by using a Resource = Handle, which again is defined as a single string that stands in for the = whole object and could be defined by the AS (or the API it=E2=80=99s = protecting).=20 >=20 > I think you need to reread the 00 draft. Only one type of = authorization request is allowed. >=20 > - OAuth style for deployments where that works fine. > - RAR style for deployments that need the extra granularity of RAR > - list of RAR style for deployments that support multiple resource = servers that require independent access tokens. > =20 >=20 > 5. The different kinds of authz requests in (4) create separate = tokens.This is very different from both OAuth 2 and XYZ, where you get = back a single access token. And in XAuth there is no way to get, for = example, two access tokens that are both described by RAR requests, so = this seems like a very arbitrary and syntactically-driven separation.=20 >=20 > I don't think you understood what is in the draft. See above. Apologies on these points =E2=80=94 I didn=E2=80=99t catch that this had = changed from the earlier drafts.=20 > =20 >=20 > 6. The assumption that JOSE will always be in the toolkit of the = client developer is not true. You can do an XYZ transaction without any = JOSE =E2=80=94 for example, using HTTP Sig or MTLS for key presentation.=20= >=20 > Per earlier feedback from you, I have strived to separate JOSE out = into Section 8, so that an extension could use HTTP signing or MTLS. Let = me know where JOSE is still an assumption. The separation is OK in the current draft, but it still states that JOSE = is the default, and by implication, preferred.=20 > =20 >=20 > 7. The statement that =E2=80=9Cthere is no HTTP signing=E2=80=9D is = false, as this is being brought up to the HTTP WG right now (I=E2=80=99m = one of the co-authors). Yes, it=E2=80=99s not an RFC, but neither is = this. And if we=E2=80=99re doing agile signature methods, which I = contend is a required extension point, then we don=E2=80=99t have a = dependency requirement for it.=20 >=20 > XAuth says from = https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-12 = # = 3 >=20 > There is currently no widely deployed open standard for HTTP signing. =20= > =20 > Yes, there is working going on. But security it is not a published = RFC, there are no libraries for it, and it has not been tested on the = open internet.=20 >=20 > While I wish the HTTP WG luck in this work, and I support it = happening, it will be hard. >=20 > OAuth 1.0 core issue was that it was signing a request (in my opinion) Which is why we shouldn=E2=80=99t have a normative dependency on it = until it=E2=80=99s done, but ignoring it entirely is silly. I=E2=80=99ve = always said this needs to be one among many options. >=20 > The widely deployed HTTP Signing is AWS SIGv4 -- which AWS supplies = libraries for every API in all popular languages so that developers = don't have to do the HTTP signing themselves.=20 >=20 > I could imagine AWS adopting XAuth and using SIGv4 instead of JOSE if = they wanted. I agree that they should be able to use TxAuth (not necessarily XAuth ;) = ) using SIGv4, if they wanted =E2=80=94 and that=E2=80=99s assuming they = don=E2=80=99t move AWS to HTTP Sig. :) >=20 >=20 >=20 > 8. XAuth adds back in an explicit =E2=80=9Crefresh token=E2=80=9D. In = XYZ, we don=E2=80=99t have a refresh token because we can use the = transaction handle to continue the transaction after a token has been = issued. This has explicit and clear semantics that follows from what the = transaction handle is used for elsewhere in the protocol =E2=80=94 = continue this request that=E2=80=99s in some authorization state and = give me the results.=20 >=20 > I think we agree that refresh is a required feature. Yes, and I think that the constructs are similar, but the difference = matters. By using the same handle for continuing the transaction over = time as you do for refreshing, XYZ is giving the client developers a = specific model: The transaction itself has a state and value over time, = referenced by the transaction handle. The transaction entity still = exists after it=E2=80=99s been approved and a token has been issued, but = the things you can do with it are different (see below). Both continuation and refresh are saying to the AS =E2=80=9Crun this = transaction again and if I can get a token (or claims or whatever) in = its current state, give me that=E2=80=9D. However, they can=E2=80=99t = really exist at the same time, so having two separate items to ask the = same question doesn=E2=80=99t make much sense.=20 >=20 > I think a transaction handle is to course grained. I don't think that = the AS should be returning all the claims in a refresh. And if there are = multiple access tokens returned from the AS, then each has their own = refresh handle. I think this requires a deeper discussion, since the whole idea of = multiple access tokens is a very different kind of approach here.=20 I see refresh much as it is in OAuth2 and UMA, where it refers to the = authorization that was granted. This means that you can do downscoping = to get lower-powered access tokens that are a subset of the overall = grant, and I think that TxAuth should be able to do a step-up auth where = you can build some additional request on top of an existing approval.=20 > =20 >=20 > 9. XAuth uses OIDC=E2=80=99s ID Token. As I=E2=80=99ve said on the = other thread, I don=E2=80=99t think we actually need a separately signed = assertion. I=E2=80=99d rather see a way to sign the entire response = which includes the user claims, if we want signature protection. >=20 > I responded in a separate thread. > =20 >=20 > 10. XAuth sends all the user=E2=80=99s claims on the login request =E2=80= =94 or more precisely, this is the only mechanism specified and the = Rationale section claims this is a feature. This violates minimal = disclosure and privacy design guidelines, and this type of protocol has = been developed before with OpenID 1.x/2.x and SAML. The problem here = unfolds when you think about how it works: The RP needs to log in. If = this is the first time it=E2=80=99s seen this user, then it needs the = user=E2=80=99s profile info. If not, and the profile info hasn=E2=80=99t = changed, there=E2=80=99s no need for it and the AS shouldn=E2=80=99t = send it. So the RP can signal this, right? Except that the RP doesn=E2=80=99= t know who the user is yet (that=E2=80=99s why they=E2=80=99re making = this call!). Can the AS make this call? They won=E2=80=99t know if the = RP has cached the user=E2=80=99s info or not. And if we=E2=80=99re using = Client ID, then the AS can=E2=80=99t even be sure that this copy of the = client is the same as another copy of the client. I think TxAuth needs = to minimize the user claims sent back to being an identifier, = information about the authentication event that could change each time = anyway, and anything that would be needed to control a cache. Additional = fields can be pulled from the equivalent of a UserInfo Endpoint in a = two-stage process that both preserves privacy and optimizes for what=E2=80= =99s available from each party. >=20 > Not clear how XYZ improves on this. XYZ does not currently internally specify how to hand user info back, = but I was looking at something in line with what Aaron Parecki=E2=80=99s = blog post specified last summer.=20 >=20 > The UserInfo Endpoint solves the Client getting more info than it = needs, but the User still needs to give consent each time unless the AS = tracks it. So it is unclear to me what value the UserInfo Endpoint = brings. Remembering user consent and delivering claims are two completely = separate problems and should not be conflated here. I was addressing the = former.=20 >=20 > Your comments have inspired me on a solution that can be done with = XAuth (or XYZ) that can't be done with OAuth 2.0/OIDC. >=20 > I'll add that to the XAuth draft and publish it.=20 > =20 >=20 > 11. XAuth defines an explicit discovery step because the client now = needs to know several things about the server. The mix-up attack and a = few other attacks in OAuth 2 stem from this kind of process. In XYZ, the = client really only needs to know the transaction endpoint URL and it = learns everything else from that point. Yes, the client needs to = discover that someplace =E2=80=94 but it was a deliberate decision in = limiting the amount of upfront information that the client needs to get = started. >=20 > That is still discovery, is it not? I literally just called it that in the sentence above, so yes. :) What = you=E2=80=99re discovering is different though. And doesn=E2=80=99t the = client still need to =E2=80=9Cdiscover=E2=80=9D the discovery endpoint = in XAuth? >=20 > Would the Client not need to know the message signing methods = supported? JOSE, HTTP Signing, and/or MTLS?=20 Only required if the client can programmatically do anything about that. = The truth is that just about every client is going to be configured to = do one kind of signing, and the developer can usually discover that. I = don=E2=80=99t see a problem with having it listed in a discovery = document next to the transaction endpoint, but I think we don=E2=80=99t = actually need it because of the items below: > =20 > I=E2=80=99ve played with the concept of a =E2=80=9Ccapabilities=E2=80=9D= list in XYZ, where the client would present a list of things it can do = and the AS trims that list to what it can also do. >=20 > So ... programatic discovery? =3D) >=20 > Are you suggesting that discovery of everything but the endpoint has = to be programatic?=20 In no way, shape, or form am I implying that. I=E2=80=99m saying that = the items that can be used for programmatic discovery can be returned = from the transaction endpoint without need for a separate endpoint. This = can even include the signing methods, and the round-trips for an = automated client are basically the same.=20 So take the XAuth approach: - client gets configured with the discovery endpoint - client calls discovery endpoint, self-configures - client calls tx endpoint And the XYZ approach: - client gets configured with the tx endpoint - client calls tx endpoint, picks whatever default method it wants for = signing (TxAuth spec can even declare a preferred version if we want) - if it works, tx has already started and things just continue = =E2=80=94 this optimizes for the happy path - if it fails, client gets back information to allow it to = self-configure and calls the tx endpoint again This is what I mean by one-stage negotiation on the discovery. If the = client gets it right, that=E2=80=99s fine and things just continue = without the extra step. If the client gets it wrong, it=E2=80=99s given = the equivalent of information from the discovery endpoint that it can = either self correct (which it would be able to do if it could self = configure from a discovery document) or it will throw an error (which is = what it=E2=80=99d do if it gets a discovery document it can=E2=80=99t do = anything with).=20 > =20 > This type of one-stage negotiation is really powerful and I think we = can get a lot from it here. >=20 > Sure ... but for many people what works today is documentation that = someone reads to understand what to do. Are you suggesting we not enable = that? I am not suggesting that we disallow human-readable documentation and = static configuration. I have no idea where you got that I was suggesting = that. But to be clear, yes you can still document things and pre-configure = them. In fact, I think that=E2=80=99s better handled in XYZ that allows = the client to be pre-configured and get started with a TX request, and = then recover better if things aren=E2=80=99t what it thought. > =20 >=20 >=20 > All in all, thanks for the draft. I think it raises important = questions and the discussion of these questions will help us build the = best system we can. >=20 > Thanks again for writing up your feedback! > =20 > /Dick --Apple-Mail=_17BE1FB0-B578-49E7-9D1B-61F56F3A9619 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 30, 2020, at 12:25 AM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Wed, Jan 29, 2020 at 8:26 AM Justin = Richer <jricher@mit.edu> wrote:
As Dick has = mentioned, I gave him some early feedback on this draft before = publication, and he=E2=80=99s asked me to write up my thoughts and = responses on the current XAuth proposal that=E2=80=99s published = here.

Thanks again for that feedback Justin. I was hoping to see = your responses before you posted so that I could clarify misconceptions, = but I'll do that now on the list. =3D)

Thanks for writing this up -- I believe = it helps us identify the areas for deeper discussion to reach rough = consensus!
 

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. 

<snip>

I think XAuth has an interesting take on the problem space = that TxAuth is looking to solve, but in my opinion it generally veers = too closely to OAuth2/OIDC/JWT in its solution approach. =

Reusing aspects of OAuth2/OIDC/JWT that are working fine for = deployments will minimize the migration effort for them to take = advantage of the security features of this work such as not using the = redirect for passing parameters. I think XAuth supports the following = clause of the current draft charter: "the group will attempt to = simplify porting from OAuth 2.0 and OpenID Connect to the new protocol = where = possible.=E2=80=9D

I understand the goals here, = but I disagree that using the constructs as directly as they have been = here is the most appropriate approach.


<snip>
 
1. XAuth removes = =E2=80=9Chandles=E2=80=9D as stand-ins for various elements. In XYZ, the = =E2=80=9Chandle=E2=80=9D concept is a key abstraction point with = specific semantics. A =E2=80=9Chandle=E2=80=9D is an identifier to a = specific instantiation of a JSON object structure. Using the = =E2=80=9Chandle=E2=80=9D for Keys, for Resources, and even the whole = Transaction lets you do a lot of core things in a parallel and reusable = way. XAuth re-invents a few of these as separate items, listed below, = and I see this as a regression.

XAuth took the = transaction handle and forked it into a completion handle and a refresh = handle so that it is clear what the Client is wanting to = happen.

It was = not clear the value of the other handles that were listed in = XYZ. 

I think this may be that you = misunderstood the purposes of the handles, as you=E2=80=99ve reinvented = nearly all of them with different labels in XAuth. :)

 

2. XAuth uses a Client = ID from OAuth 2. I removed Client IDs from XYZ because I realized that = you don=E2=80=99t need them anymore. The client ID tells the AS which = client is talking in the front channel because the client can=E2=80=99t = authenticate. In the back channel, the key (or secret) identifier is = enough to identify the client =E2=80=94 that=E2=80=99s the Key Handle in = XYZ that can be passed in lieu of the key itself. The argument that = it=E2=80=99s helpful to have an identifier for doing developer support = and managing registrations is spurious, since this is an internal = identifier that never needs to be exposed by the protocol. Additionally, = a client ID assumes a registration-based model. There are ephemeral and = per-device client instances like SPA=E2=80=99s and mobile apps that = don=E2=80=99t really fit the client ID model very well. Pushing this = requirement on all clients is bad, as we=E2=80=99ve seen in OAuth 1 and = OAuth 2. XAuth tries to manage this by splitting clients into two camps, = but I=E2=80=99m saying that no client needs and external client = ID.

I addressed this in https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#secti= on-12 # 7

 7.   *Why is =
there still a Client ID?  Could we not use a fingerprint
        of the public key to identify the Client?*

        Some AS deployments do not allow calls from Registered Clients,
        and provide different functionality to different Clients.  A
        permanent identifier for the Client is needed for the Client
        developer and the AS admin to ensure they are referring to the
        same Client.  The Client ID was used in OAuth 2.0, and it served
        the same purpose

Perhaps = you did not see = that?

I did see that and I addressed it in my = comment. The AS admin and developer can still refer to an internal = identifier without it being exposed in the protocol. 


I agree that dynamic client IDs in = OAuth 2 were problematic. In XAuth, a Dynamic Client is identified by = its key.

Would = you clarify what is broken with Client IDs for Registered Clients? It = seems to working fine for registered clients in OAuth 2 / OpenID = Connect, and migrating those deployments will be simpler if we keep the = same concept.

The key handle seems problematic as it will change when keys = are = rotated. 

Why would the key handle change = when the key is rotated? Nothing in XYZ dictates how the key handle is = generated by the AS or how the key handle is mapped to a specific key. = It=E2=80=99s not a key identifier, which is why I haven=E2=80=99t called = it a =E2=80=9Ckey id=E2=80=9D. 

I= don=E2=80=99t see why a registered client can=E2=80=99t be identified = by its key just like a dynamic client would be. What is the value in = this split? I think there=E2=80=99s value in treating all clients the = same and driving the differences in policy on the AS. Either I recognize = a key handle, or I am being given a public key (which I also might = recognize). In all of these cases the AS gets to run its policy against = the party identified by the key.

 

3. XAuth = uses a =E2=80=9Ctype=E2=80=9D field for interaction. This means the = client can only do one type of interaction for any given transaction. = XYZ started like this, but we moved away from it because we realized we = could have a client app that could handle multiple types without that = kind of dispatch. In XYZ the client sends over flags for each kind of = interaction it can do: send the user to an arbitrary URL, give the user = a code, get a callback from a browser, etc. Combining these in specific = ways addresses all of the different methods that XAuth identifies as its = types while also allowing additional things. The AS picks from the = client=E2=80=99s list based on what the AS can support as well as what = makes sense for the policies governing the requested = access.

Do you have a use case where the AS = will want to pick from a list, rather than supporting the one that the = Client wants to = use?

The AS would return interaction responses = that are the intersection of:

 - = methods the client indicates it can do in the request
 - = methods the AS knows it can support
 - methods allowed by = the policy governing the request

I = don=E2=80=99t understand the second part of this question, because the = AS still =E2=80=9Csupports the one the client wants to use=E2=80=9D in = the XYZ model.

As for a concrete = example, look at how we handle the =E2=80=9Cqrcode=E2=80=9D interaction = case, based on OAuth 2=E2=80=99s device flow. In this, you want to send = a URI to the client that it can render as a QR code as well as a code = that the user can type into a page, in case they can=E2=80=99t scan the = QR code. OAuth 2 manages this by having a user code as well as a = pre-composed URL containing the code to be used for rendering. XYZ used = to have a mode for this similar to XAuth, but we realized that we could = describe this using two separate flags: 

 - I can communicate a short code that the = user can type in at a static URL
 - I can get the user to = go to an arbitrary URL

The second = one is the same mechanism we can use for redirect-based = auth. 


In the case where the AS = interacts with an RO that is not the User, there would be nothing the = Client would need to do. Perhaps there is a use case for something = different? If so, please elaborate.
 

4. XAuth allows = OAuth-style scopes next to RAR-style data structures (and next to OIDC = claims structures). They are treated as completely separate from each = other. In OAuth 2, RAR is defined in the context of scope (and resource = and audience and other parameters), and this combination is a matter of = some debate still that needs to be solved. However, it=E2=80=99s clear = that they=E2=80=99re combined. In XYZ, the only resource request defined = is the object inside the resource request. You can mimic =E2=80=9Cscope=E2= =80=9D behavior by using a Resource Handle, which again is defined as a = single string that stands in for the whole object and could be defined = by the AS (or the API it=E2=80=99s = protecting). 

I think you need to reread the 00 = draft. Only one type of authorization request is allowed.

- OAuth style for = deployments where that works fine.
- RAR style for = deployments that need the extra granularity of RAR
- = list of RAR style for deployments that support multiple resource servers = that require independent access tokens.
 

5. The different kinds = of authz requests in (4) create separate tokens.This is very different = from both OAuth 2 and XYZ, where you get back a single access token. And = in XAuth there is no way to get, for example, two access tokens that are = both described by RAR requests, so this seems like a very arbitrary and = syntactically-driven = separation. 

I don't think you understood what is in = the draft. See = above.
<= div>
Apologies on these points =E2=80=94 I = didn=E2=80=99t catch that this had changed from the earlier = drafts. 

 

6. The = assumption that JOSE will always be in the toolkit of the client = developer is not true. You can do an XYZ transaction without any JOSE = =E2=80=94 for example, using HTTP Sig or MTLS for key = presentation. 

Per earlier feedback from you, I have = strived to separate JOSE out into Section 8, so that an extension could = use HTTP signing or MTLS. Let me know where JOSE is still an = assumption.

The separation is OK in the current = draft, but it still states that JOSE is the default, and by implication, = preferred. 

 

7. The = statement that =E2=80=9Cthere is no HTTP signing=E2=80=9D is false, as = this is being brought up to the HTTP WG right now (I=E2=80=99m one of = the co-authors). Yes, it=E2=80=99s not an RFC, but neither is this. And = if we=E2=80=99re doing agile signature methods, which I contend is a = required extension point, then we don=E2=80=99t have a dependency = requirement for it. 

XAuth says from https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#secti= on-12 # 3

There is =
currently no widely deployed open standard for HTTP signing.  =
 
Yes, there is = working going on. But security it is not a published RFC, there are no = libraries for it, and it has not been tested on the open = internet. 

While I wish the HTTP WG luck in this work, and I support it = happening, it will be hard.

OAuth 1.0 core issue was that it was signing a request (in = my = opinion)

Which is why we shouldn=E2=80=99t have a = normative dependency on it until it=E2=80=99s done, but ignoring it = entirely is silly. I=E2=80=99ve always said this needs to be one among = many options.


The widely deployed HTTP Signing is AWS SIGv4 -- which AWS = supplies libraries for every API in all popular languages so that = developers don't have to do the HTTP signing themselves. 

I could imagine AWS = adopting XAuth and using SIGv4 instead of JOSE if they = wanted.
=

I agree that they should be able to use = TxAuth (not necessarily XAuth ;) ) using SIGv4, if they wanted =E2=80=94 = and that=E2=80=99s assuming they don=E2=80=99t move AWS to HTTP Sig. = :)




8. XAuth = adds back in an explicit =E2=80=9Crefresh token=E2=80=9D. In XYZ, we = don=E2=80=99t have a refresh token because we can use the transaction = handle to continue the transaction after a token has been issued. This = has explicit and clear semantics that follows from what the transaction = handle is used for elsewhere in the protocol =E2=80=94 continue this = request that=E2=80=99s in some authorization state and give me the = results. 

I think we agree that refresh is a = required = feature.

Yes, and I think that the constructs are = similar, but the difference matters. By using the same handle for = continuing the transaction over time as you do for refreshing, XYZ is = giving the client developers a specific model: The transaction itself = has a state and value over time, referenced by the transaction handle. = The transaction entity still exists after it=E2=80=99s been approved and = a token has been issued, but the things you can do with it are different = (see below).

Both continuation and = refresh are saying to the AS =E2=80=9Crun this transaction again and if = I can get a token (or claims or whatever) in its current state, give me = that=E2=80=9D. However, they can=E2=80=99t really exist at the same = time, so having two separate items to ask the same question doesn=E2=80=99= t make much sense. 


I think a transaction handle is to course grained. I don't = think that the AS should be returning all the claims in a refresh. And = if there are multiple access tokens returned from the AS, then each has = their own refresh = handle.
=

I think this requires a deeper = discussion, since the whole idea of multiple access tokens is a very = different kind of approach here. 

I see refresh much as it is in OAuth2 and UMA, = where it refers to the authorization that was granted. This means that = you can do downscoping to get lower-powered access tokens that are a = subset of the overall grant, and I think that TxAuth should be able to = do a step-up auth where you can build some additional request on top of = an existing approval. 

 

9. XAuth uses OIDC=E2=80=99s ID Token. As I=E2=80=99ve said = on the other thread, I don=E2=80=99t think we actually need a separately = signed assertion. I=E2=80=99d rather see a way to sign the entire = response which includes the user claims, if we want signature = protection.

I responded in a separate = thread.
 

10. = XAuth sends all the user=E2=80=99s claims on the login request =E2=80=94 = or more precisely, this is the only mechanism specified and the = Rationale section claims this is a feature. This violates minimal = disclosure and privacy design guidelines, and this type of protocol has = been developed before with OpenID 1.x/2.x and SAML. The problem here = unfolds when you think about how it works: The RP needs to log in. If = this is the first time it=E2=80=99s seen this user, then it needs the = user=E2=80=99s profile info. If not, and the profile info hasn=E2=80=99t = changed, there=E2=80=99s no need for it and the AS shouldn=E2=80=99t = send it. So the RP can signal this, right? Except that the RP doesn=E2=80=99= t know who the user is yet (that=E2=80=99s why they=E2=80=99re making = this call!). Can the AS make this call? They won=E2=80=99t know if the = RP has cached the user=E2=80=99s info or not. And if we=E2=80=99re using = Client ID, then the AS can=E2=80=99t even be sure that this copy of the = client is the same as another copy of the client. I think TxAuth needs = to minimize the user claims sent back to being an identifier, = information about the authentication event that could change each time = anyway, and anything that would be needed to control a cache. Additional = fields can be pulled from the equivalent of a UserInfo Endpoint in a = two-stage process that both preserves privacy and optimizes for what=E2=80= =99s available from each party.

Not clear how XYZ = improves on = this.

XYZ does not currently internally specify = how to hand user info back, but I was looking at something in line with = what Aaron Parecki=E2=80=99s blog post specified last = summer. 


The UserInfo Endpoint solves the Client getting more info = than it needs, but the User still needs to give consent each time unless = the AS tracks it. So it is unclear to me what value the UserInfo = Endpoint = brings.
=

Remembering user consent and delivering claims = are two completely separate problems and should not be conflated here. I = was addressing the former. 


Your comments have inspired me on a solution that can be done = with XAuth (or XYZ) that can't be done with OAuth 2.0/OIDC.

I'll add that to the = XAuth draft and publish it. 
 

11. = XAuth defines an explicit discovery step because the client now needs to = know several things about the server. The mix-up attack and a few other = attacks in OAuth 2 stem from this kind of process. In XYZ, the client = really only needs to know the transaction endpoint URL and it learns = everything else from that point. Yes, the client needs to discover that = someplace =E2=80=94 but it was a deliberate decision in limiting the = amount of upfront information that the client needs to get = started.

That is still discovery, is it = not?

I literally just called it that in the sentence = above, so yes. :) What you=E2=80=99re discovering is different though. = And doesn=E2=80=99t the client still need to =E2=80=9Cdiscover=E2=80=9D = the discovery endpoint in XAuth?


Would the Client not need to know the message signing methods = supported? JOSE, HTTP Signing, and/or = MTLS? 

Only required if the client can = programmatically do anything about that. The truth is that just about = every client is going to be configured to do one kind of signing, and = the developer can usually discover that. I don=E2=80=99t see a problem = with having it listed in a discovery document next to the transaction = endpoint, but I think we don=E2=80=99t actually need it because of the = items below:

 
I=E2=80=99ve played with the concept of a = =E2=80=9Ccapabilities=E2=80=9D list in XYZ, where the client would = present a list of things it can do and the AS trims that list to what it = can also do.

So ... programatic discovery? = =3D)

Are you = suggesting that discovery of everything but the endpoint has to be = programatic? 

In no way, shape, or form am I = implying that. I=E2=80=99m saying that the items that can be used for = programmatic discovery can be returned from the transaction endpoint = without need for a separate endpoint. This can even include the signing = methods, and the round-trips for an automated client are basically the = same. 

So take the XAuth = approach:

- client gets configured = with the discovery endpoint
- client calls discovery endpoint, = self-configures
- client calls tx endpoint

And the XYZ approach:

- client gets configured with the tx = endpoint
- client calls tx endpoint, picks whatever default = method it wants for signing (TxAuth spec can even declare a preferred = version if we want)
- if it works, tx has already = started and things just continue =E2=80=94 this optimizes for the happy = path
= - if it fails, client gets back information to allow it to = self-configure and calls the tx endpoint again

This is what I mean by one-stage negotiation on = the discovery. If the client gets it right, that=E2=80=99s fine and = things just continue without the extra step. If the client gets it = wrong, it=E2=80=99s given the equivalent of information from the = discovery endpoint that it can either self correct (which it would be = able to do if it could self configure from a discovery document) or it = will throw an error (which is what it=E2=80=99d do if it gets a = discovery document it can=E2=80=99t do anything = with). 


 
This type of one-stage = negotiation is really powerful and I think we can get a lot from it = here.

Sure ... but for many people what works = today is documentation that someone reads to understand what to do. Are = you suggesting we not enable = that?

I am not suggesting that we disallow = human-readable documentation and static configuration. I have no idea = where you got that I was suggesting that.

But to be clear, yes you can still document things = and pre-configure them. In fact, I think that=E2=80=99s better handled = in XYZ that allows the client to be pre-configured and get started with = a TX request, and then recover better if things aren=E2=80=99t what it = thought.

 


All in all, thanks for the draft. I = think it raises important questions and the discussion of these = questions will help us build the best system we = can.

Thanks again for writing up your = feedback!
 
/Dick

= --Apple-Mail=_17BE1FB0-B578-49E7-9D1B-61F56F3A9619-- From nobody Thu Jan 30 11: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 0457512011A for ; Thu, 30 Jan 2020 11:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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] 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 rnFeMMSiFknk for ; Thu, 30 Jan 2020 11:22:53 -0800 (PST) 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 8C4A8120088 for ; Thu, 30 Jan 2020 11:22:52 -0800 (PST) Received: by mail-lj1-x241.google.com with SMTP id q8so4577104ljj.11 for ; Thu, 30 Jan 2020 11:22:52 -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=lzhHejOMiXldIJC0kj7HKBkTHq/GWyYFwUgcOEmrTCk=; b=e1OHP4GTMZmX0UZxC/w3+/Y2Ly/GsetaZ677P91pIM6NPfaYlz1kffzTq5q6rHNzU7 DsoQZ/5D/fkyqPoBrR/sA4wtHc75SuJMRm7HdE6BzSTaul14tSnnyvg4/Q0br+QUHyo2 KgBHA5kakxEwF/nljE+FkpqoahcmmctXr0jTq4LX5tlUbDvnvbE5ip3nG/IF1lbbisO4 J9vKT8RhlRZzUZXwUjemhtAqNlKcl53vLLJRB7EN0tURp2bbDbUg9nSkUno34dtIwAKA WCtPqhP35RB0nzez/cFH78Os+8e8iM0dTdCF6jTIjSNgC57taN/aWmNERbPfT5g07C7g L5iw== 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=lzhHejOMiXldIJC0kj7HKBkTHq/GWyYFwUgcOEmrTCk=; b=XozKtR7d5TkEMUQ+QXb15I7iV8xwOcWtFYJ0tjdMLZ7fcET4WrmdXszl/o+zzCPYNF +XYnmYMVVZv98siwWQ+aXA/To89mGuwehyAEYkIFBcFBB7r97e2yqqKP96PJpQvQnpUT OorrlYnOc1a51ephmEZCcotyDB8FDg+UrYCFgKRkEp4+8Yo0zaguaB9h/hWPAcs6gZmt PL+QO33jOQstxR+JDFXQqUiYf48mUUSQKaDIeUaq58SAw8Q57BD/sY0lX++2F5GFWrkh inDADQ3IIuVK4SJ8iGz5G37C6ebLj54vdG9wgiwqgMm5TZQ3MrlFC3tQyc+V4YgwPrZB wiGw== X-Gm-Message-State: APjAAAU4yDPp8KRkvjCK41TchTwbBDmV/e0xH0m37weUnqFFDxVO9cqm O4jXVe4JiPOV2JgER8IismGyQCeXXmmeZui4ebM= X-Google-Smtp-Source: APXvYqzzD4WAC4G7N2cpLS6mB6SZQTOyp1HayBvX8WfC6aW1bHMlt/sU1q49HXGGbxjQJb8FbnN/WudrNUTjfBdxl1A= X-Received: by 2002:a2e:84d0:: with SMTP id q16mr3866660ljh.138.1580412170667; Thu, 30 Jan 2020 11:22:50 -0800 (PST) MIME-Version: 1.0 References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> <585BCD70-6B64-4058-AC70-B677695DB391@mit.edu> <7833DDB1-FB88-4151-84B6-8DABB6436B53@amazon.com> In-Reply-To: From: Dick Hardt Date: Thu, 30 Jan 2020 11:22:24 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" , Kim , Torsten Lodderstedt , Mike Jones Content-Type: multipart/alternative; boundary="000000000000080d54059d6062b4" Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: The need for signed claims - providence 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, 30 Jan 2020 19:22:56 -0000 --000000000000080d54059d6062b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My point was disagreeing with your assertion: First, I don=E2=80=99t believe there are going to be many, if any, cases wh= ere we need user claims to be signed and encrypted separately from the core transaction messages. Sharing the entire transaction with services that only need specific claims would go against the minimal disclosure tenet. On Wed, Jan 29, 2020 at 11:55 PM Justin Richer wrote: > I did: My response to your point was that we should enable this kind of > thing but not assume that user claims are going to be =E2=80=94 or need t= o be =E2=80=94 in > a signed payload. I think that what you=E2=80=99re describing is a specif= ic > architecture decision which is not that common. It shouldn=E2=80=99t be d= isallowed > but I don=E2=80=99t think other deployments should pay that cost. > > Even in OIDC today, you=E2=80=99re allowed to ignore the signature on the= signed > ID Token if it gets delivered on the back channel. In the normal case, a > JWT provides just an extra layer of wrapping without much value. Please s= ee > Aaron=E2=80=99s post for a better writeup of that. > > So in the end, I think that plain JSON should be enabled for user claims > (which XAuth also has, I=E2=80=99ll note) along with any type of packaged= assertion > like an ID Token (which I=E2=80=99ll note that XYZ also has). > > =E2=80=94 Justin > > On Jan 30, 2020, at 7:58 AM, Dick Hardt wrote: > > Justin: would you respond to my critique of your statement? I was not > talking about SETs. > > Tl;dr: multiple services in a pipeline in a complex app may need to > independently verify a claim. > =E1=90=A7 > > On Wed, Jan 29, 2020 at 10:19 PM Justin Richer wrote: > >> I think the use cases for SET are very different from an authentication >> assertion, which is consumed then discarded. Aaron Parecki has written a >> good blog post that touches on this: >> >> https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz >> >> If we need a persistent record then we can also send that =E2=80=94 mayb= e it=E2=80=99s >> even a SET instead of an ID Token? I=E2=80=99m still fine with enabling = signed JWTs >> to carry information, but what I was against was stating any assumption >> that they would always be signed or encrypted, and that JWT would be the >> assumed carrier for that. >> >> =E2=80=94 Justin >> >> On Jan 30, 2020, at 1:00 AM, Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> +1 to Dick=E2=80=99s counterpoints. The Security Considerations in >> draft-ietf-secevent-http-push >> >> talk about validation of persisted SETs as one reason a deployment may >> wish to transmit signed SETs even over a TLS-protected channel. The same >> idea applies to identity claims or just about anything else, really. >> >> =E2=80=93 >> Annabelle Richard Backman >> AWS Identity >> >> >> *From: *Dick Hardt >> *Date: *Wednesday, January 29, 2020 at 2:16 PM >> *To: *Justin Richer >> *Cc: *"txauth@ietf.org" , Kim , >> Torsten Lodderstedt , "Richard Backman, >> Annabelle" , Mike Jones > > >> *Subject: *[UNVERIFIED SENDER] Re: The need for signed claims - >> providence >> >> I forgot to include the reference to Annabelle calling this out earlier >> >> https://mailarchive.ietf.org/arch/msg/txauth/0hR49OnE3oqNPuCIQ43fN1o886w >> >> >> On Wed, Jan 29, 2020 at 1:14 PM Dick Hardt wrote: >> >> Forking the discussion to focus on signed claims >> >> On Wed, Jan 29, 2020 at 3:37 AM Justin Richer wrote: >> >> >> First, I don=E2=80=99t believe there are going to be many, if any, cases= where we >> need user claims to be signed and encrypted separately from the core >> transaction messages. Even in OIDC, the ID Token is allowed to be unsign= ed >> when it is retrieved from the token endpoint directly using the code flo= w. >> The equivalent of this is the only place that TxAuth would be sending ba= ck >> user claims directly. We no longer have a need to protect things as they >> travel through the front channel on a redirect, and we no longer have a >> need to use the user=E2=80=99s claims as an artifact for things like ses= sion >> management (we can define a new artifact for that purpose that fits >> better). This effectively means that we don=E2=80=99t need to redefine t= he ID Token >> because we don=E2=80=99t need the equivalent of the ID token in the same= way.. For >> the cases that we do need to define user claims, we should be defining t= hem >> as a JSON object model. And I also believe that this JSON data model sho= uld >> not be intertwined with or constrained by the JWT claims registry. The O= IDC >> claims registry can serve as influence and input to our user claims set = if >> we choose, but I don=E2=80=99t think we should be intertwined with that = either. >> >> >> I disagree. I think it is likely that we will see an increase in signed >> claims and messages. >> >> In my opinion, the providence of a claim or message is far more importan= t >> than protection during transit. >> >> *Client / AS non-repudiation*: when sensitive operations are performed >> relying on the contents of a claim, the Client will want repudiation tha= t >> the AS or claims issuer made a claim. >> >> *Separation of duties in complex systems*: In large organizations, a >> major security threat is a malicious insider. Once an organization reach= es >> a certain size, you assume there are people employed at the company that= do >> not have the firms best interests in mind. One mitigation of this threat= is >> done by separating what different teams can do with customer / sensitive >> data, requiring collusion to access or modify the data. Signed messages = and >> claims simplify different components being able to independently verify = a >> message or claim. Similarly, a component issuing a claim, has assurance >> that other components in the same system are not modifying it. Large >> organizations wrap external systems that do not support this with their = own >> security mechanism -- but not all organizations are this sophisticated, = and >> as they grow, retrofitting is difficult. Enabling end to end providence = is >> a best practice in my opinion. >> >> *User Consent Audit*: as privacy becomes a larger public topic, it is >> easy to imagine organizations wanting to prove that they obtained user >> information with consent. Rather than gathering user information directl= y >> from the user, a Client can acquire claims from the User's claims provid= er >> that asserts the user provided consent to the Client. The Client can the= n >> technically establish that all user data was gathered with consent, and = the >> context of the consent. >> >> While the message containing the claims may be signed, having independen= t >> claims separately signed simplifies the least privilege tenet, where a >> component only has access to the user information it needs.. >> >> /Dick >> >> >> > --000000000000080d54059d6062b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My point was disagreeing with your assert= ion:
<= div>

First, I don=E2=80=99t believe there are= going to be many, if any, cases where we need user claims to be signed and= encrypted separately from the core transaction messages.
<= br>
Sharing the entire transaction with=C2=A0services tha= t only need specific claims would go against the minimal disclosure tenet.= =C2=A0
On Wed, Jan 29, 2020 at 11:55 PM Justin Richer <jricher@mit.edu> wrote:
= I did: My response to your point was that we should enable this kind of thi= ng but not assume that user claims are going to be =E2=80=94 or need to be = =E2=80=94 in a signed payload. I think that what you=E2=80=99re describing = is a specific architecture decision which is not that common. It shouldn=E2= =80=99t be disallowed but I don=E2=80=99t think other deployments should pa= y that cost.=C2=A0

Even in OIDC today, you=E2=80=99re al= lowed to ignore the signature on the signed ID Token if it gets delivered o= n the back channel. In the normal case, a JWT provides just an extra layer = of wrapping without much value. Please see Aaron=E2=80=99s post for a bette= r writeup of that.

So in the end, I think that pla= in JSON should be enabled for user claims (which XAuth also has, I=E2=80=99= ll note) along with any type of packaged assertion like an ID Token (which = I=E2=80=99ll note that XYZ also has).

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

On Jan 30, 2020, at 7= :58 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

Ju= stin: would you respond to my critique of your statement? I was not talking= about SETs.

Tl;dr: multiple services in a pipeline in a= complex app may need to independently verify a claim.=C2=A0
3D""=E1=90=A7

On Wed, Jan 29, 2020 at 10:19 PM Justin Riche= r <jricher@mit.edu<= /a>> wrote:
<= div>I think the use cases for SET are very different from an authentication= assertion, which is consumed then discarded. Aaron Parecki has written a g= ood blog post that touches on this:

If we need a persistent record then we can also send that =E2= =80=94 maybe it=E2=80=99s even a SET instead of an ID Token? I=E2=80=99m st= ill fine with enabling signed JWTs to carry information, but what I was aga= inst was stating any assumption that they would always be signed or encrypt= ed, and that JWT would be the assumed carrier for that.

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

On Jan 30= , 2020, at 1:00 AM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
+1 to Dick=E2=80=99s counterpoints.=C2=A0The Security Considerations in draft-ietf-secevent-http-pu= sh=C2=A0talk about validation of persisted SETs as one rea= son a deployment may wish to transmit signed SETs even over a TLS-protected= channel. The same idea applies to identity claims or just about anything e= lse, really.
=C2=A0
=E2=80=93=C2=A0=
Annabelle Richard Backman=
AWS Identi= ty
=C2=A0
=C2=A0
From:=C2=A0Dick Hardt <dick.hardt@gmail.com>
Date:<= span>=C2=A0Wednesday, January 29, 2020 at 2:16 PM
To:=C2=A0Justin Richer <jricher@mit.edu>
Cc:=C2=A0"= ;txauth@ietf.org&q= uot; <txauth@ietf.o= rg>, Kim <kim@identityblog.com>, Torsten Lodderstedt <torsten@lodderstedt.net>,= "Richard Backman, Annabelle" <richanna@amazon.com>, Mike Jones <Michael.Jones@m= icrosoft.com>
Subject:=C2=A0[UNVERIFIED SENDE= R] Re: The need for signed claims - providence
=C2=A0
I fo= rgot to include the reference to Annabelle calling this out earlier<= u>
=C2=A0
<= /div>
Forking the discussion to focus on sign= ed claims
=C2=A0
On Wed, Jan 29, 2020 at 3:37 AM Justin Richer <jricher@mit.edu> wrote:
<= div>
<snip>
First, I don=E2=80=99t believe there are g= oing to be many, if any, cases where we need user claims to be signed and e= ncrypted separately from the core transaction messages. Even in OIDC, the I= D Token is allowed to be unsigned when it is retrieved from the token endpo= int directly using the code flow. The equivalent of this is the only place = that TxAuth would be sending back user claims directly. We no longer have a= need to protect things as they travel through the front channel on a redir= ect, and we no longer have a need to use the user=E2=80=99s claims as an ar= tifact for things like session management (we can define a new artifact for= that purpose that fits better). This effectively means that we don=E2=80= =99t need to redefine the ID Token because we don=E2=80=99t need the equiva= lent of the ID token in the same way.. For the cases that we do need to def= ine user claims, we should be defining them as a JSON object model. And I a= lso believe that this JSON data model should not be intertwined with or con= strained by the JWT claims registry. The OIDC claims registry can serve as = influence and input to our user claims set if we choose, but I don=E2=80=99= t think we should be intertwined with that either.
=C2=A0
I disagree. I think it is likely that we will see an increase in sig= ned claims and messages.
=C2= =A0
In my opinion, the providence of a cla= im or message is far more important than protection during transit.=C2=A0
=C2=A0
Client / AS non-repudiation: when sensitive operations ar= e performed relying on the contents of a claim, the Client will want repudi= ation that the AS or claims issuer made a claim.
<= div>
=C2=A0
Separation = of duties in complex systems: In large organizations, a major security = threat is a malicious insider. Once an organization reaches a certain size,= you assume there are people employed at the company that do not have the f= irms best interests in mind. One mitigation of this threat is done by separ= ating what different teams can do with customer / sensitive data, requiring= collusion to access or modify the data. Signed messages and claims simplif= y different components being able to independently verify a message or clai= m. Similarly, a component issuing a claim, has assurance that other compone= nts in the same system are not modifying it. Large organizations wrap exter= nal systems that do not support this with their own security mechanism -- b= ut not all organizations are this sophisticated, and as they grow, retrofit= ting is difficult. Enabling end to end providence is a best practice in my = opinion.
=C2=A0
=
User Consent Audit: as privacy becomes a larger= public topic, it is easy to imagine organizations wanting to prove that th= ey obtained user information with consent. Rather than gathering user infor= mation directly from the user, a Client can acquire claims from the User= 9;s claims provider that asserts the user provided consent to the Client. T= he Client can then technically establish that all user data was gathered wi= th consent, and the context of the consent.
<= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0
While the message c= ontaining the claims may be signed, having independent claims separately si= gned simplifies the least privilege tenet, where a component only has acces= s to the user information it needs..=C2=A0=C2=A0
<= div>
=C2=A0
/Dick

=

--000000000000080d54059d6062b4-- From nobody Thu Jan 30 11:50: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 5EE1F1201A3 for ; Thu, 30 Jan 2020 11:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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] 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 w6t-R6FZmJEn for ; Thu, 30 Jan 2020 11:50:42 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06DE120128 for ; Thu, 30 Jan 2020 11:50:41 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id q8so4658763ljj.11 for ; Thu, 30 Jan 2020 11:50:41 -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=M4wM3/whoVwIfhi7Gwsxfw+r429luM3tf3JvXkIP6vY=; b=BI3Uj68YzWExnLoxl7n50wuCmRfKEEOspU13FPcebZrZ/HDCfQO0k3tkPlGfUVBdvB g4RwHQxfqlaKLOTVdKDjD1VBZ2Z+bc6sV25KcHhoNaehbxoVCLG7NUfHRpOEs2RMr92b skRBkXWkLkF5nLYS/RIN8q5HR/BLa51IW1CZgme+LmUQ2nnMulzUSe3G6PVoDIRSMvzd LBX8h5Vhd6892OUeo5KtD5n60omzza5DQljr6VA6jjLWl48e1vAZwLNUbrv4gWOKoOqz arV3uEFhPMQqX6Izq+RT4fQB+caxopf5mwG9esfR2PM22du6QNBvRsV8BARVgCegu/xB 7Evg== 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=M4wM3/whoVwIfhi7Gwsxfw+r429luM3tf3JvXkIP6vY=; b=WcMIkbNIoFa/M9T4aC8H3Cc9adgXC0M6eWVoNCtjxiCNkx0drVgS6maZA/VXSyTX19 KGWzIDB08JaMlS0OrRHR5plmfQZ5SzV7XotwvCakixv8t77uOdIInvIPFRwL3/br4URP jAgWeeZ7OmkP0GHCqIiDVbhCOAyqREWVHt5KJeehTqy1WUkRkTTj0z0duKDaWudvMsmo f7Q4g527Y99A+4cIEW0VTXC8o9ZUzg9idUSb3L69wD8yM0UWW76YMbUzfxw2VYJ1qClx K0S6m1Q3DAfxxHCkpa2fUlBuEpS+7lKIm4BJxyDpf2EuCND4nSoWJPlYMFsrAkgc96s3 zBpw== X-Gm-Message-State: APjAAAVoCizx9ABVxJkKPZvUigXadx8Bcn9VPvnHUnp1DMsnqqv+v5Ml yQ3+uAFztzvwiGlae2eH0QQ2DiYlu1ndlIK09lU= X-Google-Smtp-Source: APXvYqzAoZxLPZUjaDKoDByRhWaiUgzVw4DBYzvf9szD3LCn7X76Sve4merjpZW9mLtrRWKwYzQZHDT8vVL76Qm++uc= X-Received: by 2002:a2e:730e:: with SMTP id o14mr3258917ljc.51.1580413840011; Thu, 30 Jan 2020 11:50:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 30 Jan 2020 11:50:13 -0800 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000883668059d60c5bb" Archived-At: Subject: Re: [Txauth] XAuth-01 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, 30 Jan 2020 19:50:45 -0000 --000000000000883668059d60c5bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The authentication first feature solves a different, but related problem than the token-protected user information API. It deals how to minimize when user consent is requested. Either the AS prompts for release of claims and authorizations on each request, or the AS must remember which claims where released to which Client for each User. If the AS is used for authentication, the user experience of constantly being prompted is poor, so many implementations remember what was previously released, and make it available at the user info endpoint, because the AS does not know if the Client wants to fetch the data again. From a privacy point of view, making the AS remember which Clients received which claims is a burden on the AS. A compromise of the AS exposes a User's history across the all Clients. Additionally, the AS must deal with the User changing or deleting their information. Does the AS provide the new data without consent? Does it continue to provide an API to data the User has deleted? The implementation details at the AS are pretty complicated. Perhaps I am missing something, but the user info API allows a Client to decide if it when it wants to fetch data. It ALWAYS has access to the data. Since we now have a communication link between the Client and the AS *whil= e the User is at the AS*, the Client can dynamically determine what information it needs. I'm *NOT* suggesting we should support authentication first, I was just sharing an insight that it was possible now. It does complicate the protocol, but it can simplify Client and AS implementations as it brings an implementation issue into the protocol. It also makes it crisp when data between the Client and AS is shared, without prompting the User each time. /Dick On Wed, Jan 29, 2020 at 11:56 PM Justin Richer wrote: > Thanks for this iteration. I think this is a much more complicated > approach than having a token-protected user information API, though. > > =E2=80=94 Justin > > On Jan 30, 2020, at 8:06 AM, Dick Hardt wrote: > > For some reason, the IETF links for draft-hardt-xauth are broken in the > data tracker, but are working in ietf tools. > > The latest version is still up at > https://tools.ietf.org/id/draft-hardt-xauth-protocol-00.html > > But the 01 submission is stuck. > > You can see it here: > > > https://dickhardt.github.io/hardt-xauth-protocol/draft-hardt-xauth-protoc= ol.html > > See the changelog for changes. > > The big change is letting the Client ask the AS to authenticate the User, > and then return those results while the AS is still interacting with the > User. The Client can then look up the User, and decide what identity clai= ms > and/or authorizations to request from the User, if any. > > The Client can then make another request for that information, or for > nothing. > > New Users, or Users that have not provided the latest set of information, > are prompted to release it, and the results are returned to the Client. > Existing Users that have provided everything are not prompted. > > The sequence is a little more complicated, but looks to me like it solves > the issue that Justin brought up in his critique. > > > /Dick > =E1=90=A7 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000883668059d60c5bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The authentication first feature solves a= different, but related problem than the token-protected user information A= PI. It deals how to minimize when user consent is requested.

=
Either the AS prompts for release of claims and authorizations on each= request, or the AS must remember which claims where released to which Clie= nt for each User. If the AS is used for authentication, the user experience= of constantly being prompted is poor, so many implementations remember wha= t was previously released, and make it available at the user info endpoint,= because the AS does not know if the Client wants to fetch the data again. = >From a privacy point of view, making the AS remember which Clients received= =C2=A0which claims is a burden on the AS. A compromise of the AS exposes a = User's history across the all Clients.

Ad= ditionally, the AS must deal with the User changing or deleting their infor= mation. Does the AS provide the new data without consent? Does it continue = to provide an API to data the User has deleted? The implementation details = at the AS are pretty complicated.

Perhaps I= am missing something, but the user info API allows a Client to decide if i= t when it wants to fetch data. It ALWAYS has access to the data.=C2=A0

Since we now have a communication link between the Cli= ent and the AS=C2=A0 while the User is at the AS, the Client can dyn= amically determine what information it needs.

I= 9;m NOT=C2=A0suggesting we should support authentication first, I wa= s just sharing an insight that it was possible now.

It does complicate the protocol, but it can simplify Client and AS implem= entations as it brings an implementation issue into the protocol. It also m= akes it crisp when data between the Client and AS is shared, without prompt= ing the User each time.=C2=A0

/Dick

=
=C2=A0


On Wed, Jan 29, 2020= at 11:56 PM Justin Richer <jricher@m= it.edu> wrote:
Thanks for this iteration. = I think this is a much more complicated approach than having a token-protec= ted user information API, though.

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

On Jan 30, 2020, at 8:06 AM, Di= ck Hardt <dick= .hardt@gmail.com> wrote:

For some rea= son, the IETF links for draft-hardt-xauth are broken in the data tracker, b= ut are working in ietf tools.


But the 01 submission is stuck.=

You can see it here:


See= the changelog for changes.

The big change is lett= ing the Client ask the AS to authenticate the User, and then return those r= esults while the AS is still interacting with the User. The Client can then= look up the User, and decide what identity claims and/or authorizations to= request from the User, if any.

The Client can the= n make another request for that information, or for nothing.

=
New Users, or Users that have not provided the latest set of inf= ormation, are prompted to release it, and the results are returned to the C= lient. Existing Users that have provided everything are not prompted.
=

The sequence is a little more complicated, but looks to= me like it solves the issue that Justin brought up in his critique.
<= div>

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

--000000000000883668059d60c5bb-- From nobody Thu Jan 30 12: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 34CDC1201E4 for ; Thu, 30 Jan 2020 12:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.799 X-Spam-Level: X-Spam-Status: No, score=-11.799 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, 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, 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 feRme6gmt4RW for ; Thu, 30 Jan 2020 12:09:52 -0800 (PST) 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 D162D120170 for ; Thu, 30 Jan 2020 12:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1580414991; x=1611950991; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8OQsxoLy7QRRSCMYVY0LvYGJ5tXuin1a3M/hQhdgFAk=; b=NeyK2cGysJShfdiss0Z6AnhSTXhwF8wSxCsGC4ZOR6IyVlKUgPKfoiSD f4q5M2eJVEZtHJM2RN0a+Foi7Er4Y0E+GtFWnr472jbHEeVQr8i7X0KZ0 mCulPsfsxqGK7MBoxD1n63sCBTqMIKa6OPDnQQ9e6/FKoonwAIOlsKp+S c=; IronPort-SDR: lZo8iSdKNmaNUm3PUF6VAs+V8H/+3mmMRpLYD72QIVMq3kPwcoL1q7NU2uU9yRD8lmQ2B4TRdA 2DioleM1XzNQ== X-IronPort-AV: E=Sophos; i="5.70,382,1574121600"; d="scan'208,217"; a="23478460" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-62350142.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 30 Jan 2020 20:09:39 +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-62350142.us-east-1.amazon.com (Postfix) with ESMTPS id 40289A2719; Thu, 30 Jan 2020 20:09:37 +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, 30 Jan 2020 20:09:37 +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.1367.3; Thu, 30 Jan 2020 20:09:37 +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.1367.000; Thu, 30 Jan 2020 20:09:36 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt , Justin Richer CC: "txauth@ietf.org" , Kim , "Torsten Lodderstedt" , Mike Jones Thread-Topic: [UNVERIFIED SENDER] Re: The need for signed claims - providence Thread-Index: AQHV10K3kSoHYLEM9kSxQdbZn/g3U6gDlq0A//+HFAA= Date: Thu, 30 Jan 2020 20:09:36 +0000 Message-ID: <0C42D0BD-5780-4075-BE70-F69F6001A14B@amazon.com> References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> <585BCD70-6B64-4058-AC70-B677695DB391@mit.edu> <7833DDB1-FB88-4151-84B6-8DABB6436B53@amazon.com> 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.249] Content-Type: multipart/alternative; boundary="_000_0C42D0BD57804075BE70F69F6001A14Bamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: The need for signed claims - providence 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, 30 Jan 2020 20:09:54 -0000 --_000_0C42D0BD57804075BE70F69F6001A14Bamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXJndWluZyB0aGF0IGNsYWltcyBhbHdheXMgbmVlZCB0byBiZSBpbmRlcGVuZGVu dGx5IHNpZ25lZCwgYW5kIEkgZG9u4oCZdCBiZWxpZXZlIERpY2sgaXMgZWl0aGVyLiBNeSBjb25j ZXJuIGFyb3NlIGZyb20gdGhpcyBiaXQgb2YgeW91ciBmb2xsb3cgdXAgcmVzcG9uc2UgdG8gTWlr ZToNCg0KRXZlbiBpbiBPSURDLCB0aGUgSUQgVG9rZW4gaXMgYWxsb3dlZCB0byBiZSB1bnNpZ25l ZCB3aGVuIGl0IGlzIHJldHJpZXZlZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCBkaXJlY3RseSB1 c2luZyB0aGUgY29kZSBmbG93LiBUaGUgZXF1aXZhbGVudCBvZiB0aGlzIGlzIHRoZSBvbmx5IHBs YWNlIHRoYXQgVHhBdXRoIHdvdWxkIGJlIHNlbmRpbmcgYmFjayB1c2VyIGNsYWltcyBkaXJlY3Rs eS4NCg0KVGhpcyBzb3VuZGVkIHRvIG1lIGxpa2UgeW91IHdlcmUgc2F5aW5nIHRoYXQgdGhlIG9u bHkgcmVhc29uIGZvciBzaWduaW5nIG9yIGVuY3J5cHRpbmcgdGhlIElEIFRva2VuIGlzIHRvIHNl Y3VyZSBpdCBhcyBpdCBwYXNzZXMgdGhyb3VnaCB0aGUgZnJvbnQgY2hhbm5lbC4gVGhhdCBpcyBu b3QgdGhlIGNhc2UsIGFzIERpY2sgZXhwbGFpbmVkLg0KDQpGb3J0dW5hdGVseSwgSSBkb27igJl0 IHRoaW5rIGFueSBvZiB0aGlzIG1hdHRlcnMgYXMgZmFyIGFzIHRoZSBjaGFydGVyIGlzIGNvbmNl cm5lZC4gSXQgaXMgc3VmZmljaWVudCBmb3IgdGhlIGNoYXJ0ZXIgdG8gc2F5IHRoYXQgaWRlbnRp dHkgaXMgaW4gc2NvcGUuIFRoZSBzcGVjaWZpYyBtZWNoYW5pc20ocykgY2FuIGFuZCBzaG91bGQg YmUgZGV0ZXJtaW5lZCBieSB0aGUgd29ya2luZyBncm91cCwgaW4gdGhlIGNvbnRleHQgb2YgYSBk cmFmdCBzcGVjaWZpY2F0aW9uLiBJbmNsdWRpbmcgYSBwYXJ0aWN1bGFyIHByb2JsZW0gd2l0aGlu IHRoZSBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cCBkb2VzIG5vdCBtZWFuIHRoYXQgdGhlIHdv cmtpbmcgZ3JvdXAgaGFzIHRvIGludmVudCBhIGJyYW5kIG5ldyB3YXkgdG8gc29sdmUgdGhhdCBw cm9ibGVtLiBJdCBqdXN0IG1lYW5zIHRoYXQgd2UgY2FuIGludmVudCBzb21ldGhpbmcgbmV3LCBp ZiB3ZSBkZXRlcm1pbmUgaXQgaXMgd29ydGh3aGlsZSB0byBkbyBzby4NCg0K4oCTDQpBbm5hYmVs bGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBEaWNrIEhhcmR0IDxk aWNrLmhhcmR0QGdtYWlsLmNvbT4NCkRhdGU6IFRodXJzZGF5LCBKYW51YXJ5IDMwLCAyMDIwIGF0 IDExOjIzIEFNDQpUbzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1Pg0KQ2M6ICJSaWNo YXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb20+LCAidHhhdXRoQGll dGYub3JnIiA8dHhhdXRoQGlldGYub3JnPiwgS2ltIDxraW1AaWRlbnRpdHlibG9nLmNvbT4sIFRv cnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiwgTWlrZSBKb25lcyA8 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KU3ViamVjdDogUmU6IFtVTlZFUklGSUVEIFNF TkRFUl0gUmU6IFRoZSBuZWVkIGZvciBzaWduZWQgY2xhaW1zIC0gcHJvdmlkZW5jZQ0KDQpNeSBw b2ludCB3YXMgZGlzYWdyZWVpbmcgd2l0aCB5b3VyIGFzc2VydGlvbjoNCg0KRmlyc3QsIEkgZG9u 4oCZdCBiZWxpZXZlIHRoZXJlIGFyZSBnb2luZyB0byBiZSBtYW55LCBpZiBhbnksIGNhc2VzIHdo ZXJlIHdlIG5lZWQgdXNlciBjbGFpbXMgdG8gYmUgc2lnbmVkIGFuZCBlbmNyeXB0ZWQgc2VwYXJh dGVseSBmcm9tIHRoZSBjb3JlIHRyYW5zYWN0aW9uIG1lc3NhZ2VzLg0KDQpTaGFyaW5nIHRoZSBl bnRpcmUgdHJhbnNhY3Rpb24gd2l0aCBzZXJ2aWNlcyB0aGF0IG9ubHkgbmVlZCBzcGVjaWZpYyBj bGFpbXMgd291bGQgZ28gYWdhaW5zdCB0aGUgbWluaW1hbCBkaXNjbG9zdXJlIHRlbmV0Lg0KDQpP biBXZWQsIEphbiAyOSwgMjAyMCBhdCAxMTo1NSBQTSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1p dC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KSSBkaWQ6IE15IHJlc3BvbnNl IHRvIHlvdXIgcG9pbnQgd2FzIHRoYXQgd2Ugc2hvdWxkIGVuYWJsZSB0aGlzIGtpbmQgb2YgdGhp bmcgYnV0IG5vdCBhc3N1bWUgdGhhdCB1c2VyIGNsYWltcyBhcmUgZ29pbmcgdG8gYmUg4oCUIG9y IG5lZWQgdG8gYmUg4oCUIGluIGEgc2lnbmVkIHBheWxvYWQuIEkgdGhpbmsgdGhhdCB3aGF0IHlv deKAmXJlIGRlc2NyaWJpbmcgaXMgYSBzcGVjaWZpYyBhcmNoaXRlY3R1cmUgZGVjaXNpb24gd2hp Y2ggaXMgbm90IHRoYXQgY29tbW9uLiBJdCBzaG91bGRu4oCZdCBiZSBkaXNhbGxvd2VkIGJ1dCBJ IGRvbuKAmXQgdGhpbmsgb3RoZXIgZGVwbG95bWVudHMgc2hvdWxkIHBheSB0aGF0IGNvc3QuDQoN CkV2ZW4gaW4gT0lEQyB0b2RheSwgeW914oCZcmUgYWxsb3dlZCB0byBpZ25vcmUgdGhlIHNpZ25h dHVyZSBvbiB0aGUgc2lnbmVkIElEIFRva2VuIGlmIGl0IGdldHMgZGVsaXZlcmVkIG9uIHRoZSBi YWNrIGNoYW5uZWwuIEluIHRoZSBub3JtYWwgY2FzZSwgYSBKV1QgcHJvdmlkZXMganVzdCBhbiBl eHRyYSBsYXllciBvZiB3cmFwcGluZyB3aXRob3V0IG11Y2ggdmFsdWUuIFBsZWFzZSBzZWUgQWFy b27igJlzIHBvc3QgZm9yIGEgYmV0dGVyIHdyaXRldXAgb2YgdGhhdC4NCg0KU28gaW4gdGhlIGVu ZCwgSSB0aGluayB0aGF0IHBsYWluIEpTT04gc2hvdWxkIGJlIGVuYWJsZWQgZm9yIHVzZXIgY2xh aW1zICh3aGljaCBYQXV0aCBhbHNvIGhhcywgSeKAmWxsIG5vdGUpIGFsb25nIHdpdGggYW55IHR5 cGUgb2YgcGFja2FnZWQgYXNzZXJ0aW9uIGxpa2UgYW4gSUQgVG9rZW4gKHdoaWNoIEnigJlsbCBu b3RlIHRoYXQgWFlaIGFsc28gaGFzKS4NCg0KIOKAlCBKdXN0aW4NCg0KDQpPbiBKYW4gMzAsIDIw MjAsIGF0IDc6NTggQU0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpk aWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpKdXN0aW46IHdvdWxkIHlvdSByZXNwb25k IHRvIG15IGNyaXRpcXVlIG9mIHlvdXIgc3RhdGVtZW50PyBJIHdhcyBub3QgdGFsa2luZyBhYm91 dCBTRVRzLg0KDQpUbDtkcjogbXVsdGlwbGUgc2VydmljZXMgaW4gYSBwaXBlbGluZSBpbiBhIGNv bXBsZXggYXBwIG1heSBuZWVkIHRvIGluZGVwZW5kZW50bHkgdmVyaWZ5IGEgY2xhaW0uDQpbaHR0 cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldG cGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlkPTAzZTI2MTkxLWNmZTctNDNkYy05MDBj LTE1MDBkZGYzN2NmMF3hkKcNCg0KT24gV2VkLCBKYW4gMjksIDIwMjAgYXQgMTA6MTkgUE0gSnVz dGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90 ZToNCkkgdGhpbmsgdGhlIHVzZSBjYXNlcyBmb3IgU0VUIGFyZSB2ZXJ5IGRpZmZlcmVudCBmcm9t IGFuIGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbiwgd2hpY2ggaXMgY29uc3VtZWQgdGhlbiBkaXNj YXJkZWQuIEFhcm9uIFBhcmVja2kgaGFzIHdyaXR0ZW4gYSBnb29kIGJsb2cgcG9zdCB0aGF0IHRv dWNoZXMgb24gdGhpczoNCg0KaHR0cHM6Ly9hYXJvbnBhcmVja2kuY29tLzIwMTkvMDcvMTgvMTcv YWRkaW5nLWlkZW50aXR5LXRvLXh5eg0KDQpJZiB3ZSBuZWVkIGEgcGVyc2lzdGVudCByZWNvcmQg dGhlbiB3ZSBjYW4gYWxzbyBzZW5kIHRoYXQg4oCUIG1heWJlIGl04oCZcyBldmVuIGEgU0VUIGlu c3RlYWQgb2YgYW4gSUQgVG9rZW4/IEnigJltIHN0aWxsIGZpbmUgd2l0aCBlbmFibGluZyBzaWdu ZWQgSldUcyB0byBjYXJyeSBpbmZvcm1hdGlvbiwgYnV0IHdoYXQgSSB3YXMgYWdhaW5zdCB3YXMg c3RhdGluZyBhbnkgYXNzdW1wdGlvbiB0aGF0IHRoZXkgd291bGQgYWx3YXlzIGJlIHNpZ25lZCBv ciBlbmNyeXB0ZWQsIGFuZCB0aGF0IEpXVCB3b3VsZCBiZSB0aGUgYXNzdW1lZCBjYXJyaWVyIGZv ciB0aGF0Lg0KDQog4oCUIEp1c3Rpbg0KDQoNCk9uIEphbiAzMCwgMjAyMCwgYXQgMTowMCBBTSwg UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJp Y2hhbm5hQGFtYXpvbi5jb20+PiB3cm90ZToNCg0KKzEgdG8gRGlja+KAmXMgY291bnRlcnBvaW50 cy4gVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGluIGRyYWZ0LWlldGYtc2VjZXZlbnQtaHR0 cC1wdXNoPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNlY2V2ZW50LWh0 dHAtcHVzaC0wNyNzZWN0aW9uLTUuND4gdGFsayBhYm91dCB2YWxpZGF0aW9uIG9mIHBlcnNpc3Rl ZCBTRVRzIGFzIG9uZSByZWFzb24gYSBkZXBsb3ltZW50IG1heSB3aXNoIHRvIHRyYW5zbWl0IHNp Z25lZCBTRVRzIGV2ZW4gb3ZlciBhIFRMUy1wcm90ZWN0ZWQgY2hhbm5lbC4gVGhlIHNhbWUgaWRl YSBhcHBsaWVzIHRvIGlkZW50aXR5IGNsYWltcyBvciBqdXN0IGFib3V0IGFueXRoaW5nIGVsc2Us IHJlYWxseS4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkN Cg0KDQpGcm9tOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5o YXJkdEBnbWFpbC5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBKYW51YXJ5IDI5LCAyMDIwIGF0IDI6 MTYgUE0NClRvOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJA bWl0LmVkdT4+DQpDYzogInR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPiIg PHR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPj4sIEtpbSA8a2ltQGlkZW50 aXR5YmxvZy5jb208bWFpbHRvOmtpbUBpZGVudGl0eWJsb2cuY29tPj4sIFRvcnN0ZW4gTG9kZGVy c3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldD4+LCAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29t PG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NClN1Ympl Y3Q6IFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFRoZSBuZWVkIGZvciBzaWduZWQgY2xhaW1zIC0g cHJvdmlkZW5jZQ0KDQpJIGZvcmdvdCB0byBpbmNsdWRlIHRoZSByZWZlcmVuY2UgdG8gQW5uYWJl bGxlIGNhbGxpbmcgdGhpcyBvdXQgZWFybGllcg0KDQpodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL3R4YXV0aC8waFI0OU9uRTNvcU5QdUNJUTQzZk4xbzg4NncNCg0KDQpPbiBX ZWQsIEphbiAyOSwgMjAyMCBhdCAxOjE0IFBNIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwu Y29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KRm9ya2luZyB0aGUgZGlz Y3Vzc2lvbiB0byBmb2N1cyBvbiBzaWduZWQgY2xhaW1zDQoNCk9uIFdlZCwgSmFuIDI5LCAyMDIw IGF0IDM6MzcgQU0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVy QG1pdC5lZHU+PiB3cm90ZToNCjxzbmlwPg0KRmlyc3QsIEkgZG9u4oCZdCBiZWxpZXZlIHRoZXJl IGFyZSBnb2luZyB0byBiZSBtYW55LCBpZiBhbnksIGNhc2VzIHdoZXJlIHdlIG5lZWQgdXNlciBj bGFpbXMgdG8gYmUgc2lnbmVkIGFuZCBlbmNyeXB0ZWQgc2VwYXJhdGVseSBmcm9tIHRoZSBjb3Jl IHRyYW5zYWN0aW9uIG1lc3NhZ2VzLiBFdmVuIGluIE9JREMsIHRoZSBJRCBUb2tlbiBpcyBhbGxv d2VkIHRvIGJlIHVuc2lnbmVkIHdoZW4gaXQgaXMgcmV0cmlldmVkIGZyb20gdGhlIHRva2VuIGVu ZHBvaW50IGRpcmVjdGx5IHVzaW5nIHRoZSBjb2RlIGZsb3cuIFRoZSBlcXVpdmFsZW50IG9mIHRo aXMgaXMgdGhlIG9ubHkgcGxhY2UgdGhhdCBUeEF1dGggd291bGQgYmUgc2VuZGluZyBiYWNrIHVz ZXIgY2xhaW1zIGRpcmVjdGx5LiBXZSBubyBsb25nZXIgaGF2ZSBhIG5lZWQgdG8gcHJvdGVjdCB0 aGluZ3MgYXMgdGhleSB0cmF2ZWwgdGhyb3VnaCB0aGUgZnJvbnQgY2hhbm5lbCBvbiBhIHJlZGly ZWN0LCBhbmQgd2Ugbm8gbG9uZ2VyIGhhdmUgYSBuZWVkIHRvIHVzZSB0aGUgdXNlcuKAmXMgY2xh aW1zIGFzIGFuIGFydGlmYWN0IGZvciB0aGluZ3MgbGlrZSBzZXNzaW9uIG1hbmFnZW1lbnQgKHdl IGNhbiBkZWZpbmUgYSBuZXcgYXJ0aWZhY3QgZm9yIHRoYXQgcHVycG9zZSB0aGF0IGZpdHMgYmV0 dGVyKS4gVGhpcyBlZmZlY3RpdmVseSBtZWFucyB0aGF0IHdlIGRvbuKAmXQgbmVlZCB0byByZWRl ZmluZSB0aGUgSUQgVG9rZW4gYmVjYXVzZSB3ZSBkb27igJl0IG5lZWQgdGhlIGVxdWl2YWxlbnQg b2YgdGhlIElEIHRva2VuIGluIHRoZSBzYW1lIHdheS4uIEZvciB0aGUgY2FzZXMgdGhhdCB3ZSBk byBuZWVkIHRvIGRlZmluZSB1c2VyIGNsYWltcywgd2Ugc2hvdWxkIGJlIGRlZmluaW5nIHRoZW0g YXMgYSBKU09OIG9iamVjdCBtb2RlbC4gQW5kIEkgYWxzbyBiZWxpZXZlIHRoYXQgdGhpcyBKU09O IGRhdGEgbW9kZWwgc2hvdWxkIG5vdCBiZSBpbnRlcnR3aW5lZCB3aXRoIG9yIGNvbnN0cmFpbmVk IGJ5IHRoZSBKV1QgY2xhaW1zIHJlZ2lzdHJ5LiBUaGUgT0lEQyBjbGFpbXMgcmVnaXN0cnkgY2Fu IHNlcnZlIGFzIGluZmx1ZW5jZSBhbmQgaW5wdXQgdG8gb3VyIHVzZXIgY2xhaW1zIHNldCBpZiB3 ZSBjaG9vc2UsIGJ1dCBJIGRvbuKAmXQgdGhpbmsgd2Ugc2hvdWxkIGJlIGludGVydHdpbmVkIHdp dGggdGhhdCBlaXRoZXIuDQoNCkkgZGlzYWdyZWUuIEkgdGhpbmsgaXQgaXMgbGlrZWx5IHRoYXQg d2Ugd2lsbCBzZWUgYW4gaW5jcmVhc2UgaW4gc2lnbmVkIGNsYWltcyBhbmQgbWVzc2FnZXMuDQoN CkluIG15IG9waW5pb24sIHRoZSBwcm92aWRlbmNlIG9mIGEgY2xhaW0gb3IgbWVzc2FnZSBpcyBm YXIgbW9yZSBpbXBvcnRhbnQgdGhhbiBwcm90ZWN0aW9uIGR1cmluZyB0cmFuc2l0Lg0KDQpDbGll bnQgLyBBUyBub24tcmVwdWRpYXRpb246IHdoZW4gc2Vuc2l0aXZlIG9wZXJhdGlvbnMgYXJlIHBl cmZvcm1lZCByZWx5aW5nIG9uIHRoZSBjb250ZW50cyBvZiBhIGNsYWltLCB0aGUgQ2xpZW50IHdp bGwgd2FudCByZXB1ZGlhdGlvbiB0aGF0IHRoZSBBUyBvciBjbGFpbXMgaXNzdWVyIG1hZGUgYSBj bGFpbS4NCg0KU2VwYXJhdGlvbiBvZiBkdXRpZXMgaW4gY29tcGxleCBzeXN0ZW1zOiBJbiBsYXJn ZSBvcmdhbml6YXRpb25zLCBhIG1ham9yIHNlY3VyaXR5IHRocmVhdCBpcyBhIG1hbGljaW91cyBp bnNpZGVyLiBPbmNlIGFuIG9yZ2FuaXphdGlvbiByZWFjaGVzIGEgY2VydGFpbiBzaXplLCB5b3Ug YXNzdW1lIHRoZXJlIGFyZSBwZW9wbGUgZW1wbG95ZWQgYXQgdGhlIGNvbXBhbnkgdGhhdCBkbyBu b3QgaGF2ZSB0aGUgZmlybXMgYmVzdCBpbnRlcmVzdHMgaW4gbWluZC4gT25lIG1pdGlnYXRpb24g b2YgdGhpcyB0aHJlYXQgaXMgZG9uZSBieSBzZXBhcmF0aW5nIHdoYXQgZGlmZmVyZW50IHRlYW1z IGNhbiBkbyB3aXRoIGN1c3RvbWVyIC8gc2Vuc2l0aXZlIGRhdGEsIHJlcXVpcmluZyBjb2xsdXNp b24gdG8gYWNjZXNzIG9yIG1vZGlmeSB0aGUgZGF0YS4gU2lnbmVkIG1lc3NhZ2VzIGFuZCBjbGFp bXMgc2ltcGxpZnkgZGlmZmVyZW50IGNvbXBvbmVudHMgYmVpbmcgYWJsZSB0byBpbmRlcGVuZGVu dGx5IHZlcmlmeSBhIG1lc3NhZ2Ugb3IgY2xhaW0uIFNpbWlsYXJseSwgYSBjb21wb25lbnQgaXNz dWluZyBhIGNsYWltLCBoYXMgYXNzdXJhbmNlIHRoYXQgb3RoZXIgY29tcG9uZW50cyBpbiB0aGUg c2FtZSBzeXN0ZW0gYXJlIG5vdCBtb2RpZnlpbmcgaXQuIExhcmdlIG9yZ2FuaXphdGlvbnMgd3Jh cCBleHRlcm5hbCBzeXN0ZW1zIHRoYXQgZG8gbm90IHN1cHBvcnQgdGhpcyB3aXRoIHRoZWlyIG93 biBzZWN1cml0eSBtZWNoYW5pc20gLS0gYnV0IG5vdCBhbGwgb3JnYW5pemF0aW9ucyBhcmUgdGhp cyBzb3BoaXN0aWNhdGVkLCBhbmQgYXMgdGhleSBncm93LCByZXRyb2ZpdHRpbmcgaXMgZGlmZmlj dWx0LiBFbmFibGluZyBlbmQgdG8gZW5kIHByb3ZpZGVuY2UgaXMgYSBiZXN0IHByYWN0aWNlIGlu IG15IG9waW5pb24uDQoNClVzZXIgQ29uc2VudCBBdWRpdDogYXMgcHJpdmFjeSBiZWNvbWVzIGEg bGFyZ2VyIHB1YmxpYyB0b3BpYywgaXQgaXMgZWFzeSB0byBpbWFnaW5lIG9yZ2FuaXphdGlvbnMg d2FudGluZyB0byBwcm92ZSB0aGF0IHRoZXkgb2J0YWluZWQgdXNlciBpbmZvcm1hdGlvbiB3aXRo IGNvbnNlbnQuIFJhdGhlciB0aGFuIGdhdGhlcmluZyB1c2VyIGluZm9ybWF0aW9uIGRpcmVjdGx5 IGZyb20gdGhlIHVzZXIsIGEgQ2xpZW50IGNhbiBhY3F1aXJlIGNsYWltcyBmcm9tIHRoZSBVc2Vy J3MgY2xhaW1zIHByb3ZpZGVyIHRoYXQgYXNzZXJ0cyB0aGUgdXNlciBwcm92aWRlZCBjb25zZW50 IHRvIHRoZSBDbGllbnQuIFRoZSBDbGllbnQgY2FuIHRoZW4gdGVjaG5pY2FsbHkgZXN0YWJsaXNo IHRoYXQgYWxsIHVzZXIgZGF0YSB3YXMgZ2F0aGVyZWQgd2l0aCBjb25zZW50LCBhbmQgdGhlIGNv bnRleHQgb2YgdGhlIGNvbnNlbnQuDQoNCldoaWxlIHRoZSBtZXNzYWdlIGNvbnRhaW5pbmcgdGhl IGNsYWltcyBtYXkgYmUgc2lnbmVkLCBoYXZpbmcgaW5kZXBlbmRlbnQgY2xhaW1zIHNlcGFyYXRl bHkgc2lnbmVkIHNpbXBsaWZpZXMgdGhlIGxlYXN0IHByaXZpbGVnZSB0ZW5ldCwgd2hlcmUgYSBj b21wb25lbnQgb25seSBoYXMgYWNjZXNzIHRvIHRoZSB1c2VyIGluZm9ybWF0aW9uIGl0IG5lZWRz Li4NCg0KL0RpY2sNCg0KDQo= --_000_0C42D0BD57804075BE70F69F6001A14Bamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJFdXBoZW1pYSBVQ0FTIjsNCglwYW5vc2UtMToyIDEx IDUgMyA0IDEgMiAyIDEgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGFtIG5vdCBhcmd1aW5nIHRoYXQgY2xhaW1zIGFsd2F5cyBuZWVkIHRvIGJlIGluZGVwZW5k ZW50bHkgc2lnbmVkLCBhbmQgSSBkb27igJl0IGJlbGlldmUgRGljayBpcyBlaXRoZXIuIE15IGNv bmNlcm4gYXJvc2UgZnJvbSB0aGlzIGJpdCBvZiB5b3VyIGZvbGxvdyB1cCByZXNwb25zZSB0byBN aWtlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+RXZl biBpbiBPSURDLCB0aGUgSUQgVG9rZW4gaXMgYWxsb3dlZCB0byBiZSB1bnNpZ25lZCB3aGVuIGl0 IGlzIHJldHJpZXZlZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCBkaXJlY3RseSB1c2luZyB0aGUg Y29kZSBmbG93LiBUaGUgZXF1aXZhbGVudCBvZiB0aGlzIGlzIHRoZSBvbmx5IHBsYWNlIHRoYXQg VHhBdXRoIHdvdWxkIGJlIHNlbmRpbmcgYmFjayB1c2VyIGNsYWltcw0KIGRpcmVjdGx5LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNvdW5kZWQgdG8gbWUgbGlrZSB5b3Ugd2VyZSBzYXlp bmcgdGhhdCB0aGUgb25seSByZWFzb24gZm9yIHNpZ25pbmcgb3IgZW5jcnlwdGluZyB0aGUgSUQg VG9rZW4gaXMgdG8gc2VjdXJlIGl0IGFzIGl0IHBhc3NlcyB0aHJvdWdoIHRoZSBmcm9udCBjaGFu bmVsLiBUaGF0IGlzIG5vdCB0aGUgY2FzZSwgYXMgRGljayBleHBsYWluZWQuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkZvcnR1bmF0ZWx5LCBJIGRvbuKAmXQgdGhpbmsgYW55IG9mIHRoaXMgbWF0 dGVycyBhcyBmYXIgYXMgdGhlIGNoYXJ0ZXIgaXMgY29uY2VybmVkLiBJdCBpcyBzdWZmaWNpZW50 IGZvciB0aGUgY2hhcnRlciB0byBzYXkgdGhhdCBpZGVudGl0eSBpcyBpbiBzY29wZS4gVGhlIHNw ZWNpZmljIG1lY2hhbmlzbShzKSBjYW4gYW5kIHNob3VsZCBiZSBkZXRlcm1pbmVkIGJ5IHRoZSB3 b3JraW5nIGdyb3VwLCBpbiB0aGUgY29udGV4dA0KIG9mIGEgZHJhZnQgc3BlY2lmaWNhdGlvbi4g SW5jbHVkaW5nIGEgcGFydGljdWxhciBwcm9ibGVtIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIHdv cmtpbmcgZ3JvdXAgZG9lcyBub3QgbWVhbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyB0byBp bnZlbnQgYSBicmFuZCBuZXcgd2F5IHRvIHNvbHZlIHRoYXQgcHJvYmxlbS4gSXQganVzdCBtZWFu cyB0aGF0IHdlDQo8aT5jYW48L2k+IGludmVudCBzb21ldGhpbmcgbmV3LCBpZiB3ZSBkZXRlcm1p bmUgaXQgaXMgd29ydGh3aGlsZSB0byBkbyBzby48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRl bnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RGljayBI YXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJz ZGF5LCBKYW51YXJ5IDMwLCAyMDIwIGF0IDExOjIzIEFNPGJyPg0KPGI+VG86IDwvYj5KdXN0aW4g UmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtSaWNo YXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDss ICZxdW90O3R4YXV0aEBpZXRmLm9yZyZxdW90OyAmbHQ7dHhhdXRoQGlldGYub3JnJmd0OywgS2lt ICZsdDtraW1AaWRlbnRpdHlibG9nLmNvbSZndDssIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3Rv cnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0OywgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1VOVkVSSUZJRUQgU0VO REVSXSBSZTogVGhlIG5lZWQgZm9yIHNpZ25lZCBjbGFpbXMgLSBwcm92aWRlbmNlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TXkgcG9pbnQgd2FzIGRpc2FncmVlaW5nIHdpdGggeW91ciBhc3NlcnRpb246PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Rmlyc3QsIEkgZG9u4oCZdCBiZWxpZXZlIHRoZXJlIGFyZSBnb2luZyB0byBi ZSBtYW55LCBpZiBhbnksIGNhc2VzIHdoZXJlIHdlIG5lZWQgdXNlciBjbGFpbXMgdG8gYmUgc2ln bmVkIGFuZCBlbmNyeXB0ZWQgc2VwYXJhdGVseSBmcm9tIHRoZSBjb3JlIHRyYW5zYWN0aW9uIG1l c3NhZ2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U2hhcmluZyB0aGUgZW50aXJlIHRyYW5zYWN0aW9uIHdpdGgm bmJzcDtzZXJ2aWNlcyB0aGF0IG9ubHkgbmVlZCBzcGVjaWZpYyBjbGFpbXMgd291bGQgZ28gYWdh aW5zdCB0aGUgbWluaW1hbCBkaXNjbG9zdXJlIHRlbmV0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKYW4gMjksIDIwMjAgYXQgMTE6 NTUgUE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSI+ anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkaWQ6IE15IHJlc3BvbnNl IHRvIHlvdXIgcG9pbnQgd2FzIHRoYXQgd2Ugc2hvdWxkIGVuYWJsZSB0aGlzIGtpbmQgb2YgdGhp bmcgYnV0IG5vdCBhc3N1bWUgdGhhdCB1c2VyIGNsYWltcyBhcmUgZ29pbmcgdG8gYmUg4oCUIG9y IG5lZWQgdG8gYmUg4oCUIGluIGEgc2lnbmVkIHBheWxvYWQuIEkgdGhpbmsgdGhhdCB3aGF0IHlv deKAmXJlIGRlc2NyaWJpbmcgaXMgYSBzcGVjaWZpYyBhcmNoaXRlY3R1cmUgZGVjaXNpb24NCiB3 aGljaCBpcyBub3QgdGhhdCBjb21tb24uIEl0IHNob3VsZG7igJl0IGJlIGRpc2FsbG93ZWQgYnV0 IEkgZG9u4oCZdCB0aGluayBvdGhlciBkZXBsb3ltZW50cyBzaG91bGQgcGF5IHRoYXQgY29zdC4m bmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXZl biBpbiBPSURDIHRvZGF5LCB5b3XigJlyZSBhbGxvd2VkIHRvIGlnbm9yZSB0aGUgc2lnbmF0dXJl IG9uIHRoZSBzaWduZWQgSUQgVG9rZW4gaWYgaXQgZ2V0cyBkZWxpdmVyZWQgb24gdGhlIGJhY2sg Y2hhbm5lbC4gSW4gdGhlIG5vcm1hbCBjYXNlLCBhIEpXVCBwcm92aWRlcyBqdXN0IGFuIGV4dHJh IGxheWVyIG9mIHdyYXBwaW5nIHdpdGhvdXQgbXVjaCB2YWx1ZS4gUGxlYXNlIHNlZSBBYXJvbuKA mXMgcG9zdCBmb3INCiBhIGJldHRlciB3cml0ZXVwIG9mIHRoYXQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGluIHRoZSBlbmQsIEkgdGhp bmsgdGhhdCBwbGFpbiBKU09OIHNob3VsZCBiZSBlbmFibGVkIGZvciB1c2VyIGNsYWltcyAod2hp Y2ggWEF1dGggYWxzbyBoYXMsIEnigJlsbCBub3RlKSBhbG9uZyB3aXRoIGFueSB0eXBlIG9mIHBh Y2thZ2VkIGFzc2VydGlvbiBsaWtlIGFuIElEIFRva2VuICh3aGljaCBJ4oCZbGwgbm90ZSB0aGF0 IFhZWiBhbHNvIGhhcykuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBKYW4gMzAsIDIwMjAsIGF0IDc6NTggQU0sIERpY2sgSGFyZHQgJmx0Ozxh IGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2su aGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0aW46IHdvdWxkIHlvdSByZXNwb25kIHRvIG15IGNyaXRp cXVlIG9mIHlvdXIgc3RhdGVtZW50PyBJIHdhcyBub3QgdGFsa2luZyBhYm91dCBTRVRzLg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbDtkcjogbXVsdGlw bGUgc2VydmljZXMgaW4gYSBwaXBlbGluZSBpbiBhIGNvbXBsZXggYXBwIG1heSBuZWVkIHRvIGlu ZGVwZW5kZW50bHkgdmVyaWZ5IGEgY2xhaW0uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpbWcgYm9yZGVyPSIwIiBpZD0i X3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRl cj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFt cDtndWlkPTAzZTI2MTkxLWNmZTctNDNkYy05MDBjLTE1MDBkZGYzN2NmMCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtFdXBoZW1pYSBVQ0FTJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSmFuIDI5LCAyMDIwIGF0IDEwOjE5IFBNIEp1 c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0i X2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRo ZSB1c2UgY2FzZXMgZm9yIFNFVCBhcmUgdmVyeSBkaWZmZXJlbnQgZnJvbSBhbiBhdXRoZW50aWNh dGlvbiBhc3NlcnRpb24sIHdoaWNoIGlzIGNvbnN1bWVkIHRoZW4gZGlzY2FyZGVkLiBBYXJvbiBQ YXJlY2tpIGhhcyB3cml0dGVuIGEgZ29vZCBibG9nIHBvc3QgdGhhdCB0b3VjaGVzIG9uIHRoaXM6 DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9 Imh0dHBzOi8vYWFyb25wYXJlY2tpLmNvbS8yMDE5LzA3LzE4LzE3L2FkZGluZy1pZGVudGl0eS10 by14eXoiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Fhcm9ucGFyZWNraS5jb20vMjAxOS8wNy8x OC8xNy9hZGRpbmctaWRlbnRpdHktdG8teHl6PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSBuZWVkIGEgcGVyc2lzdGVudCByZWNv cmQgdGhlbiB3ZSBjYW4gYWxzbyBzZW5kIHRoYXQg4oCUIG1heWJlIGl04oCZcyBldmVuIGEgU0VU IGluc3RlYWQgb2YgYW4gSUQgVG9rZW4/IEnigJltIHN0aWxsIGZpbmUgd2l0aCBlbmFibGluZyBz aWduZWQgSldUcyB0byBjYXJyeSBpbmZvcm1hdGlvbiwgYnV0IHdoYXQgSSB3YXMgYWdhaW5zdCB3 YXMgc3RhdGluZyBhbnkgYXNzdW1wdGlvbiB0aGF0IHRoZXkgd291bGQgYWx3YXlzDQogYmUgc2ln bmVkIG9yIGVuY3J5cHRlZCwgYW5kIHRoYXQgSldUIHdvdWxkIGJlIHRoZSBhc3N1bWVkIGNhcnJp ZXIgZm9yIHRoYXQuIDxvOnA+DQo8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBKYW4gMzAsIDIwMjAsIGF0IDE6MDAgQU0sIFJpY2hhcmQgQmFja21hbiwg QW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgdG8gRGlja+KA mXMgY291bnRlcnBvaW50cy4mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1zZWNldmVudC1odHRwLXB1c2gtMDcjc2VjdGlvbi01LjQiIHRhcmdldD0i X2JsYW5rIj5UaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgaW4gZHJhZnQtaWV0Zi1zZWNldmVu dC1odHRwLXB1c2g8L2E+Jm5ic3A7dGFsayBhYm91dCB2YWxpZGF0aW9uIG9mIHBlcnNpc3RlZCBT RVRzIGFzIG9uZQ0KIHJlYXNvbiBhIGRlcGxveW1lbnQgbWF5IHdpc2ggdG8gdHJhbnNtaXQgc2ln bmVkIFNFVHMgZXZlbiBvdmVyIGEgVExTLXByb3RlY3RlZCBjaGFubmVsLiBUaGUgc2FtZSBpZGVh IGFwcGxpZXMgdG8gaWRlbnRpdHkgY2xhaW1zIG9yIGp1c3QgYWJvdXQgYW55dGhpbmcgZWxzZSwg cmVhbGx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKAkyZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5Gcm9tOiZuYnNwOzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PkRpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiZu YnNwOzwvYj5XZWRuZXNkYXksIEphbnVhcnkgMjksIDIwMjAgYXQgMjoxNiBQTTxicj4NCjxiPlRv OiZuYnNwOzwvYj5KdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQu ZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs8YnI+DQo8Yj5DYzom bmJzcDs8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnR4YXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1 dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1dGhAaWV0Zi5vcmc8L2E+Jmd0OywgS2lt ICZsdDs8YSBocmVmPSJtYWlsdG86a2ltQGlkZW50aXR5YmxvZy5jb20iIHRhcmdldD0iX2JsYW5r Ij5raW1AaWRlbnRpdHlibG9nLmNvbTwvYT4mZ3Q7LCBUb3JzdGVuIExvZGRlcnN0ZWR0DQogJmx0 OzxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsi PnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDssICZxdW90O1JpY2hhcmQgQmFja21hbiwg QW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OywgTWlrZSBKb25lcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj dDombmJzcDs8L2I+W1VOVkVSSUZJRUQgU0VOREVSXSBSZTogVGhlIG5lZWQgZm9yIHNpZ25lZCBj bGFpbXMgLSBwcm92aWRlbmNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBmb3Jnb3QgdG8gaW5jbHVkZSB0aGUgcmVmZXJlbmNlIHRvIEFubmFiZWxsZSBjYWxsaW5n IHRoaXMgb3V0IGVhcmxpZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vbWFp bGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdHhhdXRoLzBoUjQ5T25FM29xTlB1Q0lRNDNmTjFv ODg2dyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9t c2cvdHhhdXRoLzBoUjQ5T25FM29xTlB1Q0lRNDNmTjFvODg2dzwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSmFuIDI5LCAyMDIw IGF0IDE6MTQgUE0gRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkZvcmtpbmcgdGhlIGRpc2N1c3Npb24gdG8gZm9jdXMgb24gc2lnbmVkIGNs YWltczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKYW4gMjksIDIwMjAgYXQgMzozNyBBTSBK dXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9 Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7c25p cCZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZpcnN0LCBJIGRvbuKAmXQgYmVsaWV2ZSB0aGVyZSBhcmUgZ29pbmcg dG8gYmUgbWFueSwgaWYgYW55LCBjYXNlcyB3aGVyZSB3ZSBuZWVkIHVzZXIgY2xhaW1zIHRvIGJl IHNpZ25lZCBhbmQgZW5jcnlwdGVkIHNlcGFyYXRlbHkgZnJvbSB0aGUgY29yZSB0cmFuc2FjdGlv biBtZXNzYWdlcy4gRXZlbiBpbiBPSURDLCB0aGUgSUQgVG9rZW4gaXMgYWxsb3dlZCB0byBiZSB1 bnNpZ25lZCB3aGVuIGl0IGlzIHJldHJpZXZlZA0KIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IGRp cmVjdGx5IHVzaW5nIHRoZSBjb2RlIGZsb3cuIFRoZSBlcXVpdmFsZW50IG9mIHRoaXMgaXMgdGhl IG9ubHkgcGxhY2UgdGhhdCBUeEF1dGggd291bGQgYmUgc2VuZGluZyBiYWNrIHVzZXIgY2xhaW1z IGRpcmVjdGx5LiBXZSBubyBsb25nZXIgaGF2ZSBhIG5lZWQgdG8gcHJvdGVjdCB0aGluZ3MgYXMg dGhleSB0cmF2ZWwgdGhyb3VnaCB0aGUgZnJvbnQgY2hhbm5lbCBvbiBhIHJlZGlyZWN0LCBhbmQg d2UNCiBubyBsb25nZXIgaGF2ZSBhIG5lZWQgdG8gdXNlIHRoZSB1c2Vy4oCZcyBjbGFpbXMgYXMg YW4gYXJ0aWZhY3QgZm9yIHRoaW5ncyBsaWtlIHNlc3Npb24gbWFuYWdlbWVudCAod2UgY2FuIGRl ZmluZSBhIG5ldyBhcnRpZmFjdCBmb3IgdGhhdCBwdXJwb3NlIHRoYXQgZml0cyBiZXR0ZXIpLiBU aGlzIGVmZmVjdGl2ZWx5IG1lYW5zIHRoYXQgd2UgZG9u4oCZdCBuZWVkIHRvIHJlZGVmaW5lIHRo ZSBJRCBUb2tlbiBiZWNhdXNlIHdlIGRvbuKAmXQgbmVlZCB0aGUNCiBlcXVpdmFsZW50IG9mIHRo ZSBJRCB0b2tlbiBpbiB0aGUgc2FtZSB3YXkuLiBGb3IgdGhlIGNhc2VzIHRoYXQgd2UgZG8gbmVl ZCB0byBkZWZpbmUgdXNlciBjbGFpbXMsIHdlIHNob3VsZCBiZSBkZWZpbmluZyB0aGVtIGFzIGEg SlNPTiBvYmplY3QgbW9kZWwuIEFuZCBJIGFsc28gYmVsaWV2ZSB0aGF0IHRoaXMgSlNPTiBkYXRh IG1vZGVsIHNob3VsZCBub3QgYmUgaW50ZXJ0d2luZWQgd2l0aCBvciBjb25zdHJhaW5lZCBieSB0 aGUgSldUIGNsYWltcw0KIHJlZ2lzdHJ5LiBUaGUgT0lEQyBjbGFpbXMgcmVnaXN0cnkgY2FuIHNl cnZlIGFzIGluZmx1ZW5jZSBhbmQgaW5wdXQgdG8gb3VyIHVzZXIgY2xhaW1zIHNldCBpZiB3ZSBj aG9vc2UsIGJ1dCBJIGRvbuKAmXQgdGhpbmsgd2Ugc2hvdWxkIGJlIGludGVydHdpbmVkIHdpdGgg dGhhdCBlaXRoZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBkaXNhZ3JlZS4gSSB0aGluayBpdCBpcyBsaWtlbHkgdGhhdCB3ZSB3aWxsIHNlZSBh biBpbmNyZWFzZSBpbiBzaWduZWQgY2xhaW1zIGFuZCBtZXNzYWdlcy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SW4gbXkgb3BpbmlvbiwgdGhlIHByb3ZpZGVuY2Ugb2YgYSBjbGFpbSBvciBt ZXNzYWdlIGlzIGZhciBtb3JlIGltcG9ydGFudCB0aGFuIHByb3RlY3Rpb24gZHVyaW5nIHRyYW5z aXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkNsaWVudCAvIEFTIG5vbi1y ZXB1ZGlhdGlvbjwvYj46IHdoZW4gc2Vuc2l0aXZlIG9wZXJhdGlvbnMgYXJlIHBlcmZvcm1lZCBy ZWx5aW5nIG9uIHRoZSBjb250ZW50cyBvZiBhIGNsYWltLCB0aGUgQ2xpZW50IHdpbGwgd2FudCBy ZXB1ZGlhdGlvbiB0aGF0IHRoZSBBUyBvciBjbGFpbXMgaXNzdWVyIG1hZGUgYSBjbGFpbS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+U2VwYXJhdGlvbiBvZiBkdXRpZXMgaW4gY29tcGxl eCBzeXN0ZW1zPC9iPjogSW4gbGFyZ2Ugb3JnYW5pemF0aW9ucywgYSBtYWpvciBzZWN1cml0eSB0 aHJlYXQgaXMgYSBtYWxpY2lvdXMgaW5zaWRlci4gT25jZSBhbiBvcmdhbml6YXRpb24gcmVhY2hl cyBhIGNlcnRhaW4gc2l6ZSwgeW91IGFzc3VtZSB0aGVyZSBhcmUgcGVvcGxlIGVtcGxveWVkIGF0 IHRoZSBjb21wYW55IHRoYXQgZG8gbm90IGhhdmUgdGhlDQogZmlybXMgYmVzdCBpbnRlcmVzdHMg aW4gbWluZC4gT25lIG1pdGlnYXRpb24gb2YgdGhpcyB0aHJlYXQgaXMgZG9uZSBieSBzZXBhcmF0 aW5nIHdoYXQgZGlmZmVyZW50IHRlYW1zIGNhbiBkbyB3aXRoIGN1c3RvbWVyIC8gc2Vuc2l0aXZl IGRhdGEsIHJlcXVpcmluZyBjb2xsdXNpb24gdG8gYWNjZXNzIG9yIG1vZGlmeSB0aGUgZGF0YS4g U2lnbmVkIG1lc3NhZ2VzIGFuZCBjbGFpbXMgc2ltcGxpZnkgZGlmZmVyZW50IGNvbXBvbmVudHMg YmVpbmcgYWJsZQ0KIHRvIGluZGVwZW5kZW50bHkgdmVyaWZ5IGEgbWVzc2FnZSBvciBjbGFpbS4g U2ltaWxhcmx5LCBhIGNvbXBvbmVudCBpc3N1aW5nIGEgY2xhaW0sIGhhcyBhc3N1cmFuY2UgdGhh dCBvdGhlciBjb21wb25lbnRzIGluIHRoZSBzYW1lIHN5c3RlbSBhcmUgbm90IG1vZGlmeWluZyBp dC4gTGFyZ2Ugb3JnYW5pemF0aW9ucyB3cmFwIGV4dGVybmFsIHN5c3RlbXMgdGhhdCBkbyBub3Qg c3VwcG9ydCB0aGlzIHdpdGggdGhlaXIgb3duIHNlY3VyaXR5IG1lY2hhbmlzbQ0KIC0tIGJ1dCBu b3QgYWxsIG9yZ2FuaXphdGlvbnMgYXJlIHRoaXMgc29waGlzdGljYXRlZCwgYW5kIGFzIHRoZXkg Z3JvdywgcmV0cm9maXR0aW5nIGlzIGRpZmZpY3VsdC4gRW5hYmxpbmcgZW5kIHRvIGVuZCBwcm92 aWRlbmNlIGlzIGEgYmVzdCBwcmFjdGljZSBpbiBteSBvcGluaW9uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Vc2VyIENvbnNlbnQgQXVkaXQ8L2I+OiBhcyBwcml2YWN5IGJlY29tZXMg YSBsYXJnZXIgcHVibGljIHRvcGljLCBpdCBpcyBlYXN5IHRvIGltYWdpbmUgb3JnYW5pemF0aW9u cyB3YW50aW5nIHRvIHByb3ZlIHRoYXQgdGhleSBvYnRhaW5lZCB1c2VyIGluZm9ybWF0aW9uIHdp dGggY29uc2VudC4gUmF0aGVyIHRoYW4gZ2F0aGVyaW5nIHVzZXIgaW5mb3JtYXRpb24gZGlyZWN0 bHkgZnJvbSB0aGUgdXNlciwgYQ0KIENsaWVudCBjYW4gYWNxdWlyZSBjbGFpbXMgZnJvbSB0aGUg VXNlcidzIGNsYWltcyBwcm92aWRlciB0aGF0IGFzc2VydHMgdGhlIHVzZXIgcHJvdmlkZWQgY29u c2VudCB0byB0aGUgQ2xpZW50LiBUaGUgQ2xpZW50IGNhbiB0aGVuIHRlY2huaWNhbGx5IGVzdGFi bGlzaCB0aGF0IGFsbCB1c2VyIGRhdGEgd2FzIGdhdGhlcmVkIHdpdGggY29uc2VudCwgYW5kIHRo ZSBjb250ZXh0IG9mIHRoZSBjb25zZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGls ZSB0aGUgbWVzc2FnZSBjb250YWluaW5nIHRoZSBjbGFpbXMgbWF5IGJlIHNpZ25lZCwgaGF2aW5n IGluZGVwZW5kZW50IGNsYWltcyBzZXBhcmF0ZWx5IHNpZ25lZCBzaW1wbGlmaWVzIHRoZSBsZWFz dCBwcml2aWxlZ2UgdGVuZXQsIHdoZXJlIGEgY29tcG9uZW50IG9ubHkgaGFzIGFjY2VzcyB0byB0 aGUgdXNlciBpbmZvcm1hdGlvbiBpdCBuZWVkcy4uJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi9EaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0C42D0BD57804075BE70F69F6001A14Bamazoncom_-- From nobody Thu Jan 30 14:14: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 8CC4B120026 for ; Thu, 30 Jan 2020 14:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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] 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 TWQbzoj2gGW6 for ; Thu, 30 Jan 2020 14:13:58 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88AB612001A for ; Thu, 30 Jan 2020 14:13:57 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id b15so3403452lfc.4 for ; Thu, 30 Jan 2020 14:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X8WvvpMgv1Z8git+aPAU12TvzPzloUt5uACGCTjZXn8=; b=M7dmhZG5Smnhy2nxdLC+aLkPr8OeQeDVqO6VCw0zSihHkHxi560PZ/wqGiIN2t3XKn sG72tMhTl0BxyXDRgiG4lA1MKzvYeV+dJ+N3yllfYROFSfPwQmZ7abkRc9GROTUGAb22 QWckw79JQk/sP+GTa2pVckFo1SzSboqOnjse7ylWq9Fp34OxpHpoRZcb8cPwgB+wX4c4 lxihVcNauDi35tETUnxMa48fo/hcvQdIhCSXV7sbtJt23AX2GAODINhBo9MK9huWXbMZ 4FEc5uU07DqqY5JkjocTgFXyWpRMSwHI2MpTvHkpRXoy+dxBhr84F08iL8332qH1OlEw ETOQ== 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=X8WvvpMgv1Z8git+aPAU12TvzPzloUt5uACGCTjZXn8=; b=H8pxGw7kwrxQXpiQwQpWRgaJOMhAQbXolaLoN2/LQBbYP12FabfY8fbKwotID6Z6dj YW9QyRYfB3pV57iGrafGDVqmNH/bvZffvhEzmaQ9T/iRF3qz0JtG7T7JBwGIffcP63LT mFUFFP7Qy7qrgydMMMsG1+0iKsFd/hX460JKZI+dV0spVViSrcJUQ6qRAEnSUu0yCMwX YvYTz++tIMNSYlXHRWKYs6Ghh8kUYSMSe7OKqAEsIikbSsBhUFnXZwQTctJCUrrKy/cn W/q01W2LTxHfUbUxXcmeqIjGsrgAjGWJ1cedEAMZKxudaONqfdVNuFvjdAGWXb9BJqsD z0Lw== X-Gm-Message-State: APjAAAWhD+cn0hTOUoVrvsJR47wsSNEufcBrhPkbYLjcXM0t2otOlwEf ukbzBCCl68lVTZzWiH3qsbu2h334epDMkHt3c1I= X-Google-Smtp-Source: APXvYqyu7jhvPnr28BNTt9aV7zBljVPGOHUSxjXJ3YaAA2AceFWI7en+jlU2wKhxkcgtdJ9GLfO2RX46p7mbCraa7oc= X-Received: by 2002:a05:6512:78:: with SMTP id i24mr3728910lfo.10.1580422435529; Thu, 30 Jan 2020 14:13:55 -0800 (PST) MIME-Version: 1.0 References: <05467DBA-1B21-4F05-94EC-833C6E3FEBFB@mit.edu> <2E6A2343-3277-4090-AE7E-774158C08DB0@mit.edu> In-Reply-To: <2E6A2343-3277-4090-AE7E-774158C08DB0@mit.edu> From: Dick Hardt Date: Thu, 30 Jan 2020 14:13:29 -0800 Message-ID: To: Justin Richer Cc: txauth@ietf.org, Benjamin Kaduk , "rdd@cert.org" , Yaron Sheffer Content-Type: multipart/alternative; boundary="000000000000dd6cc4059d62c5a0" Archived-At: Subject: Re: [Txauth] XAuth - a revision 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: Thu, 30 Jan 2020 22:14:03 -0000 --000000000000dd6cc4059d62c5a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 30, 2020 at 1:05 AM Justin Richer wrote: > On Jan 30, 2020, at 12:25 AM, Dick Hardt wrote: > > On Wed, Jan 29, 2020 at 8:26 AM Justin Richer wrote: > >> I think XAuth has an interesting take on the problem space that TxAuth i= s >> looking to solve, but in my opinion it generally veers too closely to >> OAuth2/OIDC/JWT in its solution approach. >> > > Reusing aspects of OAuth2/OIDC/JWT that are working fine for deployments > will minimize the migration effort for them to take advantage of the > security features of this work such as not using the redirect for passing > parameters. I think XAuth supports the following clause of the current > draft charter: "the group will attempt to simplify porting from OAuth 2.0 > and OpenID Connect to the new protocol where possible.=E2=80=9D > > > I understand the goals here, but I disagree that using the constructs as > directly as they have been here is the most appropriate approach. > Ok. I think we have reasonable clarity on the disagreement. > > > > > >> 1. XAuth removes =E2=80=9Chandles=E2=80=9D as stand-ins for various elem= ents. In XYZ, the >> =E2=80=9Chandle=E2=80=9D concept is a key abstraction point with specifi= c semantics. A >> =E2=80=9Chandle=E2=80=9D is an identifier to a specific instantiation of= a JSON object >> structure. Using the =E2=80=9Chandle=E2=80=9D for Keys, for Resources, a= nd even the whole >> Transaction lets you do a lot of core things in a parallel and reusable >> way. XAuth re-invents a few of these as separate items, listed below, an= d I >> see this as a regression. >> > > XAuth took the transaction handle and forked it into a completion handle > and a refresh handle so that it is clear what the Client is wanting to > happen. > > It was not clear the value of the other handles that were listed in XYZ. > > > I think this may be that you misunderstood the purposes of the handles, a= s > you=E2=80=99ve reinvented nearly all of them with different labels in XAu= th. :) > I understand what a handle is, and what it represents. It appears that the handles provide a reference to the display, resource, user, and key objects. XYZ says the AS may issue those, but I could not find determine when the AS sends them back to the RC. I understand the value of the transaction handle XYZ, and built on that in XAuth, but XAuth always sends the display, resource, user and key information by value, not by reference, so your statement you=E2=80=99ve reinvented nearly all of them with different labels in XAuth is confusing. > > > >> >> 2. XAuth uses a Client ID from OAuth 2. I removed Client IDs from XYZ >> because I realized that you don=E2=80=99t need them anymore. The client = ID tells >> the AS which client is talking in the front channel because the client >> can=E2=80=99t authenticate. In the back channel, the key (or secret) ide= ntifier is >> enough to identify the client =E2=80=94 that=E2=80=99s the Key Handle in= XYZ that can be >> passed in lieu of the key itself. The argument that it=E2=80=99s helpful= to have an >> identifier for doing developer support and managing registrations is >> spurious, since this is an internal identifier that never needs to be >> exposed by the protocol. Additionally, a client ID assumes a >> registration-based model. There are ephemeral and per-device client >> instances like SPA=E2=80=99s and mobile apps that don=E2=80=99t really f= it the client ID >> model very well. Pushing this requirement on all clients is bad, as we= =E2=80=99ve >> seen in OAuth 1 and OAuth 2. XAuth tries to manage this by splitting >> clients into two camps, but I=E2=80=99m saying that no client needs and = external >> client ID. >> > > I addressed this in > https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-12 # 7 > > 7. *Why is there still a Client ID? Could we not use a fingerprint > of the public key to identify the Client?* > > Some AS deployments do not allow calls from Registered Clients, > and provide different functionality to different Clients. A > permanent identifier for the Client is needed for the Client > developer and the AS admin to ensure they are referring to the > same Client. The Client ID was used in OAuth 2.0, and it served > the same purpose > > > Perhaps you did not see that? > > > I did see that and I addressed it in my comment. The AS admin and > developer can still refer to an internal identifier without it being > exposed in the protocol. > There needs to be some shared identifier in the protocol, would you not agree? For Registered Clients, the AS needs to have an identifier to look up the data it has for the Client. What is broken with Client ID? What identifier are you proposing in XYZ? > > > I agree that dynamic client IDs in OAuth 2 were problematic. In XAuth, a > Dynamic Client is identified by its key. > > Would you clarify what is broken with Client IDs for Registered Clients? > It seems to working fine for registered clients in OAuth 2 / OpenID > Connect, and migrating those deployments will be simpler if we keep the > same concept. > > The key handle seems problematic as it will change when keys are rotated. > > > Why would the key handle change when the key is rotated? Nothing in XYZ > dictates how the key handle is generated by the AS or how the key handle = is > mapped to a specific key. It=E2=80=99s not a key identifier, which is why= I haven=E2=80=99t > called it a =E2=80=9Ckey id=E2=80=9D. > I mistyped, I intended to say key fingerprint, which obviously changes when the key is rotated. I reread the XYZ Key Handle section ... and you are suggesting it represents the Client instance, but it is not clear how the AS maps that to preregistered client information. > > I don=E2=80=99t see why a registered client can=E2=80=99t be identified b= y its key just > like a dynamic client would be. What is the value in this split? I think > there=E2=80=99s value in treating all clients the same and driving the di= fferences > in policy on the AS. Either I recognize a key handle, or I am being given= a > public key (which I also might recognize). In all of these cases the AS > gets to run its policy against the party identified by the key. > To clarify, your proposal is that the public key, or a fingerprint of it, is what the AS uses to look up a preregistered Client? > > > >> >> 3. XAuth uses a =E2=80=9Ctype=E2=80=9D field for interaction. This means= the client can >> only do one type of interaction for any given transaction. XYZ started l= ike >> this, but we moved away from it because we realized we could have a clie= nt >> app that could handle multiple types without that kind of dispatch. In X= YZ >> the client sends over flags for each kind of interaction it can do: send >> the user to an arbitrary URL, give the user a code, get a callback from = a >> browser, etc. Combining these in specific ways addresses all of the >> different methods that XAuth identifies as its types while also allowing >> additional things. The AS picks from the client=E2=80=99s list based on = what the AS >> can support as well as what makes sense for the policies governing the >> requested access. >> > > Do you have a use case where the AS will want to pick from a list, rather > than supporting the one that the Client wants to use? > > > The AS would return interaction responses that are the intersection of: > > - methods the client indicates it can do in the request > - methods the AS knows it can support > - methods allowed by the policy governing the request > > I don=E2=80=99t understand the second part of this question, because the = AS still > =E2=80=9Csupports the one the client wants to use=E2=80=9D in the XYZ mod= el. > I'm looking for a use case where the AS needs to select from a list, rather than use the one mechanism that the Client wants to use. Why the extra negotiation? > > As for a concrete example, look at how we handle the =E2=80=9Cqrcode=E2= =80=9D interaction > case, based on OAuth 2=E2=80=99s device flow. In this, you want to send a= URI to > the client that it can render as a QR code as well as a code that the use= r > can type into a page, in case they can=E2=80=99t scan the QR code. OAuth = 2 manages > this by having a user code as well as a pre-composed URL containing the > code to be used for rendering. XYZ used to have a mode for this similar t= o > XAuth, but we realized that we could describe this using two separate > flags: > > - I can communicate a short code that the user can type in at a static U= RL > - I can get the user to go to an arbitrary URL > > The second one is the same mechanism we can use for redirect-based auth. > I got that. I thought being more crisp in the interaction makes it easier for implementors to understand. > > > In the case where the AS interacts with an RO that is not the User, there > would be nothing the Client would need to do. Perhaps there is a use case > for something different? If so, please elaborate. > > >> >> 4. XAuth allows OAuth-style scopes next to RAR-style data structures (an= d >> next to OIDC claims structures). They are treated as completely separate >> from each other. In OAuth 2, RAR is defined in the context of scope (and >> resource and audience and other parameters), and this combination is a >> matter of some debate still that needs to be solved. However, it=E2=80= =99s clear >> that they=E2=80=99re combined. In XYZ, the only resource request defined= is the >> object inside the resource request. You can mimic =E2=80=9Cscope=E2=80= =9D behavior by using >> a Resource Handle, which again is defined as a single string that stands= in >> for the whole object and could be defined by the AS (or the API it=E2=80= =99s >> protecting). >> > > I think you need to reread the 00 draft. Only one type of authorization > request is allowed. > > - OAuth style for deployments where that works fine. > - RAR style for deployments that need the extra granularity of RAR > - list of RAR style for deployments that support multiple resource server= s > that require independent access tokens. > > >> >> 5. The different kinds of authz requests in (4) create separate >> tokens.This is very different from both OAuth 2 and XYZ, where you get b= ack >> a single access token. And in XAuth there is no way to get, for example, >> two access tokens that are both described by RAR requests, so this seems >> like a very arbitrary and syntactically-driven separation. >> > > I don't think you understood what is in the draft. See above. > > > Apologies on these points =E2=80=94 I didn=E2=80=99t catch that this had = changed from the > earlier drafts. > We can scratch this concern from the list then. Yeah! > > > >> >> 6. The assumption that JOSE will always be in the toolkit of the client >> developer is not true. You can do an XYZ transaction without any JOSE = =E2=80=94 for >> example, using HTTP Sig or MTLS for key presentation. >> > > Per earlier feedback from you, I have strived to separate JOSE out into > Section 8, so that an extension could use HTTP signing or MTLS. Let me kn= ow > where JOSE is still an assumption. > > > The separation is OK in the current draft, but it still states that JOSE > is the default, and by implication, preferred. > Yes. I think freedom from having to make a choice makes things easier to implement and deploy. For deployments where another mechanism will be significantly better, the choice is available. Is there something about JOSE that you think is problematic to make it the default? > > > >> >> 7. The statement that =E2=80=9Cthere is no HTTP signing=E2=80=9D is fals= e, as this is >> being brought up to the HTTP WG right now (I=E2=80=99m one of the co-aut= hors). Yes, >> it=E2=80=99s not an RFC, but neither is this. And if we=E2=80=99re doing= agile signature >> methods, which I contend is a required extension point, then we don=E2= =80=99t have >> a dependency requirement for it. >> > > XAuth says from > https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-12 # 3 > > There is currently no widely deployed open standard for HTTP signing. > > > Yes, there is working going on. But security it is not a published RFC, > there are no libraries for it, and it has not been tested on the open > internet. > > While I wish the HTTP WG luck in this work, and I support it happening, i= t > will be hard. > > OAuth 1.0 core issue was that it was signing a request (in my opinion) > > > Which is why we shouldn=E2=80=99t have a normative dependency on it until= it=E2=80=99s > done, but ignoring it entirely is silly. I=E2=80=99ve always said this ne= eds to be > one among many options. > I was not ignoring it. When it is done, an extension can be written on how to use HTTP Signing. Or the extension could be developed at the same time. > > > The widely deployed HTTP Signing is AWS SIGv4 -- which AWS supplies > libraries for every API in all popular languages so that developers don't > have to do the HTTP signing themselves. > > I could imagine AWS adopting XAuth and using SIGv4 instead of JOSE if the= y > wanted. > > > I agree that they should be able to use TxAuth (not necessarily XAuth ;) = ) > using SIGv4, if they wanted =E2=80=94 and that=E2=80=99s assuming they do= n=E2=80=99t move AWS to > HTTP Sig. :) > Moving AWS to HTTP Sig is very, very unlikely, having worked there. Having an easy path to utilize XAuth / TxAuth is a good goal for the resulting work. > > > > >> 8. XAuth adds back in an explicit =E2=80=9Crefresh token=E2=80=9D. In XY= Z, we don=E2=80=99t have >> a refresh token because we can use the transaction handle to continue th= e >> transaction after a token has been issued. This has explicit and clear >> semantics that follows from what the transaction handle is used for >> elsewhere in the protocol =E2=80=94 continue this request that=E2=80=99s= in some >> authorization state and give me the results. >> > > I think we agree that refresh is a required feature. > > > Yes, and I think that the constructs are similar, but the difference > matters. By using the same handle for continuing the transaction over tim= e > as you do for refreshing, XYZ is giving the client developers a specific > model: The transaction itself has a state and value over time, referenced > by the transaction handle. The transaction entity still exists after it= =E2=80=99s > been approved and a token has been issued, but the things you can do with > it are different (see below). > The word transaction is muddying what I think you are suggesting here. It more like a conversation. Transactions from a DB point of view are a set of actions that all happen, or none happen. > > Both continuation and refresh are saying to the AS =E2=80=9Crun this tran= saction > again and if I can get a token (or claims or whatever) in its current > state, give me that=E2=80=9D. However, they can=E2=80=99t really exist at= the same time, so > having two separate items to ask the same question doesn=E2=80=99t make m= uch sense. > They have different purposes. The completion (now authorization) handle is to check if the AS is done with its request processing, and if so, provide the results, which includes zero or more identity claims, and zero or more access tokens/handles. The refresh handle is to refresh a specific access token/handle. > > > I think a transaction handle is to course grained. I don't think that the > AS should be returning all the claims in a refresh. And if there are > multiple access tokens returned from the AS, then each has their own > refresh handle. > > > I think this requires a deeper discussion, since the whole idea of > multiple access tokens is a very different kind of approach here. > It is a feature of XAuth. In OAuth today, the bearer token is like a movie ticket. Whoever has the movie ticket gets in the movie. Using OAuth to obtain a bearer token is like buying a movie ticket. Sometimes I want to go to more than one movie. OAuth today makes me wait in line to buy each ticket. Why not let me buy multiple tickets at once? > > I see refresh much as it is in OAuth2 and UMA, where it refers to the > authorization that was granted. This means that you can do downscoping to > get lower-powered access tokens that are a subset of the overall grant, a= nd > I think that TxAuth should be able to do a step-up auth where you can bui= ld > some additional request on top of an existing approval. > Is "step-up auth" authentication or authorization, ... or both? > > > >> >> 9. XAuth uses OIDC=E2=80=99s ID Token. As I=E2=80=99ve said on the other= thread, I don=E2=80=99t >> think we actually need a separately signed assertion. I=E2=80=99d rather= see a way >> to sign the entire response which includes the user claims, if we want >> signature protection. >> > > I responded in a separate thread. > > >> >> 10. XAuth sends all the user=E2=80=99s claims on the login request =E2= =80=94 or more >> precisely, this is the only mechanism specified and the Rationale sectio= n >> claims this is a feature. This violates minimal disclosure and privacy >> design guidelines, and this type of protocol has been developed before w= ith >> OpenID 1.x/2.x and SAML. The problem here unfolds when you think about h= ow >> it works: The RP needs to log in. If this is the first time it=E2=80=99s= seen this >> user, then it needs the user=E2=80=99s profile info. If not, and the pro= file info >> hasn=E2=80=99t changed, there=E2=80=99s no need for it and the AS should= n=E2=80=99t send it. So the >> RP can signal this, right? Except that the RP doesn=E2=80=99t know who t= he user is >> yet (that=E2=80=99s why they=E2=80=99re making this call!). Can the AS m= ake this call? They >> won=E2=80=99t know if the RP has cached the user=E2=80=99s info or not. = And if we=E2=80=99re using >> Client ID, then the AS can=E2=80=99t even be sure that this copy of the = client is >> the same as another copy of the client. I think TxAuth needs to minimize >> the user claims sent back to being an identifier, information about the >> authentication event that could change each time anyway, and anything th= at >> would be needed to control a cache. Additional fields can be pulled from >> the equivalent of a UserInfo Endpoint in a two-stage process that both >> preserves privacy and optimizes for what=E2=80=99s available from each p= arty. >> > > Not clear how XYZ improves on this. > > > XYZ does not currently internally specify how to hand user info back, but > I was looking at something in line with what Aaron Parecki=E2=80=99s blog= post > specified last summer. > > > The UserInfo Endpoint solves the Client getting more info than it needs, > but the User still needs to give consent each time unless the AS tracks i= t. > So it is unclear to me what value the UserInfo Endpoint brings. > > > Remembering user consent and delivering claims are two completely separat= e > problems and should not be conflated here. I was addressing the former. > They are related though. If you are not wanting to ask for consent on each delivery, how do you know you have consent? > > > Your comments have inspired me on a solution that can be done with XAuth > (or XYZ) that can't be done with OAuth 2.0/OIDC. > > I'll add that to the XAuth draft and publish it. > > >> >> 11. XAuth defines an explicit discovery step because the client now need= s >> to know several things about the server. The mix-up attack and a few oth= er >> attacks in OAuth 2 stem from this kind of process. In XYZ, the client >> really only needs to know the transaction endpoint URL and it learns >> everything else from that point. Yes, the client needs to discover that >> someplace =E2=80=94 but it was a deliberate decision in limiting the amo= unt of >> upfront information that the client needs to get started. >> > > That is still discovery, is it not? > > > I literally just called it that in the sentence above, so yes. :) What > you=E2=80=99re discovering is different though. And doesn=E2=80=99t the c= lient still need > to =E2=80=9Cdiscover=E2=80=9D the discovery endpoint in XAuth? > What discovery endpoint? > > > Would the Client not need to know the message signing methods supported? > JOSE, HTTP Signing, and/or MTLS? > > > Only required if the client can programmatically do anything about that. > The truth is that just about every client is going to be configured to do > one kind of signing, and the developer can usually discover that. I don= =E2=80=99t > see a problem with having it listed in a discovery document next to the > transaction endpoint, but I think we don=E2=80=99t actually need it becau= se of the > items below: > > > >> I=E2=80=99ve played with the concept of a =E2=80=9Ccapabilities=E2=80=9D= list in XYZ, where the >> client would present a list of things it can do and the AS trims that li= st >> to what it can also do. >> > > So ... programatic discovery? =3D) > > Are you suggesting that discovery of everything but the endpoint has to b= e > programatic? > > > In no way, shape, or form am I implying that. I=E2=80=99m saying that the= items > that can be used for programmatic discovery can be returned from the > transaction endpoint without need for a separate endpoint. This can even > include the signing methods, and the round-trips for an automated client > are basically the same. > > So take the XAuth approach: > > - client gets configured with the discovery endpoint > - client calls discovery endpoint, self-configures > - client calls tx endpoint > Aaah now I see where we don't have common understanding ... that is not the XAuth approach at all. 1. *AS Discovery* The Client discovers the AS end point, keys, supported claims and authorizations, and other capabilities. Some, or all of this information could be manually preconfigured, or dynamically obtained. Dynamic AS discovery is out of scope of this document. In other words, here is some information the Client will need. You will need to manually configure it, or there may be an option to obtain some or all of the information you need programatically. The programatic discovery is out of scope. Perhaps I need to improve the language? > And the XYZ approach: > > - client gets configured with the tx endpoint > - client calls tx endpoint, picks whatever default method it wants for > signing (TxAuth spec can even declare a preferred version if we want) > - if it works, tx has already started and things just continue =E2=80=94 = this > optimizes for the happy path > - if it fails, client gets back information to allow it to self-configure > and calls the tx endpoint again > Most existing Clients are manually configured. The developer reads the AS documentation to learn what scopes and claims the AS supports, and then codes that into the Client. The XYZ approach above does not take that into account, and is in conflict with what you have below. In XAuth, I'm calling that out as a step, so the developer understands where that comes from. You effectively are saying the same thing below, so it is unclear what your concern with XAuth is. In XYZ, discovery is currently ignored. > > This is what I mean by one-stage negotiation on the discovery. If the > client gets it right, that=E2=80=99s fine and things just continue withou= t the > extra step. If the client gets it wrong, it=E2=80=99s given the equivalen= t of > information from the discovery endpoint that it can either self correct > (which it would be able to do if it could self configure from a discovery > document) or it will throw an error (which is what it=E2=80=99d do if it = gets a > discovery document it can=E2=80=99t do anything with). > > > > >> This type of one-stage negotiation is really powerful and I think we can >> get a lot from it here. >> > > Sure ... but for many people what works today is documentation that > someone reads to understand what to do. Are you suggesting we not enable > that? > > > I am not suggesting that we disallow human-readable documentation and > static configuration. I have no idea where you got that I was suggesting > that. > Because you were not supportive of the discovery step in XAuth? And you made no mention of static configuration in your description, contrary to XAuth? Hence me asking a probing question to get clarity. Interpersonal communication hint: when you have no idea on why someone is asking a clarifying question, ask yourself what might have been unclear in your communication. Then just answer the clarifying question. > > But to be clear, yes you can still document things and pre-configure them= . > In fact, I think that=E2=80=99s better handled in XYZ that allows the cli= ent to be > pre-configured and get started with a TX request, and then recover better > if things aren=E2=80=99t what it thought. > XAuth documents what information is required, and that it can be pre-configured. Where in XYZ is the negotiation after the TX request? Sounds interesting, but I did not see it. /Dick =E1=90=A7 --000000000000dd6cc4059d62c5a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 30, 2020 at 1:05 AM Justi= n Richer <jricher@mit.edu> wro= te:
On Jan 30, 2020, at 12:25 AM, Dick Hardt &l= t;dick.hardt@gmai= l.com> wrote:
O= n Wed, Jan 29, 2020 at 8:26 AM Justin Richer <jricher@mit.edu> wrote:
I think XAuth has an i= nteresting take on the problem space that TxAuth is looking to solve, but i= n my opinion it generally veers too closely to OAuth2/OIDC/JWT in its solut= ion approach.

Reusing as= pects of OAuth2/OIDC/JWT that are working fine for deployments will minimiz= e the migration effort for them to take advantage of the security features = of this work such as not using the redirect for passing parameters. I think= XAuth supports the following clause of the current draft charter: "th= e group will=C2=A0attempt to simplify porting from OAuth 2.0 and OpenID Con= nect to the new protocol where possible.=E2=80=9D

I understand t= he goals here, but I disagree that using the constructs as directly as they= have been here is the most appropriate approach.

Ok. I think we have reasonable clarity on the disa= greement.
=C2=A0

=
<snip>
=C2=A0
1. XAuth removes =E2=80= =9Chandles=E2=80=9D as stand-ins for various elements. In XYZ, the =E2=80= =9Chandle=E2=80=9D concept is a key abstraction point with specific semanti= cs. A =E2=80=9Chandle=E2=80=9D is an identifier to a specific instantiation= of a JSON object structure. Using the =E2=80=9Chandle=E2=80=9D for Keys, f= or Resources, and even the whole Transaction lets you do a lot of core thin= gs in a parallel and reusable way. XAuth re-invents a few of these as separ= ate items, listed below, and I see this as a regression.
<= /blockquote>

XAuth took the transaction handle and forke= d it into a completion handle and a refresh handle so that it is clear what= the Client is wanting to happen.

It was not clear= the value of the other handles that were listed in XYZ.=C2=A0
<= /div>

I= think this may be that you misunderstood the purposes of the handles, as y= ou=E2=80=99ve reinvented nearly all of them with different labels in XAuth.= :)

I understand what a h= andle is, and what it represents. It appears that the handles provide a ref= erence to the display, resource, user, and key objects. XYZ says the AS may= issue those, but I could not find determine when the AS sends them back to= the RC. I understand the value of the transaction handle XYZ, and built on= that in XAuth, but XAuth always sends the display, resource, user and key = information by value, not by reference, so your statement=C2=A0
<= br>
you=E2=80=99ve reinvented nearly all of= them with different labels in XAuth

is confusing.
=C2=A0

=C2=A0

2. XAuth uses a Client ID from= OAuth 2. I removed Client IDs from XYZ because I realized that you don=E2= =80=99t need them anymore. The client ID tells the AS which client is talki= ng in the front channel because the client can=E2=80=99t authenticate. In t= he back channel, the key (or secret) identifier is enough to identify the c= lient =E2=80=94 that=E2=80=99s the Key Handle in XYZ that can be passed in = lieu of the key itself. The argument that it=E2=80=99s helpful to have an i= dentifier for doing developer support and managing registrations is spuriou= s, since this is an internal identifier that never needs to be exposed by t= he protocol. Additionally, a client ID assumes a registration-based model. = There are ephemeral and per-device client instances like SPA=E2=80=99s and = mobile apps that don=E2=80=99t really fit the client ID model very well. Pu= shing this requirement on all clients is bad, as we=E2=80=99ve seen in OAut= h 1 and OAuth 2. XAuth tries to manage this by splitting clients into two c= amps, but I=E2=80=99m saying that no client needs and external client ID.

I addressed this in=C2=A0<= a href=3D"https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section= -12" target=3D"_blank">https://tools.ietf.org/html/draft-hardt-xauth-protoc= ol-00#section-12=C2=A0# 7

 7.   *Wh=
y is there still a Client ID?  Could we not use a fingerprint
        of the public key to identify the Client?*

        Some AS deployments do not allow calls from Registered Clients,
        and provide different functionality to different Clients.  A
        permanent identifier for the Client is needed for the Client
        developer and the AS admin to ensure they are referring to the
        same Client.  The Client ID was used in OAuth 2.0, and it served
        the same purpose

Perhaps you d= id not see that?

I did see that and I addressed it in my comment= . The AS admin and developer can still refer to an internal identifier with= out it being exposed in the protocol.=C2=A0
<= div>
There needs to be some shared identifier in the protocol= , would you not agree? For Registered Clients, the AS needs to have an iden= tifier to look up the data it has for the Client.=C2=A0

What is broken with Client ID? What identifier are you proposing in X= YZ?
=C2=A0


I agree that dynamic client IDs in OAuth 2 were problematic. In XAut= h, a Dynamic Client is identified by its key.

Woul= d you clarify what is broken with Client IDs for Registered Clients? It see= ms to working fine for registered clients in OAuth 2 / OpenID Connect, and = migrating those deployments will be simpler if we keep the same concept.

The key handle seems problematic as it will change w= hen keys are rotated.=C2=A0
=

Why would the key handle change when= the key is rotated? Nothing in XYZ dictates how the key handle is generate= d by the AS or how the key handle is mapped to a specific key. It=E2=80=99s= not a key identifier, which is why I haven=E2=80=99t called it a =E2=80=9C= key id=E2=80=9D.=C2=A0

I = mistyped, I intended to say key fingerprint, which obviously changes when t= he key is rotated.

I reread the XYZ Key Handle sec= tion ... and you are suggesting it represents the Client instance, but it i= s not clear how the AS maps that to preregistered client information.
=
=C2=A0

I don=E2=80=99t = see why a registered client can=E2=80=99t be identified by its key just lik= e a dynamic client would be. What is the value in this split? I think there= =E2=80=99s value in treating all clients the same and driving the differenc= es in policy on the AS. Either I recognize a key handle, or I am being give= n a public key (which I also might recognize). In all of these cases the AS= gets to run its policy against the party identified by the key.

To clarify, your proposal is that t= he public key, or a fingerprint of it, is what the AS uses to look up a pre= registered Client?

=C2=A0
=

<= div dir=3D"ltr">
=C2=A0

3. XAuth uses a =E2=80=9Ctype=E2= =80=9D field for interaction. This means the client can only do one type of= interaction for any given transaction. XYZ started like this, but we moved= away from it because we realized we could have a client app that could han= dle multiple types without that kind of dispatch. In XYZ the client sends o= ver flags for each kind of interaction it can do: send the user to an arbit= rary URL, give the user a code, get a callback from a browser, etc. Combini= ng these in specific ways addresses all of the different methods that XAuth= identifies as its types while also allowing additional things. The AS pick= s from the client=E2=80=99s list based on what the AS can support as well a= s what makes sense for the policies governing the requested access.

Do you have a use case where the= AS will want to pick from a list, rather than supporting the one that the = Client wants to use?
<= /blockquote>

The AS would return interaction responses t= hat are the intersection of:

=C2=A0- methods the c= lient indicates it can do in the request
=C2=A0- methods the AS k= nows it can support
=C2=A0- methods allowed by the policy governi= ng the request

I don=E2=80=99t understand the seco= nd part of this question, because the AS still =E2=80=9Csupports the one th= e client wants to use=E2=80=9D in the XYZ model.

I'm looking for a use case where the AS needs t= o select from a list, rather than use the one mechanism that the Client wan= ts to use. Why the extra negotiation?
=C2=A0


In the ca= se where the AS interacts with an RO that is not the User, there would be n= othing the Client would need to do. Perhaps there is a use case for somethi= ng different? If so, please elaborate.
=C2=A0

4. XA= uth allows OAuth-style scopes next to RAR-style data structures (and next t= o OIDC claims structures). They are treated as completely separate from eac= h other. In OAuth 2, RAR is defined in the context of scope (and resource a= nd audience and other parameters), and this combination is a matter of some= debate still that needs to be solved. However, it=E2=80=99s clear that the= y=E2=80=99re combined. In XYZ, the only resource request defined is the obj= ect inside the resource request. You can mimic =E2=80=9Cscope=E2=80=9D beha= vior by using a Resource Handle, which again is defined as a single string = that stands in for the whole object and could be defined by the AS (or the = API it=E2=80=99s protecting).=C2=A0

=
I think you need to reread the 00 draft. Only one type of author= ization request is allowed.

- OAuth style for depl= oyments where that works fine.
- RAR style for deployments that n= eed the extra granularity of RAR
- list of RAR style for deployme= nts that support multiple resource servers that require independent access = tokens.
=C2=A0

5. The different kinds of authz re= quests in (4) create separate tokens.This is very different from both OAuth= 2 and XYZ, where you get back a single access token. And in XAuth there is= no way to get, for example, two access tokens that are both described by R= AR requests, so this seems like a very arbitrary and syntactically-driven s= eparation.=C2=A0

I don= 9;t think you understood what is in the draft. See above.
=

Apolog= ies on these points =E2=80=94 I didn=E2=80=99t catch that this had changed = from the earlier drafts.=C2=A0

We can scratch this concern from the list then. Yeah!
=C2= =A0

=C2=A0

6. The = assumption that JOSE will always be in the toolkit of the client developer = is not true. You can do an XYZ transaction without any JOSE =E2=80=94 for e= xample, using HTTP Sig or MTLS for key presentation.=C2=A0

Per earlier feedback from you, I have str= ived to separate JOSE out into Section 8, so that an extension could use HT= TP signing or MTLS. Let me know where JOSE is still an assumption.

The separation is OK in the current draft, but it still states that JOSE= is the default, and by implication, preferred.=C2=A0

Yes. I think freedom from having to make a cho= ice makes things easier to implement and deploy.=C2=A0
For deploy= ments where another mechanism will be significantly better, the choice is a= vailable.=C2=A0

Is there something about JOSE that= you think is problematic to make it the default?
=C2=A0

=C2=A0

7. The statement tha= t =E2=80=9Cthere is no HTTP signing=E2=80=9D is false, as this is being bro= ught up to the HTTP WG right now (I=E2=80=99m one of the co-authors). Yes, = it=E2=80=99s not an RFC, but neither is this. And if we=E2=80=99re doing ag= ile signature methods, which I contend is a required extension point, then = we don=E2=80=99t have a dependency requirement for it.=C2=A0


There is currently n=
o widely deployed open standard for HTTP signing.
=C2=A0<= /div>
Yes, there is working going on. But security it is not a publishe= d RFC, there are no libraries for it, and it has not been tested on the ope= n internet.=C2=A0

While I wish the HTTP WG luck in= this work, and I support it happening, it will be hard.

OAuth 1.0 core issue was that it was signing a request (in my opinio= n)
<= br>
Which is why we shouldn=E2=80=99t have a normative dependency= on it until it=E2=80=99s done, but ignoring it entirely is silly. I=E2=80= =99ve always said this needs to be one among many options.

I was not ignoring it. When it is done, a= n extension can be written on how to use HTTP Signing. Or the extension cou= ld be developed at the same time.


= =C2=A0


The wid= ely deployed HTTP Signing is AWS SIGv4 -- which AWS supplies libraries for = every API in all popular languages so that developers don't have to do = the HTTP signing themselves.=C2=A0

I could imagine= AWS adopting XAuth and using SIGv4 instead of JOSE if they wanted.

<= div>I agree that they should be able to use TxAuth (not necessarily XAuth ;= ) ) using SIGv4, if they wanted =E2=80=94 and that=E2=80=99s assuming they = don=E2=80=99t move AWS to HTTP Sig. :)
<= br>
Moving AWS to HTTP Sig is very, very unlikely, having worked = there. Having an easy path to utilize XAuth / TxAuth is a good goal for the= resulting work.
=C2=A0

=



8. XAuth adds back in an explicit = =E2=80=9Crefresh token=E2=80=9D. In XYZ, we don=E2=80=99t have a refresh to= ken because we can use the transaction handle to continue the transaction a= fter a token has been issued. This has explicit and clear semantics that fo= llows from what the transaction handle is used for elsewhere in the protoco= l =E2=80=94 continue this request that=E2=80=99s in some authorization stat= e and give me the results.=C2=A0
<= br>
I think we agree that refresh is a required feature.

Yes, and I think that the constructs are similar, but the difference mat= ters. By using the same handle for continuing the transaction over time as = you do for refreshing, XYZ is giving the client developers a specific model= : The transaction itself has a state and value over time, referenced by the= transaction handle. The transaction entity still exists after it=E2=80=99s= been approved and a token has been issued, but the things you can do with = it are different (see below).

=
The word transaction is muddying what I think you are suggesting here.= It more like a conversation. Transactions from a DB point of view are a se= t of actions that all happen, or none happen.
=C2=A0

Both continuation and refresh are saying= to the AS =E2=80=9Crun this transaction again and if I can get a token (or= claims or whatever) in its current state, give me that=E2=80=9D. However, = they can=E2=80=99t really exist at the same time, so having two separate it= ems to ask the same question doesn=E2=80=99t make much sense.=C2=A0

They have different purposes. Th= e completion (now authorization) handle is to check if the AS is done with = its request processing, and if so, provide the results, which includes zero= or more identity claims, and zero or more access tokens/handles.

The refresh handle is to refresh a specific access token/ha= ndle.

=C2=A0


I think a transaction handle is to course grained. = I don't think that the AS should be returning all the claims in a refre= sh. And if there are multiple access tokens returned from the AS, then each= has their own refresh handle.

I think this requires a deeper di= scussion, since the whole idea of multiple access tokens is a very differen= t kind of approach here.=C2=A0

It is a feature of XAuth.=C2=A0

In OAuth tod= ay, the bearer token is like a movie ticket. Whoever has the movie ticket g= ets in the movie.
Using OAuth to obtain a bearer token is like bu= ying a movie ticket.

Sometimes I want to go to mor= e than one movie. OAuth today makes me wait in line to buy each ticket. Why= not let me buy multiple tickets at once?
=C2=A0

I see refresh much as it is in OAuth2 and UM= A, where it refers to the authorization that was granted. This means that y= ou can do downscoping to get lower-powered access tokens that are a subset = of the overall grant, and I think that TxAuth should be able to do a step-u= p auth where you can build some additional request on top of an existing ap= proval.=C2=A0

Is "st= ep-up auth" authentication or authorization, ... or both?
=C2=A0
=

=
=C2=A0
9. XAuth uses OIDC=E2=80=99s ID Token. As I=E2=80=99ve said on= the other thread, I don=E2=80=99t think we actually need a separately sign= ed assertion. I=E2=80=99d rather see a way to sign the entire response whic= h includes the user claims, if we want signature protection.

I responded in a separate thread.=
=C2=A0

10. XAuth sends all the user=E2=80=99s cla= ims on the login request =E2=80=94 or more precisely, this is the only mech= anism specified and the Rationale section claims this is a feature. This vi= olates minimal disclosure and privacy design guidelines, and this type of p= rotocol has been developed before with OpenID 1.x/2.x and SAML. The problem= here unfolds when you think about how it works: The RP needs to log in. If= this is the first time it=E2=80=99s seen this user, then it needs the user= =E2=80=99s profile info. If not, and the profile info hasn=E2=80=99t change= d, there=E2=80=99s no need for it and the AS shouldn=E2=80=99t send it. So = the RP can signal this, right? Except that the RP doesn=E2=80=99t know who = the user is yet (that=E2=80=99s why they=E2=80=99re making this call!). Can= the AS make this call? They won=E2=80=99t know if the RP has cached the us= er=E2=80=99s info or not. And if we=E2=80=99re using Client ID, then the AS= can=E2=80=99t even be sure that this copy of the client is the same as ano= ther copy of the client. I think TxAuth needs to minimize the user claims s= ent back to being an identifier, information about the authentication event= that could change each time anyway, and anything that would be needed to c= ontrol a cache. Additional fields can be pulled from the equivalent of a Us= erInfo Endpoint in a two-stage process that both preserves privacy and opti= mizes for what=E2=80=99s available from each party.
=

Not clear how XYZ improves on this.
<= /div>

=
XYZ does not currently internally specify how to hand user info back, = but I was looking at something in line with what Aaron Parecki=E2=80=99s bl= og post specified last summer.=C2=A0


The UserInfo Endpoint solves the Client getting more info than it needs, b= ut the User still needs to give consent each time unless the AS tracks it. = So it is unclear to me what value the UserInfo Endpoint brings.
=

Remem= bering user consent and delivering claims are two completely separate probl= ems and should not be conflated here. I was addressing the former.=C2=A0

They are related though. If you a= re not wanting to ask for consent on each delivery, how do you know you hav= e consent?
=C2=A0

=
Your comments have inspired me on a solution that can be don= e with XAuth (or XYZ) that can't be done with OAuth 2.0/OIDC.

I'll add that to the XAuth draft and publish it.=C2=A0<= /div>
=C2=A0

11. XAuth defines an explicit discovery ste= p because the client now needs to know several things about the server. The= mix-up attack and a few other attacks in OAuth 2 stem from this kind of pr= ocess. In XYZ, the client really only needs to know the transaction endpoin= t URL and it learns everything else from that point. Yes, the client needs = to discover that someplace =E2=80=94 but it was a deliberate decision in li= miting the amount of upfront information that the client needs to get start= ed.

That is still d= iscovery, is it not?
<= /blockquote>

I literally just called it that in the sentence = above, so yes. :) What you=E2=80=99re discovering is different though. And = doesn=E2=80=99t the client still need to =E2=80=9Cdiscover=E2=80=9D the dis= covery endpoint in XAuth?

What = discovery endpoint?=C2=A0=C2=A0


Would the Client not need to know the message signing met= hods supported? JOSE, HTTP Signing, and/or MTLS?=C2=A0

Only requ= ired if the client can programmatically do anything about that. The truth i= s that just about every client is going to be configured to do one kind of = signing, and the developer can usually discover that. I don=E2=80=99t see a= problem with having it listed in a discovery document next to the transact= ion endpoint, but I think we don=E2=80=99t actually need it because of the = items below:

=C2=A0
I=E2=80=99ve played with the c= oncept of a =E2=80=9Ccapabilities=E2=80=9D list in XYZ, where the client wo= uld present a list of things it can do and the AS trims that list to what i= t can also do.

So .= .. programatic discovery? =3D)

Are you suggesting = that discovery of everything but the endpoint has to be programatic?=C2=A0<= /div>

=
In no way, shape, or form am I implying that. I=E2=80=99m saying= that the items that can be used for programmatic discovery can be returned= from the transaction endpoint without need for a separate endpoint. This c= an even include the signing methods, and the round-trips for an automated c= lient are basically the same.=C2=A0

So take the XA= uth approach:

- client gets configured with the di= scovery endpoint=C2=A0
=
- client calls discovery endpoint, self-configures
- client = calls tx endpoint

Aaah no= w I see where we don't have common understanding ... that is not the XA= uth approach at all.=C2=A0

   1.  *AS Discovery* The Client discovers th=
e AS end point, keys,
       supported claims and authorizations, and other capabilities.
       Some, or all of this information could be manually preconfigured,
       or dynamically obtained.  Dynamic AS discovery is out of scope of
       this document.
=C2=A0In other words, here is some in= formation the Client will need. You will need to manually configure it, or = there may be an option to obtain some or all of the information you need pr= ogramatically. The programatic discovery is out of scope.

Perhaps I need to improve the language?


And the XYZ approach:

- client gets configured with the tx endpoint
- client cal= ls tx endpoint, picks whatever default method it wants for signing (TxAuth = spec can even declare a preferred version if we want)
- if it works, tx has already started and= things just continue =E2=80=94 this optimizes for the happy path
- if it fails, client gets ba= ck information to allow it to self-configure and calls the tx endpoint agai= n

Most existing Clients a= re manually configured. The developer reads the AS documentation to learn w= hat scopes and claims the AS supports, and then codes that into the Client.= The XYZ approach above does not take that into account, and is in conflict= with what you have below.=C2=A0

In XAuth, I'm= calling that out as a step, so the developer understands where that comes = from. You effectively are saying the same thing below, so it is unclear wha= t your concern with XAuth is.

In XYZ, discovery is= currently ignored.
=C2=A0

This is what I mean by one-stage negotiation on the discovery. If = the client gets it right, that=E2=80=99s fine and things just continue with= out the extra step. If the client gets it wrong, it=E2=80=99s given the equ= ivalent of information from the discovery endpoint that it can either self = correct (which it would be able to do if it could self configure from a dis= covery document) or it will throw an error (which is what it=E2=80=99d do i= f it gets a discovery document it can=E2=80=99t do anything with).=C2=A0


=C2=A0
This type of one-stage negotia= tion is really powerful and I think we can get a lot from it here.

Sure ... but for many peopl= e what works today is documentation that someone reads to understand what t= o do. Are you suggesting we not enable that?
<= /div>

I am not suggesting= that we disallow human-readable documentation and static configuration. I = have no idea where you got that I was suggesting that.

Because you were not supportive of the discov= ery step in XAuth? And you made no mention of static configuration in your = description, contrary to XAuth?=C2=A0 Hence me asking a probing question to= get clarity.=C2=A0

Interpersonal communication hi= nt:=C2=A0 when you have no idea on why someone is asking a clarifying quest= ion, ask yourself what might have been unclear in your communication. Then = just answer the clarifying question.=C2=A0
=C2=A0

But to be clear, yes you can still document= things and pre-configure them. In fact, I think that=E2=80=99s better hand= led in XYZ that allows the client to be pre-configured and get started with= a TX request, and then recover better if things aren=E2=80=99t what it tho= ught.

XAuth documents wha= t information is required, and that it can be pre-configured.=C2=A0
=C2=A0
Where in XYZ is the negotiation after the TX request? S= ounds interesting, but I did not see it.

/Dick
3D""=E1=90=A7
--000000000000dd6cc4059d62c5a0-- From nobody Thu Jan 30 22:23: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 C569212008A for ; Thu, 30 Jan 2020 22:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 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, RCVD_IN_MSPIKE_H2=-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 XkthIk0YOFXW for ; Thu, 30 Jan 2020 22:23:49 -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 4E5A712001E for ; Thu, 30 Jan 2020 22:23:48 -0800 (PST) Received: from [100.83.133.101] ([193.173.216.244]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00V6NcUD003823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jan 2020 01:23:40 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F297DA28-4177-4500-B405-9EE8FF85BAC2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 31 Jan 2020 07:22:48 +0100 In-Reply-To: <0C42D0BD-5780-4075-BE70-F69F6001A14B@amazon.com> Cc: Dick Hardt , "txauth@ietf.org" , Kim , Torsten Lodderstedt , Mike Jones To: "Richard Backman, Annabelle" References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> <585BCD70-6B64-4058-AC70-B677695DB391@mit.edu> <7833DDB1-FB88-4151-84B6-8DABB6436B53@amazon.com> <0C42D0BD-5780-4075-BE70-F69F6001A14B@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] The need for signed claims - providence 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, 31 Jan 2020 06:23:52 -0000 --Apple-Mail=_F297DA28-4177-4500-B405-9EE8FF85BAC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with this direction and it=E2=80=99s in line with what my = response was trying to say. The implications of Mike=E2=80=99s suggested = statement was that we would predetermine a preferred method of signing = things as part of the charter. I=E2=80=99m against that. I=E2=80=99m not = against us coming up with a preferred way to sign things, and not = against reusing an existing technology to do so. But none of that should = be specified as such in the charter as constraining the solution space = at this level, in my opinion. In other words, I don=E2=80=99t think we need to or should alter the = charter to address this point. =E2=80=94 Justin > On Jan 30, 2020, at 9:09 PM, Richard Backman, Annabelle = wrote: >=20 > I am not arguing that claims always need to be independently signed, = and I don=E2=80=99t believe Dick is either. My concern arose from this = bit of your follow up response to Mike: > =20 > Even in OIDC, the ID Token is allowed to be unsigned when it is = retrieved from the token endpoint directly using the code flow. The = equivalent of this is the only place that TxAuth would be sending back = user claims directly. > =20 > This sounded to me like you were saying that the only reason for = signing or encrypting the ID Token is to secure it as it passes through = the front channel. That is not the case, as Dick explained. > =20 > Fortunately, I don=E2=80=99t think any of this matters as far as the = charter is concerned. It is sufficient for the charter to say that = identity is in scope. The specific mechanism(s) can and should be = determined by the working group, in the context of a draft = specification. Including a particular problem within the scope of the = working group does not mean that the working group has to invent a brand = new way to solve that problem. It just means that we caninvent something = new, if we determine it is worthwhile to do so. > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: Dick Hardt > Date: Thursday, January 30, 2020 at 11:23 AM > To: Justin Richer > Cc: "Richard Backman, Annabelle" , = "txauth@ietf.org" , Kim , Torsten = Lodderstedt , Mike Jones = > Subject: Re: [UNVERIFIED SENDER] Re: The need for signed claims - = providence > =20 > My point was disagreeing with your assertion: >> =20 >> First, I don=E2=80=99t believe there are going to be many, if any, = cases where we need user claims to be signed and encrypted separately = from the core transaction messages. >> =20 > Sharing the entire transaction with services that only need specific = claims would go against the minimal disclosure tenet.=20 > =20 > On Wed, Jan 29, 2020 at 11:55 PM Justin Richer > wrote: >> I did: My response to your point was that we should enable this kind = of thing but not assume that user claims are going to be =E2=80=94 or = need to be =E2=80=94 in a signed payload. I think that what you=E2=80=99re= describing is a specific architecture decision which is not that = common. It shouldn=E2=80=99t be disallowed but I don=E2=80=99t think = other deployments should pay that cost.=20 >> =20 >> Even in OIDC today, you=E2=80=99re allowed to ignore the signature on = the signed ID Token if it gets delivered on the back channel. In the = normal case, a JWT provides just an extra layer of wrapping without much = value. Please see Aaron=E2=80=99s post for a better writeup of that. >> =20 >> So in the end, I think that plain JSON should be enabled for user = claims (which XAuth also has, I=E2=80=99ll note) along with any type of = packaged assertion like an ID Token (which I=E2=80=99ll note that XYZ = also has). >> =20 >> =E2=80=94 Justin >>=20 >>=20 >>> On Jan 30, 2020, at 7:58 AM, Dick Hardt > wrote: >>> =20 >>> Justin: would you respond to my critique of your statement? I was = not talking about SETs. >>> =20 >>> Tl;dr: multiple services in a pipeline in a complex app may need to = independently verify a claim.=20 >>> =E1=90=A7 >>> =20 >>> On Wed, Jan 29, 2020 at 10:19 PM Justin Richer > wrote: >>>> I think the use cases for SET are very different from an = authentication assertion, which is consumed then discarded. Aaron = Parecki has written a good blog post that touches on this: >>>> =20 >>>> https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz = >>>> =20 >>>> If we need a persistent record then we can also send that =E2=80=94 = maybe it=E2=80=99s even a SET instead of an ID Token? I=E2=80=99m still = fine with enabling signed JWTs to carry information, but what I was = against was stating any assumption that they would always be signed or = encrypted, and that JWT would be the assumed carrier for that.=20 >>>> =20 >>>> =E2=80=94 Justin >>>>=20 >>>>=20 >>>>> On Jan 30, 2020, at 1:00 AM, Richard Backman, Annabelle = > wrote: >>>>> =20 >>>>> +1 to Dick=E2=80=99s counterpoints. The Security Considerations in = draft-ietf-secevent-http-push = = talk about validation of persisted SETs as one reason a deployment may = wish to transmit signed SETs even over a TLS-protected channel. The same = idea applies to identity claims or just about anything else, really. >>>>> =20 >>>>> =E2=80=93=20 >>>>> Annabelle Richard Backman >>>>> AWS Identity >>>>> =20 >>>>> =20 >>>>> From: Dick Hardt > >>>>> Date: Wednesday, January 29, 2020 at 2:16 PM >>>>> To: Justin Richer > >>>>> Cc: "txauth@ietf.org " >, Kim >, Torsten Lodderstedt = >, "Richard = Backman, Annabelle" >, = Mike Jones > >>>>> Subject: [UNVERIFIED SENDER] Re: The need for signed claims - = providence >>>>> =20 >>>>> I forgot to include the reference to Annabelle calling this out = earlier >>>>> =20 >>>>> = https://mailarchive.ietf.org/arch/msg/txauth/0hR49OnE3oqNPuCIQ43fN1o886w = = >>>>> =20 >>>>> =20 >>>>> On Wed, Jan 29, 2020 at 1:14 PM Dick Hardt > wrote: >>>>>> Forking the discussion to focus on signed claims >>>>>> =20 >>>>>> On Wed, Jan 29, 2020 at 3:37 AM Justin Richer > wrote: >>>>>> >>>>>>> First, I don=E2=80=99t believe there are going to be many, if = any, cases where we need user claims to be signed and encrypted = separately from the core transaction messages. Even in OIDC, the ID = Token is allowed to be unsigned when it is retrieved from the token = endpoint directly using the code flow. The equivalent of this is the = only place that TxAuth would be sending back user claims directly. We no = longer have a need to protect things as they travel through the front = channel on a redirect, and we no longer have a need to use the user=E2=80=99= s claims as an artifact for things like session management (we can = define a new artifact for that purpose that fits better). This = effectively means that we don=E2=80=99t need to redefine the ID Token = because we don=E2=80=99t need the equivalent of the ID token in the same = way.. For the cases that we do need to define user claims, we should be = defining them as a JSON object model. And I also believe that this JSON = data model should not be intertwined with or constrained by the JWT = claims registry. The OIDC claims registry can serve as influence and = input to our user claims set if we choose, but I don=E2=80=99t think we = should be intertwined with that either. >>>>>> =20 >>>>>> I disagree. I think it is likely that we will see an increase in = signed claims and messages. >>>>>> =20 >>>>>> In my opinion, the providence of a claim or message is far more = important than protection during transit.=20 >>>>>> =20 >>>>>> Client / AS non-repudiation: when sensitive operations are = performed relying on the contents of a claim, the Client will want = repudiation that the AS or claims issuer made a claim. >>>>>> =20 >>>>>> Separation of duties in complex systems: In large organizations, = a major security threat is a malicious insider. Once an organization = reaches a certain size, you assume there are people employed at the = company that do not have the firms best interests in mind. One = mitigation of this threat is done by separating what different teams can = do with customer / sensitive data, requiring collusion to access or = modify the data. Signed messages and claims simplify different = components being able to independently verify a message or claim. = Similarly, a component issuing a claim, has assurance that other = components in the same system are not modifying it. Large organizations = wrap external systems that do not support this with their own security = mechanism -- but not all organizations are this sophisticated, and as = they grow, retrofitting is difficult. Enabling end to end providence is = a best practice in my opinion. >>>>>> =20 >>>>>> User Consent Audit: as privacy becomes a larger public topic, it = is easy to imagine organizations wanting to prove that they obtained = user information with consent. Rather than gathering user information = directly from the user, a Client can acquire claims from the User's = claims provider that asserts the user provided consent to the Client. = The Client can then technically establish that all user data was = gathered with consent, and the context of the consent. >>>>>> =20 >>>>>> While the message containing the claims may be signed, having = independent claims separately signed simplifies the least privilege = tenet, where a component only has access to the user information it = needs.. =20 >>>>>> =20 >>>>>> /Dick --Apple-Mail=_F297DA28-4177-4500-B405-9EE8FF85BAC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with this direction and it=E2=80=99s in line with what my response = was trying to say. The implications of Mike=E2=80=99s suggested = statement was that we would predetermine a preferred method of signing = things as part of the charter. I=E2=80=99m against that. I=E2=80=99m not = against us coming up with a preferred way to sign things, and not = against reusing an existing technology to do so. But none of that should = be specified as such in the charter as constraining the solution space = at this level, in my opinion.

In other words, I don=E2=80=99t think we need to or should = alter the charter to address this point.
 =E2=80=94 Justin

On Jan 30, 2020, at 9:09 PM, Richard Backman, Annabelle = <richanna@amazon.com> wrote:

I am not = arguing that claims always need to be independently signed, and I = don=E2=80=99t believe Dick is either. My concern arose from this bit of = your follow up response to Mike:
 
Even in OIDC, the ID Token is allowed = to be unsigned when it is retrieved from the token endpoint directly = using the code flow. The equivalent of this is the only place that = TxAuth would be sending back user claims directly.
 
This = sounded to me like you were saying that the only reason for signing or = encrypting the ID Token is to secure it as it passes through the front = channel. That is not the case, as Dick explained.
 
Fortunately, I don=E2=80=99t think any of this matters as far = as the charter is concerned. It is sufficient for the charter to say = that identity is in scope. The specific mechanism(s) can and should be = determined by the working group, in the context of a draft = specification. Including a particular problem within the scope of the = working group does not mean that the working group has to invent a brand = new way to solve that problem. It just means that we caninvent = something new, if we determine it is worthwhile to do so.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: Dick Hardt <dick.hardt@gmail.com>
Date: Thursday, January 30, = 2020 at 11:23 AM
To: Justin Richer <jricher@mit.edu>
Cc: "Richard Backman, = Annabelle" <richanna@amazon.com>, "txauth@ietf.org" <txauth@ietf.org>, Kim = <kim@identityblog.com>, Torsten Lodderstedt <torsten@lodderstedt.net>, Mike Jones <Michael.Jones@microsoft.com>
Subject: Re: [UNVERIFIED SENDER] = Re: The need for signed claims - providence
 
My point was disagreeing = with your assertion:
 
First, I = don=E2=80=99t believe there are going to be many, if any, cases where we = need user claims to be signed and encrypted separately from the core = transaction messages.
 
Sharing the entire transaction with services that only = need specific claims would go against the minimal disclosure = tenet. 
 
On Wed, Jan 29, 2020 at = 11:55 PM Justin Richer <jricher@mit.edu> wrote:
I did: My response to your point was that we should enable = this kind of thing but not assume that user claims are going to be =E2=80=94= or need to be =E2=80=94 in a signed payload. I think that what you=E2=80=99= re describing is a specific architecture decision which is not that = common. It shouldn=E2=80=99t be disallowed but I don=E2=80=99t think = other deployments should pay that cost. 
 
Even in OIDC today, you=E2=80=99re = allowed to ignore the signature on the signed ID Token if it gets = delivered on the back channel. In the normal case, a JWT provides just = an extra layer of wrapping without much value. Please see Aaron=E2=80=99s = post for a better writeup of that.
 
So in the end, I think that plain JSON should be enabled for = user claims (which XAuth also has, I=E2=80=99ll note) along with any = type of packaged assertion like an ID Token (which I=E2=80=99ll note = that XYZ also has).
 
 =E2=80=94 Justin


On Jan 30, 2020, at 7:58 AM, Dick Hardt = <dick.hardt@gmail.com> wrote:
 
Justin: would you respond to my = critique of your statement? I was not talking about SETs.
 
Tl;dr: multiple services in a pipeline = in a complex app may need to independently verify a claim. 
=E1=90=A7
 
On Wed, = Jan 29, 2020 at 10:19 PM Justin Richer <jricher@mit.edu> = wrote:
I think the use cases for SET are very = different from an authentication assertion, which is consumed then = discarded. Aaron Parecki has written a good blog post that touches on = this:
 
https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
If we need a persistent record then we = can also send that =E2=80=94 maybe it=E2=80=99s even a SET instead of an = ID Token? I=E2=80=99m still fine with enabling signed JWTs to carry = information, but what I was against was stating any assumption that they = would always be signed or encrypted, and that JWT would be the assumed = carrier for that. 
 =E2=80=94 Justin


On Jan 30, 2020, at 1:00 AM, Richard = Backman, Annabelle <richanna@amazon.com> wrote:
 
+1 to Dick=E2=80=99s = counterpoints. The Security Considerations in = draft-ietf-secevent-http-push talk about validation of = persisted SETs as one reason a deployment may wish to transmit signed = SETs even over a TLS-protected channel. The same idea applies to = identity claims or just about anything else, really.
 
=E2=80=93 
Annabelle Richard = Backman
AWS Identity
 
 
From: Dick Hardt <dick.hardt@gmail.com>
Date: Wednesday, January 29, 2020 at 2:16 PM
To: Justin Richer <jricher@mit.edu>
Cc: "txauth@ietf.org" <txauth@ietf.org>, Kim <kim@identityblog.com>, Torsten Lodderstedt <torsten@lodderstedt.net>, "Richard Backman, Annabelle" = <richanna@amazon.com>, Mike Jones <Michael.Jones@microsoft.com>
Subject: [UNVERIFIED SENDER] Re: The need for signed = claims - providence
 
I forgot to include the = reference to Annabelle calling this out earlier
 
https://mailarchive.ietf.org/arch/msg/txauth/0hR49OnE3oqNPuCIQ4= 3fN1o886w
 
 
On Wed, Jan 29, 2020 at = 1:14 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Forking the discussion to = focus on signed claims
 
On Wed, Jan 29, 2020 at = 3:37 AM Justin Richer <jricher@mit.edu> wrote:
<snip>
First, I don=E2=80=99t = believe there are going to be many, if any, cases where we need user = claims to be signed and encrypted separately from the core transaction = messages. Even in OIDC, the ID Token is allowed to be unsigned when it = is retrieved from the token endpoint directly using the code flow. The = equivalent of this is the only place that TxAuth would be sending back = user claims directly. We no longer have a need to protect things as they = travel through the front channel on a redirect, and we no longer have a = need to use the user=E2=80=99s claims as an artifact for things like = session management (we can define a new artifact for that purpose that = fits better). This effectively means that we don=E2=80=99t need to = redefine the ID Token because we don=E2=80=99t need the equivalent of = the ID token in the same way.. For the cases that we do need to define = user claims, we should be defining them as a JSON object model. And I = also believe that this JSON data model should not be intertwined with or = constrained by the JWT claims registry. The OIDC claims registry can = serve as influence and input to our user claims set if we choose, but I = don=E2=80=99t think we should be intertwined with that either.
 
I disagree. I think it is likely that = we will see an increase in signed claims and messages.
 
In my opinion, the providence of a = claim or message is far more important than protection during = transit. 
 
Client / AS = non-repudiation: when sensitive operations are performed relying on = the contents of a claim, the Client will want repudiation that the AS or = claims issuer made a claim.
 
Separation of duties in = complex systems: In large organizations, a major security threat is = a malicious insider. Once an organization reaches a certain size, you = assume there are people employed at the company that do not have the = firms best interests in mind. One mitigation of this threat is done by = separating what different teams can do with customer / sensitive data, = requiring collusion to access or modify the data. Signed messages and = claims simplify different components being able to independently verify = a message or claim. Similarly, a component issuing a claim, has = assurance that other components in the same system are not modifying it. = Large organizations wrap external systems that do not support this with = their own security mechanism -- but not all organizations are this = sophisticated, and as they grow, retrofitting is difficult. Enabling end = to end providence is a best practice in my opinion.
 
User Consent Audit: = as privacy becomes a larger public topic, it is easy to imagine = organizations wanting to prove that they obtained user information with = consent. Rather than gathering user information directly from the user, = a Client can acquire claims from the User's claims provider that asserts = the user provided consent to the Client. The Client can then technically = establish that all user data was gathered with consent, and the context = of the consent.
 
While the message containing the claims = may be signed, having independent claims separately signed simplifies = the least privilege tenet, where a component only has access to the user = information it needs..  
 
/Dick

= --Apple-Mail=_F297DA28-4177-4500-B405-9EE8FF85BAC2-- From nobody Fri Jan 31 03:22: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 D00D212080F for ; Fri, 31 Jan 2020 03:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 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, RCVD_IN_MSPIKE_H2=-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 qWEihQ3oO1N3 for ; Fri, 31 Jan 2020 03:22:48 -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 6F256120059 for ; Fri, 31 Jan 2020 03:22:47 -0800 (PST) Received: from [10.38.98.141] ([83.219.75.72]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00VBMdJx029195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jan 2020 06:22:41 -0500 From: Justin Richer Message-Id: <67F6E009-99CB-4ABC-9EE9-28882D38929C@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_E8C7AA6A-E616-4321-8BA2-A11D237C5BC6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 31 Jan 2020 12:22:38 +0100 In-Reply-To: Cc: txauth@ietf.org, Benjamin Kaduk , "rdd@cert.org" , Yaron Sheffer To: Dick Hardt References: <05467DBA-1B21-4F05-94EC-833C6E3FEBFB@mit.edu> <2E6A2343-3277-4090-AE7E-774158C08DB0@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XAuth - a revision 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: Fri, 31 Jan 2020 11:22:57 -0000 --Apple-Mail=_E8C7AA6A-E616-4321-8BA2-A11D237C5BC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 30, 2020, at 11:13 PM, Dick Hardt wrote: >=20 >=20 >=20 > On Thu, Jan 30, 2020 at 1:05 AM Justin Richer > wrote: > On Jan 30, 2020, at 12:25 AM, Dick Hardt > wrote: >> On Wed, Jan 29, 2020 at 8:26 AM Justin Richer > wrote: >> I think XAuth has an interesting take on the problem space that = TxAuth is looking to solve, but in my opinion it generally veers too = closely to OAuth2/OIDC/JWT in its solution approach. >>=20 >> Reusing aspects of OAuth2/OIDC/JWT that are working fine for = deployments will minimize the migration effort for them to take = advantage of the security features of this work such as not using the = redirect for passing parameters. I think XAuth supports the following = clause of the current draft charter: "the group will attempt to simplify = porting from OAuth 2.0 and OpenID Connect to the new protocol where = possible.=E2=80=9D >=20 > I understand the goals here, but I disagree that using the constructs = as directly as they have been here is the most appropriate approach. >=20 > Ok. I think we have reasonable clarity on the disagreement. > =20 >=20 >>=20 >> >> =20 >> 1. XAuth removes =E2=80=9Chandles=E2=80=9D as stand-ins for various = elements. In XYZ, the =E2=80=9Chandle=E2=80=9D concept is a key = abstraction point with specific semantics. A =E2=80=9Chandle=E2=80=9D is = an identifier to a specific instantiation of a JSON object structure. = Using the =E2=80=9Chandle=E2=80=9D for Keys, for Resources, and even the = whole Transaction lets you do a lot of core things in a parallel and = reusable way. XAuth re-invents a few of these as separate items, listed = below, and I see this as a regression. >>=20 >> XAuth took the transaction handle and forked it into a completion = handle and a refresh handle so that it is clear what the Client is = wanting to happen. >>=20 >> It was not clear the value of the other handles that were listed in = XYZ.=20 >=20 > I think this may be that you misunderstood the purposes of the = handles, as you=E2=80=99ve reinvented nearly all of them with different = labels in XAuth. :) >=20 > I understand what a handle is, and what it represents. It appears that = the handles provide a reference to the display, resource, user, and key = objects. XYZ says the AS may issue those, but I could not find determine = when the AS sends them back to the RC. I understand the value of the = transaction handle XYZ, and built on that in XAuth, but XAuth always = sends the display, resource, user and key information by value, not by = reference, so your statement=20 >=20 > you=E2=80=99ve reinvented nearly all of them with different labels in = XAuth >=20 > is confusing. I think what you=E2=80=99re missing is that the dynamically generated = handles are not the only handles in the system. In addition, you=E2=80=99r= e making assumptions about how to generate a handle given a piece of = information, and how the client gets access to the handle for its use in = the request. I think that=E2=80=99s why you=E2=80=99re not realizing = that you=E2=80=99re effectively removing, renaming, and replacing them = in XAuth, but with what I believe and understand to be less robust = capabilities and semantics.=20 The various handles in XYZ can come about in two ways.=20 1. They=E2=80=99re generated dynamically by the AS in response to a = client request. These are the values returned from the tx endpoint, and = I believe this is the use case that you understand better. This is to = handle dynamic, non-emphemeral clients that are capable of remembering = something in between requests. The client always has the option of = sending its information by value, but the handle gives it a short form = reference that it can use instead. The transaction handle is just = another instance of this type of handle, since it=E2=80=99s generated on = the fly.=20 2. They=E2=80=99re assigned by the AS in some static or manual fashion. = These values could be returned by a developer console page, where the = developer or admin goes and statically registers the client=E2=80=99s = various values (keys, resources, etc) and returns the associated = handles. The developer then statically configures these values into the = client =E2=80=94 such as the key handle, discussed in depth below. If = the developer updates the information in the registration, I wouldn=E2=80=99= t expect the handle values to change. Nothing says that they should be = derived from the information they represent, as unguessable unique = values are fine for most of these cases. Resource handles are likely to = be shared across multiple clients, so they=E2=80=99re very likely to be = statically configured, and in addition are likely to also be = human-readable.=20 Part of the power of XYZ is that these handles have the same model in = both cases =E2=80=94 the string is a reference to an object that could = be passed by value as well. Flexibility in how these handles are created = and=20 > =20 >=20 >> =20 >>=20 >> 2. XAuth uses a Client ID from OAuth 2. I removed Client IDs from XYZ = because I realized that you don=E2=80=99t need them anymore. The client = ID tells the AS which client is talking in the front channel because the = client can=E2=80=99t authenticate. In the back channel, the key (or = secret) identifier is enough to identify the client =E2=80=94 that=E2=80=99= s the Key Handle in XYZ that can be passed in lieu of the key itself. = The argument that it=E2=80=99s helpful to have an identifier for doing = developer support and managing registrations is spurious, since this is = an internal identifier that never needs to be exposed by the protocol. = Additionally, a client ID assumes a registration-based model. There are = ephemeral and per-device client instances like SPA=E2=80=99s and mobile = apps that don=E2=80=99t really fit the client ID model very well. = Pushing this requirement on all clients is bad, as we=E2=80=99ve seen in = OAuth 1 and OAuth 2. XAuth tries to manage this by splitting clients = into two camps, but I=E2=80=99m saying that no client needs and external = client ID. >>=20 >> I addressed this in = https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-12 = # = 7 >>=20 >> 7. *Why is there still a Client ID? Could we not use a = fingerprint >> of the public key to identify the Client?* >>=20 >> Some AS deployments do not allow calls from Registered = Clients, >> and provide different functionality to different Clients. A >> permanent identifier for the Client is needed for the Client >> developer and the AS admin to ensure they are referring to = the >> same Client. The Client ID was used in OAuth 2.0, and it = served >> the same purpose >>=20 >> Perhaps you did not see that? >=20 > I did see that and I addressed it in my comment. The AS admin and = developer can still refer to an internal identifier without it being = exposed in the protocol.=20 >=20 > There needs to be some shared identifier in the protocol, would you = not agree? For Registered Clients, the AS needs to have an identifier to = look up the data it has for the Client.=20 >=20 > What is broken with Client ID? What identifier are you proposing in = XYZ? I am proposing that the key information takes the place of the client ID = for all kinds of clients. As discussed below, the key handle is not a = key ID or a key hash =E2=80=94 but more on that in a bit. What=E2=80=99s = important is that it=E2=80=99s an identifier that the AS can look at and = ask itself, =E2=80=9CI=E2=80=99ve seen this ID, what authentication = method and policy should I use for its requests?=E2=80=9D This is the = first step in an OAuth 2 AS implementation, where the AS sees the client = ID and asks =E2=80=9Cwhat authentication method and policy should I use = for this request?=E2=80=9D This is why I see the key handle =E2=80=94 = and not a higher level construct like a client handle / client ID =E2=80=94= as the component that you would branch your decisions off of at the AS. = Once I=E2=80=99ve validated the key, whether by value or by reference, I = now know which client I=E2=80=99m talking to. I don=E2=80=99t need a = separate client identifier. I know that we don=E2=80=99t do it this way = in OAuth 2, and I think that=E2=80=99s a limiting decision that we=E2=80=99= ve gotten incorrect. In the mental model of XYZ, the policy is then tied to whatever software = that key represents, and since keys aren=E2=80=99t shared between = clients, you get the property of a unique identification system as well. = For dynamic clients, they don=E2=80=99t have to send an ID at all =E2=80=94= they send the key itself by value, since the ID won=E2=80=99t reference = anything that the AS knows about. So we have an identifier for the = clients that want a stable reference, a method for passing values for = clients that don=E2=80=99t have a stable reference, and a clear way to = upgrade from passing by value to passing by reference for clients that = want to do the equivalent of =E2=80=9CDynamic Registration=E2=80=9D. = There are a number of deployments where DynReg is used :just: to give = clients in the field a client ID because OAuth 2 requires a client ID, = and there=E2=80=99s a key that=E2=80=99s recognized during the DynReg = process. But if the server can recognize my key, I ask: why not just = start there when you do the request? You can=E2=80=99t in OAuth 2 = because of the redirect-first model and keys don=E2=80=99t even show up = there. You can in TxAuth because the model allows the client to talk to = the AS directly first, and present its keys.=20 I=E2=80=99ll again say that this is a pattern that=E2=80=99s applicable = across all of the different =E2=80=9Chandles=E2=80=9D within the XYZ = protocol. I propose that you could bootstrap an AS-initiated and = RS-first protocol by having another component create a transaction = handle to kick things off. As discussed below, resource handles can be = static or dynamic as well.=20 And it=E2=80=99s really important to know that handles do not need to = match or be derived from the information that they represent. XYZ = intentionally does not tie these together tightly. A key, like a JWK or = certificate, is going to have its own internal identifier, and there=E2=80= =99s nothing that says the key ID needs to be equal to that or rotate = with that. But what if the AS wants to use a key hash as the key handle? = That=E2=80=99s not required (or even suggested) in XYZ either -- but if = it does, then that=E2=80=99s something that both the client and AS need = to update. The AS will need to update its key reference, which means it = will update its key hash, which means it will recognize the new key hash = and tie it to the client record automatically. The client will need to = update its key and send a new hash as its key handle to the AS. However, = clients shouldn=E2=80=99t be expected to create a hash on their own =E2=80= =94 it should update its key with the AS, and the AS should issue a key = handle in response. Whether the AS creates that handle using a hash or = not is not up to the client.=20 > =20 >=20 >>=20 >> I agree that dynamic client IDs in OAuth 2 were problematic. In = XAuth, a Dynamic Client is identified by its key. >>=20 >> Would you clarify what is broken with Client IDs for Registered = Clients? It seems to working fine for registered clients in OAuth 2 / = OpenID Connect, and migrating those deployments will be simpler if we = keep the same concept. >>=20 >> The key handle seems problematic as it will change when keys are = rotated.=20 >=20 > Why would the key handle change when the key is rotated? Nothing in = XYZ dictates how the key handle is generated by the AS or how the key = handle is mapped to a specific key. It=E2=80=99s not a key identifier, = which is why I haven=E2=80=99t called it a =E2=80=9Ckey id=E2=80=9D.=20 >=20 > I mistyped, I intended to say key fingerprint, which obviously changes = when the key is rotated. >=20 > I reread the XYZ Key Handle section ... and you are suggesting it = represents the Client instance, but it is not clear how the AS maps that = to preregistered client information. Right, the key handle doesn=E2=80=99t need to rotate when the key itself = is rotated =E2=80=94 see the discussion above. > =20 >=20 > I don=E2=80=99t see why a registered client can=E2=80=99t be = identified by its key just like a dynamic client would be. What is the = value in this split? I think there=E2=80=99s value in treating all = clients the same and driving the differences in policy on the AS. Either = I recognize a key handle, or I am being given a public key (which I also = might recognize). In all of these cases the AS gets to run its policy = against the party identified by the key. >=20 > To clarify, your proposal is that the public key, or a fingerprint of = it, is what the AS uses to look up a preregistered Client? No, my proposal is that a public key is what the AS uses to recognize a = preregistered client, and that public key can be represented by a = handle. I would expect the handle to be stable over time, like a client = ID, but more specific.=20 In OAuth 2, the client ID wraps together all of the different aspects of = the client and its associated policies. In XYZ, I sought to separate = those into different handles because, as we=E2=80=99ve found in OAuth 2, = different parts of the client system can vary over time. Our notion of = what a =E2=80=9Cclient=E2=80=9D is in OAuth 2 is also pretty vague. We = have developers all over the place sharing client IDs between different = web servers (production and development environments, for example), = different instances of software (mobile applications, SPAs, and = =E2=80=9Cpublic=E2=80=9D clients), and different pieces of software = altogether (micro-components that are tied together in a single = pseudo-app). And we also have the explosion of Client IDs for apps using = DynReg for things like ephemeral instances that get used once and then = stop existing.=20 >=20 > =20 >=20 >> =20 >>=20 >> 3. XAuth uses a =E2=80=9Ctype=E2=80=9D field for interaction. This = means the client can only do one type of interaction for any given = transaction. XYZ started like this, but we moved away from it because we = realized we could have a client app that could handle multiple types = without that kind of dispatch. In XYZ the client sends over flags for = each kind of interaction it can do: send the user to an arbitrary URL, = give the user a code, get a callback from a browser, etc. Combining = these in specific ways addresses all of the different methods that XAuth = identifies as its types while also allowing additional things. The AS = picks from the client=E2=80=99s list based on what the AS can support as = well as what makes sense for the policies governing the requested = access. >>=20 >> Do you have a use case where the AS will want to pick from a list, = rather than supporting the one that the Client wants to use? >=20 > The AS would return interaction responses that are the intersection = of: >=20 > - methods the client indicates it can do in the request > - methods the AS knows it can support > - methods allowed by the policy governing the request >=20 > I don=E2=80=99t understand the second part of this question, because = the AS still =E2=80=9Csupports the one the client wants to use=E2=80=9D = in the XYZ model. >=20 > I'm looking for a use case where the AS needs to select from a list, = rather than use the one mechanism that the Client wants to use. Why the = extra negotiation? The AS isn=E2=80=99t selecting a single value from the list. It=E2=80=99s = responding to what the client wants to use, and it could respond to all = of them. If the client wants to use one mechanism, it sends only one = mechanism. XYZ enables all of the functions of XAuth=E2=80=99s = interaction methods, and then some. > =20 >=20 > As for a concrete example, look at how we handle the =E2=80=9Cqrcode=E2=80= =9D interaction case, based on OAuth 2=E2=80=99s device flow. In this, = you want to send a URI to the client that it can render as a QR code as = well as a code that the user can type into a page, in case they can=E2=80=99= t scan the QR code. OAuth 2 manages this by having a user code as well = as a pre-composed URL containing the code to be used for rendering. XYZ = used to have a mode for this similar to XAuth, but we realized that we = could describe this using two separate flags:=20 >=20 > - I can communicate a short code that the user can type in at a = static URL > - I can get the user to go to an arbitrary URL >=20 > The second one is the same mechanism we can use for redirect-based = auth.=20 >=20 > I got that. I thought being more crisp in the interaction makes it = easier for implementors to understand.=20 I don=E2=80=99t think it=E2=80=99s more crisp, I think it=E2=80=99s more = limiting, and it leads to more confusing code paths. Having implemented = both styles in XYZ in several languages, I vastly prefer the current XYZ = style.=20 When you have the =E2=80=9Ctype=E2=80=9D field, you then have to specify = what different responses mean in the context of different types, like = what XAuth does in =C2=A74.2. In XYZ, the response fields have a single = meaning, and the client does what it can with them. I think it=E2=80=99s = presumptuous to assume =E2=80=9Cqrcode=E2=80=9D as a scannable format, = for instance. Does the AS actually care how the client communicates the = URL to the user? Not really. Even if we were to optimize this for the = client and have the AS return an image instead of a URL, I think the AS = should be able to return an arbitrary image for the client to display to = the user.=20 >=20 > =20 >=20 >>=20 >> In the case where the AS interacts with an RO that is not the User, = there would be nothing the Client would need to do. Perhaps there is a = use case for something different? If so, please elaborate. >> =20 >>=20 >> 4. XAuth allows OAuth-style scopes next to RAR-style data structures = (and next to OIDC claims structures). They are treated as completely = separate from each other. In OAuth 2, RAR is defined in the context of = scope (and resource and audience and other parameters), and this = combination is a matter of some debate still that needs to be solved. = However, it=E2=80=99s clear that they=E2=80=99re combined. In XYZ, the = only resource request defined is the object inside the resource request. = You can mimic =E2=80=9Cscope=E2=80=9D behavior by using a Resource = Handle, which again is defined as a single string that stands in for the = whole object and could be defined by the AS (or the API it=E2=80=99s = protecting).=20 >>=20 >> I think you need to reread the 00 draft. Only one type of = authorization request is allowed. >>=20 >> - OAuth style for deployments where that works fine. >> - RAR style for deployments that need the extra granularity of RAR >> - list of RAR style for deployments that support multiple resource = servers that require independent access tokens. >> =20 >>=20 >> 5. The different kinds of authz requests in (4) create separate = tokens.This is very different from both OAuth 2 and XYZ, where you get = back a single access token. And in XAuth there is no way to get, for = example, two access tokens that are both described by RAR requests, so = this seems like a very arbitrary and syntactically-driven separation.=20 >>=20 >> I don't think you understood what is in the draft. See above. >=20 > Apologies on these points =E2=80=94 I didn=E2=80=99t catch that this = had changed from the earlier drafts.=20 >=20 > We can scratch this concern from the list then. Yeah! Well, kind of =E2=80=94 XAuth doesn=E2=80=99t allow the combination of = an API-specified element (a scope, a simple string value) and a more = fine grained access request. I believe this kind of combination is going = to be essential for transition from OAuth2. XYZ manages things = differently by putting the =E2=80=9Cscope=E2=80=9D like values (resource = handles) at the same level and in the same array structure as the = RAR-style complex values. This way, I can ask for access to access to a = legacy API and a fine-grained request at the same time, and get an = access token that is good for both. A =E2=80=9Cresource handle=E2=80=9D = is a =E2=80=9Cscope=E2=80=9D, since an OAuth 2 scope represents some = bundle of rights and/or information that the client is requesting, = represented as a simple string. These can be defined statically by the = API (or the AS) and configured manually in the client. Why not call it a = =E2=80=9Cscope=E2=80=9D then? Because they can *also* be dynamically = given to the client during the XYZ process.=20 RAR also enables this in OAuth2, but does so using the existing = =E2=80=9Cscope=E2=80=9D field with its existing syntax and semantics. = This is a little bit more problematic because they exist at different = levels of the request, but defining clear combination semantics is one = of the things that RAR needs to do, and to get right. I do not see a way to do this combination with XAuth=E2=80=99s model, = and that seems to be a deliberate decision, which I find unnecessarily = limiting.=20 > =20 >=20 >> =20 >>=20 >> 6. The assumption that JOSE will always be in the toolkit of the = client developer is not true. You can do an XYZ transaction without any = JOSE =E2=80=94 for example, using HTTP Sig or MTLS for key presentation.=20= >>=20 >> Per earlier feedback from you, I have strived to separate JOSE out = into Section 8, so that an extension could use HTTP signing or MTLS. Let = me know where JOSE is still an assumption. >=20 > The separation is OK in the current draft, but it still states that = JOSE is the default, and by implication, preferred.=20 >=20 > Yes. I think freedom from having to make a choice makes things easier = to implement and deploy.=20 > For deployments where another mechanism will be significantly better, = the choice is available. =E2=80=98 These statements contradict each other. Are you advocating for = =E2=80=9Cfreedom from choice=E2=80=9D or that the =E2=80=9Cchoice is = available=E2=80=9D for this particular feature? I am arguing in favor of = making choice available in the case of key presentation and removing = choice in terms of request format (as in, the core payload).=20 >=20 > Is there something about JOSE that you think is problematic to make it = the default? Yes, it leads to reliance on putting everything of note in the JOSE = payload as part of the base protocol. As explained previously, I want to = be able to use HTTP as more than an entity body carrier. We should be = using headers and methods and URLs =E2=80=94 and importantly, content = types. I think JOSE should be switched with things like Content-Type = headers and Accept headers, and that JSON bodies should be the default = as they=E2=80=99re more universal across different signing and = presentation mechanisms.=20 My Java XYZ implementation does use JOSE, but by using JWS in a detached = fashion to sign the body instead of an internal fashion. The reason for = this is that it allows the request and response to be = =E2=80=9Capplication/json=E2=80=9D and not =E2=80=9Capplication/jws=E2=80=9D= .=20 In all of these cases, I do not think it is a good idea to use JWT = claims in the TxAuth request or response namespaces. Where we use JOSE, = we should avoid JWT. > =20 >=20 >> =20 >>=20 >> 7. The statement that =E2=80=9Cthere is no HTTP signing=E2=80=9D is = false, as this is being brought up to the HTTP WG right now (I=E2=80=99m = one of the co-authors). Yes, it=E2=80=99s not an RFC, but neither is = this. And if we=E2=80=99re doing agile signature methods, which I = contend is a required extension point, then we don=E2=80=99t have a = dependency requirement for it.=20 >>=20 >> XAuth says from = https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-12 = # = 3 >>=20 >> There is currently no widely deployed open standard for HTTP signing. = =20 >> =20 >> Yes, there is working going on. But security it is not a published = RFC, there are no libraries for it, and it has not been tested on the = open internet.=20 >>=20 >> While I wish the HTTP WG luck in this work, and I support it = happening, it will be hard. >>=20 >> OAuth 1.0 core issue was that it was signing a request (in my = opinion) >=20 > Which is why we shouldn=E2=80=99t have a normative dependency on it = until it=E2=80=99s done, but ignoring it entirely is silly. I=E2=80=99ve = always said this needs to be one among many options. >=20 > I was not ignoring it. When it is done, an extension can be written on = how to use HTTP Signing. Or the extension could be developed at the same = time. >=20 The means of using HTTP Signing in TxAuth are already pretty clear, and = I=E2=80=99ve implemented it in XYZ based on the existing Cavage draft = that is being used as input to the HTTP WG. >=20 > =20 >=20 >>=20 >> The widely deployed HTTP Signing is AWS SIGv4 -- which AWS supplies = libraries for every API in all popular languages so that developers = don't have to do the HTTP signing themselves.=20 >>=20 >> I could imagine AWS adopting XAuth and using SIGv4 instead of JOSE if = they wanted. >=20 > I agree that they should be able to use TxAuth (not necessarily XAuth = ;) ) using SIGv4, if they wanted =E2=80=94 and that=E2=80=99s assuming = they don=E2=80=99t move AWS to HTTP Sig. :) >=20 > Moving AWS to HTTP Sig is very, very unlikely, having worked there. = Having an easy path to utilize XAuth / TxAuth is a good goal for the = resulting work. I still agree that they should be able to easily use TxAuth, which just = a stronger argument for the signature/proofing mechanism to be a = pluggable thing and that the request/response bodies not be JOSE objects = but JSON objects. > =20 >=20 >>=20 >>=20 >>=20 >> 8. XAuth adds back in an explicit =E2=80=9Crefresh token=E2=80=9D. In = XYZ, we don=E2=80=99t have a refresh token because we can use the = transaction handle to continue the transaction after a token has been = issued. This has explicit and clear semantics that follows from what the = transaction handle is used for elsewhere in the protocol =E2=80=94 = continue this request that=E2=80=99s in some authorization state and = give me the results.=20 >>=20 >> I think we agree that refresh is a required feature. >=20 > Yes, and I think that the constructs are similar, but the difference = matters. By using the same handle for continuing the transaction over = time as you do for refreshing, XYZ is giving the client developers a = specific model: The transaction itself has a state and value over time, = referenced by the transaction handle. The transaction entity still = exists after it=E2=80=99s been approved and a token has been issued, but = the things you can do with it are different (see below). >=20 > The word transaction is muddying what I think you are suggesting here. = It more like a conversation. Transactions from a DB point of view are a = set of actions that all happen, or none happen. I=E2=80=99ve explained previously that the database interpretation is = not the only or full interpretation of the word =E2=80=9Ctransaction=E2=80= =9D here, so I won=E2=80=99t go back into it. Conversation is perhaps = more accurate, but =E2=80=9CCxAuth=E2=80=9D is a problematic acronym. = :-D > =20 >=20 > Both continuation and refresh are saying to the AS =E2=80=9Crun this = transaction again and if I can get a token (or claims or whatever) in = its current state, give me that=E2=80=9D. However, they can=E2=80=99t = really exist at the same time, so having two separate items to ask the = same question doesn=E2=80=99t make much sense.=20 >=20 > They have different purposes. The completion (now authorization) = handle is to check if the AS is done with its request processing, and if = so, provide the results, which includes zero or more identity claims, = and zero or more access tokens/handles. >=20 > The refresh handle is to refresh a specific access token/handle. >=20 I don=E2=80=99t see these as being different, and that=E2=80=99s where = we disagree. The access token is the end result of the processing. = Refreshing is an act of continuing that processing. I do not see a good = argument for treating them separately.=20 > =20 >=20 >>=20 >> I think a transaction handle is to course grained. I don't think that = the AS should be returning all the claims in a refresh. And if there are = multiple access tokens returned from the AS, then each has their own = refresh handle. >=20 > I think this requires a deeper discussion, since the whole idea of = multiple access tokens is a very different kind of approach here.=20 >=20 > It is a feature of XAuth.=20 Kind of. XAuth allows multiple access tokens in one limited context, and = only when using rich authorization requests to do so. I would rather see = us have a general mechanism that allows us to get multiple access tokens = in a way that=E2=80=99s parallel to how you get one access token. >=20 > In OAuth today, the bearer token is like a movie ticket. Whoever has = the movie ticket gets in the movie. > Using OAuth to obtain a bearer token is like buying a movie ticket. >=20 > Sometimes I want to go to more than one movie. OAuth today makes me = wait in line to buy each ticket. Why not let me buy multiple tickets at = once? That=E2=80=99s not true. You can get one ticket that=E2=80=99s good for = two movies, to borrow your metaphor.=20 The semantics of requesting multiple access tokens in parallel is = something the working group might want to consider. I am not a fan of = how XAuth handles this, with packing things into the authorization list. = I think it=E2=80=99s a concept we should consider though. > =20 >=20 > I see refresh much as it is in OAuth2 and UMA, where it refers to the = authorization that was granted. This means that you can do downscoping = to get lower-powered access tokens that are a subset of the overall = grant, and I think that TxAuth should be able to do a step-up auth where = you can build some additional request on top of an existing approval.=20 >=20 > Is "step-up auth" authentication or authorization, ... or both? I think the question you asked is unintentionally misleading because = =E2=80=9Cstep up=E2=80=9D authentication could be seen from the client = or the AS=E2=80=99s perspective.=20 The =E2=80=9Cstep up=E2=80=9D that I mean here is from the client=E2=80=99= s perspective, not from the AS/IdP=E2=80=99s perspective. The client = wants more of something =E2=80=94 more access to an API, more user = information, etc. It=E2=80=99s likely that the AS is going to want to = interact with the user to include whatever additional access the client = is asking for, but the client doesn=E2=80=99t want to start from = scratch. You=E2=80=99ve got a ticket that=E2=80=99s good to see one = movie, and you want to add another movie to it for after. The theater = already knows who you are and how to get your money, so they can just = add it on. It=E2=80=99s entirely feasible that the process of asking for more = information would prompt the AS to re-authenticate the user, including = prompting them for additional credentials. However, from the client=E2=80=99= s view, that=E2=80=99s a side-effect of its request. >=20 > =20 >=20 >> =20 >>=20 >> 9. XAuth uses OIDC=E2=80=99s ID Token. As I=E2=80=99ve said on the = other thread, I don=E2=80=99t think we actually need a separately signed = assertion. I=E2=80=99d rather see a way to sign the entire response = which includes the user claims, if we want signature protection. >>=20 >> I responded in a separate thread. >> =20 >>=20 >> 10. XAuth sends all the user=E2=80=99s claims on the login request = =E2=80=94 or more precisely, this is the only mechanism specified and = the Rationale section claims this is a feature. This violates minimal = disclosure and privacy design guidelines, and this type of protocol has = been developed before with OpenID 1.x/2.x and SAML. The problem here = unfolds when you think about how it works: The RP needs to log in. If = this is the first time it=E2=80=99s seen this user, then it needs the = user=E2=80=99s profile info. If not, and the profile info hasn=E2=80=99t = changed, there=E2=80=99s no need for it and the AS shouldn=E2=80=99t = send it. So the RP can signal this, right? Except that the RP doesn=E2=80=99= t know who the user is yet (that=E2=80=99s why they=E2=80=99re making = this call!). Can the AS make this call? They won=E2=80=99t know if the = RP has cached the user=E2=80=99s info or not. And if we=E2=80=99re using = Client ID, then the AS can=E2=80=99t even be sure that this copy of the = client is the same as another copy of the client. I think TxAuth needs = to minimize the user claims sent back to being an identifier, = information about the authentication event that could change each time = anyway, and anything that would be needed to control a cache. Additional = fields can be pulled from the equivalent of a UserInfo Endpoint in a = two-stage process that both preserves privacy and optimizes for what=E2=80= =99s available from each party. >>=20 >> Not clear how XYZ improves on this. >=20 > XYZ does not currently internally specify how to hand user info back, = but I was looking at something in line with what Aaron Parecki=E2=80=99s = blog post specified last summer.=20 >=20 >>=20 >> The UserInfo Endpoint solves the Client getting more info than it = needs, but the User still needs to give consent each time unless the AS = tracks it. So it is unclear to me what value the UserInfo Endpoint = brings. >=20 > Remembering user consent and delivering claims are two completely = separate problems and should not be conflated here. I was addressing the = former.=20 >=20 > They are related though. If you are not wanting to ask for consent on = each delivery, how do you know you have consent? We are talking past each other. They=E2=80=99re related in the sense = that they=E2=80=99re both a part of the authorization process, but = consenting to the release of information and the delivery of that = information are completely separate from each other.=20 Consent is not the client=E2=80=99s policy, that=E2=80=99s the AS=E2=80=99= s policy. My consent is stored on the AS. The client can't know if this = is the =E2=80=9Cfirst=E2=80=9D time or not because it doesn=E2=80=99t = know who I am yet, so it can=E2=80=99t ask if I should consent again. If = the client knows who I am, it doesn=E2=80=99t need to ask the AS to log = me in in the first place.=20 However, once I=E2=80=99m interacting with the AS, the AS has a chance = of figuring things out. The AS can determine if it=E2=80=99s seen the = same client before, if it=E2=80=99s seen the same user before, and if = the same client is making the same request for the same user, and the AS = knows that it can make that decision without prompting the user. We = already do exactly this today with OAuth 2 and OIDC systems.=20 But the AS does :not: know which profile and identity claims the client = actually :needs:. The only party able to make that decision is the = client, and it can only make that decision once it has a reference to = which user is there (in terms of an identifier). The AS can (and I argue = should) give the client some kind of key for helping make that decision.=20= The push of user information into an OAuth-protected API, and separating = it from the authentication context, is one of the best parts of OpenID = Connect. Yes, the client can always request the user info as long as it = has the access token =E2=80=94 and to me that=E2=80=99s a feature, = because the client is the component that knows when it needs updated = info.=20 > =20 >=20 >>=20 >> Your comments have inspired me on a solution that can be done with = XAuth (or XYZ) that can't be done with OAuth 2.0/OIDC. >>=20 >> I'll add that to the XAuth draft and publish it.=20 >> =20 >>=20 >> 11. XAuth defines an explicit discovery step because the client now = needs to know several things about the server. The mix-up attack and a = few other attacks in OAuth 2 stem from this kind of process. In XYZ, the = client really only needs to know the transaction endpoint URL and it = learns everything else from that point. Yes, the client needs to = discover that someplace =E2=80=94 but it was a deliberate decision in = limiting the amount of upfront information that the client needs to get = started. >>=20 >> That is still discovery, is it not? >=20 > I literally just called it that in the sentence above, so yes. :) What = you=E2=80=99re discovering is different though. And doesn=E2=80=99t the = client still need to =E2=80=9Cdiscover=E2=80=9D the discovery endpoint = in XAuth? >=20 > What discovery endpoint? =20 The charter currently includes =E2=80=9CAS discovery=E2=80=9D, per your = request to add it. To me, and I would argue to most, =E2=80=9Cdiscovery=E2= =80=9D is a programmatic process. If it=E2=80=99s manual, it=E2=80=99s = not really the client =E2=80=9Cdiscovering=E2=80=9D anything, it=E2=80=99s= being told things manually by a developer. That=E2=80=99s not discovery = as the term is generally known, and I think this is a key source of = confusion here. There is no =E2=80=9Cdiscovery=E2=80=9D that=E2=80=99s = not programmatic =E2=80=94 that=E2=80=99s configuration. >=20 >>=20 >> Would the Client not need to know the message signing methods = supported? JOSE, HTTP Signing, and/or MTLS?=20 >=20 > Only required if the client can programmatically do anything about = that. The truth is that just about every client is going to be = configured to do one kind of signing, and the developer can usually = discover that. I don=E2=80=99t see a problem with having it listed in a = discovery document next to the transaction endpoint, but I think we = don=E2=80=99t actually need it because of the items below: >=20 >> =20 >> I=E2=80=99ve played with the concept of a =E2=80=9Ccapabilities=E2=80=9D= list in XYZ, where the client would present a list of things it can do = and the AS trims that list to what it can also do. >>=20 >> So ... programatic discovery? =3D) >>=20 >> Are you suggesting that discovery of everything but the endpoint has = to be programatic?=20 >=20 > In no way, shape, or form am I implying that. I=E2=80=99m saying that = the items that can be used for programmatic discovery can be returned = from the transaction endpoint without need for a separate endpoint. This = can even include the signing methods, and the round-trips for an = automated client are basically the same.=20 >=20 > So take the XAuth approach: >=20 > - client gets configured with the discovery endpoint=20 > - client calls discovery endpoint, self-configures > - client calls tx endpoint >=20 > Aaah now I see where we don't have common understanding ... that is = not the XAuth approach at all.=20 >=20 > 1. *AS Discovery* The Client discovers the AS end point, keys, > supported claims and authorizations, and other capabilities. > Some, or all of this information could be manually = preconfigured, > or dynamically obtained. Dynamic AS discovery is out of scope = of > this document. > In other words, here is some information the Client will need. You = will need to manually configure it, or there may be an option to obtain = some or all of the information you need programatically. The programatic = discovery is out of scope. >=20 > Perhaps I need to improve the language? Yes, if you mean manual configuration of elements, then that=E2=80=99s = not discovery as the term is going to be understood by most. >=20 >=20 > And the XYZ approach: >=20 > - client gets configured with the tx endpoint > - client calls tx endpoint, picks whatever default method it wants for = signing (TxAuth spec can even declare a preferred version if we want) > - if it works, tx has already started and things just continue = =E2=80=94 this optimizes for the happy path > - if it fails, client gets back information to allow it to = self-configure and calls the tx endpoint again >=20 > Most existing Clients are manually configured. The developer reads the = AS documentation to learn what scopes and claims the AS supports, and = then codes that into the Client. The XYZ approach above does not take = that into account, and is in conflict with what you have below.=20 >=20 It does take it into account =E2=80=94 all of that can happen manually = in XYZ. The developer can hard-code the tx endpoint, scopes, keys, and = everything else. The developer can hard code handles to represent all of = those that they=E2=80=99ve gotten through pre-registration. Or it can = happen dynamically using the same mechanisms within the protocol. = There=E2=80=99s not a conflict. > In XAuth, I'm calling that out as a step, so the developer understands = where that comes from. You effectively are saying the same thing below, = so it is unclear what your concern with XAuth is. >=20 > In XYZ, discovery is currently ignored. In XYZ, the only value the client absolutely MUST know about is the tx = endpoint. Discovery is not ignored, it=E2=80=99s trivial. And what = you=E2=80=99re calling =E2=80=9CDiscovery=E2=80=9D is manual/static = configuration, which is definitely covered. This can perhaps be made = more clear, but it=E2=80=99s in there. > =20 >=20 > This is what I mean by one-stage negotiation on the discovery. If the = client gets it right, that=E2=80=99s fine and things just continue = without the extra step. If the client gets it wrong, it=E2=80=99s given = the equivalent of information from the discovery endpoint that it can = either self correct (which it would be able to do if it could self = configure from a discovery document) or it will throw an error (which is = what it=E2=80=99d do if it gets a discovery document it can=E2=80=99t do = anything with).=20 >=20 >=20 >> =20 >> This type of one-stage negotiation is really powerful and I think we = can get a lot from it here. >>=20 >> Sure ... but for many people what works today is documentation that = someone reads to understand what to do. Are you suggesting we not enable = that? >=20 > I am not suggesting that we disallow human-readable documentation and = static configuration. I have no idea where you got that I was suggesting = that. >=20 > Because you were not supportive of the discovery step in XAuth? And = you made no mention of static configuration in your description, = contrary to XAuth? Hence me asking a probing question to get clarity.=20= >=20 As stated in the intro to this email, static configuration was always = part of XYZ=E2=80=99s model. And as stated above, =E2=80=9Cdiscovery=E2=80= =9D fully implies it being programmatic. I don=E2=80=99t believe = there=E2=80=99s a conflict in the way that you=E2=80=99re suggesting. > Interpersonal communication hint: when you have no idea on why = someone is asking a clarifying question, ask yourself what might have = been unclear in your communication. Then just answer the clarifying = question.=20 > =20 >=20 > But to be clear, yes you can still document things and pre-configure = them. In fact, I think that=E2=80=99s better handled in XYZ that allows = the client to be pre-configured and get started with a TX request, and = then recover better if things aren=E2=80=99t what it thought. >=20 > XAuth documents what information is required, and that it can be = pre-configured.=20 XYZ does the same, so I think we agree that this is an important aspect = of TxAuth. > =20 > Where in XYZ is the negotiation after the TX request? Sounds = interesting, but I did not see it. It=E2=80=99s not =E2=80=9Cafter=E2=80=9D so much as =E2=80=9Cpart of=E2=80= =9D the request/response. =E2=80=9CNegotiation=E2=80=9D is a slippery = word, as it often implies a back-and-forth multi-round process. I think = that=E2=80=99s a problematic and complicated pattern. What I do think is = useful is a single-trip, where the client starts things by declaring = what it knows and can do, and the server responds with something that it = can do that it now knows the client can do. TLS algorithm negotiation = and HTTP content negotiation both work this way, and do so successfully = without a complicated protocol. If the client has been preconfigured to only ask for things the server = can do, and if the client is configured to ask for only a single option, = then it=E2=80=99s identical to the case where everything is static and = making a single choice.=20 >=20 > /Dick > =E1=90=A7 --Apple-Mail=_E8C7AA6A-E616-4321-8BA2-A11D237C5BC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 30, 2020, at 11:13 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Thu, Jan 30, 2020 at 1:05 AM Justin = Richer <jricher@mit.edu> wrote:
On Jan 30, 2020, at 12:25 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
On Wed, Jan = 29, 2020 at 8:26 AM Justin Richer <jricher@mit.edu> = wrote:
I think XAuth has an = interesting take on the problem space that TxAuth is looking to solve, = but in my opinion it generally veers too closely to OAuth2/OIDC/JWT in = its solution approach.

Reusing aspects of OAuth2/OIDC/JWT that = are working fine for deployments will minimize the migration effort for = them to take advantage of the security features of this work such as not = using the redirect for passing parameters. I think XAuth supports the = following clause of the current draft charter: "the group = will attempt to simplify porting from OAuth 2.0 and OpenID Connect = to the new protocol where = possible.=E2=80=9D

I = understand the goals here, but I disagree that using the constructs as = directly as they have been here is the most appropriate = approach.

Ok. I think we have reasonable clarity = on the disagreement.
 


<snip>
 
1. XAuth removes = =E2=80=9Chandles=E2=80=9D as stand-ins for various elements. In XYZ, the = =E2=80=9Chandle=E2=80=9D concept is a key abstraction point with = specific semantics. A =E2=80=9Chandle=E2=80=9D is an identifier to a = specific instantiation of a JSON object structure. Using the = =E2=80=9Chandle=E2=80=9D for Keys, for Resources, and even the whole = Transaction lets you do a lot of core things in a parallel and reusable = way. XAuth re-invents a few of these as separate items, listed below, = and I see this as a regression.

XAuth took the = transaction handle and forked it into a completion handle and a refresh = handle so that it is clear what the Client is wanting to = happen.

It was = not clear the value of the other handles that were listed in = XYZ. 

I think this may = be that you misunderstood the purposes of the handles, as you=E2=80=99ve = reinvented nearly all of them with different labels in XAuth. = :)

I understand what a handle is, and what it represents. It = appears that the handles provide a reference to the display, resource, = user, and key objects. XYZ says the AS may issue those, but I could not = find determine when the AS sends them back to the RC. I understand the = value of the transaction handle XYZ, and built on that in XAuth, but = XAuth always sends the display, resource, user and key information by = value, not by reference, so your statement 

you=E2=80=99ve reinvented nearly all of them with different = labels in XAuth

is confusing.

I = think what you=E2=80=99re missing is that the dynamically generated = handles are not the only handles in the system. In addition, you=E2=80=99r= e making assumptions about how to generate a handle given a piece of = information, and how the client gets access to the handle for its use in = the request. I think that=E2=80=99s why you=E2=80=99re not realizing = that you=E2=80=99re effectively removing, renaming, and replacing them = in XAuth, but with what I believe and understand to be  less robust = capabilities and semantics. 

The = various handles in XYZ can come about in two ways. 

1. They=E2=80=99re generated dynamically by the AS = in response to a client request. These are the values returned from the = tx endpoint, and I believe this is the use case that you understand = better. This is to handle dynamic, non-emphemeral clients that are = capable of remembering something in between requests. The client always = has the option of sending its information by value, but the handle gives = it a short form reference that it can use instead. The transaction = handle is just another instance of this type of handle, since it=E2=80=99s= generated on the fly. 

2. = They=E2=80=99re assigned by the AS in some static or manual fashion. = These values could be returned by a developer console page, where the = developer or admin goes and statically registers the client=E2=80=99s = various values (keys, resources, etc) and returns the associated = handles. The developer then statically configures these values into the = client =E2=80=94 such as the key handle, discussed in depth below. If = the developer updates the information in the registration, I wouldn=E2=80=99= t expect the handle values to change. Nothing says that they should be = derived from the information they represent, as unguessable unique = values are fine for most of these cases. Resource handles are likely to = be shared across multiple clients, so they=E2=80=99re very likely to be = statically configured, and in addition are likely to also be = human-readable. 

Part of the = power of XYZ is that these handles have the same model in both cases =E2=80= =94 the string is a reference to an object that could be passed by value = as well. Flexibility in how these handles are created and 

 

 

2. XAuth = uses a Client ID from OAuth 2. I removed Client IDs from XYZ because I = realized that you don=E2=80=99t need them anymore. The client ID tells = the AS which client is talking in the front channel because the client = can=E2=80=99t authenticate. In the back channel, the key (or secret) = identifier is enough to identify the client =E2=80=94 that=E2=80=99s the = Key Handle in XYZ that can be passed in lieu of the key itself. The = argument that it=E2=80=99s helpful to have an identifier for doing = developer support and managing registrations is spurious, since this is = an internal identifier that never needs to be exposed by the protocol. = Additionally, a client ID assumes a registration-based model. There are = ephemeral and per-device client instances like SPA=E2=80=99s and mobile = apps that don=E2=80=99t really fit the client ID model very well. = Pushing this requirement on all clients is bad, as we=E2=80=99ve seen in = OAuth 1 and OAuth 2. XAuth tries to manage this by splitting clients = into two camps, but I=E2=80=99m saying that no client needs and external = client ID.

I addressed this in https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#secti= on-12 # 7

 7.   *Why is there still a Client ID?  Could we not =
use a fingerprint
        of the public key to identify the Client?*

        Some AS deployments do not allow calls from Registered Clients,
        and provide different functionality to different Clients.  A
        permanent identifier for the Client is needed for the Client
        developer and the AS admin to ensure they are referring to the
        same Client.  The Client ID was used in OAuth 2.0, and it served
        the same purpose

Perhaps you = did not see = that?

I did see that and I = addressed it in my comment. The AS admin and developer can still refer = to an internal identifier without it being exposed in the = protocol. 

There needs to be some shared = identifier in the protocol, would you not agree? For Registered Clients, = the AS needs to have an identifier to look up the data it has for the = Client. 

What is broken with Client ID? What identifier are you = proposing in XYZ?

I am proposing that the key information takes the = place of the client ID for all kinds of clients. As discussed below, the = key handle is not a key ID or a key hash =E2=80=94 but more on that in a = bit. What=E2=80=99s important is that it=E2=80=99s an identifier that = the AS can look at and ask itself, =E2=80=9CI=E2=80=99ve seen this ID, = what authentication method and policy should I use for its requests?=E2=80= =9D This is the first step in an OAuth 2 AS implementation, where the AS = sees the client ID and asks =E2=80=9Cwhat authentication method and = policy should I use for this request?=E2=80=9D This is why I see the key = handle =E2=80=94 and not a higher level construct like a client handle / = client ID =E2=80=94 as the component that you would branch your = decisions off of at the AS. Once I=E2=80=99ve validated the key, whether = by value or by reference, I now know which client I=E2=80=99m talking = to. I don=E2=80=99t need a separate client identifier. I know that we = don=E2=80=99t do it this way in OAuth 2, and I think that=E2=80=99s a = limiting decision that we=E2=80=99ve gotten incorrect.

In the mental model of XYZ, the policy is then = tied to whatever software that key represents, and since keys aren=E2=80=99= t shared between clients, you get the property of a unique = identification system as well. For dynamic clients, they don=E2=80=99t = have to send an ID at all =E2=80=94 they send the key itself by value, = since the ID won=E2=80=99t reference anything that the AS knows about. = So we have an identifier for the clients that want a stable reference, a = method for passing values for clients that don=E2=80=99t have a stable = reference, and a clear way to upgrade from passing by value to passing = by reference for clients that want to do the equivalent of =E2=80=9CDynami= c Registration=E2=80=9D. There are a number of deployments where DynReg = is used :just: to give clients in the field a client ID because OAuth 2 = requires a client ID, and there=E2=80=99s a key that=E2=80=99s = recognized during the DynReg process. But if the server can recognize my = key, I ask: why not just start there when you do the request? You = can=E2=80=99t in OAuth 2 because of the redirect-first model and keys = don=E2=80=99t even show up there. You can in TxAuth because the model = allows the client to talk to the AS directly first, and present its = keys. 

I=E2=80=99ll again say = that this is a pattern that=E2=80=99s applicable across all of the = different =E2=80=9Chandles=E2=80=9D within the XYZ protocol. I propose = that you could bootstrap an AS-initiated and RS-first protocol by having = another component create a transaction handle to kick things off. As = discussed below, resource handles can be static or dynamic as = well. 


And it=E2=80=99s really important to know that = handles do not need to match or be derived from the information that = they represent. XYZ intentionally does not tie these together tightly. A = key, like a JWK or certificate, is going to have its own internal = identifier, and there=E2=80=99s nothing that says the key ID needs to be = equal to that or rotate with that. But what if the AS wants to use a key = hash as the key handle? That=E2=80=99s not required (or even suggested) = in XYZ either -- but if it does, then that=E2=80=99s something that both = the client and AS need to update. The AS will need to update its key = reference, which means it will update its key hash, which means it will = recognize the new key hash and tie it to the client record = automatically. The client will need to update its key and send a new = hash as its key handle to the AS. However, clients shouldn=E2=80=99t be = expected to create a hash on their own =E2=80=94 it should update its = key with the AS, and the AS should issue a key handle in response. = Whether the AS creates that handle using a hash or not is not up to the = client. 


 


I agree that dynamic client IDs in OAuth 2 were problematic. = In XAuth, a Dynamic Client is identified by its key.

Would you clarify what = is broken with Client IDs for Registered Clients? It seems to working = fine for registered clients in OAuth 2 / OpenID Connect, and migrating = those deployments will be simpler if we keep the same concept.

The key handle seems = problematic as it will change when keys are = rotated. 

Why would = the key handle change when the key is rotated? Nothing in XYZ dictates = how the key handle is generated by the AS or how the key handle is = mapped to a specific key. It=E2=80=99s not a key identifier, which is = why I haven=E2=80=99t called it a =E2=80=9Ckey = id=E2=80=9D. 

I mistyped, I intended to say key = fingerprint, which obviously changes when the key is rotated.

I reread the XYZ Key = Handle section ... and you are suggesting it represents the Client = instance, but it is not clear how the AS maps that to preregistered = client information.

Right, the key handle doesn=E2=80=99t need to = rotate when the key itself is rotated =E2=80=94 see the discussion = above.

 

I don=E2=80=99t see why a registered = client can=E2=80=99t be identified by its key just like a dynamic client = would be. What is the value in this split? I think there=E2=80=99s value = in treating all clients the same and driving the differences in policy = on the AS. Either I recognize a key handle, or I am being given a public = key (which I also might recognize). In all of these cases the AS gets to = run its policy against the party identified by the = key.

To clarify, your proposal is that the = public key, or a fingerprint of it, is what the AS uses to look up a = preregistered Client?

No, my proposal is that a public key is what the = AS uses to recognize a preregistered client, and that public key can be = represented by a handle. I would expect the handle to be stable over = time, like a client ID, but more specific. 

In OAuth 2, the client ID wraps together all of = the different aspects of the client and its associated policies. In XYZ, = I sought to separate those into different handles because, as we=E2=80=99v= e found in OAuth 2, different parts of the client system can vary over = time. Our notion of what a =E2=80=9Cclient=E2=80=9D is in OAuth 2 is = also pretty vague. We have developers all over the place sharing client = IDs between different web servers (production and development = environments, for example), different instances of software (mobile = applications, SPAs, and =E2=80=9Cpublic=E2=80=9D clients), and different = pieces of software altogether (micro-components that are tied together = in a single pseudo-app). And we also have the explosion of Client IDs = for apps using DynReg for things like ephemeral instances that get used = once and then stop existing. 


 

 

3. XAuth = uses a =E2=80=9Ctype=E2=80=9D field for interaction. This means the = client can only do one type of interaction for any given transaction. = XYZ started like this, but we moved away from it because we realized we = could have a client app that could handle multiple types without that = kind of dispatch. In XYZ the client sends over flags for each kind of = interaction it can do: send the user to an arbitrary URL, give the user = a code, get a callback from a browser, etc. Combining these in specific = ways addresses all of the different methods that XAuth identifies as its = types while also allowing additional things. The AS picks from the = client=E2=80=99s list based on what the AS can support as well as what = makes sense for the policies governing the requested = access.

Do you have a use case where the AS = will want to pick from a list, rather than supporting the one that the = Client wants to = use?

The AS would return = interaction responses that are the intersection of:

 - methods the = client indicates it can do in the request
 - = methods the AS knows it can support
 - methods = allowed by the policy governing the request

I don=E2=80=99t understand the second = part of this question, because the AS still =E2=80=9Csupports the one = the client wants to use=E2=80=9D in the XYZ = model.

I'm looking for a use case where the AS = needs to select from a list, rather than use the one mechanism that the = Client wants to use. Why the extra = negotiation?

The AS isn=E2=80=99t selecting a single value from = the list. It=E2=80=99s responding to what the client wants to use, and = it could respond to all of them. If the client wants to use one = mechanism, it sends only one mechanism. XYZ enables all of the functions = of XAuth=E2=80=99s interaction methods, and then some.

 

As for a concrete example, look at how = we handle the =E2=80=9Cqrcode=E2=80=9D interaction case, based on OAuth = 2=E2=80=99s device flow. In this, you want to send a URI to the client = that it can render as a QR code as well as a code that the user can type = into a page, in case they can=E2=80=99t scan the QR code. OAuth 2 = manages this by having a user code as well as a pre-composed URL = containing the code to be used for rendering. XYZ used to have a mode = for this similar to XAuth, but we realized that we could describe this = using two separate flags: 

 - I can communicate a short code = that the user can type in at a static URL
 - I = can get the user to go to an arbitrary URL

The second one is the same mechanism we = can use for redirect-based = auth. 

I got that. I thought being more crisp = in the interaction makes it easier for implementors to = understand. 

I don=E2=80=99t think it=E2=80=99s more crisp, I = think it=E2=80=99s more limiting, and it leads to more confusing code = paths. Having implemented both styles in XYZ in several languages, I = vastly prefer the current XYZ style. 

When you have the =E2=80=9Ctype=E2=80=9D field, = you then have to specify what different responses mean in the context of = different types, like what XAuth does in =C2=A74.2. In XYZ, the response = fields have a single meaning, and the client does what it can with them. = I think it=E2=80=99s presumptuous to assume =E2=80=9Cqrcode=E2=80=9D as = a scannable format, for instance. Does the AS actually care how the = client communicates the URL to the user? Not really. Even if we were to = optimize this for the client and have the AS return an image instead of = a URL, I think the AS should be able to return an arbitrary image for = the client to display to the user. 


 


In the case where the AS interacts with an RO that is not the = User, there would be nothing the Client would need to do. Perhaps there = is a use case for something different? If so, please = elaborate.
 

4. XAuth = allows OAuth-style scopes next to RAR-style data structures (and next to = OIDC claims structures). They are treated as completely separate from = each other. In OAuth 2, RAR is defined in the context of scope (and = resource and audience and other parameters), and this combination is a = matter of some debate still that needs to be solved. However, it=E2=80=99s= clear that they=E2=80=99re combined. In XYZ, the only resource request = defined is the object inside the resource request. You can mimic = =E2=80=9Cscope=E2=80=9D behavior by using a Resource Handle, which again = is defined as a single string that stands in for the whole object and = could be defined by the AS (or the API it=E2=80=99s = protecting). 

I think you need to reread the 00 = draft. Only one type of authorization request is allowed.

- OAuth style for = deployments where that works fine.
- RAR style for = deployments that need the extra granularity of RAR
- = list of RAR style for deployments that support multiple resource servers = that require independent access tokens.
 

5. The different kinds = of authz requests in (4) create separate tokens.This is very different = from both OAuth 2 and XYZ, where you get back a single access token. And = in XAuth there is no way to get, for example, two access tokens that are = both described by RAR requests, so this seems like a very arbitrary and = syntactically-driven = separation. 

I don't think you understood what is in = the draft. See = above.
<= div class=3D"">
Apologies on these = points =E2=80=94 I didn=E2=80=99t catch that this had changed from the = earlier drafts. 

We can scratch this concern from the = list then. Yeah!

Well, kind of =E2=80=94 XAuth doesn=E2=80=99t = allow the combination of an API-specified element (a scope, a simple = string value) and a more fine grained access request. I believe this = kind of combination is going to be essential for transition from OAuth2. = XYZ manages things differently by putting the =E2=80=9Cscope=E2=80=9D = like values (resource handles) at the same level and in the same array = structure as the RAR-style complex values. This way, I can ask for = access to access to a legacy API and a fine-grained request at the same = time, and get an access token that is good for both. A =E2=80=9Cresource = handle=E2=80=9D is a =E2=80=9Cscope=E2=80=9D, since an OAuth 2 scope = represents some bundle of rights and/or information that the client is = requesting, represented as a simple string. These can be defined = statically by the API (or the AS) and configured manually in the client. = Why not call it a =E2=80=9Cscope=E2=80=9D then? Because they can *also* = be dynamically given to the client during the XYZ = process. 

RAR also enables this = in OAuth2, but does so using the existing =E2=80=9Cscope=E2=80=9D field = with its existing syntax and semantics. This is a little bit more = problematic because they exist at different levels of the request, but = defining clear combination semantics is one of the things that RAR needs = to do, and to get right.

I do not = see a way to do this combination with XAuth=E2=80=99s model, and that = seems to be a deliberate decision, which I find unnecessarily = limiting. 

 

 

6. The = assumption that JOSE will always be in the toolkit of the client = developer is not true. You can do an XYZ transaction without any JOSE = =E2=80=94 for example, using HTTP Sig or MTLS for key = presentation. 

Per earlier feedback from you, I have = strived to separate JOSE out into Section 8, so that an extension could = use HTTP signing or MTLS. Let me know where JOSE is still an = assumption.

The separation = is OK in the current draft, but it still states that JOSE is the = default, and by implication, = preferred. 

Yes. I think freedom from having to = make a choice makes things easier to implement and = deploy. 
For deployments where another = mechanism will be significantly better, the choice is available. = =E2=80=98

These statements contradict each other. Are you = advocating for =E2=80=9Cfreedom from choice=E2=80=9D or that the = =E2=80=9Cchoice is available=E2=80=9D for this particular feature? I am = arguing in favor of making choice available in the case of key = presentation and removing choice in terms of request format (as in, the = core payload). 


Is there something about JOSE that you think is problematic = to make it the default?

Yes, it leads to reliance on putting everything of = note in the JOSE payload as part of the base protocol. As explained = previously, I want to be able to use HTTP as more than an entity body = carrier. We should be using headers and methods and URLs =E2=80=94 and = importantly, content types. I think JOSE should be switched with things = like Content-Type headers and Accept headers, and that JSON bodies = should be the default as they=E2=80=99re more universal across different = signing and presentation mechanisms. 

My Java XYZ implementation does use JOSE, but by = using JWS in a detached fashion to sign the body instead of an internal = fashion. The reason for this is that it allows the request and response = to be =E2=80=9Capplication/json=E2=80=9D and not = =E2=80=9Capplication/jws=E2=80=9D. 

In all of these cases, I do not think it is a good = idea to use JWT claims in the TxAuth request or response namespaces. = Where we use JOSE, we should avoid JWT.

 

 

7. The = statement that =E2=80=9Cthere is no HTTP signing=E2=80=9D is false, as = this is being brought up to the HTTP WG right now (I=E2=80=99m one of = the co-authors). Yes, it=E2=80=99s not an RFC, but neither is this. And = if we=E2=80=99re doing agile signature methods, which I contend is a = required extension point, then we don=E2=80=99t have a dependency = requirement for it. 

XAuth says from https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#secti= on-12 # 3

There is currently no widely deployed open standard =
for HTTP signing.
 
Yes, there is working going on. But security it is not a = published RFC, there are no libraries for it, and it has not been tested = on the open internet. 

While I wish the HTTP WG luck in this work, and I support it = happening, it will be hard.

OAuth 1.0 core issue was that it was signing a request (in = my = opinion)

Which is why we = shouldn=E2=80=99t have a normative dependency on it until it=E2=80=99s = done, but ignoring it entirely is silly. I=E2=80=99ve always said this = needs to be one among many options.

I was not ignoring it. = When it is done, an extension can be written on how to use HTTP Signing. = Or the extension could be developed at the same time.


The means of using HTTP Signing in TxAuth are = already pretty clear, and I=E2=80=99ve implemented it in XYZ based on = the existing Cavage draft that is being used as input to the HTTP = WG.


 


The widely deployed HTTP Signing is AWS SIGv4 -- which AWS = supplies libraries for every API in all popular languages so that = developers don't have to do the HTTP signing themselves. 

I could imagine AWS = adopting XAuth and using SIGv4 instead of JOSE if they = wanted.
=

I agree that they = should be able to use TxAuth (not necessarily XAuth ;) ) using SIGv4, if = they wanted =E2=80=94 and that=E2=80=99s assuming they don=E2=80=99t = move AWS to HTTP Sig. :)
Moving AWS to HTTP Sig is very, very = unlikely, having worked there. Having an easy path to utilize XAuth / = TxAuth is a good goal for the resulting = work.

I= still agree that they should be able to easily use TxAuth, which just a = stronger argument for the signature/proofing mechanism to be a pluggable = thing and that the request/response bodies not be JOSE objects but JSON = objects.

 




8. XAuth = adds back in an explicit =E2=80=9Crefresh token=E2=80=9D. In XYZ, we = don=E2=80=99t have a refresh token because we can use the transaction = handle to continue the transaction after a token has been issued. This = has explicit and clear semantics that follows from what the transaction = handle is used for elsewhere in the protocol =E2=80=94 continue this = request that=E2=80=99s in some authorization state and give me the = results. 

I think we agree that refresh is a = required = feature.

Yes, and I think = that the constructs are similar, but the difference matters. By using = the same handle for continuing the transaction over time as you do for = refreshing, XYZ is giving the client developers a specific model: The = transaction itself has a state and value over time, referenced by the = transaction handle. The transaction entity still exists after it=E2=80=99s= been approved and a token has been issued, but the things you can do = with it are different (see below).

The word transaction is = muddying what I think you are suggesting here. It more like a = conversation. Transactions from a DB point of view are a set of actions = that all happen, or none = happen.

I=E2=80=99ve explained previously that the = database interpretation is not the only or full interpretation of the = word =E2=80=9Ctransaction=E2=80=9D here, so I won=E2=80=99t go back into = it. Conversation is perhaps more accurate, but =E2=80=9CCxAuth=E2=80=9D = is a problematic acronym. :-D

 

Both continuation and refresh are = saying to the AS =E2=80=9Crun this transaction again and if I can get a = token (or claims or whatever) in its current state, give me that=E2=80=9D.= However, they can=E2=80=99t really exist at the same time, so having = two separate items to ask the same question doesn=E2=80=99t make much = sense. 

They have different purposes. The = completion (now authorization) handle is to check if the AS is done with = its request processing, and if so, provide the results, which includes = zero or more identity claims, and zero or more access = tokens/handles.

The refresh handle is to refresh a specific access = token/handle.


I don=E2=80=99t see these as being different, and = that=E2=80=99s where we disagree. The access token is the end result of = the processing. Refreshing is an act of continuing that processing. I do = not see a good argument for treating them separately. 

 


I think a transaction handle is to course grained. I don't = think that the AS should be returning all the claims in a refresh. And = if there are multiple access tokens returned from the AS, then each has = their own refresh = handle.
=

I think this = requires a deeper discussion, since the whole idea of multiple access = tokens is a very different kind of approach = here. 

It is a feature of = XAuth. 

Kind of. XAuth allows multiple access tokens in = one limited context, and only when using rich authorization requests to = do so. I would rather see us have a general mechanism that allows us to = get multiple access tokens in a way that=E2=80=99s parallel to how you = get one access token.


In OAuth today, the bearer token is like a movie ticket. = Whoever has the movie ticket gets in the movie.
Using= OAuth to obtain a bearer token is like buying a movie ticket.

Sometimes I want to go = to more than one movie. OAuth today makes me wait in line to buy each = ticket. Why not let me buy multiple tickets at = once?

That=E2=80=99s not true. You can get one ticket = that=E2=80=99s good for two movies, to borrow your = metaphor. 

The semantics of = requesting multiple access tokens in parallel is something the working = group might want to consider. I am not a fan of how XAuth handles this, = with packing things into the authorization list. I think it=E2=80=99s a = concept we should consider though.

 

I see refresh much as it is in OAuth2 = and UMA, where it refers to the authorization that was granted. This = means that you can do downscoping to get lower-powered access tokens = that are a subset of the overall grant, and I think that TxAuth should = be able to do a step-up auth where you can build some additional request = on top of an existing approval. 

Is "step-up auth" = authentication or authorization, ... or = both?

I= think the question you asked is unintentionally misleading because = =E2=80=9Cstep up=E2=80=9D authentication could be seen from the client = or the AS=E2=80=99s perspective. 

The =E2=80=9Cstep up=E2=80=9D that I mean here is = from the client=E2=80=99s perspective, not from the AS/IdP=E2=80=99s = perspective. The client wants more of something =E2=80=94 more access to = an API, more user information, etc. It=E2=80=99s likely that the AS is = going to want to interact with the user to include whatever additional = access the client is asking for, but the client doesn=E2=80=99t want to = start from scratch. You=E2=80=99ve got a ticket that=E2=80=99s good to = see one movie, and you want to add another movie to it for after. The = theater already knows who you are and how to get your money, so they can = just add it on.

It=E2=80=99s = entirely feasible that the process of asking for more information would = prompt the AS to re-authenticate the user, including prompting them for = additional credentials. However, from the client=E2=80=99s view, = that=E2=80=99s a side-effect of its request.


 

 

9. XAuth uses OIDC=E2=80=99s ID Token. As I=E2=80=99ve said = on the other thread, I don=E2=80=99t think we actually need a separately = signed assertion. I=E2=80=99d rather see a way to sign the entire = response which includes the user claims, if we want signature = protection.

I responded in a separate = thread.
 

10. = XAuth sends all the user=E2=80=99s claims on the login request =E2=80=94 = or more precisely, this is the only mechanism specified and the = Rationale section claims this is a feature. This violates minimal = disclosure and privacy design guidelines, and this type of protocol has = been developed before with OpenID 1.x/2.x and SAML. The problem here = unfolds when you think about how it works: The RP needs to log in. If = this is the first time it=E2=80=99s seen this user, then it needs the = user=E2=80=99s profile info. If not, and the profile info hasn=E2=80=99t = changed, there=E2=80=99s no need for it and the AS shouldn=E2=80=99t = send it. So the RP can signal this, right? Except that the RP doesn=E2=80=99= t know who the user is yet (that=E2=80=99s why they=E2=80=99re making = this call!). Can the AS make this call? They won=E2=80=99t know if the = RP has cached the user=E2=80=99s info or not. And if we=E2=80=99re using = Client ID, then the AS can=E2=80=99t even be sure that this copy of the = client is the same as another copy of the client. I think TxAuth needs = to minimize the user claims sent back to being an identifier, = information about the authentication event that could change each time = anyway, and anything that would be needed to control a cache. Additional = fields can be pulled from the equivalent of a UserInfo Endpoint in a = two-stage process that both preserves privacy and optimizes for what=E2=80= =99s available from each party.

Not clear how XYZ = improves on = this.

XYZ does not = currently internally specify how to hand user info back, but I was = looking at something in line with what Aaron Parecki=E2=80=99s blog post = specified last summer. 


The UserInfo Endpoint solves the Client getting more info = than it needs, but the User still needs to give consent each time unless = the AS tracks it. So it is unclear to me what value the UserInfo = Endpoint = brings.
=

Remembering user consent and = delivering claims are two completely separate problems and should not be = conflated here. I was addressing the = former. 

They are related though. If you are not = wanting to ask for consent on each delivery, how do you know you have = consent?

We are talking past each other. They=E2=80=99re = related in the sense that they=E2=80=99re both a part of the = authorization process, but consenting to the release of information and = the delivery of that information are completely separate from each = other. 

Consent is not the = client=E2=80=99s policy, that=E2=80=99s the AS=E2=80=99s policy. My = consent is stored on the AS. The client can't know if this is the = =E2=80=9Cfirst=E2=80=9D time or not because it doesn=E2=80=99t know who = I am yet, so it can=E2=80=99t ask if I should consent again. If the = client knows who I am, it doesn=E2=80=99t need to ask the AS to log me = in in the first place. 

However, = once I=E2=80=99m interacting with the AS, the AS has a chance of = figuring things out. The AS can determine if it=E2=80=99s seen the same = client before, if it=E2=80=99s seen the same user before, and if the = same client is making the same request for the same user, and the AS = knows that it can make that decision without prompting the user. We = already do exactly this today with OAuth 2 and OIDC = systems. 

But the AS does :not: = know which profile and identity claims the client actually :needs:. The = only party able to make that decision is the client, and it can only = make that decision once it has a reference to which user is there (in = terms of an identifier). The AS can (and I argue should) give the client = some kind of key for helping make that decision. 

The push of user information into an = OAuth-protected API, and separating it from the authentication context, = is one of the best parts of OpenID Connect. Yes, the client can always = request the user info as long as it has the access token =E2=80=94 and = to me that=E2=80=99s a feature, because the client is the component that = knows when it needs updated info. 

 


Your comments have inspired me on a solution that can be done = with XAuth (or XYZ) that can't be done with OAuth 2.0/OIDC.

I'll add that to the = XAuth draft and publish it. 
 

11. = XAuth defines an explicit discovery step because the client now needs to = know several things about the server. The mix-up attack and a few other = attacks in OAuth 2 stem from this kind of process. In XYZ, the client = really only needs to know the transaction endpoint URL and it learns = everything else from that point. Yes, the client needs to discover that = someplace =E2=80=94 but it was a deliberate decision in limiting the = amount of upfront information that the client needs to get = started.

That is still discovery, is it = not?

I literally just called it that in the = sentence above, so yes. :) What you=E2=80=99re discovering is different = though. And doesn=E2=80=99t the client still need to =E2=80=9Cdiscover=E2=80= =9D the discovery endpoint in XAuth?

What discovery = endpoint?  

The charter currently includes =E2=80=9CAS = discovery=E2=80=9D, per your request to add it. To me, and I would argue = to most, =E2=80=9Cdiscovery=E2=80=9D is a programmatic process. If = it=E2=80=99s manual, it=E2=80=99s not really the client = =E2=80=9Cdiscovering=E2=80=9D anything, it=E2=80=99s being told things = manually by a developer. That=E2=80=99s not discovery as the term is = generally known, and I think this is a key source of confusion here. = There is no =E2=80=9Cdiscovery=E2=80=9D that=E2=80=99s not programmatic = =E2=80=94 that=E2=80=99s configuration.



Would the Client not need to know the message signing methods = supported? JOSE, HTTP Signing, and/or = MTLS? 

Only required = if the client can programmatically do anything about that. The truth is = that just about every client is going to be configured to do one kind of = signing, and the developer can usually discover that. I don=E2=80=99t = see a problem with having it listed in a discovery document next to the = transaction endpoint, but I think we don=E2=80=99t actually need it = because of the items below:

 
I=E2=80=99ve played with the = concept of a =E2=80=9Ccapabilities=E2=80=9D list in XYZ, where the = client would present a list of things it can do and the AS trims that = list to what it can also do.

So ... programatic = discovery? =3D)

Are you suggesting that discovery of everything but the = endpoint has to be = programatic? 

In no = way, shape, or form am I implying that. I=E2=80=99m saying that the = items that can be used for programmatic discovery can be returned from = the transaction endpoint without need for a separate endpoint. This can = even include the signing methods, and the round-trips for an automated = client are basically the same. 

So take the XAuth approach:

- client gets configured = with the discovery = endpoint 
- client calls = discovery endpoint, self-configures
- client calls = tx endpoint

Aaah now I see where we don't have = common understanding ... that is not the XAuth approach at = all. 

   1.  *AS Discovery* The =
Client discovers the AS end point, keys,
       supported claims and authorizations, and other capabilities.
       Some, or all of this information could be manually preconfigured,
       or dynamically obtained.  Dynamic AS discovery is out of scope of
       this document.
 In other words, = here is some information the Client will need. You will need to manually = configure it, or there may be an option to obtain some or all of the = information you need programatically. The programatic discovery is out = of scope.

Perhaps I need to improve the = language?

Yes, if you mean manual configuration of elements, = then that=E2=80=99s not discovery as the term is going to be understood = by most.



And the XYZ approach:

- client gets configured = with the tx endpoint
- client calls tx endpoint, = picks whatever default method it wants for signing (TxAuth spec can even = declare a preferred version if we want)
- if it works, tx = has already started and things just continue =E2=80=94 this optimizes = for the happy path
- if it fails, = client gets back information to allow it to self-configure and calls the = tx endpoint again

Most existing Clients are manually = configured. The developer reads the AS documentation to learn what = scopes and claims the AS supports, and then codes that into the Client. = The XYZ approach above does not take that into account, and is in = conflict with what you have below. 


It does take it into account =E2=80=94 all of that = can happen manually in XYZ. The developer can hard-code the tx endpoint, = scopes, keys, and everything else. The developer can hard code handles = to represent all of those that they=E2=80=99ve gotten through = pre-registration. Or it can happen dynamically using the same mechanisms = within the protocol. There=E2=80=99s not a conflict.

In = XAuth, I'm calling that out as a step, so the developer understands = where that comes from. You effectively are saying the same thing below, = so it is unclear what your concern with XAuth is.
In XYZ, discovery is currently = ignored.

In XYZ, the only value the client absolutely MUST = know about is the tx endpoint. Discovery is not ignored, it=E2=80=99s = trivial. And what you=E2=80=99re calling =E2=80=9CDiscovery=E2=80=9D is = manual/static configuration, which is definitely covered. This can = perhaps be made more clear, but it=E2=80=99s in there.

 

This is what I mean by one-stage = negotiation on the discovery. If the client gets it right, that=E2=80=99s = fine and things just continue without the extra step. If the client gets = it wrong, it=E2=80=99s given the equivalent of information from the = discovery endpoint that it can either self correct (which it would be = able to do if it could self configure from a discovery document) or it = will throw an error (which is what it=E2=80=99d do if it gets a = discovery document it can=E2=80=99t do anything with). 


 
This type of one-stage = negotiation is really powerful and I think we can get a lot from it = here.

Sure ... but for many people what works = today is documentation that someone reads to understand what to do. Are = you suggesting we not enable = that?

I am not suggesting = that we disallow human-readable documentation and static configuration. = I have no idea where you got that I was suggesting = that.

Because you were not supportive of the = discovery step in XAuth? And you made no mention of static configuration = in your description, contrary to XAuth?  Hence me asking a probing = question to get clarity. 


As stated in the intro to this email, static = configuration was always part of XYZ=E2=80=99s model. And as stated = above, =E2=80=9Cdiscovery=E2=80=9D fully implies it being programmatic. = I don=E2=80=99t believe there=E2=80=99s a conflict in the way that = you=E2=80=99re suggesting.

Interpersonal communication = hint:  when you have no idea on why someone is asking a clarifying = question, ask yourself what might have been unclear in your = communication. Then just answer the clarifying question. 
 

But to be clear, yes you can still = document things and pre-configure them. In fact, I think that=E2=80=99s = better handled in XYZ that allows the client to be pre-configured and = get started with a TX request, and then recover better if things = aren=E2=80=99t what it thought.

XAuth documents what = information is required, and that it can be = pre-configured. 

XYZ does the same, so I think we agree that this = is an important aspect of TxAuth.

 
Where = in XYZ is the negotiation after the TX request? Sounds interesting, but = I did not see it.

It=E2=80=99s not =E2=80=9Cafter=E2=80=9D so much = as =E2=80=9Cpart of=E2=80=9D the request/response. =E2=80=9CNegotiation=E2= =80=9D is a slippery word, as it often implies a back-and-forth = multi-round process. I think that=E2=80=99s a problematic and = complicated pattern. What I do think is useful is a single-trip, where = the client starts things by declaring what it knows and can do, and the = server responds with something that it can do that it now knows the = client can do. TLS algorithm negotiation and HTTP content negotiation = both work this way, and do so successfully without a complicated = protocol.

If the client has been = preconfigured to only ask for things the server can do, and if the = client is configured to ask for only a single option, then it=E2=80=99s = identical to the case where everything is static and making a single = choice. 


/Dick
3D""=E1=90=A7

= --Apple-Mail=_E8C7AA6A-E616-4321-8BA2-A11D237C5BC6-- From nobody Fri Jan 31 04:38: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 8E56112084F for ; Fri, 31 Jan 2020 04:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 nQeFrrHXxPEf for ; Fri, 31 Jan 2020 04:38:06 -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 9E9361208AC for ; Fri, 31 Jan 2020 04:38:06 -0800 (PST) Received: from [10.38.98.141] ([83.219.75.72]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00VCc2ul012037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jan 2020 07:38:03 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_12D7B291-2AAF-4C87-B144-74BA441150C8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 31 Jan 2020 13:38:01 +0100 In-Reply-To: <67F6E009-99CB-4ABC-9EE9-28882D38929C@mit.edu> Cc: "rdd@cert.org" , Yaron Sheffer , txauth@ietf.org, Benjamin Kaduk To: Dick Hardt References: <05467DBA-1B21-4F05-94EC-833C6E3FEBFB@mit.edu> <2E6A2343-3277-4090-AE7E-774158C08DB0@mit.edu> <67F6E009-99CB-4ABC-9EE9-28882D38929C@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XAuth - a revision 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: Fri, 31 Jan 2020 12:38:10 -0000 --Apple-Mail=_12D7B291-2AAF-4C87-B144-74BA441150C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Finishing a dangling sentence: >=20 > Part of the power of XYZ is that these handles have the same model in = both cases =E2=80=94 the string is a reference to an object that could = be passed by value as well. Flexibility in how these handles are created = and=20 >>=20 =E2=80=A6 used is one of the benefits of XYZ=E2=80=99s model. Handles = are opaque and AS-determined. The AS can make these in response to a = runtime action or a configuration/development time action. They can be = random, they can be hashes, they can even be structured (though in most = cases that doesn=E2=80=99t make sense because you could just send the = structured object instead). In all cases, they=E2=80=99re serializable = as a string and represent an object that could have been passed by value = in their stead. The object that the handle represents can change without = changing the handle. Two different handles could resolve to the same = underlying object. Only the AS determines what the handle maps to, in = reality.=20 =E2=80=94 Justin= --Apple-Mail=_12D7B291-2AAF-4C87-B144-74BA441150C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Finishing a dangling sentence:


Part of the power of = XYZ is that these handles have the same model in both cases =E2=80=94 = the string is a reference to an object that could be passed by value as = well. Flexibility in how these handles are created = and 

<= br class=3D"">
=E2=80=A6 used is one of the benefits of = XYZ=E2=80=99s model. Handles are opaque and AS-determined. The AS can = make these in response to a runtime action or a = configuration/development time action. They can be random, they can be = hashes, they can even be structured (though in most cases that doesn=E2=80= =99t make sense because you could just send the structured object = instead). In all cases, they=E2=80=99re serializable as a string and = represent an object that could have been passed by value in their stead. = The object that the handle represents can change without changing the = handle. Two different handles could resolve to the same underlying = object. Only the AS determines what the handle maps to, in = reality. 

 =E2=80=94 = Justin
= --Apple-Mail=_12D7B291-2AAF-4C87-B144-74BA441150C8-- From me@hashedhyphen.com Fri Jan 31 12: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 4B7A2120BC7 for ; Fri, 31 Jan 2020 12:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CK_HELO_DYNAMIC_SPLIT_IP=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISC_IP=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hashedhyphen.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 YGbkR8CyijpW for ; Fri, 31 Jan 2020 12:13:11 -0800 (PST) Received: from 133-130-107-8.hashedhyphen.com (v133-130-107-8.a036.g.tyo1.static.cnode.io [133.130.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B46120BF8 for ; Fri, 31 Jan 2020 12:13:10 -0800 (PST) Received: from hh-mbp.local (p2548003-ipngn21801marunouchi.tokyo.ocn.ne.jp [124.98.237.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by 133-130-107-8.hashedhyphen.com (Postfix) with ESMTPSA id 6AFA22E06B1 for ; Sat, 1 Feb 2020 05:13:09 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hashedhyphen.com; s=dkim; t=1580501589; bh=z1bX0aOXl5gYlZiXTUwqh3as2cVuAcqlz1L9oEFFxEA=; h=To:From:Subject:Date:From; b=vR9Bj0dP1TRW5x95pQHrXHxSWUs+A4EQdp0ybEdKJz2byIlIWDq8OT1zmKDgF5Qfv cL8gornSOO7WR9b3tPqHscKJP78ym+BAWDlCJI5WhPfZUSxiiLss2xtPuPlM6QfMBb Asszc1dsuRptf8I4j4CuisYse3UqSJzC51PdMukc= To: txauth@ietf.org From: Ryo Kato Openpgp: preference=signencrypt Autocrypt: addr=me@hashedhyphen.com; keydata= mQINBF2fZNwBEACW47rFtrKEo6wtlHjEqmzKTeIekak61KVxtIX2Ql+LX40T2GN40VFahOTb AKey+Nu/RUVy+xwv8Y+lxiqB/qX+SVY9j2XnE0tH72DfpKRBsUCwG6my1mRW/XjktfRMmd9n Jr+jz83+TVh0trKS8i4gVEHiw0nyCBcCkXSkHpI6glfubSlYg3ChqjM0GsyXBmqI7k0o5C+0 2rkZUFFst2vPFMF51thTj79flmtRd/tzFHpBXtVX00+w7E/B5ss/omwW8d1rq3CGXNIHSNBr IrF2p6BYGranYDQAcgCKlkr//0ux1CeZ/wS3+2gavX6dyjC6dJ45C0Q5W010i3Yu8PNwbS5v G5Zw4PJAg/KYE1VuJS6R07Ba6hxOy0fzityiF9WZovBWcks7UBiiqYCvqrTs4ZLjC/GAt44S 6Snrv7FMGyGnXK6xXtt0kEQhswF8leokb/jloIMFH8roYdhdmIdjX/mNeIyAsJVvZDEKcZQ7 tuFBviu1kHqUVZzUbI9Vh0litdYrdE8hS3YwVbq4UaGGcGeSDzzC7jKTUX1dqStMnsz63Q4P 6Q0dYGthot51varDcYqYZ+mosKtUdb/j5TKFP6MTPmz6QzYWl5kdRup7thlO54ZS6+Qq03vd h6uubqxGIF6oMfdyNU30LZgMbPW+QW5QzZYDQcPivCN1zOahhQARAQABtB5SeW8gS2F0byA8 bWVAaGFzaGVkaHlwaGVuLmNvbT6JAlQEEwEIAD4WIQScmViC3YJ7PSsszvhWbmajCW3E3AUC XZ9k3AIbAwUJAeEzgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRBWbmajCW3E3L0OD/4k PMfrW0rDgEgPCZwqHIppplwqRzyswOhTR+/gqPlZvBXuQmiN8WhCIfbirL86Hz4V0zttGhE5 Syd1ydEyk9s6xSYJIeriz9AxDro4Ko0LdR2TJFMkOolSu3HROFKWQgc8jgdIYgzu9pcHbiwq 81oLV8vMwz0JWGnwm0EfnEfWIgW9DSMaY9Dohj2Ea4253e4Fr1MH5DHP76WhijCc1bF/S3AI Db/0xI9oo4hVyuUnXdoGhF9xaSYIO9CKAWrE0VrEVP4wUAOGL7Ak2aj9wQzy3LqLUdcsGbFc 5U4JJcndAWOFcSkg5rOyydnN8M/7fJtqKJhhxZxq3BuV5zPZ1BAuepAPwE1PsG0HClrJenuM 0PeXfOy+3QGxFDXqUkvhxeUUxwMGKTyE/oKuoEMLuGey3LPCV6H5pgJwCyBKw/QQs5EoycAU V1rylHekE56Y0KKasYAU392kj93msl4GQoM1V0WkszKMgq+0I55eUo2xLyzYhqTu+JZVBnHy HseJzFe3PstI87Gbxtc/Fb+16A8gw7lOAdSUXmg5ZkLlrHxmLCJDld95TJFvw2ovTdBnIKjF t6vs62mrKDx/Mamodbu5Bxq8R4U6R5xiqgatwT6LgFPuUH79vltOSZsu1wT202+9vucd8lLl +CHJGsas9MLU1rIM58wjFW5WZI28sgG0IrkCDQRdn2TcARAAwIcME2A2WvTiiOKqOdIeeyW7 06Pd+d7OnHyiGGMah+liJ9R25v43RjR3P6FPqiUTCwY5Mis6Nkyc+InylUjQ35aNrE1LnuOT QjeD3lVAfBxnBsDMSC2xZT0PN+7D2CSD9Zazf+0XjvHHkI9AyGh3WOor4MkChZmZLbxCf8QL YnkchZZnPu9nrJvhZXxG7pjDg78JF4yGNcdinBasF1wzw3a5YVb10tqxzcEVxNX47aFY2Mb3 oJzocNMBMv3TpxfwVRX3RRVKq8yjYpNJiPIcplcjDnizKDXqsxvr/sTAv8DsnCJH+O4RvuKH SIo+qiAEC3HhyYpXG8b6OxesBSh6ofrbCgNVyGqrg7ETI9UpNkcGZIsWJNhg/50hbn1lfdOj vFDf0YEV2Tkg0RLj5fo1GkKK9h//Ch1UPNPRdsw4/0E3qvbyMsPa3tSOHOxv4aaBJabbnCPB DCZiMxpfNv3bx+hNImOGBZ0c2+3McHFzlTPdQHvau0glEr0WCyn4zisLe/z8H1MFfp0laorz EwRBGrSS+aEUneKUbZjY2pXTzojf1KuuG8WuA1q6Aoq0xcQcIRFk8SUIKUyvkxtscqX3MUev zuTGRmdnOjwr+mvrYVsk6K3pRFMQfaetrBDOyRbLcaAAOqKno+HKBwb+Px6LPnq57naE0CWs 4IjbJYB0HJkAEQEAAYkCPAQYAQgAJhYhBJyZWILdgns9KyzO+FZuZqMJbcTcBQJdn2TcAhsM BQkB4TOAAAoJEFZuZqMJbcTc+f4P/RqPZO5PT75R2QgDdofVXfec9gTq2QVs0jeMk46jFOgT 1tv5Hz/KyOFM1mdO7fG81e2IF/kLaskhcdPNEodEFdqsnptRm6IdJqN1hv/n2oeJS+t5qZkV QXy0ecZvdghfZsP3Cfloi5WuTpElVJMClfqeB5lBWFV7HhGg8KDnPsaMh1IXoR/qBb/XcIty ejmuainZcCvX7+MPMH4EbuJRO34/diC2/Ig+J+Swj1/t1ONFOdtliXpYOJmY9XKVO9orVUXL bdW5ChiqFVOODiAmJjmez2QvXzT03WJHjivy8xlJ+Zyv5uni+Os+Hz5nwRW/+DuMJvpHDsxT FuQgSTn/0jLW9THhFcMAFxTIXMx1282BSy0jqw4a7e8r3WRLM7ms5e1EUjsz1essa4rnVFBK BWRS9vYITSFuuLOi0m5EHlvWIwSu/Xlr8FIW5wZY5Fkl0KzUA3gIvPmoaW/kqYeGF3aFxfUA agVoBt/4LoE3joR4W2T6Ek94k52aX7cwHdjYyKCWHPl4tkAdBAIAPhulJ19TSlMeaPfyWoL9 llYxVwarCeVC9HBT/3fU4Wuw6P895AibDw+ZTaKJri8HgpSw3Al/TjD248uJeZTROPQZpcJ2 pG7Rd0HsdtW0edvI3AMhJD92l1Azyk3hCtiUlJQ7KTaZA21VA7ml3hNnNGe204Ue Message-ID: Date: Sat, 1 Feb 2020 05:13:07 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H6uxZvP7kE9b18LRYNm6opbFA33tJzdNL" Archived-At: Subject: [Txauth] Questions on key validations by RS 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, 31 Jan 2020 20:14:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H6uxZvP7kE9b18LRYNm6opbFA33tJzdNL Content-Type: multipart/mixed; boundary="ITAUPgZvvNxxpaZUf9I2ROyggajOfbN63"; protected-headers="v1" From: Ryo Kato To: txauth@ietf.org Message-ID: Subject: [Txauth] Questions on key validations by RS --ITAUPgZvvNxxpaZUf9I2ROyggajOfbN63 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi, I'm reading the draft 04, and I have some questions now. The draft says: ``` The Resource Server (RS) accepts tokens from the RC and validates them ``` and also ``` Any keys presented by the RC to the AS or RS MUST be validated as part of= the transaction in which they are presented. ``` Therefore, I understand that the *RS* MUST validate the proof of possession of RC's keys when accepting tokens from the RC. (And I understand this procedure is for so called "sender-constrained token") However, I think it is a bit ambiguous about the way for *RS* to validate that keys. Assuming the `proof` parameter is `jwsd`, i.e. Detached JWS. The current draft 04 says: ``` the RC takes the serialized body of the request and signs it ``` Yes, RC's transaction (continuation) requests to AS are always HTTP POST requests, and their body is always a non-empty JSON object. Whereas, RC's requests to *RS* are not always POST, so they can be plain GET requests. Since GET request body is missing in general, the input for JWS will be missing too. In this case, what should we take for JWS instead of request body? - Ryo --ITAUPgZvvNxxpaZUf9I2ROyggajOfbN63-- --H6uxZvP7kE9b18LRYNm6opbFA33tJzdNL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEnJlYgt2Cez0rLM74Vm5mowltxNwFAl40ilMACgkQVm5mowlt xNyjqA/8CCEP5+nZIG4fKKlGGg83jsUQdmMwkC1eMXC3NztmNWmhoG8D9qsXXamq 0n1kkOng5i9J0U357e5L7lunZfYbHbzivATkvNd/5eCMnpYUFugUAPFAg/9rh4Ao ZX4jxT6HEL8T8gzylXREx7o+dX7sDSdAUi4man8CkuHyAmvQjPXrG0e/vtMGEhzu Av2BwIl5uXRDClM9nOUWdpdida97HGciH2eXpoOf0tcLEEpAaAlcONZ9cvnuz+M4 FdQ+u9cT/IQ7/Hem9fziJAjHXeJHvbCNzrty6jnrn3MT35EOrf6vRtb+KEeKw2xJ k0qbI38WSFwqY9Whp+++GZXFbShGVW2qLTbCoatM/h0UXiSvwFFXZiC+KiAnLcAP q8wLE+mHHZAaQt1LM8ubdXGrsHiqX+Zf0epNoXEZnuEnSs6xu762EFHhP0CHm0tg Y4c6kVRE/tHyrN1yhHK7t8Y70PfnEF5VZfZrx0C46qfzE1Bu1xTgyuCpFLLowaNB +M+7NJPgnmCK1aJ36BE8ZliIt7RJasGDzALoubDNT3QCmrPy0IkHj4M5B4z6vlcx IGmVbC8ZLRst/zbNHlBvwMlu9LF7qWwv3Cpqwd1o74IEYyy7mnyNFMnFv5KgMQj9 J5lS9zYbBbwouCzA//b1rLnuOncSIlY+fJTmIDLtawuDOs/JxhU= =pWqU -----END PGP SIGNATURE----- --H6uxZvP7kE9b18LRYNm6opbFA33tJzdNL-- From nobody Fri Jan 31 12:34: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 0CCA0120041 for ; Fri, 31 Jan 2020 12:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 cV9y3q7R_B_g for ; Fri, 31 Jan 2020 12:34:24 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0D3120020 for ; Fri, 31 Jan 2020 12:34:24 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id q8so8408765ljj.11 for ; Fri, 31 Jan 2020 12:34: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=odIt+CKgoZwVxm165lZ2LRiOC1CxX2BC4mJBivZ7p/o=; b=SkgogVSIqDZOU7n8rQLIW+/1w2Syjo0dueBAC03Cyzia8HFZoAwX0WV/eCQe0UHOdh ursMHbDeTYcXOnIW1CEnQ2KcwlBoM+Mmy/mwcDIZ6DB++u/nhXPKHLnYknxZlZ5E+Wy/ cZ8cBOIaMPFHIxExBHLh5Le5er7swsrmEPo8TUb/M7jMAhbLLbkte/1Bo1G5zM7jWW+v 3+MiTNGN85X8ldxY3hWhF9PThDfQ//ZXj7hbBarb6RRcI6VbgBooRH604x9Qp2ODY7rd K2AFfsFwjbrsk6mEOB6pOey48tK0dzoDCXnQxs5UIna+27NdiHYDSmS59ZF9lfMNjsDb 9Gvw== 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=odIt+CKgoZwVxm165lZ2LRiOC1CxX2BC4mJBivZ7p/o=; b=lmM7kNplOYHsu8RaKR2kGx2of3uJjDWde3DuyamWwH99p/vw+irdrPEktRLWoqNTts jzcItEPBT3YB39eKdyV0iT/W668SWI7ILwj7HmEurSVWWeTuKndbiA/lJrC7BOUq7jqW evNpovamRRZATKlGdGYl3tum4F4I/Msw5EpUz6F9NHXUbci3yLmJVxG2DW6c9DXwc8E4 /3BqMq9czEyN3ROjpMppN8x/yD/mN26tjxJPSfgMEsyXXMIFEJgTP+WTCcMPelgkIBmO G0sNRnbqDqB1Zzr//T1yfYkntNim359p3J/atEPYOGx/7HbWfHnOYnyYOK3mY4T0DGsi PggQ== X-Gm-Message-State: APjAAAW/lJZspYhJKNAfKNZWOhBpyL2F4kR9lG1l75ForipbJI1AbzeT 5PGjn77VILMR5f1MC1G4Qhsvm1urElASQ89P4/U= X-Google-Smtp-Source: APXvYqzEbD11/oUXN63AH0Lg43yPOEWuyZrZHOPvqOIv5W+ZbTET9Y8GS65xb8zmzOds2G+GF+brZPn0dHLdJ08gP8Y= X-Received: by 2002:a2e:84d0:: with SMTP id q16mr7102017ljh.138.1580502862093; Fri, 31 Jan 2020 12:34:22 -0800 (PST) MIME-Version: 1.0 References: <05467DBA-1B21-4F05-94EC-833C6E3FEBFB@mit.edu> <2E6A2343-3277-4090-AE7E-774158C08DB0@mit.edu> <67F6E009-99CB-4ABC-9EE9-28882D38929C@mit.edu> In-Reply-To: From: Dick Hardt Date: Fri, 31 Jan 2020 12:33:55 -0800 Message-ID: To: Justin Richer Cc: "rdd@cert.org" , Yaron Sheffer , txauth@ietf.org, Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000a962de059d757f69" Archived-At: Subject: Re: [Txauth] XAuth - a revision 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: Fri, 31 Jan 2020 20:34:27 -0000 --000000000000a962de059d757f69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Your statement below: Handles are opaque and AS-determined. Is not stated in XYZ, and seems in conflict with XYZ where some handles are SHA3: 9.1 . Presenting handles Bearer handles are presented by giving the exact string value of the handle in the appropriate place. SHA3 handles are validated by taking the SHA3 hash of the handle value and encoding it in Base64URL with no padding, and presenting the encoded value. 9.2 . Validating handles Bearer handles are validated by doing an exact byte comparison of the string representation of the handle value. SHA3 handles are validated by taking the SHA3 hash of the handle value and encoding it in Base64URL with no padding, and comparing that using an exact byte comparison with the presented value. Or are you saying the RC does not present the handle back, but presents back a SHA3 hash of the handle? I don't understand what value there is in doing the hash, as it is a reference to something in the AS, and the RC is always authenticating when presenting them. =E1=90=A7 On Fri, Jan 31, 2020 at 4:38 AM Justin Richer wrote: > Finishing a dangling sentence: > > > Part of the power of XYZ is that these handles have the same model in bot= h > cases =E2=80=94 the string is a reference to an object that could be pass= ed by > value as well. Flexibility in how these handles are created and > > > > =E2=80=A6 used is one of the benefits of XYZ=E2=80=99s model. Handles are= opaque and > AS-determined. The AS can make these in response to a runtime action or a > configuration/development time action. They can be random, they can be > hashes, they can even be structured (though in most cases that doesn=E2= =80=99t make > sense because you could just send the structured object instead). In all > cases, they=E2=80=99re serializable as a string and represent an object t= hat could > have been passed by value in their stead. The object that the handle > represents can change without changing the handle. Two different handles > could resolve to the same underlying object. Only the AS determines what > the handle maps to, in reality. > > =E2=80=94 Justin > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000a962de059d757f69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your statement below:

Handles are opaque and AS-de= termined.=C2=A0

Is not stated in XYZ,= and seems in conflict with XYZ where some handles are SHA3:

= 
9.1.  Presenting handles


   Bearer handles are presented by giving the exact string value of the
   handle in the appropriate place.

   SHA3 handles are validated by taking the SHA3 hash of the handle
   value and encoding it in Base64URL with no padding, and presenting
   the encoded value.

9.2. =
 Validating handles


   Bearer handles are validated by doing an exact byte comparison of the
   string representation of the handle value.

   SHA3 handles are validated by taking the SHA3 hash of the handle
   value and encoding it in Base64URL with no padding, and comparing
   that using an exact byte comparison with the presented value.

Or are you saying the RC does not present the handle b= ack, but presents back a SHA3 hash of the handle?

= I don't understand=C2=A0what value there is in doing the hash, as it is= a reference to something in the AS, and the RC is always authenticating wh= en presenting them.=C2=A0
3D""=E1=90=A7

<= div class=3D"gmail_quote">
On Fri, Jan= 31, 2020 at 4:38 AM Justin Richer <j= richer@mit.edu> wrote:
Finishing a danglin= g sentence:


Part of the power of XYZ is that these handles have th= e same model in both cases =E2=80=94 the string is a reference to an object= that could be passed by value as well. Flexibility in how these handles ar= e created and=C2=A0


=E2=80=A6 used is one of the benefits o= f XYZ=E2=80=99s model. Handles are opaque and AS-determined. The AS can mak= e these in response to a runtime action or a configuration/development time= action. They can be random, they can be hashes, they can even be structure= d (though in most cases that doesn=E2=80=99t make sense because you could j= ust send the structured object instead). In all cases, they=E2=80=99re seri= alizable as a string and represent an object that could have been passed by= value in their stead. The object that the handle represents can change wit= hout changing the handle. Two different handles could resolve to the same u= nderlying object. Only the AS determines what the handle maps to, in realit= y.=C2=A0

=C2=A0=E2=80=94 Justin
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000a962de059d757f69-- From nobody Fri Jan 31 14:29: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 750F412002E for ; Fri, 31 Jan 2020 14:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 a0IahcCco-lX for ; Fri, 31 Jan 2020 14:29:18 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450: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 8899A12004F for ; Fri, 31 Jan 2020 14:29:17 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id v201so5922030lfa.11 for ; Fri, 31 Jan 2020 14:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RpDciP4OIEP6lRaHbqrdVi1cZ4wg5NdUHzR+F2wm39g=; b=Mneq0OSOXsogDfJD4hDAe+E4WHNxGjzRuiT25ePGeVnd3e9q5gzRYRQ0yF4ixc4tvQ UZzHoQJEP3wTKEOESxWItsxW+H8EqLj3mNJzQVIX0XXpN5znYZ11KXnkc34/vJ76KhYA oEHkOLjd4NbMnXSmfxabt3net597QTRbpmPiK8xOIOvo0IEGFBLBHIwqDFDaqtXNpmiK G5BQM8H/pNoHAR6r9vXc/R2ZSliG8HnFCDJM/1dZONI1p4bcXQNgMvAy8vXEKbuwKJ3O ExONhKhGm/Fg2JC77511W37tuDi1t1auvekOTSod0XiB2CVu9/tp4c22+XG947UPg0mx DCzg== 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=RpDciP4OIEP6lRaHbqrdVi1cZ4wg5NdUHzR+F2wm39g=; b=CSn0B67LFC7KLg8Xl86sNbMJuvlvE1iVrNeheDiHIFKOh9tcg1mdXBQiuKMWX8uLyZ tk01TA86eOvO0ApMTbC6HW1hbXToN735bS/L6idWSsxejWSxsEjILL4+XHqKHAwiDzlA 38NGJXVQ+N0Hkek7YmgCFxY9XKkrIG2ZkTVRjlvIwOYb4Ujd+zKUJ7v5iAR/67hgNBps gNMqbUGI0jxlwAEtJE/WF2IMuZ0Hz23VE4YDLOGjP1eXtfj0KZ1w/Iey7SiYFWtwGeHn nnBUZCFdSOj390McPZBUdsRHlXh7M08OQ07Pv2K/u9qzha2gHZMVyxTMQsrpnYZJxcAB d1sQ== X-Gm-Message-State: APjAAAW0fpVg4cHnt688N+RR9UJUc2W8zru+bKC7hIuKTXSy5la8JNHB vLdTVCQih6AnI4mJeE9D++XU5NLvyJqNAqiTqdIsnK9Guks= X-Google-Smtp-Source: APXvYqz/XSlgRF0Fmke1UqyGrHRjW1SoeqwSYDPTtu3lDo9knQXCBZctFb075AFd5LKHwfOKTLabY0vtjKXANnkjLyM= X-Received: by 2002:ac2:46dc:: with SMTP id p28mr6510937lfo.23.1580509755322; Fri, 31 Jan 2020 14:29:15 -0800 (PST) MIME-Version: 1.0 References: <05467DBA-1B21-4F05-94EC-833C6E3FEBFB@mit.edu> <2E6A2343-3277-4090-AE7E-774158C08DB0@mit.edu> <67F6E009-99CB-4ABC-9EE9-28882D38929C@mit.edu> In-Reply-To: <67F6E009-99CB-4ABC-9EE9-28882D38929C@mit.edu> From: Dick Hardt Date: Fri, 31 Jan 2020 14:28:48 -0800 Message-ID: To: Justin Richer Cc: txauth@ietf.org, Benjamin Kaduk , "rdd@cert.org" , Yaron Sheffer Content-Type: multipart/alternative; boundary="00000000000087b7ee059d771a72" Archived-At: Subject: Re: [Txauth] XAuth - a revision 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: Fri, 31 Jan 2020 22:29:24 -0000 --00000000000087b7ee059d771a72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 31, 2020 at 3:22 AM Justin Richer wrote: > On Jan 30, 2020, at 11:13 PM, Dick Hardt wrote: > On Thu, Jan 30, 2020 at 1:05 AM Justin Richer wrote: > >> On Jan 30, 2020, at 12:25 AM, Dick Hardt wrote: >> >> On Wed, Jan 29, 2020 at 8:26 AM Justin Richer wrote: >> >>> I think XAuth has an interesting take on the problem space that TxAuth >>> is looking to solve, but in my opinion it generally veers too closely t= o >>> OAuth2/OIDC/JWT in its solution approach. >>> >> >> Reusing aspects of OAuth2/OIDC/JWT that are working fine for deployments >> will minimize the migration effort for them to take advantage of the >> security features of this work such as not using the redirect for passin= g >> parameters. I think XAuth supports the following clause of the current >> draft charter: "the group will attempt to simplify porting from OAuth 2.= 0 >> and OpenID Connect to the new protocol where possible.=E2=80=9D >> >> >> I understand the goals here, but I disagree that using the constructs as >> directly as they have been here is the most appropriate approach. >> > > Ok. I think we have reasonable clarity on the disagreement. > > >> >> >> >> >> >>> 1. XAuth removes =E2=80=9Chandles=E2=80=9D as stand-ins for various ele= ments. In XYZ, >>> the =E2=80=9Chandle=E2=80=9D concept is a key abstraction point with sp= ecific semantics. A >>> =E2=80=9Chandle=E2=80=9D is an identifier to a specific instantiation o= f a JSON object >>> structure. Using the =E2=80=9Chandle=E2=80=9D for Keys, for Resources, = and even the whole >>> Transaction lets you do a lot of core things in a parallel and reusable >>> way. XAuth re-invents a few of these as separate items, listed below, a= nd I >>> see this as a regression. >>> >> >> XAuth took the transaction handle and forked it into a completion handle >> and a refresh handle so that it is clear what the Client is wanting to >> happen. >> >> It was not clear the value of the other handles that were listed in XYZ. >> >> >> I think this may be that you misunderstood the purposes of the handles, >> as you=E2=80=99ve reinvented nearly all of them with different labels in= XAuth. :) >> > > I understand what a handle is, and what it represents. It appears that th= e > handles provide a reference to the display, resource, user, and key > objects. XYZ says the AS may issue those, but I could not find determine > when the AS sends them back to the RC. I understand the value of the > transaction handle XYZ, and built on that in XAuth, but XAuth always send= s > the display, resource, user and key information by value, not by referenc= e, > so your statement > > you=E2=80=99ve reinvented nearly all of them with different labels in XAu= th > > > is confusing. > > > I think what you=E2=80=99re missing is that the dynamically generated han= dles are > not the only handles in the system. > I did not understand that handles could be generated by the AS and hand configured, and had missed the sentence in Section 2 for each object that the RC can present a handle instead. The Client ID in most deployments is a handle by this definition. The AS generates it, and the Client presents it in future calls to represent all the Client information. My assumption is you did not want to call them identifiers, as you want to use the term handle everywhere, and make dynamic handles and static handles interchangeable. Correct? It is unclear what value a dynamic display, resource, user, or key handle has for a given transaction, as the information is all represented by your transaction handle. Static handles, and reusing a dynamic handle in a subsequent request allows a developer to pass by reference rather than value, but it is not clear what real benefit that provides over just passing the value. The transaction handle is different as it represents all the context the AS has for the transaction, which the Client does not have access to. All the other handles seem like they are just shorter version, and are more of an identifier. > What is broken with Client ID? What identifier are you proposing in XYZ? > > > I am proposing that the key information takes the place of the client ID > for all kinds of clients. As discussed below, the key handle is not a key > ID or a key hash =E2=80=94 but more on that in a bit. What=E2=80=99s impo= rtant is that it=E2=80=99s > an identifier that the AS can look at and ask itself, =E2=80=9CI=E2=80=99= ve seen this ID, > what authentication method and policy should I use for its requests?=E2= =80=9D This > is the first step in an OAuth 2 AS implementation, where the AS sees the > client ID and asks =E2=80=9Cwhat authentication method and policy should = I use for > this request?=E2=80=9D This is why I see the key handle =E2=80=94 and not= a higher level > construct like a client handle / client ID =E2=80=94 as the component tha= t you > would branch your decisions off of at the AS. Once I=E2=80=99ve validated= the key, > whether by value or by reference, I now know which client I=E2=80=99m tal= king to. I > don=E2=80=99t need a separate client identifier. > Got it. So far the Client ID and the key handle look to me to be the same for Registered Clients. What is the information referenced by a Client ID at the AS, that would NOT be referenced by a key handle? > I know that we don=E2=80=99t do it this way in OAuth 2, and I think that= =E2=80=99s a > limiting decision that we=E2=80=99ve gotten incorrect. > Use cases that are limited by that decision would help understand why you think it was incorrect. > > In the mental model of XYZ, the policy is then tied to whatever software > that key represents, and since keys aren=E2=80=99t shared between clients= , you get > the property of a unique identification system as well. For dynamic > clients, they don=E2=80=99t have to send an ID at all =E2=80=94 they send= the key itself by > value, since the ID won=E2=80=99t reference anything that the AS knows ab= out. > So we have an identifier for the clients that want a stable reference, a > method for passing values for clients that don=E2=80=99t have a stable re= ference, > and a clear way to upgrade from passing by value to passing by reference > for clients that want to do the equivalent of =E2=80=9CDynamic Registrati= on=E2=80=9D. There > are a number of deployments where DynReg is used :just: to give clients i= n > the field a client ID because OAuth 2 requires a client ID, and there=E2= =80=99s a > key that=E2=80=99s recognized during the DynReg process. But if the serve= r can > recognize my key, I ask: why not just start there when you do the request= ? > You can=E2=80=99t in OAuth 2 because of the redirect-first model and keys= don=E2=80=99t > even show up there. You can in TxAuth because the model allows the client > to talk to the AS directly first, and present its keys. > So calling it a key handle lets you call it the same thing for both Registered Clients and Dynamic Clients? The advantage to a Dynamic Client is that it can present a reference instead of its public key again on subsequent calls? Is there another advantage? The AS could also compute a fingerprint of the Dynamic Client key and use that as its ephemeral identifier for the Dynamic Client. > And it=E2=80=99s really important to know that handles do not need to mat= ch or be > derived from the information that they represent. > Yes. I understand what a handle is. =3D) > > No, my proposal is that a public key is what the AS uses to recognize a > preregistered client, and that public key can be represented by a handle.= I > would expect the handle to be stable over time, like a client ID, but mor= e > specific. > Which public key? XAuth describes how different instances of a Registered Client can have their own private key, so the matching public key is different for each Client instance. The Client can have a certificate signed by a private key matching the public key registered for the Client at the As. > > In OAuth 2, the client ID wraps together all of the different aspects of > the client and its associated policies. In XYZ, I sought to separate thos= e > into different handles because, as we=E2=80=99ve found in OAuth 2, differ= ent parts > of the client system can vary over time. Our notion of what a =E2=80=9Ccl= ient=E2=80=9D is > in OAuth 2 is also pretty vague. We have developers all over the place > sharing client IDs between different web servers (production and > development environments, for example), different instances of software > (mobile applications, SPAs, and =E2=80=9Cpublic=E2=80=9D clients), and di= fferent pieces of > software altogether (micro-components that are tied together in a single > pseudo-app). > I don't think it is vague. The "client" is not a specific piece of software. From the User or RS's perspective, it is the "service" that was provided the identity claims and/or authorization. They don't want to have to re-authorize as they move between a mobile client, a desktop client, or a web client for the same service. What is clearly problematic is sharing the client secret across all of these places. Implementations I have worked on have centralized the client secret in one place, and then handed out the access token to the software component for it to directly call the RS. As I discussed above, certificates let a complex Client have each component independently make calls to the AS. > And we also have the explosion of Client IDs for apps using DynReg for > things like ephemeral instances that get used once and then stop existing= . > As we have discussed, Client IDs for Dynamic Clients is problematic. The only information an AS has about a Dynamic Client is what it has done with the Client previously. Note that a mobile app can be a Dynamic Client, and have a long lifetime. > The AS would return interaction responses that are the intersection of: >> >> - methods the client indicates it can do in the request >> - methods the AS knows it can support >> - methods allowed by the policy governing the request >> >> I don=E2=80=99t understand the second part of this question, because the= AS still >> =E2=80=9Csupports the one the client wants to use=E2=80=9D in the XYZ mo= del. >> > > I'm looking for a use case where the AS needs to select from a list, > rather than use the one mechanism that the Client wants to use. Why the > extra negotiation? > > > The AS isn=E2=80=99t selecting a single value from the list. It=E2=80=99s= responding to > what the client wants to use, and it could respond to all of them. If the > client wants to use one mechanism, it sends only one mechanism. XYZ enabl= es > all of the functions of XAuth=E2=80=99s interaction methods, and then som= e. > I understand how it works, and that it is more powerful. It is also more complex. What does practical value does this provide an implementor? > > > >> >> As for a concrete example, look at how we handle the =E2=80=9Cqrcode=E2= =80=9D interaction >> case, based on OAuth 2=E2=80=99s device flow. In this, you want to send = a URI to >> the client that it can render as a QR code as well as a code that the us= er >> can type into a page, in case they can=E2=80=99t scan the QR code. OAuth= 2 manages >> this by having a user code as well as a pre-composed URL containing the >> code to be used for rendering. XYZ used to have a mode for this similar = to >> XAuth, but we realized that we could describe this using two separate >> flags: >> >> - I can communicate a short code that the user can type in at a static >> URL >> - I can get the user to go to an arbitrary URL >> >> The second one is the same mechanism we can use for redirect-based auth. >> > > I got that. I thought being more crisp in the interaction makes it easier > for implementors to understand. > > > I don=E2=80=99t think it=E2=80=99s more crisp, I think it=E2=80=99s more = limiting, and it leads to > more confusing code paths. Having implemented both styles in XYZ in sever= al > languages, I vastly prefer the current XYZ style. > It is more crisp. And it is more limiting, and I think it leads to simpler code paths. > > When you have the =E2=80=9Ctype=E2=80=9D field, you then have to specify = what different > responses mean in the context of different types, like what XAuth does in > =C2=A74.2. In XYZ, the response fields have a single meaning, and the cli= ent > does what it can with them. I think it=E2=80=99s presumptuous to assume = =E2=80=9Cqrcode=E2=80=9D as > a scannable format, for instance. > A QR Code is a scannable format by definition. > Does the AS actually care how the client communicates the URL to the user= ? > Not really. > As I noted in XAuth, the AS does care. While a really long URL works fine in a redirect or popup, it does not work in a QR code. The AS can return a short URL for the QR code that redirects to the long URL. The AS does not want to impose the redirect latency on the redirect or popup. > Even if we were to optimize this for the client and have the AS return an > image instead of a URL, I think the AS should be able to return an > arbitrary image for the client to display to the user. > In XAuth I asked if we wanted to allow the Client to over a webview for the AS to load whatever it wants. Additionally, since we are designing all of this to be extensible, if another use case comes up with a different interaction method, we can just add a new type. > > > > >> >> >> In the case where the AS interacts with an RO that is not the User, ther= e >> would be nothing the Client would need to do. Perhaps there is a use cas= e >> for something different? If so, please elaborate. >> >> >>> >>> 4. XAuth allows OAuth-style scopes next to RAR-style data structures >>> (and next to OIDC claims structures). They are treated as completely >>> separate from each other. In OAuth 2, RAR is defined in the context of >>> scope (and resource and audience and other parameters), and this >>> combination is a matter of some debate still that needs to be solved. >>> However, it=E2=80=99s clear that they=E2=80=99re combined. In XYZ, the = only resource >>> request defined is the object inside the resource request. You can mimi= c >>> =E2=80=9Cscope=E2=80=9D behavior by using a Resource Handle, which agai= n is defined as a >>> single string that stands in for the whole object and could be defined = by >>> the AS (or the API it=E2=80=99s protecting). >>> >> >> I think you need to reread the 00 draft. Only one type of authorization >> request is allowed. >> >> - OAuth style for deployments where that works fine. >> - RAR style for deployments that need the extra granularity of RAR >> - list of RAR style for deployments that support multiple resource >> servers that require independent access tokens. >> >> >>> >>> 5. The different kinds of authz requests in (4) create separate >>> tokens.This is very different from both OAuth 2 and XYZ, where you get = back >>> a single access token. And in XAuth there is no way to get, for example= , >>> two access tokens that are both described by RAR requests, so this seem= s >>> like a very arbitrary and syntactically-driven separation. >>> >> >> I don't think you understood what is in the draft. See above. >> >> >> Apologies on these points =E2=80=94 I didn=E2=80=99t catch that this had= changed from the >> earlier drafts. >> > > We can scratch this concern from the list then. Yeah! > > > Well, kind of =E2=80=94 XAuth doesn=E2=80=99t allow the combination of an= API-specified > element (a scope, a simple string value) and a more fine grained access > request. > I don't think you went back to reread -00. The oauth-rich type includes a scope, and an authorizations_details. I made that change as it was not clear when I looked at RAR (which is still developing) that it did not include the scope. > Yes. I think freedom from having to make a choice makes things easier to > implement and deploy. > For deployments where another mechanism will be significantly better, the > choice is available. =E2=80=98 > > > These statements contradict each other. Are you advocating for =E2=80=9Cf= reedom > from choice=E2=80=9D or that the =E2=80=9Cchoice is available=E2=80=9D fo= r this particular feature? > I am arguing in favor of making choice available in the case of key > presentation and removing choice in terms of request format (as in, the > core payload). > Freedom from choice: if I don't want to have to make a choice, the choice is made. These are frequently called defaults. They have proven useful. =3D= ) Stated another way: here is what you do unless you have a good reason to do something else. While I think JOSE is a better default, I'm open to another method being a default. I do strongly think there should be a default. > > > Is there something about JOSE that you think is problematic to make it th= e > default? > > > Yes, it leads to reliance on putting everything of note in the JOSE > payload as part of the base protocol. > In XAuth, I factored out all the JOSE. Once again, have you read -00, or -01? https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-3 All payloads are JSON. The JOSE section describes how to use JOSE for message and header signing. https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-8 > As explained previously, I want to be able to use HTTP as more than an > entity body carrier. We should be using headers and methods and URLs =E2= =80=94 and > importantly, content types. > I agree. XAuth uses POST, GET and DELETE It uses the Authorization header and different parameters to indicate the type of token. It uses content type to indicate what the content type is. This will assist an AS that supports multiple Client authentication methods > I think JOSE should be switched with things like Content-Type headers and > Accept headers, and that JSON bodies should be the default as they=E2=80= =99re more > universal across different signing and presentation mechanisms. > > My Java XYZ implementation does use JOSE, but by using JWS in a detached > fashion to sign the body instead of an internal fashion. The reason for > this is that it allows the request and response to be =E2=80=9Capplicatio= n/json=E2=80=9D > and not =E2=80=9Capplication/jws=E2=80=9D. > Detached signatures work, but I have found them to be problematic in practice, which is why I chose "application/jws". There is no canonical form for JSON, so it can get modified, and still be valid JSON, but the signature does not match. Passing around the signature independent of the payload is more complex. A JWS can be easily passed between components and is self contained, with no worries that the JSON was modified by parsing and re-serializing it. > > In all of these cases, I do not think it is a good idea to use JWT claims > in the TxAuth request or response namespaces. Where we use JOSE, we shoul= d > avoid JWT. > I agree. JWT is good for claims. Not so good messages. > > I still agree that they should be able to easily use TxAuth, which just a > stronger argument for the signature/proofing mechanism to be a pluggable > thing and that the request/response bodies not be JOSE objects but JSON > objects. > We discussed this in early drafts, and XAuth is JSON, with JOSE added on. > > The word transaction is muddying what I think you are suggesting here. It > more like a conversation. Transactions from a DB point of view are a set = of > actions that all happen, or none happen. > > > I=E2=80=99ve explained previously that the database interpretation is not= the only > or full interpretation of the word =E2=80=9Ctransaction=E2=80=9D here, so= I won=E2=80=99t go back > into it. Conversation is perhaps more accurate, but =E2=80=9CCxAuth=E2=80= =9D is a > problematic acronym. :-D > Naming is hard. =3D) > > > >> >> Both continuation and refresh are saying to the AS =E2=80=9Crun this tra= nsaction >> again and if I can get a token (or claims or whatever) in its current >> state, give me that=E2=80=9D. However, they can=E2=80=99t really exist a= t the same time, so >> having two separate items to ask the same question doesn=E2=80=99t make = much sense. >> > > They have different purposes. The completion (now authorization) handle i= s > to check if the AS is done with its request processing, and if so, provid= e > the results, which includes zero or more identity claims, and zero or mor= e > access tokens/handles. > > The refresh handle is to refresh a specific access token/handle. > > > I don=E2=80=99t see these as being different, and that=E2=80=99s where we= disagree. The > access token is the end result of the processing. Refreshing is an act of > continuing that processing. I do not see a good argument for treating the= m > separately. > Developers are already familiar with refreshing a token > > > >> >> >> I think a transaction handle is to course grained. I don't think that th= e >> AS should be returning all the claims in a refresh. And if there are >> multiple access tokens returned from the AS, then each has their own >> refresh handle. >> >> >> I think this requires a deeper discussion, since the whole idea of >> multiple access tokens is a very different kind of approach here. >> > > It is a feature of XAuth. > > > Kind of. XAuth allows multiple access tokens in one limited context, and > only when using rich authorization requests to do so. > Given that existing implementations using scopes only support one access token, it did not seem limiting to only have a oauth_rich_list, particularly since a RAR request is a superset of functionality of a scope request. > I would rather see us have a general mechanism that allows us to get > multiple access tokens in a way that=E2=80=99s parallel to how you get on= e access > token. > A general mechanism sounds fine and dandy. Currently we don't have other ways to request authorization except for oauth scopes and RAR, which is a super set of RAR. If and when we need a more general mechanism, we could define a new type. > > > In OAuth today, the bearer token is like a movie ticket. Whoever has the > movie ticket gets in the movie. > Using OAuth to obtain a bearer token is like buying a movie ticket. > > Sometimes I want to go to more than one movie. OAuth today makes me wait > in line to buy each ticket. Why not let me buy multiple tickets at once? > > > That=E2=80=99s not true. You can get one ticket that=E2=80=99s good for t= wo movies, to > borrow your metaphor. > Which is all you can do in OAuth today. Get one ticket. > > The semantics of requesting multiple access tokens in parallel is > something the working group might want to consider. I am not a fan of how > XAuth handles this, with packing things into the authorization list. I > think it=E2=80=99s a concept we should consider though. > If you have other ideas, please share them! To elaborate on my metaphor. A family is going to the movies. The Father (one component of the family), is going to purchase tickets. Billy (age 8) can pick from the G rated movies. Sally (age 15) can pick from G, PG, and PG-13 movies, and Father can pick anything. Father does not want to buy 3 tickets that are identical and can work for any movie. (effectively what an access token is today) He only wants them to go to a movie he has approved, at the time he has selected. Father wants to buy 3 different tickets, and give the appropriate ticket to each child. The metaphor breaks down here, but each child needs to be able to refresh their ticket independent of the other's, which is why a refresh handle is required. The transaction handle is not granular enough. > > > >> >> I see refresh much as it is in OAuth2 and UMA, where it refers to the >> authorization that was granted. This means that you can do downscoping t= o >> get lower-powered access tokens that are a subset of the overall grant, = and >> I think that TxAuth should be able to do a step-up auth where you can bu= ild >> some additional request on top of an existing approval. >> > > Is "step-up auth" authentication or authorization, ... or both? > > > I think the question you asked is unintentionally misleading because =E2= =80=9Cstep > up=E2=80=9D authentication could be seen from the client or the AS=E2=80= =99s perspective. > Well, your statement was unclear as "auth" can be one or the other! From below, you intended authorization. > > The =E2=80=9Cstep up=E2=80=9D that I mean here is from the client=E2=80= =99s perspective, not from > the AS/IdP=E2=80=99s perspective. The client wants more of something =E2= =80=94 more access > to an API, more user information, etc. It=E2=80=99s likely that the AS is= going to > want to interact with the user to include whatever additional access the > client is asking for, but the client doesn=E2=80=99t want to start from s= cratch. > You=E2=80=99ve got a ticket that=E2=80=99s good to see one movie, and you= want to add > another movie to it for after. The theater already knows who you are and > how to get your money, so they can just add it on. > > It=E2=80=99s entirely feasible that the process of asking for more inform= ation > would prompt the AS to re-authenticate the user, including prompting them > for additional credentials. However, from the client=E2=80=99s view, that= =E2=80=99s a > side-effect of its request. > The step-up authentication is a policy decision independent of the Client. The User is having to provide additional authorization. > Remembering user consent and delivering claims are two completely separat= e >> problems and should not be conflated here. I was addressing the former. >> > > They are related though. If you are not wanting to ask for consent on eac= h > delivery, how do you know you have consent? > > > We are talking past each other. They=E2=80=99re related in the sense that= they=E2=80=99re > both a part of the authorization process, but consenting to the release o= f > information and the delivery of that information are completely separate > from each other. > Consent is required to release the information. That is how they are related. > > Consent is not the client=E2=80=99s policy, that=E2=80=99s the AS=E2=80= =99s policy. My consent is > stored on the AS. > Maybe. Maybe not. > The client can't know if this is the =E2=80=9Cfirst=E2=80=9D time or not = because it > doesn=E2=80=99t know who I am yet, so it can=E2=80=99t ask if I should co= nsent again. If > the client knows who I am, it doesn=E2=80=99t need to ask the AS to log m= e in in > the first place. > Did you spend anytime looking at my "authentication first" proposal in -01? The Client asks the AS to authenticate the User, and send that result, then the Client can decide what, if anything it wants to request for that User. The AS no longer needs to maintain state. > > However, once I=E2=80=99m interacting with the AS, the AS has a chance of= figuring > things out. The AS can determine if it=E2=80=99s seen the same client bef= ore, if > it=E2=80=99s seen the same user before, and if the same client is making = the same > request for the same user, and the AS knows that it can make that decisio= n > without prompting the user. We already do exactly this today with OAuth 2 > and OIDC systems. > Sometimes. Sometimes not. The specifications are mute on saving state. > > But the AS does :not: know which profile and identity claims the client > actually :needs:. The only party able to make that decision is the client= , > and it can only make that decision once it has a reference to which user = is > there (in terms of an identifier). The AS can (and I argue should) give t= he > client some kind of key for helping make that decision. > > The push of user information into an OAuth-protected API, and separating > it from the authentication context, is one of the best parts of OpenID > Connect. Yes, the client can always request the user info as long as it h= as > the access token =E2=80=94 and to me that=E2=80=99s a feature, because th= e client is the > component that knows when it needs updated info. > This is where consent and delivery are related. If the user info has been updated, has the User provided consent for the Client to receive it? The AS is the endpoint that can interact with the user, not the UserInfo endpoint. Why not just go back to the AS and ask for the data again. If consent is not required, the AS returns the data. If consent is required, the AS can interact with the User to get it. The UserInfo endpoint seems redundant if the Client can get the claims from the AS. > > > >> >> >> Your comments have inspired me on a solution that can be done with XAuth >> (or XYZ) that can't be done with OAuth 2.0/OIDC. >> >> I'll add that to the XAuth draft and publish it. >> >> >>> >>> 11. XAuth defines an explicit discovery step because the client now >>> needs to know several things about the server. The mix-up attack and a = few >>> other attacks in OAuth 2 stem from this kind of process. In XYZ, the cl= ient >>> really only needs to know the transaction endpoint URL and it learns >>> everything else from that point. Yes, the client needs to discover that >>> someplace =E2=80=94 but it was a deliberate decision in limiting the am= ount of >>> upfront information that the client needs to get started. >>> >> >> That is still discovery, is it not? >> >> >> I literally just called it that in the sentence above, so yes. :) What >> you=E2=80=99re discovering is different though. And doesn=E2=80=99t the = client still need >> to =E2=80=9Cdiscover=E2=80=9D the discovery endpoint in XAuth? >> > > What discovery endpoint? > > > The charter currently includes =E2=80=9CAS discovery=E2=80=9D, per your r= equest to add it. > To me, and I would argue to most, =E2=80=9Cdiscovery=E2=80=9D is a progra= mmatic process. If > it=E2=80=99s manual, it=E2=80=99s not really the client =E2=80=9Cdiscover= ing=E2=80=9D anything, it=E2=80=99s being > told things manually by a developer. That=E2=80=99s not discovery as the = term is > generally known, and I think this is a key source of confusion here. Ther= e > is no =E2=80=9Cdiscovery=E2=80=9D that=E2=80=99s not programmatic =E2=80= =94 that=E2=80=99s configuration. > I think of discovery is going to the AS and learning what it can do -- since discovery is learning. That can be the developer going to the AS docs and reading, or the Client calling a discovery API. After manual discovery, the developer decides how to manually configure the Client, based on what was discovered when reading the documentation. I have found it useful to call out the manual discovery so that implementors know where the information comes from. IE it is not in the specification. =E1=90=A7 --00000000000087b7ee059d771a72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 31, 2020 at 3:22 AM Justi= n Richer <jricher@mit.edu> wro= te:
On Jan 30, 20= 20, at 11:13 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
On Thu,= Jan 30, 2020 at 1:05 AM Justin Richer <jricher@mit.edu> wrote:
On Jan 30, 2020, at 12:25 AM, Dick= Hardt <dick.h= ardt@gmail.com> wrote:
On Wed, Jan 29, 2020 at 8:26 AM Justin Richer <jricher@mit.edu> wrote:
I think XAut= h has an interesting take on the problem space that TxAuth is looking to so= lve, but in my opinion it generally veers too closely to OAuth2/OIDC/JWT in= its solution approach.

= Reusing aspects of OAuth2/OIDC/JWT that are working fine for deployments wi= ll minimize the migration effort for them to take advantage of the security= features of this work such as not using the redirect for passing parameter= s. I think XAuth supports the following clause of the current draft charter= : "the group will=C2=A0attempt to simplify porting from OAuth 2.0 and = OpenID Connect to the new protocol where possible.=E2=80=9D

I un= derstand the goals here, but I disagree that using the constructs as direct= ly as they have been here is the most appropriate approach.

Ok. I think we have reasonable clarity o= n the disagreement.
=C2=A0


<snip>
=C2=A0
1. XAuth removes =E2=80=9Chandles=E2=80=9D as stand-i= ns for various elements. In XYZ, the =E2=80=9Chandle=E2=80=9D concept is a = key abstraction point with specific semantics. A =E2=80=9Chandle=E2=80=9D i= s an identifier to a specific instantiation of a JSON object structure. Usi= ng the =E2=80=9Chandle=E2=80=9D for Keys, for Resources, and even the whole= Transaction lets you do a lot of core things in a parallel and reusable wa= y. XAuth re-invents a few of these as separate items, listed below, and I s= ee this as a regression.

= XAuth took the transaction handle and forked it into a completion handle an= d a refresh handle so that it is clear what the Client is wanting to happen= .

It was not clear the value of the other handles = that were listed in XYZ.=C2=A0

I think this may be that you misu= nderstood the purposes of the handles, as you=E2=80=99ve reinvented nearly = all of them with different labels in XAuth. :)

I understand what a handle is, and what it represents= . It appears that the handles provide a reference to the display, resource,= user, and key objects. XYZ says the AS may issue those, but I could not fi= nd determine when the AS sends them back to the RC. I understand the value = of the transaction handle XYZ, and built on that in XAuth, but XAuth always= sends the display, resource, user and key information by value, not by ref= erence, so your statement=C2=A0

you=E2=80=99ve reinvented nearly all of them with different label= s in XAuth

is confusing.

I think what you=E2=80=99re missing is= that the dynamically generated handles are not the only handles in the sys= tem.

I did not understand= that handles could be generated by the AS and hand configured, and had mis= sed the sentence in Section 2 for each object that the RC can present a han= dle instead.

The Client ID in most deployments is = a handle by this definition. The AS generates it, and the Client presents i= t in future calls to represent all the Client information.

My assumption is you did not want to call them identifiers, as you= want to use the term handle everywhere, and make dynamic handles and stati= c handles interchangeable. Correct?

It is unclear = what value a dynamic display, resource, user, or key handle has for a given= transaction, as the information is all represented by your transaction han= dle.=C2=A0

Static handles, and reusing a dynamic h= andle in a subsequent request allows a developer to pass by reference rathe= r than value, but it is not clear what real benefit that provides over just= passing the value.=C2=A0

The transaction handle i= s different as it represents all the context the AS has for the transaction= , which the Client does not have access to. All the other handles seem like= they are just shorter version, and are more of an identifier.
=C2=A0
=
What is broken with Client I= D? What identifier are you proposing in XYZ?
=

I am proposing that the key information takes the place= of the client ID for all kinds of clients. As discussed below, the key han= dle is not a key ID or a key hash =E2=80=94 but more on that in a bit. What= =E2=80=99s important is that it=E2=80=99s an identifier that the AS can loo= k at and ask itself, =E2=80=9CI=E2=80=99ve seen this ID, what authenticatio= n method and policy should I use for its requests?=E2=80=9D This is the fir= st step in an OAuth 2 AS implementation, where the AS sees the client ID an= d asks =E2=80=9Cwhat authentication method and policy should I use for this= request?=E2=80=9D This is why I see the key handle =E2=80=94 and not a hig= her level construct like a client handle / client ID =E2=80=94 as the compo= nent that you would branch your decisions off of at the AS. Once I=E2=80=99= ve validated the key, whether by value or by reference, I now know which cl= ient I=E2=80=99m talking to. I don=E2=80=99t need a separate client identif= ier.

Got it.
So far the Client ID and the key handle look to me to be the s= ame for Registered Clients. What is the information referenced by a Client = ID at the AS, that would NOT be referenced by a key handle?
=C2= =A0
I know that we don=E2=80=99t do it thi= s way in OAuth 2, and I think that=E2=80=99s a limiting decision that we=E2= =80=99ve gotten incorrect.

Use cases that are limited by that decision would help understand why you= think it was incorrect.=C2=A0
=C2=A0
=

In the mental model of XYZ, the policy is then tied to = whatever software that key represents, and since keys aren=E2=80=99t shared= between clients, you get the property of a unique identification system as= well. For dynamic clients, they don=E2=80=99t have to send an ID at all = =E2=80=94 they send the key itself by value, since the ID won=E2=80=99t ref= erence anything that the AS knows about.
So we have an identifier for the clients that want = a stable reference, a method for passing values for clients that don=E2=80= =99t have a stable reference, and a clear way to upgrade from passing by va= lue to passing by reference for clients that want to do the equivalent of = =E2=80=9CDynamic Registration=E2=80=9D. There are a number of deployments w= here DynReg is used :just: to give clients in the field a client ID because= OAuth 2 requires a client ID, and there=E2=80=99s a key that=E2=80=99s rec= ognized during the DynReg process. But if the server can recognize my key, = I ask: why not just start there when you do the request? You can=E2=80=99t = in OAuth 2 because of the redirect-first model and keys don=E2=80=99t even = show up there. You can in TxAuth because the model allows the client to tal= k to the AS directly first, and present its keys.=C2=A0


So calling it a key hand= le lets you call it the same thing for both Registered Clients and Dynamic = Clients? The advantage to a Dynamic Client is that it can present a referen= ce instead of its public key again on subsequent calls? Is there another ad= vantage?

The AS could also compute a fingerprint o= f the Dynamic Client key and use that as its ephemeral identifier for the D= ynamic Client.
=C2=A0=C2=A0
And = it=E2=80=99s really important to know that handles do not need to match or = be derived from the information that they represent.

Yes. I understand what a handle is. =3D)
= =C2=A0

No, my proposal is th= at a public key is what the AS uses to recognize a preregistered client, an= d that public key can be represented by a handle. I would expect the handle= to be stable over time, like a client ID, but more specific.=C2=A0

Which public key?=C2=A0 XAuth de= scribes how different instances of a Registered Client can have their own p= rivate key, so the matching public key is different for each Client instanc= e. The Client can have a certificate signed by a private key matching the p= ublic key registered for the Client at the As.=C2=A0
=C2=A0
=

In OAuth 2, the client ID wraps t= ogether all of the different aspects of the client and its associated polic= ies. In XYZ, I sought to separate those into different handles because, as = we=E2=80=99ve found in OAuth 2, different parts of the client system can va= ry over time. Our notion of what a =E2=80=9Cclient=E2=80=9D is in OAuth 2 i= s also pretty vague. We have developers all over the place sharing client I= Ds between different web servers (production and development environments, = for example), different instances of software (mobile applications, SPAs, a= nd =E2=80=9Cpublic=E2=80=9D clients), and different pieces of software alto= gether (micro-components that are tied together in a single pseudo-app).

I don't think it is vag= ue. The "client" is not a specific piece of software. From the Us= er or RS's perspective, it is the "service" that was provided= the identity claims and/or authorization. They don't want to have to r= e-authorize as they move between a mobile client, a desktop client, or a we= b client for the same service.

What is clearly pro= blematic is sharing the client secret across all of these places. Implement= ations I have worked on have centralized the client secret in one place, an= d then handed out the access token to the software component for it to dire= ctly call the RS.

As I discussed above, certificat= es let a complex Client have each component independently make calls to the= AS.=C2=A0=C2=A0
=C2=A0
And we a= lso have the explosion of Client IDs for apps using DynReg for things like = ephemeral instances that get used once and then stop existing.=C2=A0
<= /div>

As we have discussed, Client ID= s for Dynamic Clients is problematic. The only information an AS has about = a Dynamic Client is what it has done with the Client previously. Note that = a mobile app can be a Dynamic Client, and have a long lifetime.
= =C2=A0
The AS would return interaction responses that ar= e the intersection of:

=C2=A0- methods the client = indicates it can do in the request
=C2=A0- methods the AS knows i= t can support
=C2=A0- methods allowed by the policy governing the= request

I don=E2=80=99t understand the second par= t of this question, because the AS still =E2=80=9Csupports the one the clie= nt wants to use=E2=80=9D in the XYZ model.

I'm looking for a use case where the AS needs to sele= ct from a list, rather than use the one mechanism that the Client wants to = use. Why the extra negotiation?
The AS isn=E2=80=99t selecting a single value from the list. I= t=E2=80=99s responding to what the client wants to use, and it could respon= d to all of them. If the client wants to use one mechanism, it sends only o= ne mechanism. XYZ enables all of the functions of XAuth=E2=80=99s interacti= on methods, and then some.

I understand how it works, and that it is more powerful. It is also more = complex. What does practical value does this provide an implementor?<= div>=C2=A0

=C2=A0

As for a co= ncrete example, look at how we handle the =E2=80=9Cqrcode=E2=80=9D interact= ion case, based on OAuth 2=E2=80=99s device flow. In this, you want to send= a URI to the client that it can render as a QR code as well as a code that= the user can type into a page, in case they can=E2=80=99t scan the QR code= . OAuth 2 manages this by having a user code as well as a pre-composed URL = containing the code to be used for rendering. XYZ used to have a mode for t= his similar to XAuth, but we realized that we could describe this using two= separate flags:=C2=A0

=C2=A0- I can communicate a= short code that the user can type in at a static URL
=C2=A0- I c= an get the user to go to an arbitrary URL

The seco= nd one is the same mechanism we can use for redirect-based auth.=C2=A0

I got that. I thought being m= ore crisp in the interaction makes it easier for implementors to understand= .=C2=A0

I don=E2=80= =99t think it=E2=80=99s more crisp, I think it=E2=80=99s more limiting, and= it leads to more confusing code paths. Having implemented both styles in X= YZ in several languages, I vastly prefer the current XYZ style.=C2=A0
=

It is more crisp. And it is mo= re limiting, and I think it leads to simpler code paths.

=C2=A0

When you have = the =E2=80=9Ctype=E2=80=9D field, you then have to specify what different r= esponses mean in the context of different types, like what XAuth does in = =C2=A74.2. In XYZ, the response fields have a single meaning, and the clien= t does what it can with them. I think it=E2=80=99s presumptuous to assume = =E2=80=9Cqrcode=E2=80=9D as a scannable format, for instance.
<= /div>

A QR Code is a scannable format by de= finition.
=C2=A0
Does the AS actu= ally care how the client communicates the URL to the user? Not really.

As I noted in XAuth, the AS = does care. While a really long URL works fine in a redirect or popup, it do= es not work in a QR code. The AS can return a short URL for the QR code tha= t redirects to the long URL. The AS does not want to impose the redirect la= tency on the redirect or popup.
=C2=A0
Even if we were to optimize this for the client and have the AS retur= n an image instead of a URL, I think the AS should be able to return an arb= itrary image for the client to display to the user.=C2=A0
=

In XAuth I asked if we wanted to allow the= Client to over a webview for the AS to load whatever it wants.
<= br>
Additionally, since we are designing all of this to be extens= ible, if another use case comes up with a different interaction method, we = can just add a new type.
=C2=A0


=C2=A0


In the case where the AS i= nteracts with an RO that is not the User, there would be nothing the Client= would need to do. Perhaps there is a use case for something different? If = so, please elaborate.
=C2=A0

4. XAuth allows OAuth-= style scopes next to RAR-style data structures (and next to OIDC claims str= uctures). They are treated as completely separate from each other. In OAuth= 2, RAR is defined in the context of scope (and resource and audience and o= ther parameters), and this combination is a matter of some debate still tha= t needs to be solved. However, it=E2=80=99s clear that they=E2=80=99re comb= ined. In XYZ, the only resource request defined is the object inside the re= source request. You can mimic =E2=80=9Cscope=E2=80=9D behavior by using a R= esource Handle, which again is defined as a single string that stands in fo= r the whole object and could be defined by the AS (or the API it=E2=80=99s = protecting).=C2=A0

I thin= k you need to reread the 00 draft. Only one type of authorization request i= s allowed.

- OAuth style for deployments where tha= t works fine.
- RAR style for deployments that need the extra gra= nularity of RAR
- list of RAR style for deployments that support = multiple resource servers that require independent access tokens.
=C2=A0

5. The different kinds of authz requests in (4) creat= e separate tokens.This is very different from both OAuth 2 and XYZ, where y= ou get back a single access token. And in XAuth there is no way to get, for= example, two access tokens that are both described by RAR requests, so thi= s seems like a very arbitrary and syntactically-driven separation.=C2=A0

I don't think you under= stood what is in the draft. See above.
<= /div>

Apologies on these points= =E2=80=94 I didn=E2=80=99t catch that this had changed from the earlier dr= afts.=C2=A0

We can scratc= h this concern from the list then. Yeah!

Well, kind of =E2=80=94 XAuth doesn=E2=80=99t allow t= he combination of an API-specified element (a scope, a simple string value)= and a more fine grained access request.

I don't think you went back to reread -00. The oauth-r= ich type includes a scope, and an authorizations_details.=C2=A0
<= br>
I made that change as it was not clear when I looked at RAR (= which is still developing) that it did not include the scope.
=C2= =A0
Yes. I think freedom from having to mak= e a choice makes things easier to implement and deploy.=C2=A0
For= deployments where another mechanism will be significantly better, the choi= ce is available. =E2=80=98

These statements contradict each other. Are you advocating for =E2= =80=9Cfreedom from choice=E2=80=9D or that the =E2=80=9Cchoice is available= =E2=80=9D for this particular feature? I am arguing in favor of making choi= ce available in the case of key presentation and removing choice in terms o= f request format (as in, the core payload).=C2=A0

Freedom from choice: if I don't want to have t= o make a choice, the choice is made. These are frequently called defaults. = They have proven useful. =3D)

Stated another way: = here is what you do unless you have a good reason to do something else.=C2= =A0

While I think JOSE is a better default, I'= m open to another method being a default. I do strongly think there should = be a default.
=C2=A0


Is there something about JOSE that you think is problematic to make = it the default?

Yes= , it leads to reliance on putting everything of note in the JOSE payload as= part of the base protocol.

<= div>In XAuth, I factored out all the JOSE. Once again, have you read -00, o= r -01?


All payloads= are JSON. The JOSE section describes how to use JOSE for message and heade= r signing.

=C2=A0
As explained previously, I want to be able to use HTTP as m= ore than an entity body carrier. We should be using headers and methods and= URLs =E2=80=94 and importantly, content types.

I agree.=C2=A0

XAuth uses = POST, GET and DELETE

It uses the Authorization hea= der and different parameters to indicate the type of token.
It us= es content type to indicate what the content type is. This will assist an A= S that supports multiple Client authentication methods=C2=A0
=C2= =A0
I think JOSE should be switched with th= ings like Content-Type headers and Accept headers, and that JSON bodies sho= uld be the default as they=E2=80=99re more universal across different signi= ng and presentation mechanisms.=C2=A0

My Java XYZ = implementation does use JOSE, but by using JWS in a detached fashion to sig= n the body instead of an internal fashion. The reason for this is that it a= llows the request and response to be =E2=80=9Capplication/json=E2=80=9D and= not =E2=80=9Capplication/jws=E2=80=9D.=C2=A0

Detached signatures work, but I have found them to be = problematic in practice, which is why I chose "application/jws". = There is no canonical form for JSON, so it can get modified, and still be v= alid JSON, but the signature does not match. Passing around the signature i= ndependent of the payload is more complex.

A JWS c= an be easily passed between components and is self contained, with no worri= es that the JSON was modified by parsing and re-serializing it.
= =C2=A0

In all of these cases= , I do not think it is a good idea to use JWT claims in the TxAuth request = or response namespaces. Where we use JOSE, we should avoid JWT.
=

I agree. JWT is good for claims. Not= so good messages.
=C2=A0

I still agree that they should be able to easily use TxAuth, which = just a stronger argument for the signature/proofing mechanism to be a plugg= able thing and that the request/response bodies not be JOSE objects but JSO= N objects.

We discussed t= his in early drafts, and XAuth is JSON, with JOSE added on.
=C2= =A0

The word transaction is = muddying what I think you are suggesting here. It more like a conversation.= Transactions from a DB point of view are a set of actions that all happen,= or none happen.

I= =E2=80=99ve explained previously that the database interpretation is not th= e only or full interpretation of the word =E2=80=9Ctransaction=E2=80=9D her= e, so I won=E2=80=99t go back into it. Conversation is perhaps more accurat= e, but =E2=80=9CCxAuth=E2=80=9D is a problematic acronym. :-D

Naming is hard. =3D)
=C2=A0<= /div>

=C2=A0

Both continuation and = refresh are saying to the AS =E2=80=9Crun this transaction again and if I c= an get a token (or claims or whatever) in its current state, give me that= =E2=80=9D. However, they can=E2=80=99t really exist at the same time, so ha= ving two separate items to ask the same question doesn=E2=80=99t make much = sense.=C2=A0

They have di= fferent purposes. The completion (now authorization) handle is to check if = the AS is done with its request processing, and if so, provide the results,= which includes zero or more identity claims, and zero or more access token= s/handles.

The refresh handle is to refresh a spec= ific access token/handle.


I don=E2=80=99t see these as being different, and tha= t=E2=80=99s where we disagree. The access token is the end result of the pr= ocessing. Refreshing is an act of continuing that processing. I do not see = a good argument for treating them separately.=C2=A0

Developers are already familiar with refreshing = a token
=C2=A0

=C2=A0


I think a transaction handle is to course grained. I don&#= 39;t think that the AS should be returning all the claims in a refresh. And= if there are multiple access tokens returned from the AS, then each has th= eir own refresh handle.

I think this requires a deeper discussio= n, since the whole idea of multiple access tokens is a very different kind = of approach here.=C2=A0

I= t is a feature of XAuth.=C2=A0
Kind of. XAuth allows multiple access tokens in one limited con= text, and only when using rich authorization requests to do so.
=

Given that existing implementations = using scopes only support one access token, it did not seem limiting to onl= y have a oauth_rich_list, particularly since a RAR request is a superset of= functionality of a scope request.
=C2=A0
=
I would rather see us have a general mechanism that allows us to= get multiple access tokens in a way that=E2=80=99s parallel to how you get= one access token.

A gene= ral mechanism sounds fine and dandy. Currently we don't have other ways= to request authorization except for oauth scopes and RAR, which is a super= set of RAR. If and when we need a more general mechanism, we could define = a new type.=C2=A0
=C2=A0

=
In OAuth today, the bearer token is like a movie ticket. Who= ever has the movie ticket gets in the movie.
Using OAuth to obtai= n a bearer token is like buying a movie ticket.

So= metimes I want to go to more than one movie. OAuth today makes me wait in l= ine to buy each ticket. Why not let me buy multiple tickets at once?
<= /div>

That=E2=80=99s not true. = You can get one ticket that=E2=80=99s good for two movies, to borrow your m= etaphor.=C2=A0

Which is a= ll you can do in OAuth today. Get one ticket.
=C2=A0

The semantics of requesting multiple acc= ess tokens in parallel is something the working group might want to conside= r. I am not a fan of how XAuth handles this, with packing things into the a= uthorization list. I think it=E2=80=99s a concept we should consider though= .

If you have other ideas= , please share them!

To elaborate on my metaphor.<= /div>

A family is going to the movies. The Father (one c= omponent of the family), is going to purchase tickets. Billy (age 8) can pi= ck from the G rated movies. Sally (age 15) can pick from G, PG, and PG-13 m= ovies, and Father can pick anything.=C2=A0

Father = does not want to buy 3 tickets that are identical and can work for any movi= e. (effectively what an access token is today) He only wants them to go to = a movie he has approved, at the time he has selected.

<= div>Father wants to buy 3 different tickets, and give the appropriate ticke= t to each child.

The metaphor breaks down here, bu= t each child needs to be able to refresh their ticket independent of the ot= her's, which is why a refresh handle is required. The transaction handl= e is not granular enough.
=C2=A0

<= blockquote type=3D"cite">
<= div>=C2=A0

I see refresh much as it is in OAuth2 and UMA, where i= t refers to the authorization that was granted. This means that you can do = downscoping to get lower-powered access tokens that are a subset of the ove= rall grant, and I think that TxAuth should be able to do a step-up auth whe= re you can build some additional request on top of an existing approval.=C2= =A0

Is "step-up auth= " authentication or authorization, ... or both?

I think the question you asked is uninten= tionally misleading because =E2=80=9Cstep up=E2=80=9D authentication could = be seen from the client or the AS=E2=80=99s perspective.=C2=A0
<= /div>

Well, your statement was unclear as &= quot;auth" can be one or the other! From below, you intended authoriza= tion.
=C2=A0

The = =E2=80=9Cstep up=E2=80=9D that I mean here is from the client=E2=80=99s per= spective, not from the AS/IdP=E2=80=99s perspective. The client wants more = of something =E2=80=94 more access to an API, more user information, etc. I= t=E2=80=99s likely that the AS is going to want to interact with the user t= o include whatever additional access the client is asking for, but the clie= nt doesn=E2=80=99t want to start from scratch. You=E2=80=99ve got a ticket = that=E2=80=99s good to see one movie, and you want to add another movie to = it for after. The theater already knows who you are and how to get your mon= ey, so they can just add it on.

It=E2=80=99s entir= ely feasible that the process of asking for more information would prompt t= he AS to re-authenticate the user, including prompting them for additional = credentials. However, from the client=E2=80=99s view, that=E2=80=99s a side= -effect of its request.

T= he step-up authentication is a policy decision independent of the Client. T= he User is having to provide additional authorization.
=C2=A0
<= div>
Remembering user consent and delivering claims are two completely = separate problems and should not be conflated here. I was addressing the fo= rmer.=C2=A0

They are related th= ough. If you are not wanting to ask for consent on each delivery, how do yo= u know you have consent?

We are talking past each other. They=E2=80=99re related in the sense = that they=E2=80=99re both a part of the authorization process, but consenti= ng to the release of information and the delivery of that information are c= ompletely separate from each other.=C2=A0

Consent is required to release the information. That is ho= w they are related.=C2=A0
=C2=A0
=
Consent is not the client=E2=80=99s policy, that=E2=80=99s t= he AS=E2=80=99s policy. My consent is stored on the AS.
<= /blockquote>

Maybe. Maybe not.
=C2=A0
The client can't know if this is the =E2=80=9Cf= irst=E2=80=9D time or not because it doesn=E2=80=99t know who I am yet, so = it can=E2=80=99t ask if I should consent again. If the client knows who I a= m, it doesn=E2=80=99t need to ask the AS to log me in in the first place.= =C2=A0

Did you spend anyt= ime looking at my "authentication first" proposal in -01?

The Client asks the AS to authenticate the User, and send= that result, then the Client can decide what, if anything it wants to requ= est for that User. The AS no longer needs to maintain state.
=C2= =A0

However, once I=E2=80=99= m interacting with the AS, the AS has a chance of figuring things out. The = AS can determine if it=E2=80=99s seen the same client before, if it=E2=80= =99s seen the same user before, and if the same client is making the same r= equest for the same user, and the AS knows that it can make that decision w= ithout prompting the user. We already do exactly this today with OAuth 2 an= d OIDC systems.=C2=A0

Som= etimes. Sometimes not. The specifications are mute on saving state.
=C2=A0

But the AS does :n= ot: know which profile and identity claims the client actually :needs:. The= only party able to make that decision is the client, and it can only make = that decision once it has a reference to which user is there (in terms of a= n identifier). The AS can (and I argue should) give the client some kind of= key for helping make that decision.=C2=A0

The pus= h of user information into an OAuth-protected API, and separating it from t= he authentication context, is one of the best parts of OpenID Connect. Yes,= the client can always request the user info as long as it has the access t= oken =E2=80=94 and to me that=E2=80=99s a feature, because the client is th= e component that knows when it needs updated info.=C2=A0
<= /blockquote>

This is where consent and delivery are rela= ted. If the user info has been updated, has the User provided consent for t= he Client to receive it? The AS is the endpoint that can interact with the = user, not the UserInfo endpoint.

Why not just go b= ack to the AS and ask for the data again. If consent is not required, the A= S returns the data. If consent is required, the AS can interact with the Us= er to get it.

The UserInfo endpoint seems redundan= t if the Client can get the claims from the AS.

= =C2=A0

=C2=A0

=

Y= our comments have inspired me on a solution that can be done with XAuth (or= XYZ) that can't be done with OAuth 2.0/OIDC.

= I'll add that to the XAuth draft and publish it.=C2=A0
=C2=A0=

11. XAuth defines an explicit discovery step because the cl= ient now needs to know several things about the server. The mix-up attack a= nd a few other attacks in OAuth 2 stem from this kind of process. In XYZ, t= he client really only needs to know the transaction endpoint URL and it lea= rns everything else from that point. Yes, the client needs to discover that= someplace =E2=80=94 but it was a deliberate decision in limiting the amoun= t of upfront information that the client needs to get started.
<= /div>

That is still discovery, is it = not?

I literally just called it that in the sentence above, so yes. := ) What you=E2=80=99re discovering is different though. And doesn=E2=80=99t = the client still need to =E2=80=9Cdiscover=E2=80=9D the discovery endpoint = in XAuth?

What discovery endpoi= nt?=C2=A0=C2=A0

The= charter currently includes =E2=80=9CAS discovery=E2=80=9D, per your reques= t to add it. To me, and I would argue to most, =E2=80=9Cdiscovery=E2=80=9D = is a programmatic process. If it=E2=80=99s manual, it=E2=80=99s not really = the client =E2=80=9Cdiscovering=E2=80=9D anything, it=E2=80=99s being told = things manually by a developer. That=E2=80=99s not discovery as the term is= generally known, and I think this is a key source of confusion here. There= is no =E2=80=9Cdiscovery=E2=80=9D that=E2=80=99s not programmatic =E2=80= =94 that=E2=80=99s configuration.

I think of discovery is going to the AS and learning what it can d= o -- since discovery is learning. That can be the developer going to the AS= docs and reading, or the Client calling a discovery API.=C2=A0
<= br>
After manual discovery, the developer decides how to manually= configure the Client, based on what was discovered when reading the docume= ntation.

I have found it useful to call out the ma= nual discovery so that implementors know where the information comes from. = IE it is not in the specification.


3D"==E1=90=A7
--00000000000087b7ee059d771a72-- From nobody Fri Jan 31 14:38: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 4BFA3120B91 for ; Fri, 31 Jan 2020 14:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.335 X-Spam-Level: X-Spam-Status: No, score=-0.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_08=1.651, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mznI1ldXE2IY for ; Fri, 31 Jan 2020 14:38:31 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C57120033 for ; Fri, 31 Jan 2020 14:38:31 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id r19so8746194ljg.3 for ; Fri, 31 Jan 2020 14:38:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=iXH0p5bCB5pBdeGHAFuugM4JVVUdZCS8fTpv8XPml6o=; b=fGaM4RNDNP6YxZsCucmiQ0QOFrQGrRAvtR8gmFInW+LG8ViRgBjkN/Dane85ZCY0AY 7X93kmXNdB7qt6oM/5DCh58FdIzx7bF0MC9T1yxGgXV9vqwkQUBxl0nS2DEWuyqf9ugh sPaZ49jyLLQNaVvPIpP0Ig2pVKT4lJ2urx7SdHlNLfUaJ2nNit9uBcGOUGwcBS/tbH1I sOeUFZo3F+yo2yzNyDg972nJoieQTyb8Gq5SjSf8ut5x3HRbjHkI8wBQy0lZMDWaMhII Mh0CObUmMj+PBbcV7CJQ6eqNjUD0Fm7FgwjEBZuKAY3UYFPg93CCFk6HUsNaB2lzFi0I H3tg== 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=iXH0p5bCB5pBdeGHAFuugM4JVVUdZCS8fTpv8XPml6o=; b=m7q/6s/8sioJfHHEIlNx0Clh8zqn8tdGQDpfznbqQrLvkQw3mfbnxzXXepLpKvwLBW VCQ8iUoNfc1XQjF3zY4X9nAyX4O8u+XO8WupaJENmkRfecNB5ushNxpABP4VHnujTvcm v9Eb4Mru70HrCTBraaAwKcsxq/qE8ISybue+QSGcD0XnF34o5X6e6T7mKm8g27klFF4g 9PzNL+7f0X0QeRmnonvTkITJGHvXpRVntv81z+D0QB66n8u93HB3PbQmQtk9kg+dBFpU 5ZLhFVKksugX40SgcSowzu00Mb2Fw4ctS5WziuCB3VxxFo2Nc+Bxwdt6W+liGF6K36Kl BnZA== X-Gm-Message-State: APjAAAVcW9lCRBa1eH/x+7AR3ijCDhKYKa7phoe78qX3eFFp4sqJPuKs Vyxh/27Jindnv+OK9AsjLx/SdgvRw+sL8Fl+srinumAc X-Google-Smtp-Source: APXvYqxRxGFIYRFWpHDo+xS+v43N30wt1FCFhGz+k+I1twqdGOan/5AsRXzVEghVyMdRSjRDG9dlmrcbEGfHlytjL0E= X-Received: by 2002:a2e:9d89:: with SMTP id c9mr7420413ljj.212.1580510309358; Fri, 31 Jan 2020 14:38:29 -0800 (PST) MIME-Version: 1.0 From: Dick Hardt Date: Fri, 31 Jan 2020 14:38:03 -0800 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000008da2e8059d773be6" Archived-At: Subject: [Txauth] use case document? 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, 31 Jan 2020 22:38:33 -0000 --0000000000008da2e8059d773be6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As I reflect on my conversations with Justin, a set of use cases would help guide us. We could then refer to a use case as why a feature is present and see how different features support (or don't support) different use cases. We can also use the document to decide which use cases are in scope, or out of scope. I'll put up my hand to edit. Who is interested in contributing? /Dick =E1=90=A7 --0000000000008da2e8059d773be6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I reflect on my conversations with Justin, a set of use= cases would help guide us. We could then refer to a use case as why a feat= ure is present and see how different features support (or don't support= ) different use cases.

We can also use the document to d= ecide which use cases are in scope, or out of scope.

I'll put up my hand to edit. Who is interested in contributing?
<= /div>

/Dick
3D""=E1=90=A7
--0000000000008da2e8059d773be6--
Forking the discussion to focus on signed claims
On We= d, Jan 29, 2020 at 3:37 AM Justin Richer <jricher@mit.edu> wrote:
<snip>
First, I don=E2=80=99t believe = there are going to be many, if any, cases where we need user claims to be s= igned and encrypted separately from the core transaction messages. Even in = OIDC, the ID Token is allowed to be unsigned when it is retrieved from the = token endpoint directly using the code flow. The equivalent of this is the = only place that TxAuth would be sending back user claims directly. We no lo= nger have a need to protect things as they travel through the front channel= on a redirect, and we no longer have a need to use the user=E2=80=99s clai= ms as an artifact for things like session management (we can define a new a= rtifact for that purpose that fits better). This effectively means that we = don=E2=80=99t need to redefine the ID Token because we don=E2=80=99t need t= he equivalent of the ID token in the same way. For the cases that we do nee= d to define user claims, we should be defining them as a JSON object model.= And I also believe that this JSON data model should not be intertwined wit= h or constrained by the JWT claims registry. The OIDC claims registry can s= erve as influence and input to our user claims set if we choose, but I don= =E2=80=99t think we should be intertwined with that either.

I disagree. I think it is likely that we will = see an increase in signed claims and messages.

In = my opinion, the providence of a claim or message is far more important than= protection during transit.=C2=A0

Client / AS n= on-repudiation: when sensitive operations are performed relying on the = contents of a claim, the Client will want repudiation that the AS or claims= issuer made a claim.

Separation of duties in c= omplex systems: In large organizations, a major security threat is a ma= licious insider. Once an organization reaches a certain size, you assume th= ere are people employed at the company that do not have the firms best inte= rests in mind. One mitigation of this threat is done by separating what dif= ferent teams can do with customer / sensitive data, requiring collusion to = access or modify the data. Signed messages and claims simplify different co= mponents being able to independently verify a message or claim. Similarly, = a component issuing a claim, has assurance that other components in the sam= e system are not modifying it. Large organizations wrap external systems th= at do not support this with their own security mechanism -- but not all org= anizations are this sophisticated, and as they grow, retrofitting is diffic= ult. Enabling end to end providence is a best practice in my opinion.
=

User Consent Audit: as privacy becomes a larger = public topic, it is easy to imagine organizations wanting to prove that the= y obtained user information with consent. Rather than gathering user inform= ation directly from the user, a Client can acquire claims from the User'= ;s claims provider that asserts the user provided consent to the Client. Th= e Client can then technically establish that all user data was gathered wit= h consent, and the context of the consent.

While t= he message containing the claims may be signed, having independent claims s= eparately signed simplifies the least privilege tenet, where a component on= ly has access to the user information it needs.=C2=A0=C2=A0

<= /div>
/Dick


=C2=A0
<= /div> --000000000000e1cf11059d4dd5e9-- From nobody Wed Jan 29 14:16: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 57B03120045 for ; Wed, 29 Jan 2020 14:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 88MVKQlwS_8n for ; Wed, 29 Jan 2020 14:16:03 -0800 (PST) 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 86B3112001B for ; Wed, 29 Jan 2020 14:16:02 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id q8so1084559ljj.11 for ; Wed, 29 Jan 2020 14:16:02 -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=0mODjk0+31+idEfPHSBxUC8A+sioDOtmkRTV0OGzJOI=; b=mu3RvD/ebeyBQL5XHV6ce8Cjx47DPT9CeYkfiLi4zqDIMXSdjby0MhEbEjWlY2vHIh IV30R8gOxL/o4sHUNNmTYdUrmZ0dFfaJrF/zx9DdIWM6gNRWECZ25PYRebn5LSHY3N1w upQejnuJUfL8iOZCtoCwOu6lSijsgi1U8WqNapK4/O3xlwMSE/OuUauauOQgwXHR3B0N 1RKjXMT4ubVBc0yrFSC/qS1yGib3rd07pA1KmQMBrcN4pzMn5Tg+xQVhXeMQU+ZLnDCI GK6w35u+EMyu0cqu2qj92On6RYZCwg5jFNMMhJPjQWrzSlP3JBKJ4BVAi44/FiTjQJbf 6QSg== 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=0mODjk0+31+idEfPHSBxUC8A+sioDOtmkRTV0OGzJOI=; b=nQl9dfAvFM02n9PmvzRXkHV3rHtDS+3y0FmHoANHYbeN7OsaVjkzUAl4tPHELxWKjn U1exBgSpbZpS3sWJe9sCQf07cnEFBpfddS8gjpW9t7k6z8E0N8QUWYGBlwtCLn6aVxC8 HsvqcV9XK5y5Ky71xgR3QvH0fETY4v/E1nLvGwZWIxh9ZaUqI1ms5hEzUF2IL8Xc5V3G QnHUnDZCrxQmACPR11/9XHQZB/763JjLidU4hb4UMJ/44eiN0AQsjm5aHSItmGSIrCq5 PeFlfWRJJX0LkON19Bn8iDuX/BhkqUUKsV2eWtU5y+8nWH3fC7kJ6ckEIOH9fmabkdiW EUeQ== X-Gm-Message-State: APjAAAXPb1CrCLvwotCZrvbhT4XeZgNlyL6s1+V9UAOe7gwwLVIOwG4g EJCcwXH663sZhIp4RF82OI3xRSCx3Semge9CVao= X-Google-Smtp-Source: APXvYqwgee5QdGAbp1DkG0YfHXBw4vt8fNBOb69pABMs3lFinNpcyCQ3sb0j5hvbzJhHsIYGtbNyvc67oD+xJrmbu+4= X-Received: by 2002:a2e:865a:: with SMTP id i26mr818540ljj.236.1580336160604; Wed, 29 Jan 2020 14:16:00 -0800 (PST) MIME-Version: 1.0 References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> <585BCD70-6B64-4058-AC70-B677695DB391@mit.edu> In-Reply-To: From: Dick Hardt Date: Wed, 29 Jan 2020 14:15:34 -0800 Message-ID: To: Justin Richer Cc: "txauth@ietf.org" , Kim , Torsten Lodderstedt , "Richard Backman, Annabelle" , Mike Jones Content-Type: multipart/alternative; boundary="0000000000007a86d9059d4eaf79" Archived-At: Subject: Re: [Txauth] The need for signed claims - providence 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, 29 Jan 2020 22:16:05 -0000 --0000000000007a86d9059d4eaf79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I forgot to include the reference to Annabelle calling this out earlier https://mailarchive.ietf.org/arch/msg/txauth/0hR49OnE3oqNPuCIQ43fN1o886w On Wed, Jan 29, 2020 at 1:14 PM Dick Hardt wrote: > Forking the discussion to focus on signed claims > > On Wed, Jan 29, 2020 at 3:37 AM Justin Richer wrote: > > >> First, I don=E2=80=99t believe there are going to be many, if any, cases= where we >> need user claims to be signed and encrypted separately from the core >> transaction messages. Even in OIDC, the ID Token is allowed to be unsign= ed >> when it is retrieved from the token endpoint directly using the code flo= w. >> The equivalent of this is the only place that TxAuth would be sending ba= ck >> user claims directly. We no longer have a need to protect things as they >> travel through the front channel on a redirect, and we no longer have a >> need to use the user=E2=80=99s claims as an artifact for things like ses= sion >> management (we can define a new artifact for that purpose that fits >> better). This effectively means that we don=E2=80=99t need to redefine t= he ID Token >> because we don=E2=80=99t need the equivalent of the ID token in the same= way. For >> the cases that we do need to define user claims, we should be defining t= hem >> as a JSON object model. And I also believe that this JSON data model sho= uld >> not be intertwined with or constrained by the JWT claims registry. The O= IDC >> claims registry can serve as influence and input to our user claims set = if >> we choose, but I don=E2=80=99t think we should be intertwined with that = either. >> > > I disagree. I think it is likely that we will see an increase in signed > claims and messages. > > In my opinion, the providence of a claim or message is far more important > than protection during transit. > > *Client / AS non-repudiation*: when sensitive operations are performed > relying on the contents of a claim, the Client will want repudiation that > the AS or claims issuer made a claim. > > *Separation of duties in complex systems*: In large organizations, a > major security threat is a malicious insider. Once an organization reache= s > a certain size, you assume there are people employed at the company that = do > not have the firms best interests in mind. One mitigation of this threat = is > done by separating what different teams can do with customer / sensitive > data, requiring collusion to access or modify the data. Signed messages a= nd > claims simplify different components being able to independently verify a > message or claim. Similarly, a component issuing a claim, has assurance > that other components in the same system are not modifying it. Large > organizations wrap external systems that do not support this with their o= wn > security mechanism -- but not all organizations are this sophisticated, a= nd > as they grow, retrofitting is difficult. Enabling end to end providence i= s > a best practice in my opinion. > > *User Consent Audit*: as privacy becomes a larger public topic, it is > easy to imagine organizations wanting to prove that they obtained user > information with consent. Rather than gathering user information directly > from the user, a Client can acquire claims from the User's claims provide= r > that asserts the user provided consent to the Client. The Client can then > technically establish that all user data was gathered with consent, and t= he > context of the consent. > > While the message containing the claims may be signed, having independent > claims separately signed simplifies the least privilege tenet, where a > component only has access to the user information it needs. > > /Dick > > > > --0000000000007a86d9059d4eaf79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I forgot to include the reference to Anna= belle calling this out earlier



On Wed, Jan 29, 2020 at 1:14 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">
Fork= ing the discussion to focus on signed claims

On Wed, Jan 29, 2020 at 3:37 AM= Justin Richer <jri= cher@mit.edu> wrote:
<= snip>
F= irst, I don=E2=80=99t believe there are going to be many, if any, cases whe= re we need user claims to be signed and encrypted separately from the core = transaction messages. Even in OIDC, the ID Token is allowed to be unsigned = when it is retrieved from the token endpoint directly using the code flow. = The equivalent of this is the only place that TxAuth would be sending back = user claims directly. We no longer have a need to protect things as they tr= avel through the front channel on a redirect, and we no longer have a need = to use the user=E2=80=99s claims as an artifact for things like session man= agement (we can define a new artifact for that purpose that fits better). T= his effectively means that we don=E2=80=99t need to redefine the ID Token b= ecause we don=E2=80=99t need the equivalent of the ID token in the same way= . For the cases that we do need to define user claims, we should be definin= g them as a JSON object model. And I also believe that this JSON data model= should not be intertwined with or constrained by the JWT claims registry. = The OIDC claims registry can serve as influence and input to our user claim= s set if we choose, but I don=E2=80=99t think we should be intertwined with= that either.

I disagree. I thi= nk it is likely that we will see an increase in signed claims and messages.=

In my opinion, the providence of a claim or messa= ge is far more important than protection during transit.=C2=A0
Client / AS non-repudiation: when sensitive operations = are performed relying on the contents of a claim, the Client will want repu= diation that the AS or claims issuer made a claim.

Separation of duties in complex systems: In large organizations, a = major security threat is a malicious insider. Once an organization reaches = a certain size, you assume there are people employed at the company that do= not have the firms best interests in mind. One mitigation of this threat i= s done by separating what different teams can do with customer / sensitive = data, requiring collusion to access or modify the data. Signed messages and= claims simplify different components being able to independently verify a = message or claim. Similarly, a component issuing a claim, has assurance tha= t other components in the same system are not modifying it. Large organizat= ions wrap external systems that do not support this with their own security= mechanism -- but not all organizations are this sophisticated, and as they= grow, retrofitting is difficult. Enabling end to end providence is a best = practice in my opinion.

User Consent Audit:= as privacy becomes a larger public topic, it is easy to imagine organizati= ons wanting to prove that they obtained user information with consent. Rath= er than gathering user information directly from the user, a Client can acq= uire claims from the User's claims provider that asserts the user provi= ded consent to the Client. The Client can then technically establish that a= ll user data was gathered with consent, and the context of the consent.

While the message containing the claims may be signed= , having independent claims separately signed simplifies the least privileg= e tenet, where a component only has access to the user information it needs= .=C2=A0=C2=A0

/Dick


<= /div>
=C2=A0
--0000000000007a86d9059d4eaf79-- From nobody Wed Jan 29 15:25: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 0569D120018 for ; Wed, 29 Jan 2020 15:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 juWvXIoQoCqh for ; Wed, 29 Jan 2020 15:25:35 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450: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 7D72D12003E for ; Wed, 29 Jan 2020 15:25:34 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id b15so938691lfc.4 for ; Wed, 29 Jan 2020 15:25:34 -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=0bupyy6Q9BDhiGp8svNSv3Pa5J6SEKNQK+6KbfieQaU=; b=eXUM52eCcu6RQ/pUxSYcJ7IB2JI9wZA1ax6EuOGxuN8hn9+bAAemFze5jyXwehjHuB IbcZwQfXZUolmetHHJx01DICicjAfxkamtEEzleVTX0ZXblLg/v9ouYzgZUfPJK7XhGv a/ZJjir8Ht8bI+eLTGHL0GHSyCXOPnpl2gBHMRERneh/qAt3RERlnOq2NBnWYUN6Wo67 BNYlq85YLlebNx5YZoBPTbcARVOq7kqXwEjOfpGLvk3gU8cZltGq4tPo+og6QFEgkzhN w2RPd1WCPKL3LV+2ZD4bJXNunFJ0nJLZemk0DplwimElujxLlEC775lVO85EGjmFEpnM +c6Q== 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=0bupyy6Q9BDhiGp8svNSv3Pa5J6SEKNQK+6KbfieQaU=; b=V2MPvvucy8f2fzMnH0n8Kzik6GtO2B117+3qRbyRP3iPMaLJ/LMjGBp1SIR/dv6oBm fsKREYTwNVrokrRlmWr3kInpw1ceH+pKNEExam1OfmUDVZnbrvXcTW8Lr7xinc3CgxUB xdPfoc1+hZ3ZcXUgGzfFdfrKuf0dpKkwAzK3UayJzGWQUDEqFWwLXaZh/J2dpWz/JclN hzq8DzjjqK4V10GiUbf/Qy3XFYwR4FNkuMCeelLDJ3Kv0W7RxH0sgGabVV/yO92VrLNG fi4j25EDb7pZkqdUFUhUxMb6B295wY24G+HFlz1oUXtlqs3HZ0JB/Uqb7+Y89pu6PpJe xtVA== X-Gm-Message-State: APjAAAVTd/4+hOtDf2R7GW3n4/+wOrNSzRWeUm2dOM5qg6GLL+dbwfoA d0ZTsmWD5DOts1BmdXoeOJupNLHsZEDVyYsLHuk= X-Google-Smtp-Source: APXvYqwUQPAnTk0tOpryVtzhvdBiDNslpVcqsGSv67P7DnokrCgPA5RdRvW3oOMFbnt85BJe3pMsb+hIVMD62wYsvuY= X-Received: by 2002:ac2:531b:: with SMTP id c27mr893053lfh.91.1580340332474; Wed, 29 Jan 2020 15:25:32 -0800 (PST) MIME-Version: 1.0 References: <05467DBA-1B21-4F05-94EC-833C6E3FEBFB@mit.edu> In-Reply-To: <05467DBA-1B21-4F05-94EC-833C6E3FEBFB@mit.edu> From: Dick Hardt Date: Wed, 29 Jan 2020 15:25:06 -0800 Message-ID: To: Justin Richer Cc: txauth@ietf.org, Benjamin Kaduk , "rdd@cert.org" , Yaron Sheffer Content-Type: multipart/alternative; boundary="000000000000243503059d4fa8ea" Archived-At: Subject: Re: [Txauth] XAuth - a revision 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, 29 Jan 2020 23:25:38 -0000 --000000000000243503059d4fa8ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 29, 2020 at 8:26 AM Justin Richer wrote: > As Dick has mentioned, I gave him some early feedback on this draft befor= e > publication, and he=E2=80=99s asked me to write up my thoughts and respon= ses on the > current XAuth proposal that=E2=80=99s published here. > Thanks again for that feedback Justin. I was hoping to see your responses before you posted so that I could clarify misconceptions, but I'll do that now on the list. =3D) Thanks for writing this up -- I believe it helps us identify the areas for deeper discussion to reach rough consensus! > > 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. > > > > I think XAuth has an interesting take on the problem space that TxAuth is > looking to solve, but in my opinion it generally veers too closely to > OAuth2/OIDC/JWT in its solution approach. > Reusing aspects of OAuth2/OIDC/JWT that are working fine for deployments will minimize the migration effort for them to take advantage of the security features of this work such as not using the redirect for passing parameters. I think XAuth supports the following clause of the current draft charter: "the group will attempt to simplify porting from OAuth 2.0 and OpenID Connect to the new protocol where possible." > 1. XAuth removes =E2=80=9Chandles=E2=80=9D as stand-ins for various eleme= nts. In XYZ, the > =E2=80=9Chandle=E2=80=9D concept is a key abstraction point with specific= semantics. A > =E2=80=9Chandle=E2=80=9D is an identifier to a specific instantiation of = a JSON object > structure. Using the =E2=80=9Chandle=E2=80=9D for Keys, for Resources, an= d even the whole > Transaction lets you do a lot of core things in a parallel and reusable > way. XAuth re-invents a few of these as separate items, listed below, and= I > see this as a regression. > XAuth took the transaction handle and forked it into a completion handle and a refresh handle so that it is clear what the Client is wanting to happen. It was not clear the value of the other handles that were listed in XYZ. > > 2. XAuth uses a Client ID from OAuth 2. I removed Client IDs from XYZ > because I realized that you don=E2=80=99t need them anymore. The client I= D tells > the AS which client is talking in the front channel because the client > can=E2=80=99t authenticate. In the back channel, the key (or secret) iden= tifier is > enough to identify the client =E2=80=94 that=E2=80=99s the Key Handle in = XYZ that can be > passed in lieu of the key itself. The argument that it=E2=80=99s helpful = to have an > identifier for doing developer support and managing registrations is > spurious, since this is an internal identifier that never needs to be > exposed by the protocol. Additionally, a client ID assumes a > registration-based model. There are ephemeral and per-device client > instances like SPA=E2=80=99s and mobile apps that don=E2=80=99t really fi= t the client ID > model very well. Pushing this requirement on all clients is bad, as we=E2= =80=99ve > seen in OAuth 1 and OAuth 2. XAuth tries to manage this by splitting > clients into two camps, but I=E2=80=99m saying that no client needs and e= xternal > client ID. > I addressed this in https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-12 # 7 7. *Why is there still a Client ID? Could we not use a fingerprint of the public key to identify the Client?* Some AS deployments do not allow calls from Registered Clients, and provide different functionality to different Clients. A permanent identifier for the Client is needed for the Client developer and the AS admin to ensure they are referring to the same Client. The Client ID was used in OAuth 2.0, and it served the same purpose Perhaps you did not see that? I agree that dynamic client IDs in OAuth 2 were problematic. In XAuth, a Dynamic Client is identified by its key. Would you clarify what is broken with Client IDs for Registered Clients? It seems to working fine for registered clients in OAuth 2 / OpenID Connect, and migrating those deployments will be simpler if we keep the same concept= . The key handle seems problematic as it will change when keys are rotated. > > 3. XAuth uses a =E2=80=9Ctype=E2=80=9D field for interaction. This means = the client can > only do one type of interaction for any given transaction. XYZ started li= ke > this, but we moved away from it because we realized we could have a clien= t > app that could handle multiple types without that kind of dispatch. In XY= Z > the client sends over flags for each kind of interaction it can do: send > the user to an arbitrary URL, give the user a code, get a callback from a > browser, etc. Combining these in specific ways addresses all of the > different methods that XAuth identifies as its types while also allowing > additional things. The AS picks from the client=E2=80=99s list based on w= hat the AS > can support as well as what makes sense for the policies governing the > requested access. > Do you have a use case where the AS will want to pick from a list, rather than supporting the one that the Client wants to use? In the case where the AS interacts with an RO that is not the User, there would be nothing the Client would need to do. Perhaps there is a use case for something different? If so, please elaborate. > > 4. XAuth allows OAuth-style scopes next to RAR-style data structures (and > next to OIDC claims structures). They are treated as completely separate > from each other. In OAuth 2, RAR is defined in the context of scope (and > resource and audience and other parameters), and this combination is a > matter of some debate still that needs to be solved. However, it=E2=80=99= s clear > that they=E2=80=99re combined. In XYZ, the only resource request defined = is the > object inside the resource request. You can mimic =E2=80=9Cscope=E2=80=9D= behavior by using > a Resource Handle, which again is defined as a single string that stands = in > for the whole object and could be defined by the AS (or the API it=E2=80= =99s > protecting). > I think you need to reread the 00 draft. Only one type of authorization request is allowed. - OAuth style for deployments where that works fine. - RAR style for deployments that need the extra granularity of RAR - list of RAR style for deployments that support multiple resource servers that require independent access tokens. > > 5. The different kinds of authz requests in (4) create separate > tokens.This is very different from both OAuth 2 and XYZ, where you get ba= ck > a single access token. And in XAuth there is no way to get, for example, > two access tokens that are both described by RAR requests, so this seems > like a very arbitrary and syntactically-driven separation. > I don't think you understood what is in the draft. See above. > > 6. The assumption that JOSE will always be in the toolkit of the client > developer is not true. You can do an XYZ transaction without any JOSE =E2= =80=94 for > example, using HTTP Sig or MTLS for key presentation. > Per earlier feedback from you, I have strived to separate JOSE out into Section 8, so that an extension could use HTTP signing or MTLS. Let me know where JOSE is still an assumption. > > 7. The statement that =E2=80=9Cthere is no HTTP signing=E2=80=9D is false= , as this is > being brought up to the HTTP WG right now (I=E2=80=99m one of the co-auth= ors). Yes, > it=E2=80=99s not an RFC, but neither is this. And if we=E2=80=99re doing = agile signature > methods, which I contend is a required extension point, then we don=E2=80= =99t have > a dependency requirement for it. > XAuth says from https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-12 # 3 There is currently no widely deployed open standard for HTTP signing. Yes, there is working going on. But security it is not a published RFC, there are no libraries for it, and it has not been tested on the open internet. While I wish the HTTP WG luck in this work, and I support it happening, it will be hard. OAuth 1.0 core issue was that it was signing a request (in my opinion) The widely deployed HTTP Signing is AWS SIGv4 -- which AWS supplies libraries for every API in all popular languages so that developers don't have to do the HTTP signing themselves. I could imagine AWS adopting XAuth and using SIGv4 instead of JOSE if they wanted. > 8. XAuth adds back in an explicit =E2=80=9Crefresh token=E2=80=9D. In XYZ= , we don=E2=80=99t have a > refresh token because we can use the transaction handle to continue the > transaction after a token has been issued. This has explicit and clear > semantics that follows from what the transaction handle is used for > elsewhere in the protocol =E2=80=94 continue this request that=E2=80=99s = in some > authorization state and give me the results. > I think we agree that refresh is a required feature. I think a transaction handle is to course grained. I don't think that the AS should be returning all the claims in a refresh. And if there are multiple access tokens returned from the AS, then each has their own refresh handle. > > 9. XAuth uses OIDC=E2=80=99s ID Token. As I=E2=80=99ve said on the other = thread, I don=E2=80=99t > think we actually need a separately signed assertion. I=E2=80=99d rather = see a way > to sign the entire response which includes the user claims, if we want > signature protection. > I responded in a separate thread. > > 10. XAuth sends all the user=E2=80=99s claims on the login request =E2=80= =94 or more > precisely, this is the only mechanism specified and the Rationale section > claims this is a feature. This violates minimal disclosure and privacy > design guidelines, and this type of protocol has been developed before wi= th > OpenID 1.x/2.x and SAML. The problem here unfolds when you think about ho= w > it works: The RP needs to log in. If this is the first time it=E2=80=99s = seen this > user, then it needs the user=E2=80=99s profile info. If not, and the prof= ile info > hasn=E2=80=99t changed, there=E2=80=99s no need for it and the AS shouldn= =E2=80=99t send it. So the > RP can signal this, right? Except that the RP doesn=E2=80=99t know who th= e user is > yet (that=E2=80=99s why they=E2=80=99re making this call!). Can the AS ma= ke this call? They > won=E2=80=99t know if the RP has cached the user=E2=80=99s info or not. A= nd if we=E2=80=99re using > Client ID, then the AS can=E2=80=99t even be sure that this copy of the c= lient is > the same as another copy of the client. I think TxAuth needs to minimize > the user claims sent back to being an identifier, information about the > authentication event that could change each time anyway, and anything tha= t > would be needed to control a cache. Additional fields can be pulled from > the equivalent of a UserInfo Endpoint in a two-stage process that both > preserves privacy and optimizes for what=E2=80=99s available from each pa= rty. > Not clear how XYZ improves on this. The UserInfo Endpoint solves the Client getting more info than it needs, but the User still needs to give consent each time unless the AS tracks it. So it is unclear to me what value the UserInfo Endpoint brings. Your comments have inspired me on a solution that can be done with XAuth (or XYZ) that can't be done with OAuth 2.0/OIDC. I'll add that to the XAuth draft and publish it. > > 11. XAuth defines an explicit discovery step because the client now needs > to know several things about the server. The mix-up attack and a few othe= r > attacks in OAuth 2 stem from this kind of process. In XYZ, the client > really only needs to know the transaction endpoint URL and it learns > everything else from that point. Yes, the client needs to discover that > someplace =E2=80=94 but it was a deliberate decision in limiting the amou= nt of > upfront information that the client needs to get started. > That is still discovery, is it not? Would the Client not need to know the message signing methods supported? JOSE, HTTP Signing, and/or MTLS? > I=E2=80=99ve played with the concept of a =E2=80=9Ccapabilities=E2=80=9D = list in XYZ, where the > client would present a list of things it can do and the AS trims that lis= t > to what it can also do. > So ... programatic discovery? =3D) Are you suggesting that discovery of everything but the endpoint has to be programatic? > This type of one-stage negotiation is really powerful and I think we can > get a lot from it here. > Sure ... but for many people what works today is documentation that someone reads to understand what to do. Are you suggesting we not enable that? > > > All in all, thanks for the draft. I think it raises important questions > and the discussion of these questions will help us build the best system = we > can. > Thanks again for writing up your feedback! /Dick --000000000000243503059d4fa8ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jan 29, 2020 at 8:2= 6 AM Justin Richer <jricher@mit.edu> wrote:
As Dick has mentioned, I gave him some early feedback = on this draft before publication, and he=E2=80=99s asked me to write up my = thoughts and responses on the current XAuth proposal that=E2=80=99s publish= ed here.

Thanks again for that feedba= ck Justin. I was hoping to see your responses before you posted so that I c= ould clarify misconceptions, but I'll do that now on the list. =3D)

Thanks for writing this up -- I believe it helps us i= dentify the areas for deeper discussion to reach rough consensus!
=C2=A0
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 wor= king group work here (as in our eventual output) as TxAuth.=C2=A0

<snip>

I thin= k XAuth has an interesting take on the problem space that TxAuth is looking= to solve, but in my opinion it generally veers too closely to OAuth2/OIDC/= JWT in its solution approach.

Reusing aspects of OAuth2/OIDC/JWT that are working fine for deployme= nts will minimize the migration effort for them to take advantage of the se= curity features of this work such as not using the redirect for passing par= ameters. I think XAuth supports the following clause of the current draft c= harter: "the group will=C2=A0attempt to simplify porting from OAuth 2.= 0 and OpenID Connect to the new protocol where possible."
<snip>
=C2=A0
1. XAuth removes =E2=80=9C= handles=E2=80=9D as stand-ins for various elements. In XYZ, the =E2=80=9Cha= ndle=E2=80=9D concept is a key abstraction point with specific semantics. A= =E2=80=9Chandle=E2=80=9D is an identifier to a specific instantiation of a= JSON object structure. Using the =E2=80=9Chandle=E2=80=9D for Keys, for Re= sources, and even the whole Transaction lets you do a lot of core things in= a parallel and reusable way. XAuth re-invents a few of these as separate i= tems, listed below, and I see this as a regression.

XAuth took the transaction handle and forked it = into a completion handle and a refresh handle so that it is clear what the = Client is wanting to happen.

It was not clear the = value of the other handles that were listed in XYZ.=C2=A0
=C2=A0<= /div>

<= /div>
2. XAuth uses a Client ID from OAuth 2. I removed Client IDs from= XYZ because I realized that you don=E2=80=99t need them anymore. The clien= t ID tells the AS which client is talking in the front channel because the = client can=E2=80=99t authenticate. In the back channel, the key (or secret)= identifier is enough to identify the client =E2=80=94 that=E2=80=99s the K= ey Handle in XYZ that can be passed in lieu of the key itself. The argument= that it=E2=80=99s helpful to have an identifier for doing developer suppor= t and managing registrations is spurious, since this is an internal identif= ier that never needs to be exposed by the protocol. Additionally, a client = ID assumes a registration-based model. There are ephemeral and per-device c= lient instances like SPA=E2=80=99s and mobile apps that don=E2=80=99t reall= y fit the client ID model very well. Pushing this requirement on all client= s is bad, as we=E2=80=99ve seen in OAuth 1 and OAuth 2. XAuth tries to mana= ge this by splitting clients into two camps, but I=E2=80=99m saying that no= client needs and external client ID.

 7.   *Why is there st=
ill a Client ID?  Could we not use a fingerprint
        of the public key to identify the Client?*

        Some AS deployments do not allow calls from Registered Clients,
        and provide different functionality to different Clients.  A
        permanent identifier for the Client is needed for the Client
        developer and the AS admin to ensure they are referring to the
        same Client.  The Client ID was used in OAuth 2.0, and it served
        the same purpose

Perhaps you did not see that?

I agree that dynamic client IDs in OAuth 2 were problematic. In XAu= th, a Dynamic Client is identified by its key.

Wou= ld you clarify what is broken with Client IDs for Registered Clients? It se= ems to working fine for registered clients in OAuth 2 / OpenID Connect, and= migrating those deployments will be simpler if we keep the same concept.

The key handle seems problematic as it will change = when keys are rotated.=C2=A0
=C2=A0

3. XAuth uses a =E2= =80=9Ctype=E2=80=9D field for interaction. This means the client can only d= o one type of interaction for any given transaction. XYZ started like this,= but we moved away from it because we realized we could have a client app t= hat could handle multiple types without that kind of dispatch. In XYZ the c= lient sends over flags for each kind of interaction it can do: send the use= r to an arbitrary URL, give the user a code, get a callback from a browser,= etc. Combining these in specific ways addresses all of the different metho= ds that XAuth identifies as its types while also allowing additional things= . The AS picks from the client=E2=80=99s list based on what the AS can supp= ort as well as what makes sense for the policies governing the requested ac= cess.

Do you have a use c= ase where the AS will want to pick from a list, rather than supporting the = one that the Client wants to use?

In the case wher= e the AS interacts with an RO that is not the User, there would be nothing = the Client would need to do. Perhaps there is a use case for something diff= erent? If so, please elaborate.
=C2=A0

4. XAuth all= ows OAuth-style scopes next to RAR-style data structures (and next to OIDC = claims structures). They are treated as completely separate from each other= . In OAuth 2, RAR is defined in the context of scope (and resource and audi= ence and other parameters), and this combination is a matter of some debate= still that needs to be solved. However, it=E2=80=99s clear that they=E2=80= =99re combined. In XYZ, the only resource request defined is the object ins= ide the resource request. You can mimic =E2=80=9Cscope=E2=80=9D behavior by= using a Resource Handle, which again is defined as a single string that st= ands in for the whole object and could be defined by the AS (or the API it= =E2=80=99s protecting).=C2=A0

=
I think you need to reread the 00 draft. Only one type of authorizatio= n request is allowed.

- OAuth style for deployment= s where that works fine.
- RAR style for deployments that need th= e extra granularity of RAR
- list of RAR style for deployments th= at support multiple resource servers that require independent access tokens= .
=C2=A0

5. The different kinds of authz requests i= n (4) create separate tokens.This is very different from both OAuth 2 and X= YZ, where you get back a single access token. And in XAuth there is no way = to get, for example, two access tokens that are both described by RAR reque= sts, so this seems like a very arbitrary and syntactically-driven separatio= n.=C2=A0

I don't thin= k you understood what is in the draft. See above.
=C2=A0

6. The assumption that JOSE will always be in the toolkit of the client d= eveloper is not true. You can do an XYZ transaction without any JOSE =E2=80= =94 for example, using HTTP Sig or MTLS for key presentation.=C2=A0

Per earlier feedback from you, I= have strived to separate JOSE out into Section 8, so that an extension cou= ld use HTTP signing or MTLS. Let me know where JOSE is still an assumption.=
=C2=A0

7. The statement that =E2=80=9Cthere is no HTTP= signing=E2=80=9D is false, as this is being brought up to the HTTP WG righ= t now (I=E2=80=99m one of the co-authors). Yes, it=E2=80=99s not an RFC, bu= t neither is this. And if we=E2=80=99re doing agile signature methods, whic= h I contend is a required extension point, then we don=E2=80=99t have a dep= endency requirement for it.=C2=A0

There is currently no wide= ly deployed open standard for HTTP signing.
=C2=A0
<= div>Yes, there is working going on. But security it is not a published RFC,= there are no libraries for it, and it has not been tested on the open inte= rnet.=C2=A0

While I wish the HTTP WG luck in this = work, and I support it happening, it will be hard.

OAuth 1.0 core issue was that it was signing a request (in my opinion)

The widely deployed HTTP Signing is AWS SIGv4 -- whic= h AWS supplies libraries for every API in all popular languages so that dev= elopers don't have to do the HTTP signing themselves.=C2=A0
<= br>
I could imagine AWS adopting XAuth and using SIGv4 instead of= JOSE if they wanted.



8. XAut= h adds back in an explicit =E2=80=9Crefresh token=E2=80=9D. In XYZ, we don= =E2=80=99t have a refresh token because we can use the transaction handle t= o continue the transaction after a token has been issued. This has explicit= and clear semantics that follows from what the transaction handle is used = for elsewhere in the protocol =E2=80=94 continue this request that=E2=80=99= s in some authorization state and give me the results.=C2=A0

I think we agree that refresh is = a required feature.

I think a transaction handle i= s to course grained. I don't think that the AS should be returning all = the claims in a refresh. And if there are multiple access tokens returned f= rom the AS, then each has their own refresh handle.
=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">

9. XAuth uses OIDC=E2=80=99s ID Token. As I=E2=80=99ve said on the= other thread, I don=E2=80=99t think we actually need a separately signed a= ssertion. I=E2=80=99d rather see a way to sign the entire response which in= cludes the user claims, if we want signature protection.
<= /div>

I responded in a separate thread.
=C2=A0
<= div>

10. XAuth sends all the user=E2=80=99s claims = on the login request =E2=80=94 or more precisely, this is the only mechanis= m specified and the Rationale section claims this is a feature. This violat= es minimal disclosure and privacy design guidelines, and this type of proto= col has been developed before with OpenID 1.x/2.x and SAML. The problem her= e unfolds when you think about how it works: The RP needs to log in. If thi= s is the first time it=E2=80=99s seen this user, then it needs the user=E2= =80=99s profile info. If not, and the profile info hasn=E2=80=99t changed, = there=E2=80=99s no need for it and the AS shouldn=E2=80=99t send it. So the= RP can signal this, right? Except that the RP doesn=E2=80=99t know who the= user is yet (that=E2=80=99s why they=E2=80=99re making this call!). Can th= e AS make this call? They won=E2=80=99t know if the RP has cached the user= =E2=80=99s info or not. And if we=E2=80=99re using Client ID, then the AS c= an=E2=80=99t even be sure that this copy of the client is the same as anoth= er copy of the client. I think TxAuth needs to minimize the user claims sen= t back to being an identifier, information about the authentication event t= hat could change each time anyway, and anything that would be needed to con= trol a cache. Additional fields can be pulled from the equivalent of a User= Info Endpoint in a two-stage process that both preserves privacy and optimi= zes for what=E2=80=99s available from each party.

Not clear how XYZ improves on this.

The UserInfo Endpoint solves the Client getting more info = than it needs, but the User still needs to give consent each time unless th= e AS tracks it. So it is unclear to me what value the UserInfo Endpoint bri= ngs.

Your comments have inspired me on a solution = that can be done with XAuth (or XYZ) that can't be done with OAuth 2.0/= OIDC.

I'll add that to the XAuth draft and pub= lish it.=C2=A0
=C2=A0

11. XAuth defines an explici= t discovery step because the client now needs to know several things about = the server. The mix-up attack and a few other attacks in OAuth 2 stem from = this kind of process. In XYZ, the client really only needs to know the tran= saction endpoint URL and it learns everything else from that point. Yes, th= e client needs to discover that someplace =E2=80=94 but it was a deliberate= decision in limiting the amount of upfront information that the client nee= ds to get started.

= That is still discovery, is it not?

Would the Clie= nt not need to know the message signing methods supported? JOSE, HTTP Signi= ng, and/or MTLS?=C2=A0
=C2=A0
I=E2=80=99ve played with the conce= pt of a =E2=80=9Ccapabilities=E2=80=9D list in XYZ, where the client would = present a list of things it can do and the AS trims that list to what it ca= n also do.

So ... p= rogramatic discovery? =3D)

Are you suggesting that= discovery of everything but the endpoint has to be programatic?=C2=A0
=C2=A0
This type of one-stage negotiation is really powerful and I t= hink we can get a lot from it here.

Sure ... but for many people what works today is documenta= tion that someone reads to understand what to do. Are you suggesting we not= enable that?
=C2=A0


All in all= , thanks for the draft. I think it raises important questions and the discu= ssion of these questions will help us build the best system we can.

Thanks again for writing u= p your feedback!
=C2=A0
/Dick
--000000000000243503059d4fa8ea-- From nobody Wed Jan 29 16:01: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 3369A12004C for ; Wed, 29 Jan 2020 16:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.497 X-Spam-Level: X-Spam-Status: No, score=-14.497 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 6nQZ6chHPCVJ for ; Wed, 29 Jan 2020 16:01:05 -0800 (PST) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.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 3889512003F for ; Wed, 29 Jan 2020 16:01:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1580342465; x=1611878465; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gsmu8GtyFIC7MZv5xwoa16oOvgLL+1NJY/Mevw1gnTg=; b=nckmipXJQ/d1rp0//aMmsgrB4KyPvXZuuFdYLT1dDXnrwkMums2F0YD7 n4UAdFQ9Ll65VU2LbV0M6Zkt7oPNIBBFY3LoT2OxBbjEy+FqmwXIV4hvc ks4OYuSaaQKs1cwbzGpRbFrCYJGjlS7TUf4oK/1vgpGvf1DbZMbY2pBP9 Q=; IronPort-SDR: 1btoCzUCKWnI+WuWTmPvKX6K0MA9ZB4CQ5gSEA8Dv6kp/dQRcoL/UxMm6oDV6rn50AMFYbHE/E r9ETMn4W71hA== X-IronPort-AV: E=Sophos; i="5.70,379,1574121600"; d="scan'208,217"; a="14852978" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1e-62350142.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 30 Jan 2020 00:01:04 +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-62350142.us-east-1.amazon.com (Postfix) with ESMTPS id BA35BA2484; Thu, 30 Jan 2020 00:01:00 +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, 30 Jan 2020 00:01:00 +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.1367.3; Thu, 30 Jan 2020 00:00:59 +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.1367.000; Thu, 30 Jan 2020 00:00:59 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt , Justin Richer CC: "txauth@ietf.org" , Kim , "Torsten Lodderstedt" , Mike Jones Thread-Topic: [UNVERIFIED SENDER] Re: The need for signed claims - providence Thread-Index: AQHV1vG+3lR3YxKDi0yASALYD/pmLqgBzLSA Date: Thu, 30 Jan 2020 00:00:59 +0000 Message-ID: <7833DDB1-FB88-4151-84B6-8DABB6436B53@amazon.com> References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> <585BCD70-6B64-4058-AC70-B677695DB391@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.249] Content-Type: multipart/alternative; boundary="_000_7833DDB1FB88415184B68DABB6436B53amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: The need for signed claims - providence 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, 30 Jan 2020 00:01:09 -0000 --_000_7833DDB1FB88415184B68DABB6436B53amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgdG8gRGlja+KAmXMgY291bnRlcnBvaW50cy4gVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z IGluIGRyYWZ0LWlldGYtc2VjZXZlbnQtaHR0cC1wdXNoPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXNlY2V2ZW50LWh0dHAtcHVzaC0wNyNzZWN0aW9uLTUuND4gdGFsayBh Ym91dCB2YWxpZGF0aW9uIG9mIHBlcnNpc3RlZCBTRVRzIGFzIG9uZSByZWFzb24gYSBkZXBsb3lt ZW50IG1heSB3aXNoIHRvIHRyYW5zbWl0IHNpZ25lZCBTRVRzIGV2ZW4gb3ZlciBhIFRMUy1wcm90 ZWN0ZWQgY2hhbm5lbC4gVGhlIHNhbWUgaWRlYSBhcHBsaWVzIHRvIGlkZW50aXR5IGNsYWltcyBv ciBqdXN0IGFib3V0IGFueXRoaW5nIGVsc2UsIHJlYWxseS4NCg0K4oCTDQpBbm5hYmVsbGUgUmlj aGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBEaWNrIEhhcmR0IDxkaWNrLmhh cmR0QGdtYWlsLmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgSmFudWFyeSAyOSwgMjAyMCBhdCAyOjE2 IFBNDQpUbzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1Pg0KQ2M6ICJ0eGF1dGhAaWV0 Zi5vcmciIDx0eGF1dGhAaWV0Zi5vcmc+LCBLaW0gPGtpbUBpZGVudGl0eWJsb2cuY29tPiwgVG9y c3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+LCAiUmljaGFyZCBCYWNr bWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPiwgTWlrZSBKb25lcyA8TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KU3ViamVjdDogW1VOVkVSSUZJRUQgU0VOREVSXSBSZTog VGhlIG5lZWQgZm9yIHNpZ25lZCBjbGFpbXMgLSBwcm92aWRlbmNlDQoNCkkgZm9yZ290IHRvIGlu Y2x1ZGUgdGhlIHJlZmVyZW5jZSB0byBBbm5hYmVsbGUgY2FsbGluZyB0aGlzIG91dCBlYXJsaWVy DQoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdHhhdXRoLzBoUjQ5T25F M29xTlB1Q0lRNDNmTjFvODg2dw0KDQoNCk9uIFdlZCwgSmFuIDI5LCAyMDIwIGF0IDE6MTQgUE0g RGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwu Y29tPj4gd3JvdGU6DQpGb3JraW5nIHRoZSBkaXNjdXNzaW9uIHRvIGZvY3VzIG9uIHNpZ25lZCBj bGFpbXMNCg0KT24gV2VkLCBKYW4gMjksIDIwMjAgYXQgMzozNyBBTSBKdXN0aW4gUmljaGVyIDxq cmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KPHNuaXA+DQpG aXJzdCwgSSBkb27igJl0IGJlbGlldmUgdGhlcmUgYXJlIGdvaW5nIHRvIGJlIG1hbnksIGlmIGFu eSwgY2FzZXMgd2hlcmUgd2UgbmVlZCB1c2VyIGNsYWltcyB0byBiZSBzaWduZWQgYW5kIGVuY3J5 cHRlZCBzZXBhcmF0ZWx5IGZyb20gdGhlIGNvcmUgdHJhbnNhY3Rpb24gbWVzc2FnZXMuIEV2ZW4g aW4gT0lEQywgdGhlIElEIFRva2VuIGlzIGFsbG93ZWQgdG8gYmUgdW5zaWduZWQgd2hlbiBpdCBp cyByZXRyaWV2ZWQgZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgZGlyZWN0bHkgdXNpbmcgdGhlIGNv ZGUgZmxvdy4gVGhlIGVxdWl2YWxlbnQgb2YgdGhpcyBpcyB0aGUgb25seSBwbGFjZSB0aGF0IFR4 QXV0aCB3b3VsZCBiZSBzZW5kaW5nIGJhY2sgdXNlciBjbGFpbXMgZGlyZWN0bHkuIFdlIG5vIGxv bmdlciBoYXZlIGEgbmVlZCB0byBwcm90ZWN0IHRoaW5ncyBhcyB0aGV5IHRyYXZlbCB0aHJvdWdo IHRoZSBmcm9udCBjaGFubmVsIG9uIGEgcmVkaXJlY3QsIGFuZCB3ZSBubyBsb25nZXIgaGF2ZSBh IG5lZWQgdG8gdXNlIHRoZSB1c2Vy4oCZcyBjbGFpbXMgYXMgYW4gYXJ0aWZhY3QgZm9yIHRoaW5n cyBsaWtlIHNlc3Npb24gbWFuYWdlbWVudCAod2UgY2FuIGRlZmluZSBhIG5ldyBhcnRpZmFjdCBm b3IgdGhhdCBwdXJwb3NlIHRoYXQgZml0cyBiZXR0ZXIpLiBUaGlzIGVmZmVjdGl2ZWx5IG1lYW5z IHRoYXQgd2UgZG9u4oCZdCBuZWVkIHRvIHJlZGVmaW5lIHRoZSBJRCBUb2tlbiBiZWNhdXNlIHdl IGRvbuKAmXQgbmVlZCB0aGUgZXF1aXZhbGVudCBvZiB0aGUgSUQgdG9rZW4gaW4gdGhlIHNhbWUg d2F5Li4gRm9yIHRoZSBjYXNlcyB0aGF0IHdlIGRvIG5lZWQgdG8gZGVmaW5lIHVzZXIgY2xhaW1z LCB3ZSBzaG91bGQgYmUgZGVmaW5pbmcgdGhlbSBhcyBhIEpTT04gb2JqZWN0IG1vZGVsLiBBbmQg SSBhbHNvIGJlbGlldmUgdGhhdCB0aGlzIEpTT04gZGF0YSBtb2RlbCBzaG91bGQgbm90IGJlIGlu dGVydHdpbmVkIHdpdGggb3IgY29uc3RyYWluZWQgYnkgdGhlIEpXVCBjbGFpbXMgcmVnaXN0cnku IFRoZSBPSURDIGNsYWltcyByZWdpc3RyeSBjYW4gc2VydmUgYXMgaW5mbHVlbmNlIGFuZCBpbnB1 dCB0byBvdXIgdXNlciBjbGFpbXMgc2V0IGlmIHdlIGNob29zZSwgYnV0IEkgZG9u4oCZdCB0aGlu ayB3ZSBzaG91bGQgYmUgaW50ZXJ0d2luZWQgd2l0aCB0aGF0IGVpdGhlci4NCg0KSSBkaXNhZ3Jl ZS4gSSB0aGluayBpdCBpcyBsaWtlbHkgdGhhdCB3ZSB3aWxsIHNlZSBhbiBpbmNyZWFzZSBpbiBz aWduZWQgY2xhaW1zIGFuZCBtZXNzYWdlcy4NCg0KSW4gbXkgb3BpbmlvbiwgdGhlIHByb3ZpZGVu Y2Ugb2YgYSBjbGFpbSBvciBtZXNzYWdlIGlzIGZhciBtb3JlIGltcG9ydGFudCB0aGFuIHByb3Rl Y3Rpb24gZHVyaW5nIHRyYW5zaXQuDQoNCkNsaWVudCAvIEFTIG5vbi1yZXB1ZGlhdGlvbjogd2hl biBzZW5zaXRpdmUgb3BlcmF0aW9ucyBhcmUgcGVyZm9ybWVkIHJlbHlpbmcgb24gdGhlIGNvbnRl bnRzIG9mIGEgY2xhaW0sIHRoZSBDbGllbnQgd2lsbCB3YW50IHJlcHVkaWF0aW9uIHRoYXQgdGhl IEFTIG9yIGNsYWltcyBpc3N1ZXIgbWFkZSBhIGNsYWltLg0KDQpTZXBhcmF0aW9uIG9mIGR1dGll cyBpbiBjb21wbGV4IHN5c3RlbXM6IEluIGxhcmdlIG9yZ2FuaXphdGlvbnMsIGEgbWFqb3Igc2Vj dXJpdHkgdGhyZWF0IGlzIGEgbWFsaWNpb3VzIGluc2lkZXIuIE9uY2UgYW4gb3JnYW5pemF0aW9u IHJlYWNoZXMgYSBjZXJ0YWluIHNpemUsIHlvdSBhc3N1bWUgdGhlcmUgYXJlIHBlb3BsZSBlbXBs b3llZCBhdCB0aGUgY29tcGFueSB0aGF0IGRvIG5vdCBoYXZlIHRoZSBmaXJtcyBiZXN0IGludGVy ZXN0cyBpbiBtaW5kLiBPbmUgbWl0aWdhdGlvbiBvZiB0aGlzIHRocmVhdCBpcyBkb25lIGJ5IHNl cGFyYXRpbmcgd2hhdCBkaWZmZXJlbnQgdGVhbXMgY2FuIGRvIHdpdGggY3VzdG9tZXIgLyBzZW5z aXRpdmUgZGF0YSwgcmVxdWlyaW5nIGNvbGx1c2lvbiB0byBhY2Nlc3Mgb3IgbW9kaWZ5IHRoZSBk YXRhLiBTaWduZWQgbWVzc2FnZXMgYW5kIGNsYWltcyBzaW1wbGlmeSBkaWZmZXJlbnQgY29tcG9u ZW50cyBiZWluZyBhYmxlIHRvIGluZGVwZW5kZW50bHkgdmVyaWZ5IGEgbWVzc2FnZSBvciBjbGFp bS4gU2ltaWxhcmx5LCBhIGNvbXBvbmVudCBpc3N1aW5nIGEgY2xhaW0sIGhhcyBhc3N1cmFuY2Ug dGhhdCBvdGhlciBjb21wb25lbnRzIGluIHRoZSBzYW1lIHN5c3RlbSBhcmUgbm90IG1vZGlmeWlu ZyBpdC4gTGFyZ2Ugb3JnYW5pemF0aW9ucyB3cmFwIGV4dGVybmFsIHN5c3RlbXMgdGhhdCBkbyBu b3Qgc3VwcG9ydCB0aGlzIHdpdGggdGhlaXIgb3duIHNlY3VyaXR5IG1lY2hhbmlzbSAtLSBidXQg bm90IGFsbCBvcmdhbml6YXRpb25zIGFyZSB0aGlzIHNvcGhpc3RpY2F0ZWQsIGFuZCBhcyB0aGV5 IGdyb3csIHJldHJvZml0dGluZyBpcyBkaWZmaWN1bHQuIEVuYWJsaW5nIGVuZCB0byBlbmQgcHJv dmlkZW5jZSBpcyBhIGJlc3QgcHJhY3RpY2UgaW4gbXkgb3Bpbmlvbi4NCg0KVXNlciBDb25zZW50 IEF1ZGl0OiBhcyBwcml2YWN5IGJlY29tZXMgYSBsYXJnZXIgcHVibGljIHRvcGljLCBpdCBpcyBl YXN5IHRvIGltYWdpbmUgb3JnYW5pemF0aW9ucyB3YW50aW5nIHRvIHByb3ZlIHRoYXQgdGhleSBv YnRhaW5lZCB1c2VyIGluZm9ybWF0aW9uIHdpdGggY29uc2VudC4gUmF0aGVyIHRoYW4gZ2F0aGVy aW5nIHVzZXIgaW5mb3JtYXRpb24gZGlyZWN0bHkgZnJvbSB0aGUgdXNlciwgYSBDbGllbnQgY2Fu IGFjcXVpcmUgY2xhaW1zIGZyb20gdGhlIFVzZXIncyBjbGFpbXMgcHJvdmlkZXIgdGhhdCBhc3Nl cnRzIHRoZSB1c2VyIHByb3ZpZGVkIGNvbnNlbnQgdG8gdGhlIENsaWVudC4gVGhlIENsaWVudCBj YW4gdGhlbiB0ZWNobmljYWxseSBlc3RhYmxpc2ggdGhhdCBhbGwgdXNlciBkYXRhIHdhcyBnYXRo ZXJlZCB3aXRoIGNvbnNlbnQsIGFuZCB0aGUgY29udGV4dCBvZiB0aGUgY29uc2VudC4NCg0KV2hp bGUgdGhlIG1lc3NhZ2UgY29udGFpbmluZyB0aGUgY2xhaW1zIG1heSBiZSBzaWduZWQsIGhhdmlu ZyBpbmRlcGVuZGVudCBjbGFpbXMgc2VwYXJhdGVseSBzaWduZWQgc2ltcGxpZmllcyB0aGUgbGVh c3QgcHJpdmlsZWdlIHRlbmV0LCB3aGVyZSBhIGNvbXBvbmVudCBvbmx5IGhhcyBhY2Nlc3MgdG8g dGhlIHVzZXIgaW5mb3JtYXRpb24gaXQgbmVlZHMuLg0KDQovRGljaw0KDQoNCg0K --_000_7833DDB1FB88415184B68DABB6436B53amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSB0 byBEaWNr4oCZcyBjb3VudGVycG9pbnRzLiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1zZWNldmVudC1odHRwLXB1c2gtMDcjc2VjdGlvbi01LjQiPg0KVGhl IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGluIGRyYWZ0LWlldGYtc2VjZXZlbnQtaHR0cC1wdXNo PC9hPiB0YWxrIGFib3V0IHZhbGlkYXRpb24gb2YgcGVyc2lzdGVkIFNFVHMgYXMgb25lIHJlYXNv biBhIGRlcGxveW1lbnQgbWF5IHdpc2ggdG8gdHJhbnNtaXQgc2lnbmVkIFNFVHMgZXZlbiBvdmVy IGEgVExTLXByb3RlY3RlZCBjaGFubmVsLiBUaGUgc2FtZSBpZGVhIGFwcGxpZXMgdG8gaWRlbnRp dHkgY2xhaW1zIG9yIGp1c3QgYWJvdXQgYW55dGhpbmcNCiBlbHNlLCByZWFsbHkuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+4oCT Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkRpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0Ozxicj4N CjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEphbnVhcnkgMjksIDIwMjAgYXQgMjoxNiBQTTxicj4N CjxiPlRvOiA8L2I+SnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0Ozxicj4NCjxi PkNjOiA8L2I+JnF1b3Q7dHhhdXRoQGlldGYub3JnJnF1b3Q7ICZsdDt0eGF1dGhAaWV0Zi5vcmcm Z3Q7LCBLaW0gJmx0O2tpbUBpZGVudGl0eWJsb2cuY29tJmd0OywgVG9yc3RlbiBMb2RkZXJzdGVk dCAmbHQ7dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQmZ3Q7LCAmcXVvdDtSaWNoYXJkIEJhY2ttYW4s IEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDssIE1pa2UgSm9uZXMg Jmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ W1VOVkVSSUZJRUQgU0VOREVSXSBSZTogVGhlIG5lZWQgZm9yIHNpZ25lZCBjbGFpbXMgLSBwcm92 aWRlbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBmb3Jnb3QgdG8gaW5jbHVkZSB0aGUgcmVmZXJlbmNlIHRvIEFu bmFiZWxsZSBjYWxsaW5nIHRoaXMgb3V0IGVhcmxpZXINCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL21zZy90eGF1dGgvMGhSNDlPbkUzb3FOUHVDSVE0M2ZOMW84ODZ3Ij5odHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3R4YXV0aC8waFI0OU9uRTNvcU5QdUNJUTQz Zk4xbzg4Nnc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiAyOSwgMjAyMCBhdCAxOjE0IFBNIERpY2sg SGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+ZGljay5oYXJk dEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9ya2luZyB0aGUgZGlz Y3Vzc2lvbiB0byBmb2N1cyBvbiBzaWduZWQgY2xhaW1zPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiAyOSwgMjAyMCBhdCAzOjM3IEFNIEp1 c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0i X2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtzbmlwJmd0OzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5GaXJzdCwgSSBkb27igJl0IGJlbGlldmUgdGhlcmUgYXJlIGdvaW5nIHRvIGJlIG1hbnks IGlmIGFueSwgY2FzZXMgd2hlcmUgd2UgbmVlZCB1c2VyIGNsYWltcyB0byBiZSBzaWduZWQgYW5k IGVuY3J5cHRlZCBzZXBhcmF0ZWx5IGZyb20gdGhlIGNvcmUgdHJhbnNhY3Rpb24gbWVzc2FnZXMu IEV2ZW4gaW4gT0lEQywgdGhlIElEIFRva2VuIGlzIGFsbG93ZWQgdG8gYmUgdW5zaWduZWQgd2hl biBpdCBpcyByZXRyaWV2ZWQNCiBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCBkaXJlY3RseSB1c2lu ZyB0aGUgY29kZSBmbG93LiBUaGUgZXF1aXZhbGVudCBvZiB0aGlzIGlzIHRoZSBvbmx5IHBsYWNl IHRoYXQgVHhBdXRoIHdvdWxkIGJlIHNlbmRpbmcgYmFjayB1c2VyIGNsYWltcyBkaXJlY3RseS4g V2Ugbm8gbG9uZ2VyIGhhdmUgYSBuZWVkIHRvIHByb3RlY3QgdGhpbmdzIGFzIHRoZXkgdHJhdmVs IHRocm91Z2ggdGhlIGZyb250IGNoYW5uZWwgb24gYSByZWRpcmVjdCwgYW5kIHdlDQogbm8gbG9u Z2VyIGhhdmUgYSBuZWVkIHRvIHVzZSB0aGUgdXNlcuKAmXMgY2xhaW1zIGFzIGFuIGFydGlmYWN0 IGZvciB0aGluZ3MgbGlrZSBzZXNzaW9uIG1hbmFnZW1lbnQgKHdlIGNhbiBkZWZpbmUgYSBuZXcg YXJ0aWZhY3QgZm9yIHRoYXQgcHVycG9zZSB0aGF0IGZpdHMgYmV0dGVyKS4gVGhpcyBlZmZlY3Rp dmVseSBtZWFucyB0aGF0IHdlIGRvbuKAmXQgbmVlZCB0byByZWRlZmluZSB0aGUgSUQgVG9rZW4g YmVjYXVzZSB3ZSBkb27igJl0IG5lZWQgdGhlDQogZXF1aXZhbGVudCBvZiB0aGUgSUQgdG9rZW4g aW4gdGhlIHNhbWUgd2F5Li4gRm9yIHRoZSBjYXNlcyB0aGF0IHdlIGRvIG5lZWQgdG8gZGVmaW5l IHVzZXIgY2xhaW1zLCB3ZSBzaG91bGQgYmUgZGVmaW5pbmcgdGhlbSBhcyBhIEpTT04gb2JqZWN0 IG1vZGVsLiBBbmQgSSBhbHNvIGJlbGlldmUgdGhhdCB0aGlzIEpTT04gZGF0YSBtb2RlbCBzaG91 bGQgbm90IGJlIGludGVydHdpbmVkIHdpdGggb3IgY29uc3RyYWluZWQgYnkgdGhlIEpXVCBjbGFp bXMNCiByZWdpc3RyeS4gVGhlIE9JREMgY2xhaW1zIHJlZ2lzdHJ5IGNhbiBzZXJ2ZSBhcyBpbmZs dWVuY2UgYW5kIGlucHV0IHRvIG91ciB1c2VyIGNsYWltcyBzZXQgaWYgd2UgY2hvb3NlLCBidXQg SSBkb27igJl0IHRoaW5rIHdlIHNob3VsZCBiZSBpbnRlcnR3aW5lZCB3aXRoIHRoYXQgZWl0aGVy LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZGlzYWdyZWUuIEkgdGhpbmsgaXQgaXMgbGlrZWx5IHRo YXQgd2Ugd2lsbCBzZWUgYW4gaW5jcmVhc2UgaW4gc2lnbmVkIGNsYWltcyBhbmQgbWVzc2FnZXMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu IG15IG9waW5pb24sIHRoZSBwcm92aWRlbmNlIG9mIGEgY2xhaW0gb3IgbWVzc2FnZSBpcyBmYXIg bW9yZSBpbXBvcnRhbnQgdGhhbiBwcm90ZWN0aW9uIGR1cmluZyB0cmFuc2l0LiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5DbGll bnQgLyBBUyBub24tcmVwdWRpYXRpb248L2I+OiB3aGVuIHNlbnNpdGl2ZSBvcGVyYXRpb25zIGFy ZSBwZXJmb3JtZWQgcmVseWluZyBvbiB0aGUgY29udGVudHMgb2YgYSBjbGFpbSwgdGhlIENsaWVu dCB3aWxsIHdhbnQgcmVwdWRpYXRpb24gdGhhdCB0aGUgQVMgb3IgY2xhaW1zIGlzc3VlciBtYWRl IGEgY2xhaW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPlNlcGFyYXRpb24gb2YgZHV0aWVzIGluIGNvbXBsZXggc3lzdGVtczwvYj46IElu IGxhcmdlIG9yZ2FuaXphdGlvbnMsIGEgbWFqb3Igc2VjdXJpdHkgdGhyZWF0IGlzIGEgbWFsaWNp b3VzIGluc2lkZXIuIE9uY2UgYW4gb3JnYW5pemF0aW9uIHJlYWNoZXMgYSBjZXJ0YWluIHNpemUs IHlvdSBhc3N1bWUgdGhlcmUgYXJlIHBlb3BsZSBlbXBsb3llZCBhdCB0aGUgY29tcGFueSB0aGF0 IGRvIG5vdCBoYXZlIHRoZQ0KIGZpcm1zIGJlc3QgaW50ZXJlc3RzIGluIG1pbmQuIE9uZSBtaXRp Z2F0aW9uIG9mIHRoaXMgdGhyZWF0IGlzIGRvbmUgYnkgc2VwYXJhdGluZyB3aGF0IGRpZmZlcmVu dCB0ZWFtcyBjYW4gZG8gd2l0aCBjdXN0b21lciAvIHNlbnNpdGl2ZSBkYXRhLCByZXF1aXJpbmcg Y29sbHVzaW9uIHRvIGFjY2VzcyBvciBtb2RpZnkgdGhlIGRhdGEuIFNpZ25lZCBtZXNzYWdlcyBh bmQgY2xhaW1zIHNpbXBsaWZ5IGRpZmZlcmVudCBjb21wb25lbnRzIGJlaW5nIGFibGUNCiB0byBp bmRlcGVuZGVudGx5IHZlcmlmeSBhIG1lc3NhZ2Ugb3IgY2xhaW0uIFNpbWlsYXJseSwgYSBjb21w b25lbnQgaXNzdWluZyBhIGNsYWltLCBoYXMgYXNzdXJhbmNlIHRoYXQgb3RoZXIgY29tcG9uZW50 cyBpbiB0aGUgc2FtZSBzeXN0ZW0gYXJlIG5vdCBtb2RpZnlpbmcgaXQuIExhcmdlIG9yZ2FuaXph dGlvbnMgd3JhcCBleHRlcm5hbCBzeXN0ZW1zIHRoYXQgZG8gbm90IHN1cHBvcnQgdGhpcyB3aXRo IHRoZWlyIG93biBzZWN1cml0eSBtZWNoYW5pc20NCiAtLSBidXQgbm90IGFsbCBvcmdhbml6YXRp b25zIGFyZSB0aGlzIHNvcGhpc3RpY2F0ZWQsIGFuZCBhcyB0aGV5IGdyb3csIHJldHJvZml0dGlu ZyBpcyBkaWZmaWN1bHQuIEVuYWJsaW5nIGVuZCB0byBlbmQgcHJvdmlkZW5jZSBpcyBhIGJlc3Qg cHJhY3RpY2UgaW4gbXkgb3Bpbmlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+VXNlciBDb25zZW50IEF1ZGl0PC9iPjogYXMgcHJpdmFj eSBiZWNvbWVzIGEgbGFyZ2VyIHB1YmxpYyB0b3BpYywgaXQgaXMgZWFzeSB0byBpbWFnaW5lIG9y Z2FuaXphdGlvbnMgd2FudGluZyB0byBwcm92ZSB0aGF0IHRoZXkgb2J0YWluZWQgdXNlciBpbmZv cm1hdGlvbiB3aXRoIGNvbnNlbnQuIFJhdGhlciB0aGFuIGdhdGhlcmluZyB1c2VyIGluZm9ybWF0 aW9uIGRpcmVjdGx5IGZyb20gdGhlIHVzZXIsIGENCiBDbGllbnQgY2FuIGFjcXVpcmUgY2xhaW1z IGZyb20gdGhlIFVzZXIncyBjbGFpbXMgcHJvdmlkZXIgdGhhdCBhc3NlcnRzIHRoZSB1c2VyIHBy b3ZpZGVkIGNvbnNlbnQgdG8gdGhlIENsaWVudC4gVGhlIENsaWVudCBjYW4gdGhlbiB0ZWNobmlj YWxseSBlc3RhYmxpc2ggdGhhdCBhbGwgdXNlciBkYXRhIHdhcyBnYXRoZXJlZCB3aXRoIGNvbnNl bnQsIGFuZCB0aGUgY29udGV4dCBvZiB0aGUgY29uc2VudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgdGhlIG1lc3NhZ2UgY29udGFp bmluZyB0aGUgY2xhaW1zIG1heSBiZSBzaWduZWQsIGhhdmluZyBpbmRlcGVuZGVudCBjbGFpbXMg c2VwYXJhdGVseSBzaWduZWQgc2ltcGxpZmllcyB0aGUgbGVhc3QgcHJpdmlsZWdlIHRlbmV0LCB3 aGVyZSBhIGNvbXBvbmVudCBvbmx5IGhhcyBhY2Nlc3MgdG8gdGhlIHVzZXIgaW5mb3JtYXRpb24g aXQgbmVlZHMuLiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4vRGljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_7833DDB1FB88415184B68DABB6436B53amazoncom_-- From nobody Wed Jan 29 16:55: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 D3BDD120047 for ; Wed, 29 Jan 2020 16:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.4 X-Spam-Level: X-Spam-Status: No, score=-14.4 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 dSFSgkSqJ3ie for ; Wed, 29 Jan 2020 16:55:45 -0800 (PST) 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 76656120018 for ; Wed, 29 Jan 2020 16:55:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1580345745; x=1611881745; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=80bDwHk5hgR/5sVZaDzQKBV/unNbxpPwD5W1G4PDJcs=; b=ibzbAd7NHq/D0mVxFN2JMkEBKa3DQWFaEhL5koMf/5wVoxObxMUCDTCb f02DzayQYkVzlLj+SPkqIcVB9omcj1DmBL9qkqAAMs9wNs8Wn/MUnAhot f3Jm+kWrx9Mp9tuuZB3ZHQOgnI6TmXfROnX0GVD0yIpbvXxqiIErTTRms 8=; IronPort-SDR: kESgUR3F1efpcU89B3Yj3tSKYSIZk/+UvcqFlFqPyRQmQ6Sagi+ebAKAMp2KZdBoVA06fc1wcP YU1I1M9L9NtA== X-IronPort-AV: E=Sophos; i="5.70,380,1574121600"; d="scan'208,217"; a="21928589" 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-9102.sea19.amazon.com with ESMTP; 30 Jan 2020 00:55:33 +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 4C309A3A73; Thu, 30 Jan 2020 00:55:33 +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, 30 Jan 2020 00:55:32 +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.1367.3; Thu, 30 Jan 2020 00:55:32 +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.1367.000; Thu, 30 Jan 2020 00:55:32 +0000 From: "Richard Backman, Annabelle" To: Justin Richer , "txauth@ietf.org" CC: Kim , Mike Jones , Torsten Lodderstedt , Dick Hardt , "Richard Backman, Annabelle" Thread-Topic: [Txauth] [EXTERNAL] Re: Questions on the TxAuth charter Thread-Index: AQHV1oNewUIDL3ZtxkShH8+4e1meTqgBg6iAgABZJYA= Date: Thu, 30 Jan 2020 00:55:32 +0000 Message-ID: <792B1100-064C-48DD-BD63-9C1A9BEFE859@amazon.com> References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> <585BCD70-6B64-4058-AC70-B677695DB391@mit.edu> In-Reply-To: <585BCD70-6B64-4058-AC70-B677695DB391@mit.edu> 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.29] Content-Type: multipart/alternative; boundary="_000_792B1100064C48DDBD639C1A9BEFE859amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] [EXTERNAL] Re: Questions on the 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, 30 Jan 2020 00:55:49 -0000 --_000_792B1100064C48DDBD639C1A9BEFE859amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gZ29pbmcgdG8gYXBwcm9hY2ggdGhpcyBmcm9tIGEgZGlmZmVyZW50IGFuZ2xl4oCmIEFz IEnigJl2ZSBzYWlkIGJlZm9yZSwgSSB0aGluayBhIGNoYXJ0ZXIgc2hvdWxkIGJlIGNsb3NlciB0 byBhIHByb2JsZW0gc3RhdGVtZW50IHRoYW4gYSBkZXNpZ24gZG9jdW1lbnQuIEl0IHNob3VsZCBm b2N1cyBvbiB3aGF0IHRoZSBncm91cCBpcyB0cnlpbmcgdG8gZG8sIG5vdCBob3cgdGhleeKAmXJl IGdvaW5nIHRvIGRvIGl0LiBUaGUgcmVhc29uIGZvciB0aGUgd29ya2luZyBncm91cCBpcywgYWZ0 ZXIgYWxsLCB0byBmaWd1cmUgb3V0IHRoZSDigJxob3figJ0gcGFydC4gVG8gdGhhdCBlbmQsIGEg Y2hhcnRlciBzaG91bGQgbm90IHByZXNjcmliZSBzcGVjaWZpYyB0ZWNobm9sb2dpZXMgb3IgZGVz aWduIGNob2ljZXMuIERvaW5nIHNvIHVubmVjZXNzYXJpbHkgY29uc3RyYWlucyB0aGUgd29ya2lu ZyBncm91cCBhbmQgcHJvdmlkZXMgemVybyBiZW5lZml0LiBJZiBldmVyeW9uZSBhZ3JlZXMgdGhh dCB0ZWNobm9sb2d5IFggaXMgdGhlIHJpZ2h0IGNob2ljZSB3aGVuIHdyaXRpbmcgdGhlIGNoYXJ0 ZXIsIHRoZXnigJlsbCBhZ3JlZSB0aGF0IGl0IGlzIHRoZSByaWdodCBjaG9pY2Ugd2hlbiB3cml0 aW5nIHdvcmtpbmcgZ3JvdXAgZHJhZnRz4oCmdW5sZXNzIHNvbWV0aGluZyBoYXMgY2hhbmdlZCDi gJMgbmV3IGluZm9ybWF0aW9uIGhhcyBjb21lIG91dCwgbmV3IHVzZSBjYXNlcywgbmV3IHRlY2hu b2xvZ2llcywgYWRkaXRpb25hbCBzdGFrZWhvbGRlcnMgaGF2ZSBnb3R0ZW4gaW52b2x2ZWQsIGV0 Yy4g4oCTIGluIHdoaWNoIGNhc2UgaXQgbWF5IGJlIHZlcnkgaW1wb3J0YW50IHRoYXQgdGhlIHdv cmtpbmcgZ3JvdXAgaGF2ZSB0aGUgZnJlZWRvbSB0byBleHBsb3JlIG90aGVyIG9wdGlvbnMuDQoN ClNvbWV0aW1lcyB0aGUgcHJvYmxlbSB0byBiZSBzb2x2ZWQgbmVlZHMgdG8gYmUgc2NvcGVkIGRv d24gYWxvbmcgdGVjaG5vbG9neSBsaW5lcyAoZS5nLiwgSFRUUCBBUElzIHZlcnN1cyBBUElzIG9u IGFueSBwcm90b2NvbCBpbWFnaW5hYmxlKSBpbiBvcmRlciB0byBtYWtlIGl0IHRyYWN0YWJsZS4g SSBhbSBub3Qgb3Bwb3NlZCB0byB0aG9zZSBjb25zdHJhaW50cyB3aGVuIHRoZXkgYXJlIG5lZWRl ZCwgdGhvdWdoIG9mdGVuIHRoZXkgY2FuIGJlIGhhbmRsZWQgd2l0aCBhIOKAnHdlIHdpbGwgaW5p dGlhbGx5IGZvY3VzIG9u4oCm4oCdIHJhdGhlciB0aGFuIGEgaGFyZCDigJx3ZSB3aWxsIG9ubHkg c3VwcG9ydOKApuKAnSBhcyBkZW1vbnN0cmF0ZWQgYnkgdGhlIFR4QXV0aCBjaGFydGVy4oCZcyBh cHByb2FjaCB0byBIVFRQIHZzIENPQVAuIEluIGFueSBjYXNlLCBJIGRvIG5vdCBzZWUgSldUIG9y IE9JREMgY2xhaW1zIGFzIG5lY2Vzc2FyeSBjb25zdHJhaW50cyB0byBzY29wZSB0aGUgcHJvYmxl bSBkb3duLiBUaGV5IG1heSB3ZWxsIGJlIHRoZSByaWdodCBjaG9pY2VzIGZvciB3aGF0IHRoZXkg YXJlIGJlaW5nIHN1Z2dlc3RlZCBmb3IgaGVyZSwgYnV0IGhhdmluZyB0aGF0IGRlYmF0ZSBub3cg aXMgdW5uZWNlc3NhcnkgYW5kIHBvdGVudGlhbGx5IGhhcm1mdWwgKHNlZSBhYm92ZSksIGFuZCB3 aWxsIG5lZWRsZXNzbHkgZGVsYXkgdGhlIGZvcm1hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cCBh bmQgZGV2ZWxvcG1lbnQgb2YgdGhlIHByb3RvY29sLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJk IEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNA aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+DQpE YXRlOiBXZWRuZXNkYXksIEphbnVhcnkgMjksIDIwMjAgYXQgMzozOCBBTQ0KVG86ICJ0eGF1dGhA aWV0Zi5vcmciIDx0eGF1dGhAaWV0Zi5vcmc+DQpDYzogS2ltIDxraW1AaWRlbnRpdHlibG9nLmNv bT4sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4sIFRvcnN0ZW4gTG9k ZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiwgRGljayBIYXJkdCA8ZGljay5oYXJk dEBnbWFpbC5jb20+LCAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYT00MGFt YXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1R4YXV0aF0gW0VYVEVSTkFM XSBSZTogUXVlc3Rpb25zIG9uIHRoZSBUeEF1dGggY2hhcnRlcg0KDQpJIGdvdCBhIGNoYW5jZSB0 byBjaGF0IHdpdGggTWlrZSBhbmQgSSB3YW50ZWQgdG8gZXhwYW5kIG15IG9mZi10aGUtY3VmZiBy ZXNwb25zZSAoYmVsb3cpIHdpdGggc29tZSBtb3JlIGRldGFpbCB0aGFuIEkgd2FzIGFibGUgdG8g d3JpdGUgaW4gdGhlIG1vbWVudCwgYmVjYXVzZSBJIGRvbuKAmXQgdGhpbmsgdGhhdCB3ZeKAmXJl IGFjdHVhbGx5IHRoYXQgZmFyIGFwYXJ0Lg0KDQpUbyBzdGFydCwgaXQgd2FzbuKAmXQgb2J2aW91 cyB0byBtZSAoYW5kIG1pZ2h0IG5vdCBoYXZlIGJlZW4gdG8gb3RoZXJzKSB0aGUgc3BlY2lmaWMg cHJlY2lzaW9uIG9mIE1pa2XigJlzIHN0YXRlbWVudCBiZWxvdy4gSGUgY2xhcmlmaWVkIHRvIG1l IHRoYXQgd2hhdCBoZSBtZWFucyBpcyB0aGF0IHdoZXJlIHVzZXIgY2xhaW1zIGFyZSBzaWduZWQg b3IgZW5jcnlwdGVkLCB0aGVuIEpXVCBwcm92aWRlcyBhbiBvYnZpb3VzIHdheSB0byBkbyBpdC4g SW4gb3RoZXIgd29yZHMsIOKAnGRvbuKAmXQgcmUtaW52ZW50IHRoZSBJRCBUb2tlbiB3aXRoIG5l dyBjcnlwdG/igJ0uIFRoZXJlIGFyZSBzZXZlcmFsIHRoaW5ncyB0byBhZGRyZXNzIGhlcmUgd2l0 aCB0aGF0IGluIG1pbmQuDQoNCkZpcnN0LCBJIGRvbuKAmXQgYmVsaWV2ZSB0aGVyZSBhcmUgZ29p bmcgdG8gYmUgbWFueSwgaWYgYW55LCBjYXNlcyB3aGVyZSB3ZSBuZWVkIHVzZXIgY2xhaW1zIHRv IGJlIHNpZ25lZCBhbmQgZW5jcnlwdGVkIHNlcGFyYXRlbHkgZnJvbSB0aGUgY29yZSB0cmFuc2Fj dGlvbiBtZXNzYWdlcy4gRXZlbiBpbiBPSURDLCB0aGUgSUQgVG9rZW4gaXMgYWxsb3dlZCB0byBi ZSB1bnNpZ25lZCB3aGVuIGl0IGlzIHJldHJpZXZlZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCBk aXJlY3RseSB1c2luZyB0aGUgY29kZSBmbG93LiBUaGUgZXF1aXZhbGVudCBvZiB0aGlzIGlzIHRo ZSBvbmx5IHBsYWNlIHRoYXQgVHhBdXRoIHdvdWxkIGJlIHNlbmRpbmcgYmFjayB1c2VyIGNsYWlt cyBkaXJlY3RseS4gV2Ugbm8gbG9uZ2VyIGhhdmUgYSBuZWVkIHRvIHByb3RlY3QgdGhpbmdzIGFz IHRoZXkgdHJhdmVsIHRocm91Z2ggdGhlIGZyb250IGNoYW5uZWwgb24gYSByZWRpcmVjdCwgYW5k IHdlIG5vIGxvbmdlciBoYXZlIGEgbmVlZCB0byB1c2UgdGhlIHVzZXLigJlzIGNsYWltcyBhcyBh biBhcnRpZmFjdCBmb3IgdGhpbmdzIGxpa2Ugc2Vzc2lvbiBtYW5hZ2VtZW50ICh3ZSBjYW4gZGVm aW5lIGEgbmV3IGFydGlmYWN0IGZvciB0aGF0IHB1cnBvc2UgdGhhdCBmaXRzIGJldHRlcikuIFRo aXMgZWZmZWN0aXZlbHkgbWVhbnMgdGhhdCB3ZSBkb27igJl0IG5lZWQgdG8gcmVkZWZpbmUgdGhl IElEIFRva2VuIGJlY2F1c2Ugd2UgZG9u4oCZdCBuZWVkIHRoZSBlcXVpdmFsZW50IG9mIHRoZSBJ RCB0b2tlbiBpbiB0aGUgc2FtZSB3YXkuIEZvciB0aGUgY2FzZXMgdGhhdCB3ZSBkbyBuZWVkIHRv IGRlZmluZSB1c2VyIGNsYWltcywgd2Ugc2hvdWxkIGJlIGRlZmluaW5nIHRoZW0gYXMgYSBKU09O IG9iamVjdCBtb2RlbC4gQW5kIEkgYWxzbyBiZWxpZXZlIHRoYXQgdGhpcyBKU09OIGRhdGEgbW9k ZWwgc2hvdWxkIG5vdCBiZSBpbnRlcnR3aW5lZCB3aXRoIG9yIGNvbnN0cmFpbmVkIGJ5IHRoZSBK V1QgY2xhaW1zIHJlZ2lzdHJ5LiBUaGUgT0lEQyBjbGFpbXMgcmVnaXN0cnkgY2FuIHNlcnZlIGFz IGluZmx1ZW5jZSBhbmQgaW5wdXQgdG8gb3VyIHVzZXIgY2xhaW1zIHNldCBpZiB3ZSBjaG9vc2Us IGJ1dCBJIGRvbuKAmXQgdGhpbmsgd2Ugc2hvdWxkIGJlIGludGVydHdpbmVkIHdpdGggdGhhdCBl aXRoZXIuDQoNClNlY29uZCwgaW4gc3BpdGUgb2YgdGhlIHN1Y2Nlc3Mgb2YgT0lEQywgdGhlcmUg YXJlIHNldmVyYWwgZm9ybWF0cyBvdXQgdGhlcmUgZm9yIHVzZXIgY2xhaW1zIGJleW9uZCBKV1Qg YW5kIEpPU0UuIFZlcmlmaWFibGUgQ3JlZGVudGlhbHMgKFZDLCBodHRwczovL3d3dy53My5vcmcv VFIvdmMtZGF0YS1tb2RlbC8pIGlzIG9uZSB0aGF0IGhhcyBzZXZlcmFsIGRpZmZlcmVudCBmb3Jt YXRzLCBhbmQgd2UgYXJlIGFsc28gc2VlaW5nIHN5c3RlbXMgYnVpbHQgdXAgYXJvdW5kIENPU0Ug YW5kIENCT1IgKGxpa2UgSVBMRCwgaHR0cHM6Ly9pcGxkLmlvLykuIE9yIHlvdSBjb3VsZCBldmVu IHVzZSBhIFNBTUwgZG9jdW1lbnQuIEkgZG9u4oCZdCB0aGluayBUeEF1dGggc2hvdWxkIHBpY2sg anVzdCBvbmUgb2YgdGhlc2UuIEluc3RlYWQsIEkgd2FudCBUeEF1dGggdG8gZGVmaW5lIHBsYWNl cyB0byBwdXQgdGhlc2UgZm9ybWF0cyBpbiByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzLiBJbiBteSBk cmFmdCB0aGVyZeKAmXMgYSBzcG90IGZvciBhbiBPSURDIHN0eWxlIElEIFRva2VuIG9yIGEgVkMg ZG9jdW1lbnQsIGlmIHlvdSBoYXZlIG9uZS4gV2l0aGluIGVhY2ggb2YgdGhlc2UsIGJ5IGFsbCBt ZWFucywgbGV04oCZcyBsb2NrIHRoZW0gZG93biBhbmQgc2F5IHRoYXQgdGhlIOKAnG9pZGNfaWRf dG9rZW7igJ0gZmllbGQgaXMgYSBKV1QgaW4gY29tcGFjdCBmb3JtYXQgdGhhdCBNVVNUIGJlIHNp Z25lZCwgZXRjLiBBbmQgSSB0aGluayBpdCBtYWtlcyBsaXR0bGUgc2Vuc2UgdG8gaW52ZW50IG91 ciBvd24gY3VzdG9tIGZvcm1hdCB0byBkbyBleGFjdGx5IHRoYXQga2luZCBvZiB0aGluZy4NCg0K VGhpcmQsIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGRu4oCZdCByZS1pbnZlbnQgYW4gZXhpc3Rpbmcg Y3J5cHRvIGZvcm1hdCwgYW5kIEnigJlsbCBnbyBmdXJ0aGVyIHRoYXQgd2Ugc2hvdWxkbuKAmXQg YmUgaW52ZW50aW5nIGNyeXB0byBhdCBhbGwuIFRoaXMgZG9lc27igJl0IG1lYW4gd2UgaGF2ZSB0 byBwaWNrIG9uZSBhbmQgb25seSBvbmUsIGJlY2F1c2UgdGhpcyBpcyBvbmUgb2YgdGhlIHNwYWNl cyB0aGF0IHdlIGNhbiAoYW5kIEkgYXJndWUgc2hvdWxkKSBoYXZlIHNvbWUgYWdpbGl0eS4gV2Ug Y2FuIGRlZmluZSB0aGUgcHJvdG9jb2wgaW4gdGVybXMgb2YgSlNPTiBhbmQgdGhlbiBoYXZlIGEg c3VpdGUgb2YgY3J5cHRvZ3JhcGhpYyBjYXJyaWVycyB0aGF0IHByb3RlY3QgdGhhdCBKU09OLCBp bmNsdWRpbmcgSk9TRSwgSFRUUCBNZXNzYWdlIFNpZ25hdHVyZXMsIGFuZCBNdXR1YWwgVExTLiBU aGVyZSBhcmUgYSBidW5jaCBvZiBvdGhlcnMgb3V0IHRoZXJlIGFzIHdlbGwsIGxpa2UgdGhlIERQ b1Aga2V5IHByZXNlbnRhdGlvbiBjb21pbmcgb3V0IG9mIE9BdXRoIDIgcmlnaHQgbm93LCB0aGF0 IHNob3VsZCBiZSBzd2l0Y2hhYmxlIGFzIG9wdGlvbnMgaGVyZSBiZWNhdXNlIHRoZXnigJlyZSBn b2luZyB0byBhcHBseSB0byBkaWZmZXJlbnQgdXNlIGNhc2VzIGFuZCBkZXBsb3ltZW50cy4gUGx1 cywgdGhhdCBKU09OIGNvdWxkIGJlIHRyYW5zbGF0ZWQgdG8gQ0JPUiAod2l0aG91dCBkYXRhIG9y IHN0cnVjdHVyZSBsb3NzKSBhbmQgcHJvdGVjdGVkIGJ5IENPU0Ug4oCUIGV2ZW4gaWYgd2UgZG9u 4oCZdCBkZWZpbmUgdGhhdCBvdXJzZWx2ZXMsIHRoZSBmYWN0IHRoYXQgd2XigJlyZSBidWlsZGlu ZyBvdXIgc3RydWN0dXJlIG9uIHJhdyBKU09OIG1lYW5zIHRoYXQgaXQgY2FuIGJlIHRyYW5zbGF0 ZWQgbW9yZSBlYXNpbHkgbGF0ZXIuDQoNCkZvdXJ0aCwgSSBhbSB2ZXJ5IHNlbnNpdGl2ZSB0byBj YWxsaW5nIG91dCBwcmVmZXJyZWQgY3J5cHRvIHNvbHV0aW9ucyBiZWNhdXNlIEkgYmVsaWV2ZSB0 aGF0IGxlbmRzIHRvIHVzIHVzaW5nIHRoYXQgYXMgYW4gZXhjdXNlIHRvIHVzZSB0aGF0IHBhcnRp Y3VsYXIgaGFtbWVyIHRvIHNvbHZlIGFsbCB0aGUgcHJvYmxlbXMuIFRoZXJlIGhhdmUgYmVlbiBw cm9wb3NhbHMgdG8gbWFrZSB0aGUgZW50aXJlIHByb3RvY29sIEpXVHMgaW4gYWxsIGRpcmVjdGlv bnMsIGZvciBpbnN0YW5jZSwgdGhhdCBJIHRoaW5rIGFyZSByZWFsbHkgcHJvYmxlbWF0aWMgYmVj YXVzZSBvZiB0aGUgbGltaXRzIHRoYXQgaXQgcGxhY2VzIG9uIGV4cHJlc3Npb24gb2YgaXRlbXMg b3V0c2lkZSBvZiB0aGUgcGF5bG9hZCBpdHNlbGYuIFRoaXMgaXMgbm90IHdoYXQgTWlrZSBpcyBz dWdnZXN0aW5nIGJlbG93LCBidXQgaXTigJlzIGEgcG90ZW50aWFsIGZhbGxvdXQgZnJvbSB3aGF0 IGhlIGRvZXMgcHJvcG9zZS4NCg0KDQoNCkluIGNvbmNsdXNpb24sIEpPU0UgYW5kIEpXVCBhcmUg ZmFudGFzdGljIGFuZCB0aGV5IHNvbHZlIGEgbG90IG9mIHByb2JsZW1zIGluIGFuIGVsZWdhbnQg d2F5LiBCdXQgSSB0aGluayB3ZSBuZWVkIHRvIHF1ZXN0aW9uIHdoZXRoZXIgd2UgbmVlZCB0aGVp ciBzb2x1dGlvbnMgYXQgYWxsLCBhbmQgd2hlcmUgd2UgZG8sIGlmIHdlIHdhbnQgdG8gZW5hYmxl IG90aGVyIHNvbHV0aW9ucyBhcyB3ZWxsLiBJbiBteSB2aWV3LCB3ZSBkb27igJl0IG5lZWQgSk9T RS9KV1QgYmVjYXVzZSB3ZSBhdm9pZCB0aGUgcHJvYmxlbXMgdGhhdCB0aGV5IHNvbHZlLCBhbmQg dGhlIHBsYWNlcyB0aGF0IHdlIGRvIHdhbnQgdG8gdXNlIHRoZW0gSSBzdHJvbmdseSBiZWxpZXZl IHRoZXJlIGFyZSBhbHJlYWR5IG90aGVyIGFsdGVybmF0aXZlcyB0aGF0IHdlIHdhbnQgdG8gaGF2 ZSBhcyBvcHRpb25zLg0KDQpTbyBJIHdhbnQgdG8gaGF2ZSBKT1NFLCBidXQgaXQgbmVlZHMgdG8g YmUgaW4gdGhlIHJpZ2h0IHBsYWNlcyBhbmQgSSBkbyBub3Qgd2FudCBpdCB0byBiZSBhIGRlcGVu ZGVuY3kgb24gYWxsIGltcGxlbWVudGF0aW9ucy4gSSB0aGluayB0aGF0IHdlIGNhbiBkbyB0aGF0 IHdpdGhvdXQgc2F5aW5nIEpXVCBpcyBhIHByZWZlcnJlZCBmb3JtYXQuIEkgdGhpbmsgaXTigJlz IG1vcmUgaW1wb3J0YW50IHRoYXQgdGhlIGNoYXJ0ZXIgaW5jb3Jwb3JhdGUgc3BlY2lmaWMgdGV4 dCBvZiB3aGF04oCZcyBvdXQgb2Ygc2NvcGUsIGluY2x1ZGluZyBkZWZpbmluZyBhIGNyeXB0b2dy YXBoaWMgcHJvdGVjdGlvbiBtZWNoYW5pc20uDQoNCk9uZSBvZiB0aGUgaGFyZGVzdCB0aGluZ3Mg Zm9yIGEgc3RhbmRhcmQgdG8gZG8gaXMgZGV0ZXJtaW5lIHdoZXJlIHRoZSBmbGV4aWJpbGl0eSBz aG91bGQgYmUuIE15IHN0YW5jZSBpcyB0aGF0IHdlIHNob3VsZCBoYXZlIGEgc3RydWN0dXJhbCBm b3JtYXQgYmFzZWQgb24gSlNPTiBidXQgdGhhdCB0aGUgY29udGVudHMgb2YgdGhhdCBKU09OIGFy ZSBleHRlbnNpYmxlIGJ1dCB0aGF0IGVhY2ggcG9ydGlvbiBhbmQgZXh0ZW5zaW9uIGFyZSB2ZXJ5 IHN0cmljdCBhYm91dCB3aGF04oCZcyB0aGVyZS4gQW5vdGhlciBrZXkgZmxleGlibGUgcG9pbnQg aXMgdGhhdCB0aGUgY29udGVudCBvZiB0aGUgSlNPTi1iYXNlZCBwYXlsb2FkcyBjYW4gYmUgcHJv dGVjdGVkIGluIGEgdmFyaWV0eSBvZiB3YXlzLiBDaG9pY2UgY2FuIGJlIGRlYmlsaXRhdGluZywg YnV0IGl0IGNhbiBhbHNvIGJlIGZyZWVpbmcuIFBpbm5pbmcgZXZlcnl0aGluZyB0byBKT1NFIHdv dWxkIGRvIHVzIGEgZGlzc2VydmljZS4NCg0KIOKAlCBKdXN0aW4NCg0KDQpPbiBKYW4gMjksIDIw MjAsIGF0IDEwOjA1IEFNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpy aWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KDQpJIHN0cm9uZ2x5IG9iamVjdCB0byBjYWxsaW5nIG91 dCBKV1RzIGFzIHRoZSBwcmVmZXJyZWQgc29sdXRpb24gZm9yIHNpZ25lZCBhbmQgZW5jcnlwdGVk IGNsYWltcyB3aXRoaW4gdGhpcyB3b3JraW5nIGdyb3VwLg0KDQog4oCUIEp1c3Rpbg0KDQoNCk9u IEphbiAyOSwgMjAyMCwgYXQgOTo1MCBBTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0K VGhhbmtzIGZvciB3cml0aW5nIHRoZXNlIGRldGFpbGVkIHF1ZXN0aW9ucywgS2ltLiAgSSBiZWxp ZXZlIHRoYXQgdGhleSBwb2ludCBvdXQgYSBudW1iZXIgb2YgcGxhY2VzIHdoZXJlIGV2ZW4gZXhw ZXJ0cyBpbiB0aGUgZmllbGQsIHN1Y2ggYXMgeW91cnNlbGYsIGN1cnJlbnRseSBoYXZlIHRyb3Vi bGUgdW5kZXJzdGFuZGluZyBwYXJ0cyBvZiB3aGF0IHRoZSBjaGFydGVyIGlzIHByb3Bvc2luZyB0 aGF0IHdlIGRvIOKAkyBwYXJ0aWFsbHkgYmVjYXVzZSB0ZXJtaW5vbG9neSBpcyB1c2VkIHRoYXQg aXNu4oCZdCBjb21tb25seSB1bmRlcnN0b29kLiAgSSBob3BlIHRoYXQgdGhlIGRyYWZ0IGNoYXJ0 ZXIgd2lsbCBiZSByZXZpc2VkIHRvIG1ha2UgdGhlIGludGVudCBhbmQgdGhlIGdvYWxzIG1vcmUg YWNjZXNzaWJsZSBhbmQgbGVzcyBhbWJpZ3VvdXMuDQoNClJlc3BvbmRpbmcgdG8gdGhlIGRpc2N1 c3Npb24gb24gd2hldGhlciBleGlzdGluZyBKV1QgaWRlbnRpdHkgY2xhaW1zIHdpbGwgZG8gdGhl IGpvYiBvciBub3QsIGZvcnR1bmF0ZWx5LCBldmVuIGlmIHRoZXkgZG9u4oCZdCwgdGhlcmXigJlz IGEgbWVjaGFuaXNtIHRvIGFkZCBvbmVzIHRoYXQgZG86IHRoZSBJQU5BIEpTT04gV2ViIFRva2Vu IENsYWltcyByZWdpc3RyeSBhdCBodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9qd3Qv and0LnhodG1sI2NsYWltcy4gIEZvciBpbnN0YW5jZSwgYW4g4oCcZW1haWxfYWRkcmVzc2Vz4oCd IGNsYWltIHRoYXQgaXMgYXJyYXktdmFsdWVkIGNvdWxkIGJlIGRlZmluZWQgYW5kIHJlZ2lzdGVy ZWQgaWYgdGhlcmXigJlzIGEgbmVlZCB0byByZXByZXNlbnQgbXVsdGlwbGUgZS1tYWlsIGFkZHJl c3NlcywgcGVyIEFubmFiZWxsZeKAmXMgZXhhbXBsZS4gIFRoZSBmdXJ0aGVyIGdvb2QgbmV3cyBp cyB0aGF0IGlmIHRoZSB3b3JraW5nIGdyb3VwIGRlZmluZXMgbmV3IGNsYWltcyB0aGF0IGFyZSBy ZWdpc3RlcmVkLCB0aGV5IGNhbiBiZSByZXVzZWQgYnkgb3RoZXJzIGFsc28gdXNpbmcgSldUcyDi gJMganVzdCBsaWtlIHRoaXMgd29ya2luZyBncm91cCBjYW4gcmV1c2UgY2xhaW1zIGRlZmluZWQg Ynkgb3RoZXJzLg0KDQpBbHNvIG9uIHRoZSBzdWJqZWN0IG9mIEpXVHMsIEkgd291bGQgc3VnZ2Vz dCB0aGF0IHRoZSBjaGFydGVyIGJlIHVwZGF0ZWQgdG8gZXhwbGljaXRseSBjYWxsIG91dCB0aGF0 IEpXVHMgd2lsbCBiZSB0aGUgd29ya2luZyBncm91cOKAmXMgcHJlZmVycmVkIHJlcHJlc2VudGF0 aW9uIHNpZ25lZCBhbmQvb3IgZW5jcnlwdGVkIGNsYWltcy4NCg0KRmluYWxseSwgSSBhbHNvIHRo aW5rIHRoYXQgdGhlIGNoYXJ0ZXIgd291bGQgYmVuZWZpdCBmcm9tIGV4cGxpY2l0bHkgbGlzdGlu ZyB0aGluZ3MgdGhhdCBhcmUgb3V0IG9mIHNjb3BlICh3aGljaCBpcyBvZnRlbiBkb25lIGluIGNo YXJ0ZXJzKS4NCg0KVGhhbmtzIGFnYWluIGZvciBwcm9tcHRpbmcgdGhpcyB1c2VmdWwgZGlzY3Vz c2lvbiwgS2ltLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBUeGF1dGggPHR4YXV0aC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzp0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBKdXN0aW4g UmljaGVyDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjksIDIwMjAgMTI6NDYgQU0NClRvOiBU b3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3Rl bkBsb2RkZXJzdGVkdC5uZXQ+Pg0KQ2M6IEtpbSA8a2ltQGlkZW50aXR5YmxvZy5jb208bWFpbHRv OmtpbUBpZGVudGl0eWJsb2cuY29tPj47IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29t PG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+OyB0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4 YXV0aEBpZXRmLm9yZz47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00MGFt YXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFy Yy5pZXRmLm9yZz4+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbVHhhdXRoXSBRdWVzdGlvbnMg b24gdGhlIFR4QXV0aCBjaGFydGVyDQoNCkkgZGlkbuKAmXQgbWVhbiDigJxwYXRjaOKAnSB0byBz b3VuZCBkaXNwYXJhZ2luZywgc29ycnkgaWYgaXQgY2FtZSBhY3Jvc3MgYXMgc3VjaC4gV2hhdCBJ IG1lYW4gYnkg4oCccGF0Y2hpbmfigJ0gaGVyZSBpcyB0aGF0IGl0IGlzIGFkZGluZyBmdW5jdGlv bmFsaXR5IHRvIGFuIGV4aXN0aW5nIHNldCBvZiBjbGFpbXMgYW5kIHNjaGVtYS4gSWYgeW91IGFy ZSB1c2luZyB0aGF0IHNjaGVtYSBhcyBhIGJhc2UsIGl0IG1ha2VzIHNlbnNlIGFzIGEgdmlhYmxl IHNvbHV0aW9uIGluIHRoYXQgc3BhY2UuIEksIGhvd2V2ZXIsIGFtIGJyaW5naW5nIHVwIHRoZSBx dWVzdGlvbiBvZiB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGF0IHNjaGVtYSBhcyBvdXIgYmFzZSBh dCBhbGwuDQoNCknigJlsbCBub3RlIHRoYXQgODExMiBkb2VzbuKAmXQgZGVmaW5lIGEgc2NoZW1h IG9yIHN5bnRheCwgYm90aCBvZiB3aGljaCBhcmUgcmVxdWlyZWQuIEJ1dCBpZiB3ZSB3ZXJlIHN0 YXJ0aW5nIE9JREMgdG9kYXkgd2l0aCBFS1lD4oCZcyByZXF1aXJlbWVudHMsIEnigJltIG5vdCBj b252aW5jZWQgd2XigJlkIGVuZCB1cCB3aXRoIHRoZSBzYW1lIHN0cnVjdHVyZS4NCg0KQXMgd2l0 aCBldmVyeXRoaW5nLCBpdOKAmXMgYSB2ZXJ5IGltcG9ydGFudCBpbnB1dCBpbnRvIHdoYXQgd2Xi gJlyZSB0cnlpbmcgdG8gc29sdmUsIGVzcGVjaWFsbHkgaW5mbHVlbmNpbmcgd2hhdOKAmXMgZXh0 ZW5zaWJsZSBhbmQgaG93Lg0KDQog4oCUIEp1c3Rpbg0KDQoNCg0KT24gSmFuIDI5LCAyMDIwLCBh dCA4OjA2IEFNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxt YWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3cm90ZToNCg0KDQoNCg0KDQpBbSAyOS4w MS4yMDIwIHVtIDA3OjM0IHNjaHJpZWIgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1h aWx0bzpqcmljaGVyQG1pdC5lZHU+PjoNCkkgdGhpbmsgdGhlIGVreWMgd29yayBpcyBncmVhdCBm b3Igd2hhdCBpdCBpcywgYnV0IGFnYWluIHdlIGhhdmUgYW4gb3Bwb3J0dW5pdHkgdG8gdGFrZSBh IHN0ZXAgYmV5b25kIGl0LiBJbiBteSB2aWV3LCB3ZeKAmWQgYmUgYmV0dGVyIG9mZiBkZWZpbmlu ZyBhIG1lYW5zIG9mIHNwZWNpZnlpbmcgZmllbGQgbWV0YWRhdGEgYSBsYSBOSVNUIElSIDgxMTIg YXMgcGFydCBvZiB0aGUgc2NoZW1hIGluc3RlYWQgb2YgcGF0Y2hpbmcgdGhlIGV4aXN0aW5nIE9J REMgZmllbGRzLiBodHRwczovL3BhZ2VzLm5pc3QuZ292L05JU1RJUi04MTEyLzxodHRwczovL25h bTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZw YWdlcy5uaXN0LmdvdiUyRk5JU1RJUi04MTEyJTJGJmRhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9u ZXMlNDBtaWNyb3NvZnQuY29tJTdDOWZhZTUwMzY2OWY0NDNhMDk2ODMwOGQ3YTQ5N2M0NWYlN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTU4ODQ0MDQ5MzM4 MzQ0JnNkYXRhPXJPckthTzdNdkRES0x5ZkIyUWl2YlZUY2o1RW1SU0oxblJYWHMzMGpFejAlM0Qm cmVzZXJ2ZWQ9MD4NCg0KV2UgdHJpZWQgYW5kIGl0IGRpZCBub3QgZnVsZmlsbCBvdXIgcmVxdWly ZW1lbnRzLiB2ZXJpZmllZF9jbGFpbXMgaXMgYnkgbm8gbWVhbnMgYSBwYXRjaCwgaXTigJlzIGEg dmlhYmxlIHNvbHV0aW9uLg0KDQoNCg0KDQog4oCUIEp1c3Rpbg0KDQoNCg0KT24gSmFuIDI5LCAy MDIwLCBhdCA2OjEzIEFNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3cm90ZToNCg0KDQoNCg0KDQpB bSAyOC4wMS4yMDIwIHVtIDE4OjAwIHNjaHJpZWIgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUg PHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86cmljaGFubmE9NDBh bWF6b24uY29tQGRtYXJjLmlldGYub3JnPj46DQpUaGUgLi4uX3ZlcmlmaWVkIGNsYWltcyBkb27i gJl0IGRlZmluZSBob3cgb3Igd2hlbiB2ZXJpZmljYXRpb24gb2NjdXJyZWQuDQoNClN1cmUsIHRo ZXkgZG8uIExvb2sgYXQgdGhlIHRpbWUgYW5kIG1ldGhvZCBmaWVsZHMuDQoNClNpbmNlIE9wZW5J ZCBDb25uZWN0IGZvciBJZGVudGl0eSBBc3N1cmFuY2UgKGFrYSB2ZXJpZmllZF9jbGFpbXMpIGlz IG9uZ29pbmcgd29yayBmZWVsIGZyZWUgdG8gY29udHJpYnV0ZS4NCg0KaHR0cHM6Ly9vcGVuaWQu bmV0L3dnL2VreWMtaWRhLzxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZvcGVuaWQubmV0JTJGd2clMkZla3ljLWlkYSUyRiZk YXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzlmYWU1MDM2Njlm NDQzYTA5NjgzMDhkN2E0OTdjNDVmJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNzE1ODg0NDA0OTMzODM0NCZzZGF0YT1wZzh1cHd5TiUyQlhLZWFGWmFLRXZS JTJCVEVQc0tnamVKdGRId1BNMWZlJTJGeG5jJTNEJnJlc2VydmVkPTA+DQoNCi0tDQpUeGF1dGgg bWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQoNCg== --_000_792B1100064C48DDBD639C1A9BEFE859amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5J4oCZbSBnb2luZyB0byBhcHByb2FjaCB0aGlzIGZyb20gYSBkaWZmZXJlbnQgYW5nbGXi gKYgQXMgSeKAmXZlIHNhaWQgYmVmb3JlLCBJIHRoaW5rIGEgY2hhcnRlciBzaG91bGQgYmUgY2xv c2VyIHRvIGEgcHJvYmxlbSBzdGF0ZW1lbnQgdGhhbiBhIGRlc2lnbiBkb2N1bWVudC4gSXQgc2hv dWxkIGZvY3VzIG9uIHdoYXQgdGhlIGdyb3VwIGlzIHRyeWluZyB0byBkbywgbm90IGhvdyB0aGV5 4oCZcmUgZ29pbmcgdG8gZG8gaXQuDQogVGhlIHJlYXNvbiBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAg aXMsIGFmdGVyIGFsbCwgdG8gZmlndXJlIG91dCB0aGUg4oCcaG934oCdIHBhcnQuIFRvIHRoYXQg ZW5kLCBhIGNoYXJ0ZXIgc2hvdWxkIG5vdCBwcmVzY3JpYmUgc3BlY2lmaWMgdGVjaG5vbG9naWVz IG9yIGRlc2lnbiBjaG9pY2VzLiBEb2luZyBzbyB1bm5lY2Vzc2FyaWx5IGNvbnN0cmFpbnMgdGhl IHdvcmtpbmcgZ3JvdXAgYW5kIHByb3ZpZGVzIHplcm8gYmVuZWZpdC4gSWYgZXZlcnlvbmUgYWdy ZWVzDQogdGhhdCB0ZWNobm9sb2d5IFggaXMgdGhlIHJpZ2h0IGNob2ljZSB3aGVuIHdyaXRpbmcg dGhlIGNoYXJ0ZXIsIHRoZXnigJlsbCBhZ3JlZSB0aGF0IGl0IGlzIHRoZSByaWdodCBjaG9pY2Ug d2hlbiB3cml0aW5nIHdvcmtpbmcgZ3JvdXAgZHJhZnRz4oCmdW5sZXNzIHNvbWV0aGluZyBoYXMg Y2hhbmdlZCDigJMgbmV3IGluZm9ybWF0aW9uIGhhcyBjb21lIG91dCwgbmV3IHVzZSBjYXNlcywg bmV3IHRlY2hub2xvZ2llcywgYWRkaXRpb25hbCBzdGFrZWhvbGRlcnMNCiBoYXZlIGdvdHRlbiBp bnZvbHZlZCwgZXRjLiDigJMgaW4gd2hpY2ggY2FzZSBpdCBtYXkgYmUgdmVyeSBpbXBvcnRhbnQg dGhhdCB0aGUgd29ya2luZyBncm91cCBoYXZlIHRoZSBmcmVlZG9tIHRvIGV4cGxvcmUgb3RoZXIg b3B0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZXRpbWVzIHRoZSBwcm9ibGVtIHRv IGJlIHNvbHZlZCBuZWVkcyB0byBiZSBzY29wZWQgZG93biBhbG9uZyB0ZWNobm9sb2d5IGxpbmVz IChlLmcuLCBIVFRQIEFQSXMgdmVyc3VzIEFQSXMgb24gYW55IHByb3RvY29sIGltYWdpbmFibGUp IGluIG9yZGVyIHRvIG1ha2UgaXQgdHJhY3RhYmxlLiBJIGFtIG5vdCBvcHBvc2VkIHRvIHRob3Nl IGNvbnN0cmFpbnRzIHdoZW4gdGhleSBhcmUgbmVlZGVkLCB0aG91Z2gNCiBvZnRlbiB0aGV5IGNh biBiZSBoYW5kbGVkIHdpdGggYSDigJx3ZSB3aWxsIGluaXRpYWxseSBmb2N1cyBvbuKApuKAnSBy YXRoZXIgdGhhbiBhIGhhcmQg4oCcd2Ugd2lsbCBvbmx5IHN1cHBvcnTigKbigJ0gYXMgZGVtb25z dHJhdGVkIGJ5IHRoZSBUeEF1dGggY2hhcnRlcuKAmXMgYXBwcm9hY2ggdG8gSFRUUCB2cyBDT0FQ LiBJbiBhbnkgY2FzZSwgSSBkbyBub3Qgc2VlIEpXVCBvciBPSURDIGNsYWltcyBhcyBuZWNlc3Nh cnkgY29uc3RyYWludHMgdG8gc2NvcGUgdGhlIHByb2JsZW0NCiBkb3duLiBUaGV5IG1heSB3ZWxs IGJlIHRoZSByaWdodCBjaG9pY2VzIGZvciB3aGF0IHRoZXkgYXJlIGJlaW5nIHN1Z2dlc3RlZCBm b3IgaGVyZSwgYnV0IGhhdmluZyB0aGF0IGRlYmF0ZSBub3cgaXMgdW5uZWNlc3NhcnkgYW5kIHBv dGVudGlhbGx5IGhhcm1mdWwgKHNlZSBhYm92ZSksIGFuZCB3aWxsIG5lZWRsZXNzbHkgZGVsYXkg dGhlIGZvcm1hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cCBhbmQgZGV2ZWxvcG1lbnQgb2YgdGhl IHByb3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPuKAkyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgUmlj aGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UeGF1dGggJmx0O3R4YXV0aC1ib3VuY2Vz QGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQu ZWR1Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEphbnVhcnkgMjksIDIwMjAgYXQg MzozOCBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7dHhhdXRoQGlldGYub3JnJnF1b3Q7ICZsdDt0 eGF1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5LaW0gJmx0O2tpbUBpZGVudGl0eWJs b2cuY29tJmd0OywgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0 OywgVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQmZ3Q7LCBE aWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDssICZxdW90O1JpY2hhcmQgQmFj a21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDtyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbVHhhdXRoXSBbRVhURVJOQUxdIFJl OiBRdWVzdGlvbnMgb24gdGhlIFR4QXV0aCBjaGFydGVyPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZ290IGEgY2hhbmNlIHRvIGNoYXQgd2l0 aCBNaWtlIGFuZCBJIHdhbnRlZCB0byBleHBhbmQgbXkgb2ZmLXRoZS1jdWZmIHJlc3BvbnNlIChi ZWxvdykgd2l0aCBzb21lIG1vcmUgZGV0YWlsIHRoYW4gSSB3YXMgYWJsZSB0byB3cml0ZSBpbiB0 aGUgbW9tZW50LCBiZWNhdXNlIEkgZG9u4oCZdCB0aGluayB0aGF0IHdl4oCZcmUgYWN0dWFsbHkg dGhhdCBmYXIgYXBhcnQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRvIHN0YXJ0LCBpdCB3YXNu4oCZdCBvYnZpb3VzIHRvIG1lIChhbmQgbWln aHQgbm90IGhhdmUgYmVlbiB0byBvdGhlcnMpIHRoZSBzcGVjaWZpYyBwcmVjaXNpb24gb2YgTWlr ZeKAmXMgc3RhdGVtZW50IGJlbG93LiBIZSBjbGFyaWZpZWQgdG8gbWUgdGhhdCB3aGF0IGhlIG1l YW5zIGlzIHRoYXQgd2hlcmUgdXNlciBjbGFpbXMgYXJlIHNpZ25lZCBvciBlbmNyeXB0ZWQsIHRo ZW4gSldUIHByb3ZpZGVzIGFuIG9idmlvdXMNCiB3YXkgdG8gZG8gaXQuIEluIG90aGVyIHdvcmRz LCDigJxkb27igJl0IHJlLWludmVudCB0aGUgSUQgVG9rZW4gd2l0aCBuZXcgY3J5cHRv4oCdLiBU aGVyZSBhcmUgc2V2ZXJhbCB0aGluZ3MgdG8gYWRkcmVzcyBoZXJlIHdpdGggdGhhdCBpbiBtaW5k LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G aXJzdCwgSSBkb27igJl0IGJlbGlldmUgdGhlcmUgYXJlIGdvaW5nIHRvIGJlIG1hbnksIGlmIGFu eSwgY2FzZXMgd2hlcmUgd2UgbmVlZCB1c2VyIGNsYWltcyB0byBiZSBzaWduZWQgYW5kIGVuY3J5 cHRlZCBzZXBhcmF0ZWx5IGZyb20gdGhlIGNvcmUgdHJhbnNhY3Rpb24gbWVzc2FnZXMuIEV2ZW4g aW4gT0lEQywgdGhlIElEIFRva2VuIGlzIGFsbG93ZWQgdG8gYmUgdW5zaWduZWQgd2hlbiBpdCBp cyByZXRyaWV2ZWQNCiBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCBkaXJlY3RseSB1c2luZyB0aGUg Y29kZSBmbG93LiBUaGUgZXF1aXZhbGVudCBvZiB0aGlzIGlzIHRoZSBvbmx5IHBsYWNlIHRoYXQg VHhBdXRoIHdvdWxkIGJlIHNlbmRpbmcgYmFjayB1c2VyIGNsYWltcyBkaXJlY3RseS4gV2Ugbm8g bG9uZ2VyIGhhdmUgYSBuZWVkIHRvIHByb3RlY3QgdGhpbmdzIGFzIHRoZXkgdHJhdmVsIHRocm91 Z2ggdGhlIGZyb250IGNoYW5uZWwgb24gYSByZWRpcmVjdCwgYW5kIHdlDQogbm8gbG9uZ2VyIGhh dmUgYSBuZWVkIHRvIHVzZSB0aGUgdXNlcuKAmXMgY2xhaW1zIGFzIGFuIGFydGlmYWN0IGZvciB0 aGluZ3MgbGlrZSBzZXNzaW9uIG1hbmFnZW1lbnQgKHdlIGNhbiBkZWZpbmUgYSBuZXcgYXJ0aWZh Y3QgZm9yIHRoYXQgcHVycG9zZSB0aGF0IGZpdHMgYmV0dGVyKS4gVGhpcyBlZmZlY3RpdmVseSBt ZWFucyB0aGF0IHdlIGRvbuKAmXQgbmVlZCB0byByZWRlZmluZSB0aGUgSUQgVG9rZW4gYmVjYXVz ZSB3ZSBkb27igJl0IG5lZWQgdGhlDQogZXF1aXZhbGVudCBvZiB0aGUgSUQgdG9rZW4gaW4gdGhl IHNhbWUgd2F5LiBGb3IgdGhlIGNhc2VzIHRoYXQgd2UgZG8gbmVlZCB0byBkZWZpbmUgdXNlciBj bGFpbXMsIHdlIHNob3VsZCBiZSBkZWZpbmluZyB0aGVtIGFzIGEgSlNPTiBvYmplY3QgbW9kZWwu IEFuZCBJIGFsc28gYmVsaWV2ZSB0aGF0IHRoaXMgSlNPTiBkYXRhIG1vZGVsIHNob3VsZCBub3Qg YmUgaW50ZXJ0d2luZWQgd2l0aCBvciBjb25zdHJhaW5lZCBieSB0aGUgSldUIGNsYWltcw0KIHJl Z2lzdHJ5LiBUaGUgT0lEQyBjbGFpbXMgcmVnaXN0cnkgY2FuIHNlcnZlIGFzIGluZmx1ZW5jZSBh bmQgaW5wdXQgdG8gb3VyIHVzZXIgY2xhaW1zIHNldCBpZiB3ZSBjaG9vc2UsIGJ1dCBJIGRvbuKA mXQgdGhpbmsgd2Ugc2hvdWxkIGJlIGludGVydHdpbmVkIHdpdGggdGhhdCBlaXRoZXIuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY29uZCwg aW4gc3BpdGUgb2YgdGhlIHN1Y2Nlc3Mgb2YgT0lEQywgdGhlcmUgYXJlIHNldmVyYWwgZm9ybWF0 cyBvdXQgdGhlcmUgZm9yIHVzZXIgY2xhaW1zIGJleW9uZCBKV1QgYW5kIEpPU0UuIFZlcmlmaWFi bGUgQ3JlZGVudGlhbHMgKFZDLCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LnczLm9yZy9UUi92 Yy1kYXRhLW1vZGVsLyI+aHR0cHM6Ly93d3cudzMub3JnL1RSL3ZjLWRhdGEtbW9kZWwvPC9hPikg aXMgb25lDQogdGhhdCBoYXMgc2V2ZXJhbCBkaWZmZXJlbnQgZm9ybWF0cywgYW5kIHdlIGFyZSBh bHNvIHNlZWluZyBzeXN0ZW1zIGJ1aWx0IHVwIGFyb3VuZCBDT1NFIGFuZCBDQk9SIChsaWtlIElQ TEQsDQo8YSBocmVmPSJodHRwczovL2lwbGQuaW8vIj5odHRwczovL2lwbGQuaW8vPC9hPikuIE9y IHlvdSBjb3VsZCBldmVuIHVzZSBhIFNBTUwgZG9jdW1lbnQuIEkgZG9u4oCZdCB0aGluayBUeEF1 dGggc2hvdWxkIHBpY2sganVzdCBvbmUgb2YgdGhlc2UuIEluc3RlYWQsIEkgd2FudCBUeEF1dGgg dG8gZGVmaW5lIHBsYWNlcyB0byBwdXQgdGhlc2UgZm9ybWF0cyBpbiByZXF1ZXN0cyBhbmQgcmVz cG9uc2VzLiBJbiBteSBkcmFmdCB0aGVyZeKAmXMgYSBzcG90IGZvcg0KIGFuIE9JREMgc3R5bGUg SUQgVG9rZW4gb3IgYSBWQyBkb2N1bWVudCwgaWYgeW91IGhhdmUgb25lLiBXaXRoaW4gZWFjaCBv ZiB0aGVzZSwgYnkgYWxsIG1lYW5zLCBsZXTigJlzIGxvY2sgdGhlbSBkb3duIGFuZCBzYXkgdGhh dCB0aGUg4oCcb2lkY19pZF90b2tlbuKAnSBmaWVsZCBpcyBhIEpXVCBpbiBjb21wYWN0IGZvcm1h dCB0aGF0IE1VU1QgYmUgc2lnbmVkLCBldGMuIEFuZCBJIHRoaW5rIGl0IG1ha2VzIGxpdHRsZSBz ZW5zZSB0byBpbnZlbnQgb3VyIG93bg0KIGN1c3RvbSBmb3JtYXQgdG8gZG8gZXhhY3RseSB0aGF0 IGtpbmQgb2YgdGhpbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoaXJkLCBJIGFncmVlIHRoYXQgd2Ugc2hvdWxkbuKAmXQgcmUt aW52ZW50IGFuIGV4aXN0aW5nIGNyeXB0byBmb3JtYXQsIGFuZCBJ4oCZbGwgZ28gZnVydGhlciB0 aGF0IHdlIHNob3VsZG7igJl0IGJlIGludmVudGluZyBjcnlwdG8gYXQgYWxsLiBUaGlzIGRvZXNu 4oCZdCBtZWFuIHdlIGhhdmUgdG8gcGljayBvbmUgYW5kIG9ubHkgb25lLCBiZWNhdXNlIHRoaXMg aXMgb25lIG9mIHRoZSBzcGFjZXMgdGhhdCB3ZSBjYW4gKGFuZA0KIEkgYXJndWUgc2hvdWxkKSBo YXZlIHNvbWUgYWdpbGl0eS4gV2UgY2FuIGRlZmluZSB0aGUgcHJvdG9jb2wgaW4gdGVybXMgb2Yg SlNPTiBhbmQgdGhlbiBoYXZlIGEgc3VpdGUgb2YgY3J5cHRvZ3JhcGhpYyBjYXJyaWVycyB0aGF0 IHByb3RlY3QgdGhhdCBKU09OLCBpbmNsdWRpbmcgSk9TRSwgSFRUUCBNZXNzYWdlIFNpZ25hdHVy ZXMsIGFuZCBNdXR1YWwgVExTLiBUaGVyZSBhcmUgYSBidW5jaCBvZiBvdGhlcnMgb3V0IHRoZXJl IGFzIHdlbGwsIGxpa2UNCiB0aGUgRFBvUCBrZXkgcHJlc2VudGF0aW9uIGNvbWluZyBvdXQgb2Yg T0F1dGggMiByaWdodCBub3csIHRoYXQgc2hvdWxkIGJlIHN3aXRjaGFibGUgYXMgb3B0aW9ucyBo ZXJlIGJlY2F1c2UgdGhleeKAmXJlIGdvaW5nIHRvIGFwcGx5IHRvIGRpZmZlcmVudCB1c2UgY2Fz ZXMgYW5kIGRlcGxveW1lbnRzLiBQbHVzLCB0aGF0IEpTT04gY291bGQgYmUgdHJhbnNsYXRlZCB0 byBDQk9SICh3aXRob3V0IGRhdGEgb3Igc3RydWN0dXJlIGxvc3MpIGFuZCBwcm90ZWN0ZWQNCiBi eSBDT1NFIOKAlCBldmVuIGlmIHdlIGRvbuKAmXQgZGVmaW5lIHRoYXQgb3Vyc2VsdmVzLCB0aGUg ZmFjdCB0aGF0IHdl4oCZcmUgYnVpbGRpbmcgb3VyIHN0cnVjdHVyZSBvbiByYXcgSlNPTiBtZWFu cyB0aGF0IGl0IGNhbiBiZSB0cmFuc2xhdGVkIG1vcmUgZWFzaWx5IGxhdGVyLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3VydGgsIEkgYW0g dmVyeSBzZW5zaXRpdmUgdG8gY2FsbGluZyBvdXQgcHJlZmVycmVkIGNyeXB0byBzb2x1dGlvbnMg YmVjYXVzZSBJIGJlbGlldmUgdGhhdCBsZW5kcyB0byB1cyB1c2luZyB0aGF0IGFzIGFuIGV4Y3Vz ZSB0byB1c2UgdGhhdCBwYXJ0aWN1bGFyIGhhbW1lciB0byBzb2x2ZSBhbGwgdGhlIHByb2JsZW1z LiBUaGVyZSBoYXZlIGJlZW4gcHJvcG9zYWxzIHRvIG1ha2UgdGhlIGVudGlyZSBwcm90b2NvbA0K IEpXVHMgaW4gYWxsIGRpcmVjdGlvbnMsIGZvciBpbnN0YW5jZSwgdGhhdCBJIHRoaW5rIGFyZSBy ZWFsbHkgcHJvYmxlbWF0aWMgYmVjYXVzZSBvZiB0aGUgbGltaXRzIHRoYXQgaXQgcGxhY2VzIG9u IGV4cHJlc3Npb24gb2YgaXRlbXMgb3V0c2lkZSBvZiB0aGUgcGF5bG9hZCBpdHNlbGYuIFRoaXMg aXMgbm90IHdoYXQgTWlrZSBpcyBzdWdnZXN0aW5nIGJlbG93LCBidXQgaXTigJlzIGEgcG90ZW50 aWFsIGZhbGxvdXQgZnJvbSB3aGF0IGhlIGRvZXMgcHJvcG9zZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGNvbmNsdXNpb24sIEpP U0UgYW5kIEpXVCBhcmUgZmFudGFzdGljIGFuZCB0aGV5IHNvbHZlIGEgbG90IG9mIHByb2JsZW1z IGluIGFuIGVsZWdhbnQgd2F5LiBCdXQgSSB0aGluayB3ZSBuZWVkIHRvIHF1ZXN0aW9uIHdoZXRo ZXIgd2UgbmVlZCB0aGVpciBzb2x1dGlvbnMgYXQgYWxsLCBhbmQgd2hlcmUgd2UgZG8sIGlmIHdl IHdhbnQgdG8gZW5hYmxlIG90aGVyIHNvbHV0aW9ucyBhcyB3ZWxsLiBJbiBteSB2aWV3LA0KIHdl IGRvbuKAmXQgbmVlZCBKT1NFL0pXVCBiZWNhdXNlIHdlIGF2b2lkIHRoZSBwcm9ibGVtcyB0aGF0 IHRoZXkgc29sdmUsIGFuZCB0aGUgcGxhY2VzIHRoYXQgd2UgZG8gd2FudCB0byB1c2UgdGhlbSBJ IHN0cm9uZ2x5IGJlbGlldmUgdGhlcmUgYXJlIGFscmVhZHkgb3RoZXIgYWx0ZXJuYXRpdmVzIHRo YXQgd2Ugd2FudCB0byBoYXZlIGFzIG9wdGlvbnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIEkgd2FudCB0byBoYXZlIEpPU0Us IGJ1dCBpdCBuZWVkcyB0byBiZSBpbiB0aGUgcmlnaHQgcGxhY2VzIGFuZCBJIGRvIG5vdCB3YW50 IGl0IHRvIGJlIGEgZGVwZW5kZW5jeSBvbiBhbGwgaW1wbGVtZW50YXRpb25zLiBJIHRoaW5rIHRo YXQgd2UgY2FuIGRvIHRoYXQgd2l0aG91dCBzYXlpbmcgSldUIGlzIGEgcHJlZmVycmVkIGZvcm1h dC4gSSB0aGluayBpdOKAmXMgbW9yZSBpbXBvcnRhbnQgdGhhdCB0aGUgY2hhcnRlcg0KIGluY29y cG9yYXRlIHNwZWNpZmljIHRleHQgb2Ygd2hhdOKAmXMgb3V0IG9mIHNjb3BlLCBpbmNsdWRpbmcg ZGVmaW5pbmcgYSBjcnlwdG9ncmFwaGljIHByb3RlY3Rpb24gbWVjaGFuaXNtLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgb2Yg dGhlIGhhcmRlc3QgdGhpbmdzIGZvciBhIHN0YW5kYXJkIHRvIGRvIGlzIGRldGVybWluZSB3aGVy ZSB0aGUgZmxleGliaWxpdHkgc2hvdWxkIGJlLiBNeSBzdGFuY2UgaXMgdGhhdCB3ZSBzaG91bGQg aGF2ZSBhIHN0cnVjdHVyYWwgZm9ybWF0IGJhc2VkIG9uIEpTT04gYnV0IHRoYXQgdGhlIGNvbnRl bnRzIG9mIHRoYXQgSlNPTiBhcmUgZXh0ZW5zaWJsZSBidXQgdGhhdCBlYWNoIHBvcnRpb24gYW5k DQogZXh0ZW5zaW9uIGFyZSB2ZXJ5IHN0cmljdCBhYm91dCB3aGF04oCZcyB0aGVyZS4gQW5vdGhl ciBrZXkgZmxleGlibGUgcG9pbnQgaXMgdGhhdCB0aGUgY29udGVudCBvZiB0aGUgSlNPTi1iYXNl ZCBwYXlsb2FkcyBjYW4gYmUgcHJvdGVjdGVkIGluIGEgdmFyaWV0eSBvZiB3YXlzLiBDaG9pY2Ug Y2FuIGJlIGRlYmlsaXRhdGluZywgYnV0IGl0IGNhbiBhbHNvIGJlIGZyZWVpbmcuIFBpbm5pbmcg ZXZlcnl0aGluZyB0byBKT1NFIHdvdWxkIGRvIHVzIGENCiBkaXNzZXJ2aWNlLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDvi gJQgSnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBKYW4gMjksIDIwMjAsIGF0IDEwOjA1IEFNLCBKdXN0aW4gUmljaGVy ICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1Ij5qcmljaGVyQG1pdC5lZHU8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pkkgc3Ryb25nbHkgb2JqZWN0IHRvIGNhbGxpbmcgb3V0IEpXVHMgYXMgdGhlIHByZWZlcnJlZCBz b2x1dGlvbiBmb3Igc2lnbmVkIGFuZCBlbmNyeXB0ZWQgY2xhaW1zIHdpdGhpbiB0aGlzIHdvcmtp bmcgZ3JvdXAuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIEphbiAyOSwgMjAyMCwgYXQgOTo1MCBBTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhhbmtzIGZvciB3cml0 aW5nIHRoZXNlIGRldGFpbGVkIHF1ZXN0aW9ucywgS2ltLiZuYnNwOyBJIGJlbGlldmUgdGhhdCB0 aGV5IHBvaW50IG91dCBhIG51bWJlciBvZiBwbGFjZXMgd2hlcmUgZXZlbiBleHBlcnRzIGluIHRo ZSBmaWVsZCwgc3VjaCBhcyB5b3Vyc2VsZiwgY3VycmVudGx5IGhhdmUgdHJvdWJsZSB1bmRlcnN0 YW5kaW5nIHBhcnRzIG9mIHdoYXQgdGhlIGNoYXJ0ZXINCiBpcyBwcm9wb3NpbmcgdGhhdCB3ZSBk byDigJMgcGFydGlhbGx5IGJlY2F1c2UgdGVybWlub2xvZ3kgaXMgdXNlZCB0aGF0IGlzbuKAmXQg Y29tbW9ubHkgdW5kZXJzdG9vZC4mbmJzcDsgSSBob3BlIHRoYXQgdGhlIGRyYWZ0IGNoYXJ0ZXIg d2lsbCBiZSByZXZpc2VkIHRvIG1ha2UgdGhlIGludGVudCBhbmQgdGhlIGdvYWxzIG1vcmUgYWNj ZXNzaWJsZSBhbmQgbGVzcyBhbWJpZ3VvdXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5SZXNwb25kaW5nIHRvIHRoZSBk aXNjdXNzaW9uIG9uIHdoZXRoZXIgZXhpc3RpbmcgSldUIGlkZW50aXR5IGNsYWltcyB3aWxsIGRv IHRoZSBqb2Igb3Igbm90LCBmb3J0dW5hdGVseSwgZXZlbiBpZiB0aGV5IGRvbuKAmXQsIHRoZXJl 4oCZcyBhIG1lY2hhbmlzbSB0byBhZGQgb25lcyB0aGF0IGRvOiB0aGUgSUFOQSBKU09OIFdlYiBU b2tlbiBDbGFpbXMgcmVnaXN0cnkgYXQ8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMv and0L2p3dC54aHRtbCNjbGFpbXMiPmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2p3 dC9qd3QueGh0bWwjY2xhaW1zPC9hPi4mbmJzcDsNCiBGb3IgaW5zdGFuY2UsIGFuIOKAnGVtYWls X2FkZHJlc3Nlc+KAnSBjbGFpbSB0aGF0IGlzIGFycmF5LXZhbHVlZCBjb3VsZCBiZSBkZWZpbmVk IGFuZCByZWdpc3RlcmVkIGlmIHRoZXJl4oCZcyBhIG5lZWQgdG8gcmVwcmVzZW50IG11bHRpcGxl IGUtbWFpbCBhZGRyZXNzZXMsIHBlciBBbm5hYmVsbGXigJlzIGV4YW1wbGUuJm5ic3A7IFRoZSBm dXJ0aGVyIGdvb2QgbmV3cyBpcyB0aGF0IGlmIHRoZSB3b3JraW5nIGdyb3VwIGRlZmluZXMgbmV3 IGNsYWltcyB0aGF0IGFyZQ0KIHJlZ2lzdGVyZWQsIHRoZXkgY2FuIGJlIHJldXNlZCBieSBvdGhl cnMgYWxzbyB1c2luZyBKV1RzIOKAkyBqdXN0IGxpa2UgdGhpcyB3b3JraW5nIGdyb3VwIGNhbiBy ZXVzZSBjbGFpbXMgZGVmaW5lZCBieSBvdGhlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5BbHNvIG9uIHRoZSBzdWJq ZWN0IG9mIEpXVHMsIEkgd291bGQgc3VnZ2VzdCB0aGF0IHRoZSBjaGFydGVyIGJlIHVwZGF0ZWQg dG8gZXhwbGljaXRseSBjYWxsIG91dCB0aGF0IEpXVHMgd2lsbCBiZSB0aGUgd29ya2luZyBncm91 cOKAmXMgcHJlZmVycmVkIHJlcHJlc2VudGF0aW9uIHNpZ25lZCBhbmQvb3IgZW5jcnlwdGVkIGNs YWltcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPkZpbmFsbHksIEkgYWxzbyB0aGluayB0aGF0IHRoZSBjaGFydGVyIHdv dWxkIGJlbmVmaXQgZnJvbSBleHBsaWNpdGx5IGxpc3RpbmcgdGhpbmdzIHRoYXQgYXJlIG91dCBv ZiBzY29wZSAod2hpY2ggaXMgb2Z0ZW4gZG9uZSBpbiBjaGFydGVycykuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGFu a3MgYWdhaW4gZm9yIHByb21wdGluZyB0aGlzIHVzZWZ1bCBkaXNjdXNzaW9uLCBLaW0uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPlR4YXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aC1ib3VuY2Vz QGlldGYub3JnIj50eGF1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+SnVzdGluDQogUmlj aGVyPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPldlZG5lc2RheSwgSmFudWFyeSAyOSwgMjAyMCAxMjo0NiBBTTxicj4NCjxi PlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ VG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0Ij50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5LaW0gJmx0Ozxh IGhyZWY9Im1haWx0bzpraW1AaWRlbnRpdHlibG9nLmNvbSI+a2ltQGlkZW50aXR5YmxvZy5jb208 L2E+Jmd0OzsgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwu Y29tIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHhhdXRoQGlldGYub3Jn Ij50eGF1dGhAaWV0Zi5vcmc8L2E+Ow0KIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8 YSBocmVmPSJtYWlsdG86cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnIj5yaWNo YW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bRVhU RVJOQUxdIFJlOiBbVHhhdXRoXSBRdWVzdGlvbnMgb24gdGhlIFR4QXV0aCBjaGFydGVyPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGRpZG7igJl0IG1lYW4g4oCccGF0Y2jigJ0gdG8gc291bmQgZGlzcGFyYWdpbmcs IHNvcnJ5IGlmIGl0IGNhbWUgYWNyb3NzIGFzIHN1Y2guIFdoYXQgSSBtZWFuIGJ5IOKAnHBhdGNo aW5n4oCdIGhlcmUgaXMgdGhhdCBpdCBpcyBhZGRpbmcgZnVuY3Rpb25hbGl0eSB0byBhbiBleGlz dGluZyBzZXQgb2YgY2xhaW1zIGFuZCBzY2hlbWEuIElmIHlvdSBhcmUgdXNpbmcgdGhhdCBzY2hl bWEgYXMgYSBiYXNlLCBpdCBtYWtlcyBzZW5zZQ0KIGFzIGEgdmlhYmxlIHNvbHV0aW9uIGluIHRo YXQgc3BhY2UuIEksIGhvd2V2ZXIsIGFtIGJyaW5naW5nIHVwIHRoZSBxdWVzdGlvbiBvZiB3aGV0 aGVyIHdlIGFyZSB1c2luZyB0aGF0IHNjaGVtYSBhcyBvdXIgYmFzZSBhdCBhbGwuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5J4oCZbGwgbm90ZSB0aGF0IDgxMTIgZG9lc27igJl0IGRlZmluZSBhIHNjaGVt YSBvciBzeW50YXgsIGJvdGggb2Ygd2hpY2ggYXJlIHJlcXVpcmVkLiBCdXQgaWYgd2Ugd2VyZSBz dGFydGluZyBPSURDIHRvZGF5IHdpdGggRUtZQ+KAmXMgcmVxdWlyZW1lbnRzLCBJ4oCZbSBub3Qg Y29udmluY2VkIHdl4oCZZCBlbmQgdXAgd2l0aCB0aGUgc2FtZSBzdHJ1Y3R1cmUuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIHdpdGggZXZlcnl0aGluZywgaXTigJlzIGEgdmVy eSBpbXBvcnRhbnQgaW5wdXQgaW50byB3aGF0IHdl4oCZcmUgdHJ5aW5nIHRvIHNvbHZlLCBlc3Bl Y2lhbGx5IGluZmx1ZW5jaW5nIHdoYXTigJlzIGV4dGVuc2libGUgYW5kIGhvdy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIEphbiAyOSwgMjAyMCwgYXQgODowNiBBTSwgVG9yc3RlbiBMb2RkZXJzdGVk dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Ij50b3JzdGVuQGxv ZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BbSAy OS4wMS4yMDIwIHVtIDA3OjM0IHNjaHJpZWIgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFp bHRvOmpyaWNoZXJAbWl0LmVkdSI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs6PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHRoaW5rIHRoZSBla3ljIHdvcmsgaXMgZ3JlYXQgZm9yIHdoYXQgaXQgaXMsIGJ1 dCBhZ2FpbiB3ZSBoYXZlIGFuIG9wcG9ydHVuaXR5IHRvIHRha2UgYSBzdGVwIGJleW9uZCBpdC4g SW4gbXkgdmlldywgd2XigJlkIGJlIGJldHRlciBvZmYgZGVmaW5pbmcgYSBtZWFucyBvZiBzcGVj aWZ5aW5nIGZpZWxkIG1ldGFkYXRhIGEgbGEgTklTVCBJUiA4MTEyIGFzIHBhcnQgb2YgdGhlIHNj aGVtYSBpbnN0ZWFkIG9mIHBhdGNoaW5nDQogdGhlIGV4aXN0aW5nIE9JREMgZmllbGRzLiZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRnBhZ2VzLm5pc3QuZ292JTJGTklTVElSLTgxMTIlMkYmYW1wO2Rh dGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDOWZhZTUwMzY2OWY0 NDNhMDk2ODMwOGQ3YTQ5N2M0NWYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 QzElN0MwJTdDNjM3MTU4ODQ0MDQ5MzM4MzQ0JmFtcDtzZGF0YT1yT3JLYU83TXZEREtMeWZCMlFp dmJWVGNqNUVtUlNKMW5SWFhzMzBqRXowJTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwczovL3BhZ2Vz Lm5pc3QuZ292L05JU1RJUi04MTEyLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5XZSB0cmllZCBhbmQgaXQgZGlkIG5vdCBmdWxmaWxsIG91ciByZXF1aXJlbWVudHMuIHZl cmlmaWVkX2NsYWltcyBpcyBieSBubyBtZWFucyBhIHBhdGNoLCBpdOKAmXMgYSB2aWFibGUgc29s dXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKYW4gMjksIDIwMjAs IGF0IDY6MTMgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldCI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QW0gMjguMDEuMjAyMCB1bSAxODowMCBzY2hyaWVi IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmE9 NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnIj5yaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMu aWV0Zi5vcmc8L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSAuLi5fdmVyaWZpZWQgY2xh aW1zIGRvbuKAmXQgZGVmaW5lIGhvdyBvciB3aGVuIHZlcmlmaWNhdGlvbiBvY2N1cnJlZC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VyZSwgdGhleSBkby4gTG9vayBhdCB0aGUgdGltZSBh bmQgbWV0aG9kIGZpZWxkcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2Ug T3BlbklkIENvbm5lY3QgZm9yIElkZW50aXR5IEFzc3VyYW5jZSAoYWthIHZlcmlmaWVkX2NsYWlt cykgaXMgb25nb2luZyB3b3JrIGZlZWwgZnJlZSB0byBjb250cmlidXRlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZvcGVuaWQubmV0JTJGd2clMkZla3ljLWlk YSUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0M5 ZmFlNTAzNjY5ZjQ0M2EwOTY4MzA4ZDdhNDk3YzQ1ZiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3 Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNTg4NDQwNDkzMzgzNDQmYW1wO3NkYXRhPXBnOHVwd3lO JTJCWEtlYUZaYUtFdlIlMkJURVBzS2dqZUp0ZEh3UE0xZmUlMkZ4bmMlM0QmYW1wO3Jlc2VydmVk PTAiPmh0dHBzOi8vb3BlbmlkLm5ldC93Zy9la3ljLWlkYS88L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8YnI+DQpUeGF1dGggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlR4YXV0aEBpZXRmLm9yZyI+VHhhdXRoQGlldGYub3Jn PC9hPjxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_792B1100064C48DDBD639C1A9BEFE859amazoncom_-- From nobody Wed Jan 29 22:19: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 8FE4412006B for ; Wed, 29 Jan 2020 22:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 mHBgVUM7xpDe for ; Wed, 29 Jan 2020 22:19:18 -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 E3C47120059 for ; Wed, 29 Jan 2020 22:19:17 -0800 (PST) Received: from [100.83.133.69] (static.kpn.net [217.166.241.47] (may be forged)) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00U6J41s017828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jan 2020 01:19:06 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1369ECFC-32A4-49E4-BEA3-5C2EB07AB079" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 30 Jan 2020 07:19:04 +0100 In-Reply-To: <7833DDB1-FB88-4151-84B6-8DABB6436B53@amazon.com> Cc: Dick Hardt , "txauth@ietf.org" , Kim , Torsten Lodderstedt , Mike Jones To: "Richard Backman, Annabelle" References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> <585BCD70-6B64-4058-AC70-B677695DB391@mit.edu> <7833DDB1-FB88-4151-84B6-8DABB6436B53@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: The need for signed claims - providence 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, 30 Jan 2020 06:19:21 -0000 --Apple-Mail=_1369ECFC-32A4-49E4-BEA3-5C2EB07AB079 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think the use cases for SET are very different from an authentication = assertion, which is consumed then discarded. Aaron Parecki has written a = good blog post that touches on this: https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz If we need a persistent record then we can also send that =E2=80=94 = maybe it=E2=80=99s even a SET instead of an ID Token? I=E2=80=99m still = fine with enabling signed JWTs to carry information, but what I was = against was stating any assumption that they would always be signed or = encrypted, and that JWT would be the assumed carrier for that. =E2=80=94 Justin > On Jan 30, 2020, at 1:00 AM, Richard Backman, Annabelle = wrote: >=20 > +1 to Dick=E2=80=99s counterpoints. The Security Considerations in = draft-ietf-secevent-http-push = = talk about validation of persisted SETs as one reason a deployment may = wish to transmit signed SETs even over a TLS-protected channel. The same = idea applies to identity claims or just about anything else, really. > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: Dick Hardt > Date: Wednesday, January 29, 2020 at 2:16 PM > To: Justin Richer > Cc: "txauth@ietf.org" , Kim , = Torsten Lodderstedt , "Richard Backman, = Annabelle" , Mike Jones = > Subject: [UNVERIFIED SENDER] Re: The need for signed claims - = providence > =20 > I forgot to include the reference to Annabelle calling this out = earlier > =20 > = https://mailarchive.ietf.org/arch/msg/txauth/0hR49OnE3oqNPuCIQ43fN1o886w = = > =20 > =20 > On Wed, Jan 29, 2020 at 1:14 PM Dick Hardt > wrote: >> Forking the discussion to focus on signed claims >> =20 >> On Wed, Jan 29, 2020 at 3:37 AM Justin Richer > wrote: >> >>> First, I don=E2=80=99t believe there are going to be many, if any, = cases where we need user claims to be signed and encrypted separately = from the core transaction messages. Even in OIDC, the ID Token is = allowed to be unsigned when it is retrieved from the token endpoint = directly using the code flow. The equivalent of this is the only place = that TxAuth would be sending back user claims directly. We no longer = have a need to protect things as they travel through the front channel = on a redirect, and we no longer have a need to use the user=E2=80=99s = claims as an artifact for things like session management (we can define = a new artifact for that purpose that fits better). This effectively = means that we don=E2=80=99t need to redefine the ID Token because we = don=E2=80=99t need the equivalent of the ID token in the same way.. For = the cases that we do need to define user claims, we should be defining = them as a JSON object model. And I also believe that this JSON data = model should not be intertwined with or constrained by the JWT claims = registry. The OIDC claims registry can serve as influence and input to = our user claims set if we choose, but I don=E2=80=99t think we should be = intertwined with that either. >> =20 >> I disagree. I think it is likely that we will see an increase in = signed claims and messages. >> =20 >> In my opinion, the providence of a claim or message is far more = important than protection during transit.=20 >> =20 >> Client / AS non-repudiation: when sensitive operations are performed = relying on the contents of a claim, the Client will want repudiation = that the AS or claims issuer made a claim. >> =20 >> Separation of duties in complex systems: In large organizations, a = major security threat is a malicious insider. Once an organization = reaches a certain size, you assume there are people employed at the = company that do not have the firms best interests in mind. One = mitigation of this threat is done by separating what different teams can = do with customer / sensitive data, requiring collusion to access or = modify the data. Signed messages and claims simplify different = components being able to independently verify a message or claim. = Similarly, a component issuing a claim, has assurance that other = components in the same system are not modifying it. Large organizations = wrap external systems that do not support this with their own security = mechanism -- but not all organizations are this sophisticated, and as = they grow, retrofitting is difficult. Enabling end to end providence is = a best practice in my opinion. >> =20 >> User Consent Audit: as privacy becomes a larger public topic, it is = easy to imagine organizations wanting to prove that they obtained user = information with consent. Rather than gathering user information = directly from the user, a Client can acquire claims from the User's = claims provider that asserts the user provided consent to the Client. = The Client can then technically establish that all user data was = gathered with consent, and the context of the consent. >> =20 >> While the message containing the claims may be signed, having = independent claims separately signed simplifies the least privilege = tenet, where a component only has access to the user information it = needs.. =20 >> =20 >> /Dick --Apple-Mail=_1369ECFC-32A4-49E4-BEA3-5C2EB07AB079 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think the use cases for SET are very different from an authentication = assertion, which is consumed then discarded. Aaron Parecki has written a = good blog post that touches on this:

https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz

If we need = a persistent record then we can also send that =E2=80=94 maybe it=E2=80=99= s even a SET instead of an ID Token? I=E2=80=99m still fine with = enabling signed JWTs to carry information, but what I was against was = stating any assumption that they would always be signed or encrypted, = and that JWT would be the assumed carrier for that.

 =E2=80=94 Justin

On Jan 30, 2020, at 1:00 AM, Richard Backman, Annabelle = <richanna@amazon.com> wrote:

+1 to = Dick=E2=80=99s counterpoints. The = Security Considerations in draft-ietf-secevent-http-push talk about validation of = persisted SETs as one reason a deployment may wish to transmit signed = SETs even over a TLS-protected channel. The same idea applies to = identity claims or just about anything else, really.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: Dick Hardt <dick.hardt@gmail.com>
Date: Wednesday, January 29, = 2020 at 2:16 PM
To: Justin Richer <jricher@mit.edu>
Cc: "txauth@ietf.org" <txauth@ietf.org>, Kim = <kim@identityblog.com>, Torsten Lodderstedt <torsten@lodderstedt.net>, "Richard Backman, Annabelle" = <richanna@amazon.com>, Mike Jones <Michael.Jones@microsoft.com>
Subject: [UNVERIFIED SENDER] Re: = The need for signed claims - providence
 
I forgot to include the = reference to Annabelle calling this out earlier
 
https://mailarchive.ietf.org/arch/msg/txauth/0hR49OnE3oqNPuCIQ4= 3fN1o886w
 
 
On Wed, Jan 29, 2020 at = 1:14 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Forking the discussion to focus on = signed claims
 
On Wed, Jan 29, 2020 at = 3:37 AM Justin Richer <jricher@mit.edu> wrote:
<snip>
First, I = don=E2=80=99t believe there are going to be many, if any, cases where we = need user claims to be signed and encrypted separately from the core = transaction messages. Even in OIDC, the ID Token is allowed to be = unsigned when it is retrieved from the token endpoint directly using the = code flow. The equivalent of this is the only place that TxAuth would be = sending back user claims directly. We no longer have a need to protect = things as they travel through the front channel on a redirect, and we no = longer have a need to use the user=E2=80=99s claims as an artifact for = things like session management (we can define a new artifact for that = purpose that fits better). This effectively means that we don=E2=80=99t = need to redefine the ID Token because we don=E2=80=99t need the = equivalent of the ID token in the same way.. For the cases that we do = need to define user claims, we should be defining them as a JSON object = model. And I also believe that this JSON data model should not be = intertwined with or constrained by the JWT claims registry. The OIDC = claims registry can serve as influence and input to our user claims set = if we choose, but I don=E2=80=99t think we should be intertwined with = that either.
 
I disagree. I think it is likely that we will see an increase = in signed claims and messages.
 
In my opinion, the providence of a claim or message is far = more important than protection during transit. 
 
Client / AS = non-repudiation: when sensitive operations are performed relying on = the contents of a claim, the Client will want repudiation that the AS or = claims issuer made a claim.
 
Separation of duties in complex systems: In = large organizations, a major security threat is a malicious insider. = Once an organization reaches a certain size, you assume there are people = employed at the company that do not have the firms best interests in = mind. One mitigation of this threat is done by separating what different = teams can do with customer / sensitive data, requiring collusion to = access or modify the data. Signed messages and claims simplify different = components being able to independently verify a message or claim. = Similarly, a component issuing a claim, has assurance that other = components in the same system are not modifying it. Large organizations = wrap external systems that do not support this with their own security = mechanism -- but not all organizations are this sophisticated, and as = they grow, retrofitting is difficult. Enabling end to end providence is = a best practice in my opinion.
 
User Consent Audit: as privacy becomes a = larger public topic, it is easy to imagine organizations wanting to = prove that they obtained user information with consent. Rather than = gathering user information directly from the user, a Client can acquire = claims from the User's claims provider that asserts the user provided = consent to the Client. The Client can then technically establish that = all user data was gathered with consent, and the context of the = consent.
 
While the message containing the claims may be signed, having = independent claims separately signed simplifies the least privilege = tenet, where a component only has access to the user information it = needs..  
 
/Dick

= --Apple-Mail=_1369ECFC-32A4-49E4-BEA3-5C2EB07AB079-- From nobody Wed Jan 29 22:58: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 959F11200CD for ; Wed, 29 Jan 2020 22:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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] 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 KFtJdxAZrK_7 for ; Wed, 29 Jan 2020 22:58:31 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA201200C3 for ; Wed, 29 Jan 2020 22:58:30 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id r19so2117594ljg.3 for ; Wed, 29 Jan 2020 22:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YXXRi3Ur25O9zMbvgQ9+yo3KUKK57bLUne2PcpqKwio=; b=Q3oqzU2SBpK1Y1WqAZkHqidzMRsduSZlw07CfsxOYsjuNnCq/TuZB3H3XR3y3ICgLN Up1e2yqb6qZTfQajydGsuS1JmuAtzgVzFczy2nVOvNQKOKKKWCtTMM5o8neF/pJT2P8y HPzsNA9Tg5YV5dtAJ3Gm3yjP9Y1MlpJkzndjUO6XHit7ce/HwMrR6jHMU/n+owCpOpfd L+lll++4IKn9V9bsBBni839Kipqt2qeVIPV/FqacpLRCSwkXSeHNL4UMFwmL5kThTERs hlpUXplVGLDqV7ofUx4qZzD3HoQwS5/cG/nB6agME9MvG5v5iJQod/EbtXwHVM/8jM2c jrtA== 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=YXXRi3Ur25O9zMbvgQ9+yo3KUKK57bLUne2PcpqKwio=; b=AixfXIlSqBfteuE0KwAKqtRZQ2jCuwzabjUIgkTnWzubBcOgMZ1RnfILAJysEI7LeR nNA4oR3+xUdamvAapURQnwH0ZKQY4xfTwtW/ZbwX4x63OsYxhi50Cm51hKoIIwfq+/e+ f+3qH19n3sL3qkU7Bkpbt4rJ9IcXES2dlxM575MRsPPkuHj4DjtSZ1fSn95kKmWde0Px QW0zPQx6hj/IK8bce2tPV+b+1LT8LW0Udjk3Xd2AAVdxk9F/iexavxaKtFuNsXVEeZdc 6zp9Z304TcUJhmJ6RSthu+iA9+OhcMI8f+ln2nWyD1rZu2Tc06I+AhyqIz0WAQIPvJMR TrPg== X-Gm-Message-State: APjAAAW79BGQ44kX2LOXTXLbACjUAtC4sXdDWV4wS4wjCqsI4pRdDkVJ liv+kS2VNHI4pvSuPYZyPuaifj9F9tum13eldGA= X-Google-Smtp-Source: APXvYqxE+tzubl0FlKJ7bEyFEt51GblkmDBsjbqSPvohYW1ja+tC488xoRQJXruoKyCnP/+9cpaBbSiXpdiQ/oJs3wg= X-Received: by 2002:a2e:84d0:: with SMTP id q16mr1902788ljh.138.1580367508553; Wed, 29 Jan 2020 22:58:28 -0800 (PST) MIME-Version: 1.0 References: <1A271B3F-63C7-4575-9363-3AA9A9DCCC78@mit.edu> <430ED973-AA62-4D75-975B-A1163605162A@lodderstedt.net> <08ADC53C-8FA8-4A7F-995E-4D88EC0DB5CE@mit.edu> <585BCD70-6B64-4058-AC70-B677695DB391@mit.edu> <7833DDB1-FB88-4151-84B6-8DABB6436B53@amazon.com> In-Reply-To: From: Dick Hardt Date: Wed, 29 Jan 2020 22:58:02 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" , Kim , Torsten Lodderstedt , Mike Jones Content-Type: multipart/alternative; boundary="000000000000f64927059d55fb5d" Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: The need for signed claims - providence 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, 30 Jan 2020 06:58:35 -0000 --000000000000f64927059d55fb5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin: would you respond to my critique of your statement? I was not talking about SETs. Tl;dr: multiple services in a pipeline in a complex app may need to independently verify a claim. =E1=90=A7 On Wed, Jan 29, 2020 at 10:19 PM Justin Richer wrote: > I think the use cases for SET are very different from an authentication > assertion, which is consumed then discarded. Aaron Parecki has written a > good blog post that touches on this: > > https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz > > If we need a persistent record then we can also send that =E2=80=94 maybe= it=E2=80=99s > even a SET instead of an ID Token? I=E2=80=99m still fine with enabling s= igned JWTs > to carry information, but what I was against was stating any assumption > that they would always be signed or encrypted, and that JWT would be the > assumed carrier for that. > > =E2=80=94 Justin > > On Jan 30, 2020, at 1:00 AM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > +1 to Dick=E2=80=99s counterpoints. The Security Considerations in > draft-ietf-secevent-http-push > > talk about validation of persisted SETs as one reason a deployment may > wish to transmit signed SETs even over a TLS-protected channel. The same > idea applies to identity claims or just about anything else, really. > > =E2=80=93 > Annabelle Richard Backman > AWS Identity > > > *From: *Dick Hardt > *Date: *Wednesday, January 29, 2020 at 2:16 PM > *To: *Justin Richer > *Cc: *"txauth@ietf.org" , Kim , > Torsten Lodderstedt , "Richard Backman, > Annabelle" , Mike Jones > *Subject: *[UNVERIFIED SENDER] Re: The need for signed claims - providenc= e > > I forgot to include the reference to Annabelle calling this out earlier > > https://mailarchive.ietf.org/arch/msg/txauth/0hR49OnE3oqNPuCIQ43fN1o886w > > > On Wed, Jan 29, 2020 at 1:14 PM Dick Hardt wrote: > > Forking the discussion to focus on signed claims > > On Wed, Jan 29, 2020 at 3:37 AM Justin Richer wrote: > > > First, I don=E2=80=99t believe there are going to be many, if any, cases = where we > need user claims to be signed and encrypted separately from the core > transaction messages. Even in OIDC, the ID Token is allowed to be unsigne= d > when it is retrieved from the token endpoint directly using the code flow= . > The equivalent of this is the only place that TxAuth would be sending bac= k > user claims directly. We no longer have a need to protect things as they > travel through the front channel on a redirect, and we no longer have a > need to use the user=E2=80=99s claims as an artifact for things like sess= ion > management (we can define a new artifact for that purpose that fits > better). This effectively means that we don=E2=80=99t need to redefine th= e ID Token > because we don=E2=80=99t need the equivalent of the ID token in the same = way.. For > the cases that we do need to define user claims, we should be defining th= em > as a JSON object model. And I also believe that this JSON data model shou= ld > not be intertwined with or constrained by the JWT claims registry. The OI= DC > claims registry can serve as influence and input to our user claims set i= f > we choose, but I don=E2=80=99t think we should be intertwined with that e= ither. > > > I disagree. I think it is likely that we will see an increase in signed > claims and messages. > > In my opinion, the providence of a claim or message is far more important > than protection during transit. > > *Client / AS non-repudiation*: when sensitive operations are performed > relying on the contents of a claim, the Client will want repudiation that > the AS or claims issuer made a claim. > > *Separation of duties in complex systems*: In large organizations, a > major security threat is a malicious insider. Once an organization reache= s > a certain size, you assume there are people employed at the company that = do > not have the firms best interests in mind. One mitigation of this threat = is > done by separating what different teams can do with customer / sensitive > data, requiring collusion to access or modify the data. Signed messages a= nd > claims simplify different components being able to independently verify a > message or claim. Similarly, a component issuing a claim, has assurance > that other components in the same system are not modifying it. Large > organizations wrap external systems that do not support this with their o= wn > security mechanism -- but not all organizations are this sophisticated, a= nd > as they grow, retrofitting is difficult. Enabling end to end providence i= s > a best practice in my opinion. > > *User Consent Audit*: as privacy becomes a larger public topic, it is > easy to imagine organizations wanting to prove that they obtained user > information with consent. Rather than gathering user information directly > from the user, a Client can acquire claims from the User's claims provide= r > that asserts the user provided consent to the Client. The Client can then > technically establish that all user data was gathered with consent, and t= he > context of the consent. > > While the message containing the claims may be signed, having independent > claims separately signed simplifies the least privilege tenet, where a > component only has access to the user information it needs.. > > /Dick > > > --000000000000f64927059d55fb5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Justin: would you respond to my critique of your statement= ? I was not talking about SETs.

Tl;dr: multiple services= in a pipeline in a complex app may need to independently verify a claim.= =C2=A0
<= img alt=3D"" style=3D"width:0px;max-height:0px;overflow:hidden" src=3D"http= s://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%3D&t= ype=3Dzerocontent&guid=3D03e26191-cfe7-43dc-900c-1500ddf37cf0">=E1=90=A7

On Wed, Jan 29, 2020 at 10:19 PM= Justin Richer <jricher@mit.edu&g= t; wrote:
I think the use cases for SET are very = different from an authentication assertion, which is consumed then discarde= d. Aaron Parecki has written a good blog post that touches on this:

If we need a persistent record= then we can also send that =E2=80=94 maybe it=E2=80=99s even a SET instead= of an ID Token? I=E2=80=99m still fine with enabling signed JWTs to carry = information, but what I was against was stating any assumption that they wo= uld always be signed or encrypted, and that JWT would be the assumed carrie= r for that.

=C2=A0=E2=80=94 Justin

On Jan 30, 2020, at 1:00 AM, Richard Backman, Annabel= le <richanna@am= azon.com> wrote:

+1 to = Dick=E2=80=99s counterpoints.=C2=A0The Security Considerations= in draft-ietf-secevent-http-push=C2=A0talk about validati= on of persisted SETs as one reason a deployment may wish to transmit signed= SETs even over a TLS-protected channel. The same idea applies to identity = claims or just about anything else, really.
= =C2=A0
=E2= =80=93=C2=A0
Annabelle Richard Backman
AWS Identity
=C2=A0
=C2=A0
From:=C2=A0Dick H= ardt <dick.har= dt@gmail.com>
Date:=C2=A0Wednesday, January 2= 9, 2020 at 2:16 PM
To:=C2=A0Justin Richer <jricher@mit.edu>
<= b>Cc:=C2=A0"txauth@ietf.org" <txauth@ietf.org>, Kim <kim@identityblog.com>, Torsten L= odderstedt <torsten@lodderstedt.net>, "Richard Backman, Annabelle" &l= t;richanna@amazon.= com>, Mike Jones <Michael.Jones@microsoft.com>
Subject:= =C2=A0[UNVERIFIED SENDER] Re: The need for signed claims - provi= dence
=C2=A0
I forgot to include the reference to Annabell= e calling this out earlier
=C2=A0<= u>
= =C2=A0
=C2=A0<= /div>
On Wed, Jan 29, 2020 at 1:14 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Forkin= g the discussion to focus on signed claims
=C2=A0
On Wed, Jan 29, 2020 at 3:= 37 AM Justin Richer <jricher@mit.edu> wr= ote:
<snip>
First, I do= n=E2=80=99t believe there are going to be many, if any, cases where we need= user claims to be signed and encrypted separately from the core transactio= n messages. Even in OIDC, the ID Token is allowed to be unsigned when it is= retrieved from the token endpoint directly using the code flow. The equiva= lent of this is the only place that TxAuth would be sending back user claim= s directly. We no longer have a need to protect things as they travel throu= gh the front channel on a redirect, and we no longer have a need to use the= user=E2=80=99s claims as an artifact for things like session management (w= e can define a new artifact for that purpose that fits better). This effect= ively means that we don=E2=80=99t need to redefine the ID Token because we = don=E2=80=99t need the equivalent of the ID token in the same way.. For the= cases that we do need to define user claims, we should be defining them as= a JSON object model. And I also believe that this JSON data model should n= ot be intertwined with or constrained by the JWT claims registry. The OIDC = claims registry can serve as influence and input to our user claims set if = we choose, but I don=E2=80=99t think we should be intertwined with that eit= her.
=C2= =A0
I disagree. I think it is likely that = we will see an increase in signed claims and messages.
<= /div>
=C2=A0
In my op= inion, the providence of a claim or message is far more important than prot= ection during transit.=C2=A0
=C2=A0
Client / AS non-repudiation= : when sensitive operations are performed relying on the contents of a clai= m, the Client will want repudiation that the AS or claims issuer made a cla= im.
=C2=A0
Separation of duties in complex systems: In large or= ganizations, a major security threat is a malicious insider. Once an organi= zation reaches a certain size, you assume there are people employed at the = company that do not have the firms best interests in mind. One mitigation o= f this threat is done by separating what different teams can do with custom= er / sensitive data, requiring collusion to access or modify the data. Sign= ed messages and claims simplify different components being able to independ= ently verify a message or claim. Similarly, a component issuing a claim, ha= s assurance that other components in the same system are not modifying it. = Large organizations wrap external systems that do not support this with the= ir own security mechanism -- but not all organizations are this sophisticat= ed, and as they grow, retrofitting is difficult. Enabling end to end provid= ence is a best practice in my opinion.
=C2=A0
User Consent Audit: as privacy becomes a larger public topic, it is easy to imagine organiza= tions wanting to prove that they obtained user information with consent. Ra= ther than gathering user information directly from the user, a Client can a= cquire claims from the User's claims provider that asserts the user pro= vided consent to the Client. The Client can then technically establish that= all user data was gathered with consent, and the context of the consent.
=C2=A0
While the message containing the claims may be signed, having in= dependent claims separately signed simplifies the least privilege tenet, wh= ere a component only has access to the user information it needs..=C2=A0=C2= =A0
=C2=A0
/Dick

 =E2=80=94 Justin

On Jan 29, 2020, at 9:50 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for writing these = detailed questions, Kim.  I believe that they point out a number of = places where even experts in the field, such as yourself, currently have = trouble understanding parts of what the charter is proposing that we do = =E2=80=93 partially because terminology is used that isn=E2=80=99t = commonly understood.  I hope that the draft charter will be revised = to make the intent and the goals more accessible and less ambiguous.
 
Responding = to the discussion on whether existing JWT identity claims will do the = job or not, fortunately, even if they don=E2=80=99t, there=E2=80=99s a = mechanism to add ones that do: the IANA JSON Web Token Claims registry = at https://www.iana.org/assignments/jwt/jwt.xhtml#claims. = ; For instance, an =E2=80=9Cemail_addresses=E2=80=9D claim that is = array-valued could be defined and registered if there=E2=80=99s a need = to represent multiple e-mail addresses, per Annabelle=E2=80=99s = example.  The further good news is that if the working group = defines new claims that are registered, they can be reused by others = also using JWTs =E2=80=93 just like this working group can reuse claims = defined by others.
 
Also on the = subject of JWTs, I would suggest that the charter be updated to = explicitly call out that JWTs will be the working group=E2=80=99s = preferred representation signed and/or encrypted claims.
 
Finally, I = also think that the charter would benefit from explicitly listing things = that are out of scope (which is often done in charters).
 
Thanks = again for prompting this useful discussion, Kim.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Justin = Richer
Sent: Wednesday, January 29, 2020 = 12:46 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>Cc: Kim <kim@identityblog.com>; = Dick Hardt <dick.hardt@gmail.com>; txauth@ietf.org; Richard Backman, Annabelle = <richanna=3D40amazon.com@dmarc.ietf.org>
Subject: [EXTERNAL] Re: [Txauth] = Questions on the TxAuth charter
 
I didn=E2=80=99t mean =E2=80=9Cpatch=E2=80=9D to sound = disparaging, sorry if it came across as such. What I mean by = =E2=80=9Cpatching=E2=80=9D here is that it is adding functionality to an = existing set of claims and schema. If you are using that schema as a = base, it makes sense as a viable solution in that space. I, however, am = bringing up the question of whether we are using that schema as our base = at all.
 
I=E2=80=99ll note that 8112 doesn=E2=80=99= t define a schema or syntax, both of which are required. But if we were = starting OIDC today with EKYC=E2=80=99s requirements, I=E2=80=99m not = convinced we=E2=80=99d end up with the same structure. 
 
As with everything, it=E2=80=99s a very = important input into what we=E2=80=99re trying to solve, especially = influencing what=E2=80=99s extensible and how.
 
 =E2=80=94 Justin


On Jan 29, 2020, at 8:06 AM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:
 
 


Am = 29.01.2020 um 07:34 schrieb Justin Richer <jricher@mit.edu>:

=EF=BB=BFI think the ekyc work is great for what it is, but = again we have an opportunity to take a step beyond it. In my view, = we=E2=80=99d be better off defining a means of specifying field metadata = a la NIST IR 8112 as part of the schema instead of patching the existing = OIDC fields. https://pages.nist.gov/NISTIR-8112/
 
We tried and it did not fulfill our requirements. = verified_claims is by no means a patch, it=E2=80=99s a viable = solution.


 
 =E2=80=94 Justin


On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:
 
 


Am = 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:

The ..._verified claims don=E2=80=99t define how or when = verification occurred.
 
Sure, they do. Look at the = time and method fields. 
 
Since OpenId Connect for Identity Assurance (aka = verified_claims) is ongoing work feel free to contribute.
 
https://openid.net/wg/ekyc-ida/