From nobody Sun Dec 1 07:41:35 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F3F12009C for ; Sun, 1 Dec 2019 07:41:33 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Mdi1CNtSCOV for ; Sun, 1 Dec 2019 07:41:29 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE7612003F for ; Sun, 1 Dec 2019 07:41:28 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id y11so37869799wrt.6 for ; Sun, 01 Dec 2019 07:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:mime-version:subject:message-id:date:cc:to; bh=D7j3iN7N+1EE0jEmuT2MZ/AxDpbC1ZSjZr++gYyxEnE=; b=NTLz18HXRxuHBpcyAd0JStp9j1GRMW8SsmPsQ36ugpQ/eCuzsF+w7y8uTzoLuSilI3 +eihJh4GGm4N1yvaON05SgeoGKhjKh3+1fucAuH/DUsDs941bJ2mWpukX9gyirEWhmph 1FmNyGs3XZ3oviw1BOUcy7AaIxSCRHwslNemoCM5FkvHw2axi9X6u/C0N1ZrNBC4thdq eTB9qetaBxXx2rPpNguVErH+jaiNiXyRozbkbToLxFZ8r/v4/aMcLbKKdnxs3YpCLz0p Z9y8fsC1Vg9oMklW5K1NnfimZ5Gz4vVNEqx2ihY5ArtsIPj5EbWrNTU7XboXtnPWuQVJ Rhdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=D7j3iN7N+1EE0jEmuT2MZ/AxDpbC1ZSjZr++gYyxEnE=; b=JfNg1/cNz8c2A9qa/EEdMoaWZCEGEignXgJjK1Zwv9paCWyWEZwV8cI808VhqY5eCm b5wEJSBTh3MtaeLqPBpuHJsYYMmvL6eEDIs6RBNgAVogZbAbCHHhdlkM05EFhdlI4JZG uyG+Wq2Pa6qRza4Z8irEmhQVMzdH0YLz1GIyLJ2mUQYvAl5OVUTBrUjLzaT45p3HtGIq Y1h0QSrqa6xKCL7kP7laIBkgR/XdoO27seelDzvFSGjDH8eUuMM/tpvZhpoZw7+1iS1d +pYUbH2UGbM6sw6qz+CfCy8Ga/R0xmzcikc2SBtJzPPC3Re+Qe748sVbMWUk39tlhx0z p8Lg== X-Gm-Message-State: APjAAAWTv4UZd9J3H0fPJx/ikJSLh1l9FSneOaLbYNUk16IqiRTRDLfJ aBLG4kdfd9WnrdKZuh28Yy/7aA== X-Google-Smtp-Source: APXvYqw+GqmSgOT5r0WYz0ZJyGwHZbA/ULxt9sL6nMBnsn6wAfs/ev3tc9Hd6jgrB4/nta+pYp0WeQ== X-Received: by 2002:a5d:4752:: with SMTP id o18mr16074026wrs.330.1575214887005; Sun, 01 Dec 2019 07:41:27 -0800 (PST) Received: from [192.168.71.123] (p549EE7F4.dip0.t-ipconnect.de. [84.158.231.244]) by smtp.gmail.com with ESMTPSA id z6sm6365971wmz.12.2019.12.01.07.41.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Dec 2019 07:41:26 -0800 (PST) From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_8359F295-535C-426C-A4FA-7682B1BD3D41"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Message-Id: <6DD96E5F-2F26-4280-BDF9-41F43CB5A3AF@lodderstedt.net> Date: Sun, 1 Dec 2019 16:41:11 +0100 Cc: "Richard Backman, Annabelle" , oauth To: Annabelle Backman X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 15:41:33 -0000 --Apple-Mail=_8359F295-535C-426C-A4FA-7682B1BD3D41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Annabelle, > Am 27.11.2019 um 02:46 schrieb Richard Backman, Annabelle = : >=20 > =EF=BB=BFTorsten, >=20 > I'm not tracking how cookies are relevant to the discussion. I=E2=80=99m still trying to understand why you and others argue mTLS = cannot be used in public cloud deployments (and thus focus on = application level PoP). Session cookies serve the same purpose in web apps as access tokens for = APIs but there are much more web apps than APIs. I use the analogy to = illustrate that either there are security issues with cloud deployments = of web apps or the techniques used to secure web apps are ok for APIs as = well. Here are the two main arguments and my conclusions/questions: =20 1) mTLS it=E2=80=99s not end 2 end: although that=E2=80=99s true from a = connection perspective, there are solutions employed to secure the last = hop(s) between TLS terminating proxy and service (private net, VPN, = TLS). That works and is considered secure enough for (session) cookies, = it should be the same for access tokens. 2) TLS terminating proxies do not forward cert data: if the service = itself terminates TLS this is feasible, we do it for our = public-cloud-hosted mTLS-protected APIs. If TLS termination is provided = by a component run by the cloud provider, the question is: is this = component able to forward the client certificate to the service? If not, = web apps using certs for authentication cannot be supported straightway = by the cloud provider. Any insights? > I'm guessing that's because we're not on the same page regarding use = cases, so allow me to clearly state mine: I think we are, we are just focusing on different ends of the TLS = tunnel. My focus is on the service provider=E2=80=99s side, esp. public = cloud hosting, whereas you are focusing on client side TLS terminating = proxies. >=20 > The use case I am concerned with is requests between services where = end-to-end TLS cannot be guaranteed. For example, an enterprise service = running on-premise, communicating with a service in the cloud, where the = enterprise's outbound traffic is routed through a TLS Inspection (TLSI) = appliance. The TLSI appliance sits in the middle of the communication, = terminating the TLS session established by the on-premise service and = establishing a separate TLS connection with the cloud service. >=20 > In this kind of environment, there is no end-to-end TLS connection = between on-premise service and cloud service, and it is very unlikely = that the TLSI appliance is configurable enough to support TLS-based = sender-constraint mechanisms without significantly compromising on the = scope of "sender" (e.g., "this service at this enterprise" becomes "this = enterprise=E2=80=9D). I=E2=80=99m not familiar with these kind of proxies, but happy to learn = more and to discuss potential solutions. Here are some questions: - Have you seen this kind of proxies intercepting the connection from = on-prem service deployments to service provider? I=E2=80=99m asking = because I thought the main use case was to intercept employees PC = internet traffic.=20 - Are you saying this kind of proxy does not support mutual TLS at all? = At least theoretically, the proxy could combine source and destination = to select a cert/key pair to use for outbound TLS client authentication.=20= > Even if it is possible, it is likely to require advanced configuration = that is non-trivial for administrators to deploy. It's no longer as = simple as the developer passing a self-signed certificate to the HTTP = stack. I agree. Cert binding is established in OAuth protocol messages, which = would require the appliance to understand the protocol. On the other = hand, I would expect these kind of proxy to understand a lot about the = protocols running through it, otherwise they cannot fulfil their task of = inspecting this traffic.=20 best regards, Torsten.=20 >=20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity >=20 >=20 > =EF=BB=BFOn 11/23/19, 9:50 AM, "Torsten Lodderstedt" = wrote: >=20 >=20 >=20 >>>>>>>>> On 23. Nov 2019, at 00:34, Richard Backman, Annabelle = wrote: >>>>>>>>> how are cookies protected from leakage, replay, injection in a = setup like this? >> They aren=E2=80=99t. >=20 > Thats very interesting when compared to what we are discussing with = respect to API security.=20 >=20 > It effectively means anyone able to capture a session cookie, e.g. = between TLS termination point and application, by way of an HTML = injection, or any other suitable attack is able to impersonate a = legitimate user by injecting the cookie(s) in an arbitrary user agent. = The impact of such an attack might be even worse than abusing an access = token given the (typically) broad scope of a session. >=20 > TLS-based methods for sender constrained access tokens, in contrast, = prevent this type of replay, even if the requests are protected between = client and TLS terminating proxy, only. Ensuring the authenticity of the = client certificate when forwarded from TLS terminating proxy to service, = e.g. through another authenticated TLS connection, will even prevent = injection within the data center/cloud environment.=20 >=20 > I come to the conclusion that we already have the mechanism at hand to = implement APIs with a considerable higher security level than what is = accepted today for web applications. So what problem do we want to = solve? >=20 >> But my primary concern here isn't web browser traffic, it's calls = from services/apps running inside a corporate network to services = outside a corporate network (e.g., service-to-service API calls that = pass through a corporate TLS gateway). >=20 > Can you please describe the challenges arising in these settings? I = assume those proxies won=E2=80=99t support CONNECT style pass through = otherwise we wouldn=E2=80=99t talk about them. >=20 >>> That=E2=80=99s a totally valid point. But again, such a solution = makes the life of client developers harder. >>> I personally think, we as a community need to understand the pros = and cons of both approaches. I also think we have not even come close to = this point, which, in my option, is the prerequisite for making informed = decisions. >> Agreed. It's clear that there are a number of parties coming at this = from a number of different directions, and that's coloring our = perceptions. That's why I think we need to nail down the scope of what = we're trying to solve with DPoP before we can have a productive = conversation how it should work. >=20 > We will do so. >=20 >> =E2=80=93 >> Annabelle Richard Backman >> AWS Identity >> =EF=BB=BFOn 11/22/19, 10:51 PM, "Torsten Lodderstedt" = wrote: >>>> On 22. Nov 2019, at 22:12, Richard Backman, Annabelle = wrote: >>> The service provider doesn't own the entire connection. They have no = control over corporate or government TLS gateways, or other terminators = that might exist on the client's side. In larger organizations, or when = cloud hosting is involved, the service team may not even own all the = hops on their side. >> how are cookies protected from leakage, replay, injection in a setup = like this? >>> While presumably they have some trust in them, protection against = leaked bearer tokens is an attractive defense-in-depth measure. >> That=E2=80=99s a totally valid point. But again, such a solution = makes the life of client developers harder. >> I personally think, we as a community need to understand the pros and = cons of both approaches. I also think we have not even come close to = this point, which, in my option, is the prerequisite for making informed = decisions. >>> =E2=80=93 >>> Annabelle Richard Backman >>> AWS Identity >>> =EF=BB=BFOn 11/22/19, 9:37 PM, "OAuth on behalf of Torsten = Lodderstedt" wrote: >>>> On 22. Nov 2019, at 21:21, Richard Backman, Annabelle = wrote: >>>> The dichotomy of "TLS working" and "TLS failed" only applies to a = single TLS connection. In non-end-to-end TLS environments, each TLS = terminator between client and RS introduces additional token = leakage/exfiltration risk, irrespective of the quality of the TLS = connections themselves. Each terminator also introduces complexity for = implementing mTLS, Token Binding, or any other TLS-based sender = constraint solution, which means developers with non-end-to-end TLS use = cases will be more likely to turn to DPoP. >>> The point is we are talking about different developers here. The = client developer does not need to care about the connection between = proxy and service. She relies on the service provider to get it right. = So the developers (or DevOps or admins) of the service provider need to = ensure end to end security. And if the path is secured once, it will = work for all clients. >>>> If DPoP is intended to address "cases where neither mTLS nor OAuth = Token Binding are available" [1], then it should address this risk of = token leakage between client and RS. If on the other hand DPoP is only = intended to support the SPA use case and assumes the use of end-to-end = TLS, then the document should be updated to reflect that. >>> I agree. >>>> [1]: https://tools.ietf.org/html/draft-fett-oauth-dpop-03#section-1 >>>> =E2=80=93 >>>> Annabelle Richard Backman >>>> AWS Identity >>>> On 11/22/19, 8:17 PM, "OAuth on behalf of Torsten Lodderstedt" = wrote: >>>> Hi Neil, >>>>> On 22. Nov 2019, at 18:08, Neil Madden = wrote: >>>>> On 22 Nov 2019, at 07:53, Torsten Lodderstedt = wrote: >>>>>>> On 22. Nov 2019, at 15:24, Justin Richer = wrote: >>>>>>> I=E2=80=99m going to +1 Dick and Annabelle=E2=80=99s question = about the scope here. That was the one major thing that struck me during = the DPoP discussions in Singapore yesterday: we don=E2=80=99t seem to = agree on what DPoP is for. Some (including the authors, it seems) see it = as a quick point-solution to a specific use case. Others see it as a = general PoP mechanism. >>>>>>> If it=E2=80=99s the former, then it should be explicitly tied to = one specific set of things. If it=E2=80=99s the latter, then it needs to = be expanded. >>>>>> as a co-author of the DPoP draft I state again what I said = yesterday: DPoP is a mechanism for sender-constraining access tokens = sent from SPAs only. The threat to be prevented is token replay. >>>>> I think the phrase "token replay" is ambiguous. Traditionally it = refers to an attacker being able to capture a token (or whole requests) = in use and then replay it against the same RS. This is already protected = against by the use of normal TLS on the connection between the client = and the RS. I think instead you are referring to a malicious/compromised = RS replaying the token to a different RS - which has more of the flavour = of a man in the middle attack (of the phishing kind). >>>> I would argue TLS basically prevents leakage and not replay. The = threats we try to cope with can be found in the Security BCP. There are = multiple ways access tokens can leak, including referrer headers, = mix-up, open redirection, browser history, and all sorts of access token = leakage at the resource server >>>> Please have a look at = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.= >>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.= 8 also has an extensive discussion of potential counter measures, = including audience restricted access tokens and a conclusion to = recommend sender constrained access tokens over other mechanisms. >>>>> But if that's the case then there are much simpler defences than = those proposed in the current draft: >>>>> 1. Get separate access tokens for each RS with correct audience = and scopes. The consensus appears to be that this is hard to do in some = cases, hence the draft. >>>> How many deployments do you know that today are able to issue = RS-specific access tokens? >>>> BTW: how would you identify the RS? >>>> I agree that would be an alternative and I=E2=80=99m a great fan of = such tokens (and used them a lot at Deutsche Telekom) but in my = perception this pattern needs still to be established in the market. = Moreover, they basically protect from a rough RS (if the URL is used as = audience) replaying the token someplace else, but they do not protect = from all other kinds of leakage/replay (e.g. log files). >>>>> 2. Make the DPoP token be a simple JWT with an "iat" and the = origin of the RS. This stops the token being reused elsewhere but the = client can reuse it (replay it) for many requests. >>>>> 3. Issue a macaroon-based access token and the client can add a = correct audience and scope restrictions at the point of use. >>>> Why is this needed if the access token is already audience = restricted? Or do you propose this as alternative? >>>>> Protecting against the first kind of replay attacks only becomes = an issue if we assume the protections in TLS have failed. But if DPoP is = only intended for cases where mTLS can't be used, it shouldn't have to = protect against a stronger threat model in which we assume that TLS = security has been lost. >>>> I agree. >>>> best regards, >>>> Torsten. >>>>> -- Neil --Apple-Mail=_8359F295-535C-426C-A4FA-7682B1BD3D41 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 Fw0xOTEyMDExNTQxMTFaMC8GCSqGSIb3DQEJBDEiBCA0rFaSvfIW1cU6tyZbNzdcAKqN7YrOzb+6 r64RYqMm6DCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAKLOXXKcXpdcVDfz2RNl/reThoFKv9nNk90uj+rT4U+i3Kq2pR6A2aZ8dRwb GIdVcFzdcW17bO3XD+ztK4leFzZLG3LQDng/B+1U1gEXjUZPsifiv7hlpiMaFmq2u05NSvGgrN0p npicAMdvu0wjzkqODLVSO249goIInjODkhsDTiKx/7T6jPFczYIWmu7jhL75OkKzOsZPv+ISjIZj T/LPcGALqc2uZcd/J9a6Xi7abgoaLy55gpP+pDy3t1NdFgKOH3zvY/3CjkjtmhAh9KndBWOykX1d PoA3HHew1eDh8msuKCKtJ1c5vP2nOFSvy97k2BfPxJSR6Z5GxyAkJHAAAAAAAAA= --Apple-Mail=_8359F295-535C-426C-A4FA-7682B1BD3D41-- From nobody Mon Dec 2 01:05:17 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B575120013 for ; Mon, 2 Dec 2019 01:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, 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=rub.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Frt9YsKgGCw for ; Mon, 2 Dec 2019 01:05:13 -0800 (PST) Received: from out3.mail.ruhr-uni-bochum.de (out3.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:8:1001::8693:359b]) (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 47985120041 for ; Mon, 2 Dec 2019 01:05:13 -0800 (PST) Received: from mx3.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out3.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 47RK2D3Hw9z8SB9; Mon, 2 Dec 2019 10:05:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1575277508; bh=00ZrNJS5g9A6Az5DBq4WZJ4wSb9o25LORNZjjWGpkbo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Z8YYojC+hGOnzPeULrC67y1XO4uWRg9G8FrZ+njebB6tdKHZE9wo1cFubQGCmzObW QpDHMDk2lUIMyJWrJvvMfpSETQzcSiYM8iTYKNFxaQk35u6JMEDtZ74n+L5XfUkPa0 0h7nwojdjNPhHO22WIcWgYWGZ9zt1SFk3QGBT8VQ= Received: from out3.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx3.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 47RK2D1sgfz8S9f; Mon, 2 Dec 2019 10:05:08 +0100 (CET) X-RUB-Notes: Internal origin=IPv6:2a05:3e00:c:1001:5054:ff:fe37:b9e4 X-Envelope-Sender: Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:c:1001:5054:ff:fe37:b9e4]) by out3.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 47RK2C37Nyz8SJ9; Mon, 2 Dec 2019 10:05:07 +0100 (CET) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.0 at mx3.mail.ruhr-uni-bochum.de Received: from [192.168.93.131] (sky.nds.ruhr-uni-bochum.de [134.147.40.41]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 47RK2C43KRzytW; Mon, 2 Dec 2019 10:05:07 +0100 (CET) To: fett@danielfett.de, oauth@ietf.org References: <35143dd1-edeb-e0fd-6f36-a39d9b7f7008@hackmanit.de> <4f1d1215-aa23-93ab-ae5b-75426d7f07cc@danielfett.de> From: Christian Mainka Autocrypt: addr=Christian.Mainka@rub.de; keydata= mQINBEefF5YBEADa0W+FyzUZStHhp8YmnjPZm4Bws4sKmwXRxfSJp89Z5r79kxaXdLErifPS w4uyQuhosugg65KlNwFgtMprtGeEvQpqnsGFz1ZJFnMDZnMho48NDXdFA8KWUUTFHZTlv8fy NOH3EQ/jcWfq2VizuIewJNqyrVpbUimosQmLsBB9xLeiT6u8B0zh0hCYhnX77Y87MnPYlW1T fxT7mjGe2SJnGdm85CH2Q/9aIj7OTA5vZhrCdrbddo0c5h6WMqeYSbxUYrJ0/zBHFpfbWmFD OIEtvYLjKhEtjIpvKL6U7fJaJNPqTFp+Y0T+folxRMYIxWPMtacnvMa9YqBiEmdK8VyFBMmi gkhVqdrTKLtsxQrutKaRxJ+ACbEdNuGpjnK5ON+sNmPTmqs816x+JJGLu1ci03gbCIXXvwXF /pV2tX/dBGbTgYWZ4DAIdIJoHKgAjC0r64409nDwb4BKWtEDTAxbP+2mPVqH0uthGBz8J29Q zWUDztfy3AK7nZjhg0NRabBUYe6PPGaV81tluH5nEMvvcXSstbwAcg8BPmuSGp3G6VE4BxS6 bnRIbL9XQP24xn3TFiAus79Wmzz3yBangmUCo616qWJqpqie6arce+Zce8szwMIJD753gEo8 L+GXJ8H/jQWS8C9qPvmD9GlW+RaWoTRb4BkTds305e0HPyl9aQARAQABtDVDaHJpc3RpYW4g TWFpbmthIChSdWItTWFpbCkgPENocmlzdGlhbi5NYWlua2FAcnViLmRlPokCNgQTAQIAIAUC R58XlgIbIwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEBxg1ZHbyZM9FjIP/3AHN9PRFg3n ld0DQCCGJzu1owT4b1is1pjHC+cpoJE0KqGiYBsPb1x3p/K8+E82ZENXP0s1KMZWEz+6dm+i 5ekb10jlSXppnkoeVBh9ITBjqurRkzSHRAkKtcLLIjYXyLKCQtnMJNCYU4OLA0xqlqcqa6U3 gRHW8mFNRjNkXjxSwGD0+vEeZ1WnfUkuvHYSWAUBn8f3Xn/KP0jlwzi8xZUxZgMcrPhV3s/X dNhQMvkzXUJd61AOCRAU2ZpxTIa57bIwahJ/RLdVzumTJHEMcRJpU6MMgfYnUUHRiiIUkhhB jWrzeSaoFpoHzYwKVflh+T2u/s909sQY17eT4IeVrjT3GZfXO4PnRC85gKqJMUuEE5dYrc/f iwzZdDX1y0zl2j6URITNXKu8s5x89PUzpg/ex22iArRDS8FfQGQXx600OpSWYUYSp4CrmNKK 1M42+caUwS2TysGoH3ebqtQ0Bu4WFxArmbMc9pkgsSuCwRKphBahT0U8JnLOXyqvhVC1A5sU 8HMAPhIg9mKd8swNh+ONGW97KwHONfcJhJ2lDwr8jZYh/6dg0J/wXdnl+naht+oiVnG2dHIQ 95iGFjiILW7OC0laYS0BCFSGJiG/wYr/heGNf+IgIXs1MJUE+AbiwGYE2FZRRA3oonLzQcQ4 xYLG3WKhlG6cUg2tYAKiY7hjtCpDaHJpc3RpYW4gTWFpbmthIDxDaHJpc3RpYW4uTWFpbmth QHJ1Yi5kZT6JAjsEEwECACUCGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJRCCWaAhkB AAoJEBxg1ZHbyZM9PuYP/3a/1kPLhy11Hjqz12SJoQi10JlTpRILcWXAoUOFmOQlPkMzwp+j vyg0XMW7VHfRpNyFDhMofAsibVFj6OvWRmg6Mrpsz0IwbH6k7ukcb0Uvv/EWhBHvqDpkGdIo 0iAkoyuygTIVsLRjJmU0QrnaS9J/QQTQSzpMG0Y/NXmt8a6j0aR92hYllhTdWbHGgQlcMa6R JBBR9fExoOlc9LZM3gyFI89STpWZcvFviO6VYlIKTqCFiH8W4u/yzP3fvjz2JLSS3SAAyd4z oaqMGSDqb97iJI39jja2BrJCkHDGpb0god0IMz+LMSXFc5faewBy5HfIsOj2tt4J9gUoKOwp fIDccOMirO5qywo5w79ofzx4AWDl+O1q4SXJmFUQWdnanM9TwR0wRmFa2q5ZugHlQbIdGMqR py5XrcTBcSoQRxGiFdjchJAYeNNQnOIMdHtolcSHpwKUc0CLIjrzMMnAui1WIr8jcdxiuqrU EJDZWiVZhxetq1An8lDX8q5IDmq1ZnS5PfmlOpMmL3QduEEqQQ40St2pbfCyCMz19jK/d6Kb lVoG4MhGq1ofIKu6KfWZmIEsiLGidNPByL84AB+8B9VArlS5pG4esIF5c5nyv1InlNCz5aNZ XzRxvJVqYEcTnM6f+29BDNGCPGfIVCyiocYCE2Z6TSA//VyQXMGdxB1UuQINBEefF9IBEACa oaSOVrtoEx+1FFoFHro9mI2rViLcHY44EyPBSlgUQgNeyMBnV9yrFf2awpZimXkXYOJ39dtD KOleiJ+XpM7n0tEDJ+tPz4Avc2iQ4RMyIndrM4okmfmTHuWZkV5ZJAERF59hMRDp8dRBzFDB XDEVhFsOZGFaf5qJE78774Jb/I0Sh6wn4FY2Pr/ZdEA5FOlzHNa8LlMv2Qeh8t+HdL/ySTDG JAI2qTeszqWtDSnMT+ExYH+zWCiYYw0/2/U01L/Qn5wNiEihAv4XYkkQsMecMw9H8zZ7Ob1h rSwWR1pYJIiJ94cHDTeLIq2bY0yHuxiQLbUMyCkPQhTXvz1mdkzVHlhMZefHkeo25dvbnCot 6JoWOyyCghEixtMeRpYReKOmkHDVMRLqo1VJSxYhyrmmdZUfJjTBqqpl4nvYPj5cLvogI2Cp GeKFgkfzZ3/OIMamipJOLQHoX80Y04Ug9k5BxUHJPPX054g+GB6YT1xYncPDj+J+aP1EvOSM h4DyAspB9gZoI5Xx8swL3UvQySpakgHoGeOfz0wsYOijoGW9UCkwqIWbrQ44Y+SgjxKEp3rk Z0a5PCcOSNPynIIxyWukbIDk6nhqp/Ni3vzpoAjGHs05w+YqP/sv8wykeK/2JejNkpZIDVop nvXFDc5QLc+cn70X1Ny9sYYj1+/KmS7d4QARAQABiQIfBBgBAgAJBQJHnxfSAhsMAAoJEBxg 1ZHbyZM9DIIP/iBxx1yb3Iy7m23GcNsfWRUnSmkAdkLf9VoEESvxtuC1l8AEUCeoTiQ0LSas Z2asV6yoMQOStv3eW6/WL6ZUL0jTm7x3Ki0/Ej+obnKpCKV3E45ku7unilXI4+TSPXxmwQOi 0ZVa+MwZn7jhwQuk60EgBUW0VyPmpgYnxtcb2HGGRj3V06A+T2963AyrM6gFBDSm5ulSwKyd LBDsbOpD9JXCvVrAFwCs8isa0snhhuipQZR3fKYhQ8pbCGSFYJ+BAgZuj02eeEQZP8J04LAY ItcsuO01B27svDJRF6BcoYljfO6Cat625mxsjYvITTsq0iCTx0d/OOee7nPhChB7bsRm9/F/ /N0STfbQVRyt0RZS0uGzo5lESk+TnlteNx6oJUpWTgO7FXr4j2ZpSGznjV57Sjgh8QttUubI DPrjFSGiY8z0DxZrIdWVtgDj2LeVnjql5eZpOn2BCe/+dRg581t5vZvCaIlpu+YBxWmJHU7V PyAY6Sq4xY6JW6B3yqkqTmOPE/ARUIYRzHPmv15kCINS/Jpw6fWTzsD1HPaRVVEwDuFRSxaK toDFOB7DktTf2NsyKDC0GN3w6x+I9VUHjJePK3wXqjQs0g/DXc7OBJV+1nBkj0ZlHqtuiNom fhycC18ZvUs6re/gu2jSSK3ME5Tll/qYGq5DcuzSTSnNS1Q3 Message-ID: <277a3bc8-32fc-8c7c-85dc-5030d2d07728@rub.de> Date: Mon, 2 Dec 2019 10:05:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <4f1d1215-aa23-93ab-ae5b-75426d7f07cc@danielfett.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 09:05:15 -0000 Hi Daniel, I think this problem is not only restricted to the redirect_uri. Regarding countermeasure (1), also the A-AS can return the same client_id as the client uses on the H-AS. TL;DR: In countermeasure (1), only the issuer prevents MixUp, the client_id parameter can be faked as well during the registration of the client (especially if Dynamic Client Registration is used). Regards Christian On 26.11.19 15:20, Daniel Fett wrote: > Hi Karsten, > > Very interesting observation! > > My gut feeling is that this is the real problem here: > > Am 26.11.19 um 14:24 schrieb Karsten Meyer zu Selhausen: >> Depending on its implementation the client might simply extract all da= ta >> contained in the Client Information Response and use it for >> authorizations with the specific AS. >> We were able to confirm that one popular open-source library behaves i= n >> this exact way. It stores the redirect URI contained in the Client >> Information Response and uses it for Authorization Requests with the >> A-AS although it differs from the redirect URI in the Client >> Registration Request. > The client uses untrusted, unverified data to make its decision on what= > redirect URI to use. > > Nonetheless, we should definitely mention this in the BCP! > >> In our opinion this makes the countermeasure "AS-specific redirect URI= s" >> obsolete and we believe the other countermeasure described in the BCP >> (adding an AS identifier and the client_id of the intended recipient t= o >> AS's responses) should be used to prevent Mix-Up attacks. If the >> involved entities use the OIDC hybrid flow this countermeasure is >> automatically applied. > These are more intrusive changes than the per-AS redirect URI and may > require new parameters. > > Daniel > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Dr.-Ing. Christian Mainka Horst G=C3=B6rtz Institute for IT-Security=20 Chair for Network and Data Security=20 Ruhr-University Bochum, Germany Universit=C3=A4tsstr. 150, ID 2/463 D-44801 Bochum, Germany Telefon: +49 (0) 234 / 32-26796 Fax: +49 (0) 234 / 32-14347 http://nds.rub.de/chair/people/cmainka/ @CheariX From nobody Mon Dec 2 02:26:25 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6261200D7 for ; Mon, 2 Dec 2019 02:26:23 -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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z7QUf1GuZ1J for ; Mon, 2 Dec 2019 02:26:22 -0800 (PST) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26CD8120073 for ; Mon, 2 Dec 2019 02:26:22 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 968F54496; Mon, 2 Dec 2019 10:26:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1575282379; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tFtkCXdoNjhQsz+MLvLLtpBj6S2HcocNHwV/NGXbtXM=; b=va6rFZPBXn4DIjvesh575/MPFQy3yl8yoPVkc6+qhtw5ZUhkqShpWfsVO2hn6MSJ3Xkspu KSWxveZv3RCsH0YehQL44KpbayzKvx/Ciux3b9qoAYS1sHc5e+rc500V1STJwpF9aqmF7P tp9VlZJI+PWKA/UZKP7AcNvnNmH/TY4= To: Christian Mainka , oauth@ietf.org References: <35143dd1-edeb-e0fd-6f36-a39d9b7f7008@hackmanit.de> <4f1d1215-aa23-93ab-ae5b-75426d7f07cc@danielfett.de> <277a3bc8-32fc-8c7c-85dc-5030d2d07728@rub.de> From: Daniel Fett Message-ID: <8047bf89-1120-426d-e020-e58766c2ce3a@danielfett.de> Date: Mon, 2 Dec 2019 11:26:19 +0100 MIME-Version: 1.0 In-Reply-To: <277a3bc8-32fc-8c7c-85dc-5030d2d07728@rub.de> Content-Type: multipart/alternative; boundary="------------7C37DC385B6C5BF4919110A4" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1575282379; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tFtkCXdoNjhQsz+MLvLLtpBj6S2HcocNHwV/NGXbtXM=; b=ociVWsYlMfVQXGQ70XsmN/rMd/xD1/KyWTiiCjQtrYmF60KUnvhAYHuNuxjW+n+nwW0Tl+ UqzrVjhxlJ8nR0VywThGq3N28htOkSQUHg0WNycIvXciBPPtjOto4oDZyhx2IFUYVx5nvq 8Urj3dbwJ0SGqPGVdECDrob/ZAPRXpI= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1575282379; a=rsa-sha256; cv=none; b=nGFuBhmpE6+SFRW1GvgNHNQCxpXl0mElPIudWhNS9IOVP/Ft2PZvE57Y480A/GACyEWg6n54W3qFDvWn7z+WXf+sz24Jm5/5k1BXBwNUyMTQqRchLUg929Q2a8R7kumvIikDO5Cto1+tped/oT+cl9vvaW0JFWQXroT1DMJ+Hf4= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: --- Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 10:26:23 -0000 This is a multi-part message in MIME format. --------------7C37DC385B6C5BF4919110A4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Am 02.12.19 um 10:05 schrieb Christian Mainka: > I think this problem is not only restricted to the redirect_uri. > Regarding countermeasure (1), also the A-AS can return the same > client_id as the client uses on the H-AS. > > TL;DR: In countermeasure (1), only the issuer prevents MixUp, the > client_id parameter can be faked as well during the registration of the > client (especially if Dynamic Client Registration is used). What would be the issuer identifiers of A-AS and H-AS in this case be, as seen by the client? -Daniel --------------7C37DC385B6C5BF4919110A4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Am 02.12.19 um 10:05 schrieb Christian Mainka:
I think this problem is not only restricted to the redirect_uri.
Regarding countermeasure (1), also the A-AS can return the same
client_id as the client uses on the H-AS.

TL;DR: In countermeasure (1), only the issuer prevents MixUp, the
client_id parameter can be faked as well during the registration of the
client (especially if Dynamic Client Registration is used).

What would be the issuer identifiers of A-AS and H-AS in this case be, as seen by the client?

-Daniel


--------------7C37DC385B6C5BF4919110A4-- From nobody Mon Dec 2 13:34:56 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFBA12008C for ; Mon, 2 Dec 2019 13:34:53 -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 OvhjzTXSje3w for ; Mon, 2 Dec 2019 13:34:51 -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 CDAB1120018 for ; Mon, 2 Dec 2019 13:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1575322491; x=1606858491; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FKbNQPHnmLyMRy0lE3behaW1i/5Vm64PQF46QPC2ubU=; b=c9nNLcgTiZkEyuKF4i3LPPid+PP37eW8ft/01kUQegDwiuwWXDOEfoeP oXKlR+H4OvAnYsxo1/nn9zMsaAqGSXUVF3oAdAKRhMj54Of2Gx6SNmNlz RmGQHfHnCplsLte5lgH9lbTM9Jz5TTExxvPAsQIH4hVziXBshr4JTtf8E Q=; IronPort-SDR: xAuLswDWvbZYL46K/WXAbs6EWhRjMEDjOcOhq65wowZd/yOp/xNdrYCmcy+bOu9oNacy7Fd5xc LDW06PpMfqKA== X-IronPort-AV: E=Sophos;i="5.69,270,1571702400"; d="scan'208";a="7282797" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2a-c5104f52.us-west-2.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 02 Dec 2019 21:34:49 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2a-c5104f52.us-west-2.amazon.com (Postfix) with ESMTPS id 6E4CBA18C6; Mon, 2 Dec 2019 21:34:48 +0000 (UTC) Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 2 Dec 2019 21:34:47 +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, 2 Dec 2019 21:34:47 +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, 2 Dec 2019 21:34:47 +0000 From: "Richard Backman, Annabelle" To: Torsten Lodderstedt CC: oauth Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt Thread-Index: AQHVqF3YgLh4lMdWs0CTPwFtLj4EVqem2cuA Date: Mon, 2 Dec 2019 21:34:47 +0000 Message-ID: <3F3A350A-0EF3-4968-968E-9325F8434E80@amazon.com> References: <6DD96E5F-2F26-4280-BDF9-41F43CB5A3AF@lodderstedt.net> In-Reply-To: <6DD96E5F-2F26-4280-BDF9-41F43CB5A3AF@lodderstedt.net> 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.217] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: New Version Notification for draft-fett-oauth-dpop-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 21:34:54 -0000 PiBTZXNzaW9uIGNvb2tpZXMgc2VydmUgdGhlIHNhbWUgcHVycG9zZSBpbiB3ZWIgYXBwcyBhcyBh Y2Nlc3MgdG9rZW5zIGZvciBBUElzIGJ1dCB0aGVyZSBhcmUgbXVjaCBtb3JlIHdlYiBhcHBzIHRo YW4gQVBJcy4gSSB1c2UgdGhlIGFuYWxvZ3kgdG8gaWxsdXN0cmF0ZSB0aGF0IGVpdGhlciB0aGVy ZSBhcmUgc2VjdXJpdHkgaXNzdWVzIHdpdGggY2xvdWQgZGVwbG95bWVudHMgb2Ygd2ViIGFwcHMg b3IgdGhlIHRlY2huaXF1ZXMgdXNlZCB0byBzZWN1cmUgd2ViIGFwcHMgYXJlIG9rIGZvciBBUElz IGFzIHdlbGwuDQoNCiJTZWN1cml0eSBpc3N1ZXMiIGlzIGEgbG9hZGVkIHRlcm0sIGJ1dCBpZiB5 b3UgbWVhbiB0aGF0IHRoZXJlIGFyZSBwcmFjdGljYWwgcmlza3MgdGhhdCBhcmUgbm90IGFkZHJl c3NlZCBieSBiZWFyZXIgdG9rZW5zICh3aGV0aGVyIHRoZXkgYmUgc2Vzc2lvbiBjb29raWVzIG9y IGFjY2VzcyB0b2tlbnMpIHRoZW4geWVzLCBJIHRoaW5rIHdlIGJvdGggYWdyZWUgdGhhdCB0aGVy ZSBhcmUuIE90aGVyd2lzZSB3ZSB3b3VsZG4ndCBiZSBkaXNjdXNzaW5nIFBvUCwgc2VuZGVyLWNv bnN0cmFpbmVkIHRva2VucywgZXRjLiBUTFMtYmFzZWQgc29sdXRpb25zIG1pdGlnYXRlIHNvbWUg cmlza3MsIHdoaWxlIGxlYXZpbmcgb3RoZXJzIHVubWl0aWdhdGVkLiBEZXBlbmRpbmcgb24geW91 ciB1c2UgY2FzZSBhbmQgdGhyZWF0IG1vZGVsLCB0aGVzZSByaXNrcyBtYXkgb3IgbWF5IG5vdCBw cmVzZW50IHByYWN0aWNhbCB0aHJlYXRzLiBGb3IgbXkgdXNlIGNhc2VzLCB0aGV5IGRvLg0KDQpV bHRpbWF0ZWx5IEknZCBsaWtlIHRvIG1pdGlnYXRlIHRoZXNlIHJpc2tzIGZvciBib3RoIHNlcnZp Y2UgQVBJcyBhbmQgd2ViIGFwcGxpY2F0aW9ucy4gTXkgZm9jdXMgaXMgb24gc2VydmljZSBBUElz IGZvciBhIGNvdXBsZSByZWFzb25zOg0KDQoxLiBJbnRlcm9wZXJhYmlsaXR5IGlzIG1vcmUgaW1w b3J0YW50IHdoZW4gdGhlIHNlbmRlciBhbmQgcmVjaXBpZW50IGFyZW4ndCBuZWNlc3NhcmlseSBv d25lZCBieSBhIHNpbmdsZSBlbnRpdHkuIEkgY2FuIGRvIHByb3ByaWV0YXJ5IHRoaW5ncyBpbiBK YXZhU2NyaXB0IGlmIEkgd2FudCB0byBqdXN0IGFzIEkgY2FuIGluIGNsaWVudCBTREtzLCBidXQg dGhpcyBicmVha3MgZG93biBpZiBteSBBUEkgaW1wbGVtZW50cyBhIHN0YW5kYXJkIHByb3RvY29s IGFuZCBpcyBleHBlY3RlZCB0byB3b3JrIHdpdGggb2ZmLXRoZS1zaGVsZiBjbGllbnRzIGFuZC9v ciBpbXBsZW1lbnRhdGlvbnMgZnJvbSBvdGhlciB2ZW5kb3JzLg0KDQoyLiBXZWIgYXBwbGljYXRp b25zIGFyZSBqdXN0IGEgc3BlY2lhbCBzdWJzZXQgb2Ygc2VydmljZSBBUElzIHRoYXQgaGFwcGVu cyB0byBiZSBhY2Nlc3NlZCB2aWEgYSBicm93c2VyLiBBIHNvbHV0aW9uIGZvciBzZXJ2aWNlIEFQ SXMgb3VnaHQgdG8gYmUgcmV1c2FibGUgZm9yIHdlYiBhcHBsaWNhdGlvbnMsIG9yIGF0IGxlYXN0 IHNlcnZlIGFzIGEgZm91bmRhdGlvbiBmb3IgdGhlaXIgc29sdXRpb24uDQoNCj4gICAgLSBIYXZl IHlvdSBzZWVuIHRoaXMga2luZCBvZiBwcm94aWVzIGludGVyY2VwdGluZyB0aGUgY29ubmVjdGlv biBmcm9tIG9uLXByZW0gc2VydmljZSBkZXBsb3ltZW50cyB0byBzZXJ2aWNlIHByb3ZpZGVyPyBJ 4oCZbSBhc2tpbmcgYmVjYXVzZSBJIHRob3VnaHQgdGhlIG1haW4gdXNlIGNhc2Ugd2FzIHRvIGlu dGVyY2VwdCBlbXBsb3llZXMgUEMgaW50ZXJuZXQgdHJhZmZpYy4NCg0KSSdtIHdvcmtpbmcgZnJv bSBzZWNvbmQtaGFuZCBrbm93bGVkZ2UgaGVyZSwgYnV0IGxpa2UgbW9zdCB0aGluZ3MgaW4gdGhl IGVudGVycHJpc2Ugd29ybGQsIGl0IGRlcGVuZHMuIFNlcGFyYXRpbmcgZW1wbG95ZWUgZGV2aWNl IG91dGJvdW5kIHRyYWZmaWMgZnJvbSBpbnRlcm5hbCBzZXJ2aWNlIG91dGJvdW5kIHRyYWZmaWMg cmVxdWlyZXMgc29tZSBsZXZlbCBvZiBzb3BoaXN0aWNhdGlvbiwgYmUgaXQgaW4gbmV0d29yayB0 b3BvbG9neSwgcm91dGluZyBydWxlcywgb3IgY29uZmlndXJhdGlvbiBydWxlcyBvbiB0aGUgVExJ UyBhcHBsaWFuY2UuIA0KDQo+ICAgIC0gQXJlIHlvdSBzYXlpbmcgdGhpcyBraW5kIG9mIHByb3h5 IGRvZXMgbm90IHN1cHBvcnQgbXV0dWFsIFRMUyBhdCBhbGw/DQoNCkZyb20gd2hhdCBJIHVuZGVy c3RhbmQsIGF0IHRoZSB2ZXJ5IGxlYXN0IG1UTFMgaXMgbm90IHVuaXZlcnNhbGx5IHN1cHBvcnRl ZC4gVGhlcmUgbWF5IGJlIHNvbWUgdmVuZG9ycyB0aGF0IHN1cHBvcnQgaXQsIGJ1dCBpdCdzIG5v dCBndWFyYW50ZWVkLiBUaGUgZG9jdW1lbnRhdGlvbiBmb3IgU3ltYW50ZWMncyBTU0wgVmlzaWJp bGl0eSBwcm9kdWN0IFsxXSBpbmRpY2F0ZXMgdGhhdCBzZXNzaW9ucyB1c2luZyBjbGllbnQgY2Vy dGlmaWNhdGVzIHdpbGwgYmUgcmVqZWN0ZWQgdW5sZXNzIHRoZXkgYXJlIGV4ZW1wdGVkIGJhc2Vk IG9uIGRlc3RpbmF0aW9uIHdoaXRlbGlzdGluZyAod2hpY2ggaXMgcHJvYmxlbWF0aWMgd2hlbiB0 aGUgZGVzdGluYXRpb24gbWF5IGJlIGEgZ2VuZXJhbC1wdXJwb3NlIGNsb3VkIHNlcnZpY2UgcHJv dmlkZXIpLg0KDQo+IE9uIHRoZSBvdGhlciBoYW5kLCBJIHdvdWxkIGV4cGVjdCB0aGVzZSBraW5k IG9mIHByb3h5IHRvIHVuZGVyc3RhbmQgYSBsb3QgYWJvdXQgdGhlIHByb3RvY29scyBydW5uaW5n IHRocm91Z2ggaXQsIG90aGVyd2lzZSB0aGV5IGNhbm5vdCBmdWxmaWwgdGhlaXIgdGFzayBvZiBp bnNwZWN0aW5nIHRoaXMgdHJhZmZpYy4NCg0KTWF5YmUsIG1heWJlIG5vdC4gSW4gYW55IGNhc2Ug dGhlcmUncyBhIGRpZmZlcmVuY2UgYmV0d2VlbiB1bmRlcnN0YW5kaW5nIEhUVFAgb3IgU01UUCBv ciBQMlAtcHJvdG9jb2wtZHUtam91ciBhbmQgdW5kZXJzdGFuZGluZyB0aGUgYXBwbGljYXRpb24t bGV2ZWwgcHJvdG9jb2wgcnVubmluZyBvbiB0b3Agb2YgSFRUUC4gVGhlcmUgaGFzbid0IGJlZW4g YW55IG5lZWQgZm9yIHRoZXNlIHByb3hpZXMgdG8gdW5kZXJzdGFuZCBPQXV0aCAyLjAgdGh1cyBm YXIuDQoNClsxXTogaHR0cHM6Ly9vcmlnaW4tc3ltd2lzZWRvd25sb2FkLnN5bWFudGVjLmNvbS9y ZXNvdXJjZXMvd2ViZ3VpZGVzL3NzbHYvNDUvQ29udGVudC9Ub3BpY3MvdHJvdWJsZXNob290aW5n L1N1cHBvcnRfZm9yX0NsaWVudF9DZXJ0Lmh0bQ0K4oCTIA0KQW5uYWJlbGxlIFJpY2hhcmQgQmFj a21hbg0KQVdTIElkZW50aXR5DQoNCg0K77u/T24gMTIvMS8xOSwgNzo0MSBBTSwgIlRvcnN0ZW4g TG9kZGVyc3RlZHQiIDx0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPiB3 cm90ZToNCg0KICAgIA0KICAgIEFubmFiZWxsZSwNCiAgICANCiAgICA+IEFtIDI3LjExLjIwMTkg dW0gMDI6NDYgc2NocmllYiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1h em9uLmNvbT46DQogICAgPiANCiAgICA+IO+7v1RvcnN0ZW4sDQogICAgPiANCiAgICA+IEknbSBu b3QgdHJhY2tpbmcgaG93IGNvb2tpZXMgYXJlIHJlbGV2YW50IHRvIHRoZSBkaXNjdXNzaW9uLg0K ICAgIA0KICAgIEnigJltIHN0aWxsIHRyeWluZyB0byB1bmRlcnN0YW5kIHdoeSB5b3UgYW5kIG90 aGVycyBhcmd1ZSBtVExTIGNhbm5vdCBiZSB1c2VkIGluIHB1YmxpYyBjbG91ZCBkZXBsb3ltZW50 cyAoYW5kIHRodXMgZm9jdXMgb24gYXBwbGljYXRpb24gbGV2ZWwgUG9QKS4NCiAgICANCiAgICBT ZXNzaW9uIGNvb2tpZXMgc2VydmUgdGhlIHNhbWUgcHVycG9zZSBpbiB3ZWIgYXBwcyBhcyBhY2Nl c3MgdG9rZW5zIGZvciBBUElzIGJ1dCB0aGVyZSBhcmUgbXVjaCBtb3JlIHdlYiBhcHBzIHRoYW4g QVBJcy4gSSB1c2UgdGhlIGFuYWxvZ3kgdG8gaWxsdXN0cmF0ZSB0aGF0IGVpdGhlciB0aGVyZSBh cmUgc2VjdXJpdHkgaXNzdWVzIHdpdGggY2xvdWQgZGVwbG95bWVudHMgb2Ygd2ViIGFwcHMgb3Ig dGhlIHRlY2huaXF1ZXMgdXNlZCB0byBzZWN1cmUgd2ViIGFwcHMgYXJlIG9rIGZvciBBUElzIGFz IHdlbGwuDQogICAgDQogICAgSGVyZSBhcmUgdGhlIHR3byBtYWluIGFyZ3VtZW50cyBhbmQgbXkg Y29uY2x1c2lvbnMvcXVlc3Rpb25zOiAgDQogICAgDQogICAgMSkgbVRMUyBpdOKAmXMgbm90IGVu ZCAyIGVuZDogYWx0aG91Z2ggdGhhdOKAmXMgdHJ1ZSBmcm9tIGEgY29ubmVjdGlvbiBwZXJzcGVj dGl2ZSwgdGhlcmUgYXJlIHNvbHV0aW9ucyBlbXBsb3llZCB0byBzZWN1cmUgdGhlIGxhc3QgaG9w KHMpIGJldHdlZW4gVExTIHRlcm1pbmF0aW5nIHByb3h5IGFuZCBzZXJ2aWNlIChwcml2YXRlIG5l dCwgVlBOLCBUTFMpLiBUaGF0IHdvcmtzIGFuZCBpcyBjb25zaWRlcmVkIHNlY3VyZSBlbm91Z2gg Zm9yIChzZXNzaW9uKSBjb29raWVzLCBpdCBzaG91bGQgYmUgdGhlIHNhbWUgZm9yIGFjY2VzcyB0 b2tlbnMuDQogICAgDQogICAgMikgVExTIHRlcm1pbmF0aW5nIHByb3hpZXMgZG8gbm90IGZvcndh cmQgY2VydCBkYXRhOiBpZiB0aGUgc2VydmljZSBpdHNlbGYgdGVybWluYXRlcyBUTFMgdGhpcyBp cyBmZWFzaWJsZSwgd2UgZG8gaXQgZm9yIG91ciBwdWJsaWMtY2xvdWQtaG9zdGVkIG1UTFMtcHJv dGVjdGVkIEFQSXMuIElmIFRMUyB0ZXJtaW5hdGlvbiBpcyBwcm92aWRlZCBieSBhIGNvbXBvbmVu dCBydW4gYnkgdGhlIGNsb3VkIHByb3ZpZGVyLCB0aGUgcXVlc3Rpb24gaXM6IGlzIHRoaXMgY29t cG9uZW50IGFibGUgdG8gZm9yd2FyZCB0aGUgY2xpZW50IGNlcnRpZmljYXRlIHRvIHRoZSBzZXJ2 aWNlPyBJZiBub3QsIHdlYiBhcHBzIHVzaW5nIGNlcnRzIGZvciBhdXRoZW50aWNhdGlvbiBjYW5u b3QgYmUgc3VwcG9ydGVkIHN0cmFpZ2h0d2F5IGJ5IHRoZSBjbG91ZCBwcm92aWRlci4gQW55IGlu c2lnaHRzPw0KICAgIA0KICAgID4gSSdtIGd1ZXNzaW5nIHRoYXQncyBiZWNhdXNlIHdlJ3JlIG5v dCBvbiB0aGUgc2FtZSBwYWdlIHJlZ2FyZGluZyB1c2UgY2FzZXMsIHNvIGFsbG93IG1lIHRvIGNs ZWFybHkgc3RhdGUgbWluZToNCiAgICANCiAgICBJIHRoaW5rIHdlIGFyZSwgd2UgYXJlIGp1c3Qg Zm9jdXNpbmcgb24gZGlmZmVyZW50IGVuZHMgb2YgdGhlIFRMUyB0dW5uZWwuIE15IGZvY3VzIGlz IG9uIHRoZSBzZXJ2aWNlIHByb3ZpZGVy4oCZcyBzaWRlLCBlc3AuIHB1YmxpYyBjbG91ZCBob3N0 aW5nLCB3aGVyZWFzIHlvdSBhcmUgZm9jdXNpbmcgb24gY2xpZW50IHNpZGUgVExTIHRlcm1pbmF0 aW5nIHByb3hpZXMuDQogICAgDQogICAgPiANCiAgICA+IFRoZSB1c2UgY2FzZSBJIGFtIGNvbmNl cm5lZCB3aXRoIGlzIHJlcXVlc3RzIGJldHdlZW4gc2VydmljZXMgd2hlcmUgZW5kLXRvLWVuZCBU TFMgY2Fubm90IGJlIGd1YXJhbnRlZWQuIEZvciBleGFtcGxlLCBhbiBlbnRlcnByaXNlIHNlcnZp Y2UgcnVubmluZyBvbi1wcmVtaXNlLCBjb21tdW5pY2F0aW5nIHdpdGggYSBzZXJ2aWNlIGluIHRo ZSBjbG91ZCwgd2hlcmUgdGhlIGVudGVycHJpc2UncyBvdXRib3VuZCB0cmFmZmljIGlzIHJvdXRl ZCB0aHJvdWdoIGEgVExTIEluc3BlY3Rpb24gKFRMU0kpIGFwcGxpYW5jZS4gVGhlIFRMU0kgYXBw bGlhbmNlIHNpdHMgaW4gdGhlIG1pZGRsZSBvZiB0aGUgY29tbXVuaWNhdGlvbiwgdGVybWluYXRp bmcgdGhlIFRMUyBzZXNzaW9uIGVzdGFibGlzaGVkIGJ5IHRoZSBvbi1wcmVtaXNlIHNlcnZpY2Ug YW5kIGVzdGFibGlzaGluZyBhIHNlcGFyYXRlIFRMUyBjb25uZWN0aW9uIHdpdGggdGhlIGNsb3Vk IHNlcnZpY2UuDQogICAgPiANCiAgICA+IEluIHRoaXMga2luZCBvZiBlbnZpcm9ubWVudCwgdGhl cmUgaXMgbm8gZW5kLXRvLWVuZCBUTFMgY29ubmVjdGlvbiBiZXR3ZWVuIG9uLXByZW1pc2Ugc2Vy dmljZSBhbmQgY2xvdWQgc2VydmljZSwgYW5kIGl0IGlzIHZlcnkgdW5saWtlbHkgdGhhdCB0aGUg VExTSSBhcHBsaWFuY2UgaXMgY29uZmlndXJhYmxlIGVub3VnaCB0byBzdXBwb3J0IFRMUy1iYXNl ZCBzZW5kZXItY29uc3RyYWludCBtZWNoYW5pc21zIHdpdGhvdXQgc2lnbmlmaWNhbnRseSBjb21w cm9taXNpbmcgb24gdGhlIHNjb3BlIG9mICJzZW5kZXIiIChlLmcuLCAidGhpcyBzZXJ2aWNlIGF0 IHRoaXMgZW50ZXJwcmlzZSIgYmVjb21lcyAidGhpcyBlbnRlcnByaXNl4oCdKS4NCiAgICANCiAg ICBJ4oCZbSBub3QgZmFtaWxpYXIgd2l0aCB0aGVzZSBraW5kIG9mIHByb3hpZXMsIGJ1dCBoYXBw eSB0byBsZWFybiBtb3JlIGFuZCB0byBkaXNjdXNzIHBvdGVudGlhbCBzb2x1dGlvbnMuDQogICAg DQogICAgSGVyZSBhcmUgc29tZSBxdWVzdGlvbnM6DQogICAgLSBIYXZlIHlvdSBzZWVuIHRoaXMg a2luZCBvZiBwcm94aWVzIGludGVyY2VwdGluZyB0aGUgY29ubmVjdGlvbiBmcm9tIG9uLXByZW0g c2VydmljZSBkZXBsb3ltZW50cyB0byBzZXJ2aWNlIHByb3ZpZGVyPyBJ4oCZbSBhc2tpbmcgYmVj YXVzZSBJIHRob3VnaHQgdGhlIG1haW4gdXNlIGNhc2Ugd2FzIHRvIGludGVyY2VwdCBlbXBsb3ll ZXMgUEMgaW50ZXJuZXQgdHJhZmZpYy4gDQogICAgLSBBcmUgeW91IHNheWluZyB0aGlzIGtpbmQg b2YgcHJveHkgZG9lcyBub3Qgc3VwcG9ydCBtdXR1YWwgVExTIGF0IGFsbD8gQXQgbGVhc3QgdGhl b3JldGljYWxseSwgdGhlIHByb3h5IGNvdWxkIGNvbWJpbmUgc291cmNlIGFuZCBkZXN0aW5hdGlv biB0byBzZWxlY3QgYSBjZXJ0L2tleSBwYWlyIHRvIHVzZSBmb3Igb3V0Ym91bmQgVExTIGNsaWVu dCBhdXRoZW50aWNhdGlvbi4gDQogICAgDQogICAgPiBFdmVuIGlmIGl0IGlzIHBvc3NpYmxlLCBp dCBpcyBsaWtlbHkgdG8gcmVxdWlyZSBhZHZhbmNlZCBjb25maWd1cmF0aW9uIHRoYXQgaXMgbm9u LXRyaXZpYWwgZm9yIGFkbWluaXN0cmF0b3JzIHRvIGRlcGxveS4gSXQncyBubyBsb25nZXIgYXMg c2ltcGxlIGFzIHRoZSBkZXZlbG9wZXIgcGFzc2luZyBhIHNlbGYtc2lnbmVkIGNlcnRpZmljYXRl IHRvIHRoZSBIVFRQIHN0YWNrLg0KICAgIA0KICAgIEkgYWdyZWUuIENlcnQgYmluZGluZyBpcyBl c3RhYmxpc2hlZCBpbiBPQXV0aCBwcm90b2NvbCBtZXNzYWdlcywgd2hpY2ggd291bGQgcmVxdWly ZSB0aGUgYXBwbGlhbmNlIHRvIHVuZGVyc3RhbmQgdGhlIHByb3RvY29sLiBPbiB0aGUgb3RoZXIg aGFuZCwgSSB3b3VsZCBleHBlY3QgdGhlc2Uga2luZCBvZiBwcm94eSB0byB1bmRlcnN0YW5kIGEg bG90IGFib3V0IHRoZSBwcm90b2NvbHMgcnVubmluZyB0aHJvdWdoIGl0LCBvdGhlcndpc2UgdGhl eSBjYW5ub3QgZnVsZmlsIHRoZWlyIHRhc2sgb2YgaW5zcGVjdGluZyB0aGlzIHRyYWZmaWMuIA0K ICAgIA0KICAgIGJlc3QgcmVnYXJkcywNCiAgICBUb3JzdGVuLiANCiAgICANCiAgICANCiAgICAN CiAgICA+IA0KICAgID4g4oCTIA0KICAgID4gQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KICAg ID4gQVdTIElkZW50aXR5DQogICAgPiANCiAgICA+IA0KICAgID4g77u/T24gMTEvMjMvMTksIDk6 NTAgQU0sICJUb3JzdGVuIExvZGRlcnN0ZWR0IiA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdy b3RlOg0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4+Pj4+Pj4+PiBPbiAyMy4gTm92IDIw MTksIGF0IDAwOjM0LCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9u LmNvbT4gd3JvdGU6DQogICAgPj4+Pj4+Pj4+IGhvdyBhcmUgY29va2llcyBwcm90ZWN0ZWQgZnJv bSBsZWFrYWdlLCByZXBsYXksIGluamVjdGlvbiBpbiBhIHNldHVwIGxpa2UgdGhpcz8NCiAgICA+ PiBUaGV5IGFyZW7igJl0Lg0KICAgID4gDQogICAgPiBUaGF0cyB2ZXJ5IGludGVyZXN0aW5nIHdo ZW4gY29tcGFyZWQgdG8gd2hhdCB3ZSBhcmUgZGlzY3Vzc2luZyB3aXRoIHJlc3BlY3QgdG8gQVBJ IHNlY3VyaXR5LiANCiAgICA+IA0KICAgID4gSXQgZWZmZWN0aXZlbHkgbWVhbnMgYW55b25lIGFi bGUgdG8gY2FwdHVyZSBhIHNlc3Npb24gY29va2llLCBlLmcuIGJldHdlZW4gVExTIHRlcm1pbmF0 aW9uIHBvaW50IGFuZCBhcHBsaWNhdGlvbiwgYnkgd2F5IG9mIGFuIEhUTUwgaW5qZWN0aW9uLCBv ciBhbnkgb3RoZXIgc3VpdGFibGUgYXR0YWNrIGlzIGFibGUgdG8gaW1wZXJzb25hdGUgYSBsZWdp dGltYXRlIHVzZXIgYnkgaW5qZWN0aW5nIHRoZSBjb29raWUocykgaW4gYW4gYXJiaXRyYXJ5IHVz ZXIgYWdlbnQuIFRoZSBpbXBhY3Qgb2Ygc3VjaCBhbiBhdHRhY2sgbWlnaHQgYmUgZXZlbiB3b3Jz ZSB0aGFuIGFidXNpbmcgYW4gYWNjZXNzIHRva2VuIGdpdmVuIHRoZSAodHlwaWNhbGx5KSBicm9h ZCBzY29wZSBvZiBhIHNlc3Npb24uDQogICAgPiANCiAgICA+IFRMUy1iYXNlZCBtZXRob2RzIGZv ciBzZW5kZXIgY29uc3RyYWluZWQgYWNjZXNzIHRva2VucywgaW4gY29udHJhc3QsIHByZXZlbnQg dGhpcyB0eXBlIG9mIHJlcGxheSwgZXZlbiBpZiB0aGUgcmVxdWVzdHMgYXJlIHByb3RlY3RlZCBi ZXR3ZWVuIGNsaWVudCBhbmQgVExTIHRlcm1pbmF0aW5nIHByb3h5LCBvbmx5LiBFbnN1cmluZyB0 aGUgYXV0aGVudGljaXR5IG9mIHRoZSBjbGllbnQgY2VydGlmaWNhdGUgd2hlbiBmb3J3YXJkZWQg ZnJvbSBUTFMgdGVybWluYXRpbmcgcHJveHkgdG8gc2VydmljZSwgZS5nLiB0aHJvdWdoIGFub3Ro ZXIgYXV0aGVudGljYXRlZCBUTFMgY29ubmVjdGlvbiwgd2lsbCBldmVuIHByZXZlbnQgaW5qZWN0 aW9uIHdpdGhpbiB0aGUgZGF0YSBjZW50ZXIvY2xvdWQgZW52aXJvbm1lbnQuIA0KICAgID4gDQog ICAgPiBJIGNvbWUgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCB3ZSBhbHJlYWR5IGhhdmUgdGhlIG1l Y2hhbmlzbSBhdCBoYW5kIHRvIGltcGxlbWVudCBBUElzIHdpdGggYSBjb25zaWRlcmFibGUgaGln aGVyIHNlY3VyaXR5IGxldmVsIHRoYW4gd2hhdCBpcyBhY2NlcHRlZCB0b2RheSBmb3Igd2ViIGFw cGxpY2F0aW9ucy4gU28gd2hhdCBwcm9ibGVtIGRvIHdlIHdhbnQgdG8gc29sdmU/DQogICAgPiAN CiAgICA+PiBCdXQgbXkgcHJpbWFyeSBjb25jZXJuIGhlcmUgaXNuJ3Qgd2ViIGJyb3dzZXIgdHJh ZmZpYywgaXQncyBjYWxscyBmcm9tIHNlcnZpY2VzL2FwcHMgcnVubmluZyBpbnNpZGUgYSBjb3Jw b3JhdGUgbmV0d29yayB0byBzZXJ2aWNlcyBvdXRzaWRlIGEgY29ycG9yYXRlIG5ldHdvcmsgKGUu Zy4sIHNlcnZpY2UtdG8tc2VydmljZSBBUEkgY2FsbHMgdGhhdCBwYXNzIHRocm91Z2ggYSBjb3Jw b3JhdGUgVExTIGdhdGV3YXkpLg0KICAgID4gDQogICAgPiBDYW4geW91IHBsZWFzZSBkZXNjcmli ZSB0aGUgY2hhbGxlbmdlcyBhcmlzaW5nIGluIHRoZXNlIHNldHRpbmdzPyBJIGFzc3VtZSB0aG9z ZSBwcm94aWVzIHdvbuKAmXQgc3VwcG9ydCBDT05ORUNUIHN0eWxlIHBhc3MgdGhyb3VnaCBvdGhl cndpc2Ugd2Ugd291bGRu4oCZdCB0YWxrIGFib3V0IHRoZW0uDQogICAgPiANCiAgICA+Pj4gVGhh dOKAmXMgYSB0b3RhbGx5IHZhbGlkIHBvaW50LiBCdXQgYWdhaW4sIHN1Y2ggYSBzb2x1dGlvbiBt YWtlcyB0aGUgbGlmZSBvZiBjbGllbnQgZGV2ZWxvcGVycyBoYXJkZXIuDQogICAgPj4+IEkgcGVy c29uYWxseSB0aGluaywgd2UgYXMgYSBjb21tdW5pdHkgbmVlZCB0byB1bmRlcnN0YW5kIHRoZSBw cm9zIGFuZCBjb25zIG9mIGJvdGggYXBwcm9hY2hlcy4gSSBhbHNvIHRoaW5rIHdlIGhhdmUgbm90 IGV2ZW4gY29tZSBjbG9zZSB0byB0aGlzIHBvaW50LCB3aGljaCwgaW4gbXkgb3B0aW9uLCBpcyB0 aGUgcHJlcmVxdWlzaXRlIGZvciBtYWtpbmcgaW5mb3JtZWQgZGVjaXNpb25zLg0KICAgID4+IEFn cmVlZC4gSXQncyBjbGVhciB0aGF0IHRoZXJlIGFyZSBhIG51bWJlciBvZiBwYXJ0aWVzIGNvbWlu ZyBhdCB0aGlzIGZyb20gYSBudW1iZXIgb2YgZGlmZmVyZW50IGRpcmVjdGlvbnMsIGFuZCB0aGF0 J3MgY29sb3Jpbmcgb3VyIHBlcmNlcHRpb25zLiBUaGF0J3Mgd2h5IEkgdGhpbmsgd2UgbmVlZCB0 byBuYWlsIGRvd24gdGhlIHNjb3BlIG9mIHdoYXQgd2UncmUgdHJ5aW5nIHRvIHNvbHZlIHdpdGgg RFBvUCBiZWZvcmUgd2UgY2FuIGhhdmUgYSBwcm9kdWN0aXZlIGNvbnZlcnNhdGlvbiBob3cgaXQg c2hvdWxkIHdvcmsuDQogICAgPiANCiAgICA+IFdlIHdpbGwgZG8gc28uDQogICAgPiANCiAgICA+ PiDigJMNCiAgICA+PiBBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQogICAgPj4gQVdTIElkZW50 aXR5DQogICAgPj4g77u/T24gMTEvMjIvMTksIDEwOjUxIFBNLCAiVG9yc3RlbiBMb2RkZXJzdGVk dCIgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiB3cm90ZToNCiAgICA+Pj4+IE9uIDIyLiBOb3Yg MjAxOSwgYXQgMjI6MTIsIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00MGFt YXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KICAgID4+PiBUaGUgc2VydmljZSBwcm92 aWRlciBkb2Vzbid0IG93biB0aGUgZW50aXJlIGNvbm5lY3Rpb24uIFRoZXkgaGF2ZSBubyBjb250 cm9sIG92ZXIgY29ycG9yYXRlIG9yIGdvdmVybm1lbnQgVExTIGdhdGV3YXlzLCBvciBvdGhlciB0 ZXJtaW5hdG9ycyB0aGF0IG1pZ2h0IGV4aXN0IG9uIHRoZSBjbGllbnQncyBzaWRlLiBJbiBsYXJn ZXIgb3JnYW5pemF0aW9ucywgb3Igd2hlbiBjbG91ZCBob3N0aW5nIGlzIGludm9sdmVkLCB0aGUg c2VydmljZSB0ZWFtIG1heSBub3QgZXZlbiBvd24gYWxsIHRoZSBob3BzIG9uIHRoZWlyIHNpZGUu DQogICAgPj4gaG93IGFyZSBjb29raWVzIHByb3RlY3RlZCBmcm9tIGxlYWthZ2UsIHJlcGxheSwg aW5qZWN0aW9uIGluIGEgc2V0dXAgbGlrZSB0aGlzPw0KICAgID4+PiBXaGlsZSBwcmVzdW1hYmx5 IHRoZXkgaGF2ZSBzb21lIHRydXN0IGluIHRoZW0sIHByb3RlY3Rpb24gYWdhaW5zdCBsZWFrZWQg YmVhcmVyIHRva2VucyBpcyBhbiBhdHRyYWN0aXZlIGRlZmVuc2UtaW4tZGVwdGggbWVhc3VyZS4N CiAgICA+PiBUaGF04oCZcyBhIHRvdGFsbHkgdmFsaWQgcG9pbnQuIEJ1dCBhZ2Fpbiwgc3VjaCBh IHNvbHV0aW9uIG1ha2VzIHRoZSBsaWZlIG9mIGNsaWVudCBkZXZlbG9wZXJzIGhhcmRlci4NCiAg ICA+PiBJIHBlcnNvbmFsbHkgdGhpbmssIHdlIGFzIGEgY29tbXVuaXR5IG5lZWQgdG8gdW5kZXJz dGFuZCB0aGUgcHJvcyBhbmQgY29ucyBvZiBib3RoIGFwcHJvYWNoZXMuIEkgYWxzbyB0aGluayB3 ZSBoYXZlIG5vdCBldmVuIGNvbWUgY2xvc2UgdG8gdGhpcyBwb2ludCwgd2hpY2gsIGluIG15IG9w dGlvbiwgaXMgdGhlIHByZXJlcXVpc2l0ZSBmb3IgbWFraW5nIGluZm9ybWVkIGRlY2lzaW9ucy4N CiAgICA+Pj4g4oCTDQogICAgPj4+IEFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCiAgICA+Pj4g QVdTIElkZW50aXR5DQogICAgPj4+IO+7v09uIDExLzIyLzE5LCA5OjM3IFBNLCAiT0F1dGggb24g YmVoYWxmIG9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQiIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiB0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPiB3cm90 ZToNCiAgICA+Pj4+IE9uIDIyLiBOb3YgMjAxOSwgYXQgMjE6MjEsIFJpY2hhcmQgQmFja21hbiwg QW5uYWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0K ICAgID4+Pj4gVGhlIGRpY2hvdG9teSBvZiAiVExTIHdvcmtpbmciIGFuZCAiVExTIGZhaWxlZCIg b25seSBhcHBsaWVzIHRvIGEgc2luZ2xlIFRMUyBjb25uZWN0aW9uLiBJbiBub24tZW5kLXRvLWVu ZCBUTFMgZW52aXJvbm1lbnRzLCBlYWNoIFRMUyB0ZXJtaW5hdG9yIGJldHdlZW4gY2xpZW50IGFu ZCBSUyBpbnRyb2R1Y2VzIGFkZGl0aW9uYWwgdG9rZW4gbGVha2FnZS9leGZpbHRyYXRpb24gcmlz aywgaXJyZXNwZWN0aXZlIG9mIHRoZSBxdWFsaXR5IG9mIHRoZSBUTFMgY29ubmVjdGlvbnMgdGhl bXNlbHZlcy4gRWFjaCB0ZXJtaW5hdG9yIGFsc28gaW50cm9kdWNlcyBjb21wbGV4aXR5IGZvciBp bXBsZW1lbnRpbmcgbVRMUywgVG9rZW4gQmluZGluZywgb3IgYW55IG90aGVyIFRMUy1iYXNlZCBz ZW5kZXIgY29uc3RyYWludCBzb2x1dGlvbiwgd2hpY2ggbWVhbnMgZGV2ZWxvcGVycyB3aXRoIG5v bi1lbmQtdG8tZW5kIFRMUyB1c2UgY2FzZXMgd2lsbCBiZSBtb3JlIGxpa2VseSB0byB0dXJuIHRv IERQb1AuDQogICAgPj4+IFRoZSBwb2ludCBpcyB3ZSBhcmUgdGFsa2luZyBhYm91dCBkaWZmZXJl bnQgZGV2ZWxvcGVycyBoZXJlLiBUaGUgY2xpZW50IGRldmVsb3BlciBkb2VzIG5vdCBuZWVkIHRv IGNhcmUgYWJvdXQgdGhlIGNvbm5lY3Rpb24gYmV0d2VlbiBwcm94eSBhbmQgc2VydmljZS4gU2hl IHJlbGllcyBvbiB0aGUgc2VydmljZSBwcm92aWRlciB0byBnZXQgaXQgcmlnaHQuIFNvIHRoZSBk ZXZlbG9wZXJzIChvciBEZXZPcHMgb3IgYWRtaW5zKSBvZiB0aGUgc2VydmljZSBwcm92aWRlciBu ZWVkIHRvIGVuc3VyZSBlbmQgdG8gZW5kIHNlY3VyaXR5LiBBbmQgaWYgdGhlIHBhdGggaXMgc2Vj dXJlZCBvbmNlLCBpdCB3aWxsIHdvcmsgZm9yIGFsbCBjbGllbnRzLg0KICAgID4+Pj4gSWYgRFBv UCBpcyBpbnRlbmRlZCB0byBhZGRyZXNzICJjYXNlcyB3aGVyZSBuZWl0aGVyIG1UTFMgbm9yIE9B dXRoIFRva2VuIEJpbmRpbmcgYXJlIGF2YWlsYWJsZSIgWzFdLCB0aGVuIGl0IHNob3VsZCBhZGRy ZXNzIHRoaXMgcmlzayBvZiB0b2tlbiBsZWFrYWdlIGJldHdlZW4gY2xpZW50IGFuZCBSUy4gSWYg b24gdGhlIG90aGVyIGhhbmQgRFBvUCBpcyBvbmx5IGludGVuZGVkIHRvIHN1cHBvcnQgdGhlIFNQ QSB1c2UgY2FzZSBhbmQgYXNzdW1lcyB0aGUgdXNlIG9mIGVuZC10by1lbmQgVExTLCB0aGVuIHRo ZSBkb2N1bWVudCBzaG91bGQgYmUgdXBkYXRlZCB0byByZWZsZWN0IHRoYXQuDQogICAgPj4+IEkg YWdyZWUuDQogICAgPj4+PiBbMV06IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1m ZXR0LW9hdXRoLWRwb3AtMDMjc2VjdGlvbi0xDQogICAgPj4+PiDigJMNCiAgICA+Pj4+IEFubmFi ZWxsZSBSaWNoYXJkIEJhY2ttYW4NCiAgICA+Pj4+IEFXUyBJZGVudGl0eQ0KICAgID4+Pj4gT24g MTEvMjIvMTksIDg6MTcgUE0sICJPQXV0aCBvbiBiZWhhbGYgb2YgVG9yc3RlbiBMb2RkZXJzdGVk dCIgPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHRvcnN0ZW49NDBsb2RkZXJz dGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KICAgID4+Pj4gSGkgTmVpbCwNCiAgICA+ Pj4+PiBPbiAyMi4gTm92IDIwMTksIGF0IDE4OjA4LCBOZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5A Zm9yZ2Vyb2NrLmNvbT4gd3JvdGU6DQogICAgPj4+Pj4gT24gMjIgTm92IDIwMTksIGF0IDA3OjUz LCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmll dGYub3JnPiB3cm90ZToNCiAgICA+Pj4+Pj4+IE9uIDIyLiBOb3YgMjAxOSwgYXQgMTU6MjQsIEp1 c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4gd3JvdGU6DQogICAgPj4+Pj4+PiBJ4oCZbSBn b2luZyB0byArMSBEaWNrIGFuZCBBbm5hYmVsbGXigJlzIHF1ZXN0aW9uIGFib3V0IHRoZSBzY29w ZSBoZXJlLiBUaGF0IHdhcyB0aGUgb25lIG1ham9yIHRoaW5nIHRoYXQgc3RydWNrIG1lIGR1cmlu ZyB0aGUgRFBvUCBkaXNjdXNzaW9ucyBpbiBTaW5nYXBvcmUgeWVzdGVyZGF5OiB3ZSBkb27igJl0 IHNlZW0gdG8gYWdyZWUgb24gd2hhdCBEUG9QIGlzIGZvci4gU29tZSAoaW5jbHVkaW5nIHRoZSBh dXRob3JzLCBpdCBzZWVtcykgc2VlIGl0IGFzIGEgcXVpY2sgcG9pbnQtc29sdXRpb24gdG8gYSBz cGVjaWZpYyB1c2UgY2FzZS4gT3RoZXJzIHNlZSBpdCBhcyBhIGdlbmVyYWwgUG9QIG1lY2hhbmlz bS4NCiAgICA+Pj4+Pj4+IElmIGl04oCZcyB0aGUgZm9ybWVyLCB0aGVuIGl0IHNob3VsZCBiZSBl eHBsaWNpdGx5IHRpZWQgdG8gb25lIHNwZWNpZmljIHNldCBvZiB0aGluZ3MuIElmIGl04oCZcyB0 aGUgbGF0dGVyLCB0aGVuIGl0IG5lZWRzIHRvIGJlIGV4cGFuZGVkLg0KICAgID4+Pj4+PiBhcyBh IGNvLWF1dGhvciBvZiB0aGUgRFBvUCBkcmFmdCBJIHN0YXRlIGFnYWluIHdoYXQgSSBzYWlkIHll c3RlcmRheTogRFBvUCBpcyBhIG1lY2hhbmlzbSBmb3Igc2VuZGVyLWNvbnN0cmFpbmluZyBhY2Nl c3MgdG9rZW5zIHNlbnQgZnJvbSBTUEFzIG9ubHkuIFRoZSB0aHJlYXQgdG8gYmUgcHJldmVudGVk IGlzIHRva2VuIHJlcGxheS4NCiAgICA+Pj4+PiBJIHRoaW5rIHRoZSBwaHJhc2UgInRva2VuIHJl cGxheSIgaXMgYW1iaWd1b3VzLiBUcmFkaXRpb25hbGx5IGl0IHJlZmVycyB0byBhbiBhdHRhY2tl ciBiZWluZyBhYmxlIHRvIGNhcHR1cmUgYSB0b2tlbiAob3Igd2hvbGUgcmVxdWVzdHMpIGluIHVz ZSBhbmQgdGhlbiByZXBsYXkgaXQgYWdhaW5zdCB0aGUgc2FtZSBSUy4gVGhpcyBpcyBhbHJlYWR5 IHByb3RlY3RlZCBhZ2FpbnN0IGJ5IHRoZSB1c2Ugb2Ygbm9ybWFsIFRMUyBvbiB0aGUgY29ubmVj dGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBSUy4gSSB0aGluayBpbnN0ZWFkIHlvdSBh cmUgcmVmZXJyaW5nIHRvIGEgbWFsaWNpb3VzL2NvbXByb21pc2VkIFJTIHJlcGxheWluZyB0aGUg dG9rZW4gdG8gYSBkaWZmZXJlbnQgUlMgLSB3aGljaCBoYXMgbW9yZSBvZiB0aGUgZmxhdm91ciBv ZiBhIG1hbiBpbiB0aGUgbWlkZGxlIGF0dGFjayAob2YgdGhlIHBoaXNoaW5nIGtpbmQpLg0KICAg ID4+Pj4gSSB3b3VsZCBhcmd1ZSBUTFMgYmFzaWNhbGx5IHByZXZlbnRzIGxlYWthZ2UgYW5kIG5v dCByZXBsYXkuIFRoZSB0aHJlYXRzIHdlIHRyeSB0byBjb3BlIHdpdGggY2FuIGJlIGZvdW5kIGlu IHRoZSBTZWN1cml0eSBCQ1AuIFRoZXJlIGFyZSBtdWx0aXBsZSB3YXlzIGFjY2VzcyB0b2tlbnMg Y2FuIGxlYWssIGluY2x1ZGluZyByZWZlcnJlciBoZWFkZXJzLCBtaXgtdXAsIG9wZW4gcmVkaXJl Y3Rpb24sIGJyb3dzZXIgaGlzdG9yeSwgYW5kIGFsbCBzb3J0cyBvZiBhY2Nlc3MgdG9rZW4gbGVh a2FnZSBhdCB0aGUgcmVzb3VyY2Ugc2VydmVyDQogICAgPj4+PiBQbGVhc2UgaGF2ZSBhIGxvb2sg YXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHkt dG9waWNzLTEzI3NlY3Rpb24tNC4NCiAgICA+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMyNzZWN0aW9uLTQuOCBhbHNvIGhh cyBhbiBleHRlbnNpdmUgZGlzY3Vzc2lvbiBvZiBwb3RlbnRpYWwgY291bnRlciBtZWFzdXJlcywg aW5jbHVkaW5nIGF1ZGllbmNlIHJlc3RyaWN0ZWQgYWNjZXNzIHRva2VucyBhbmQgYSBjb25jbHVz aW9uIHRvIHJlY29tbWVuZCBzZW5kZXIgY29uc3RyYWluZWQgYWNjZXNzIHRva2VucyBvdmVyIG90 aGVyIG1lY2hhbmlzbXMuDQogICAgPj4+Pj4gQnV0IGlmIHRoYXQncyB0aGUgY2FzZSB0aGVuIHRo ZXJlIGFyZSBtdWNoIHNpbXBsZXIgZGVmZW5jZXMgdGhhbiB0aG9zZSBwcm9wb3NlZCBpbiB0aGUg Y3VycmVudCBkcmFmdDoNCiAgICA+Pj4+PiAxLiBHZXQgc2VwYXJhdGUgYWNjZXNzIHRva2VucyBm b3IgZWFjaCBSUyB3aXRoIGNvcnJlY3QgYXVkaWVuY2UgYW5kIHNjb3Blcy4gVGhlIGNvbnNlbnN1 cyBhcHBlYXJzIHRvIGJlIHRoYXQgdGhpcyBpcyBoYXJkIHRvIGRvIGluIHNvbWUgY2FzZXMsIGhl bmNlIHRoZSBkcmFmdC4NCiAgICA+Pj4+IEhvdyBtYW55IGRlcGxveW1lbnRzIGRvIHlvdSBrbm93 IHRoYXQgdG9kYXkgYXJlIGFibGUgdG8gaXNzdWUgUlMtc3BlY2lmaWMgYWNjZXNzIHRva2Vucz8N CiAgICA+Pj4+IEJUVzogaG93IHdvdWxkIHlvdSBpZGVudGlmeSB0aGUgUlM/DQogICAgPj4+PiBJ IGFncmVlIHRoYXQgd291bGQgYmUgYW4gYWx0ZXJuYXRpdmUgYW5kIEnigJltIGEgZ3JlYXQgZmFu IG9mIHN1Y2ggdG9rZW5zIChhbmQgdXNlZCB0aGVtIGEgbG90IGF0IERldXRzY2hlIFRlbGVrb20p IGJ1dCBpbiBteSBwZXJjZXB0aW9uIHRoaXMgcGF0dGVybiBuZWVkcyBzdGlsbCB0byBiZSBlc3Rh Ymxpc2hlZCBpbiB0aGUgbWFya2V0LiBNb3Jlb3ZlciwgdGhleSBiYXNpY2FsbHkgcHJvdGVjdCBm cm9tIGEgcm91Z2ggUlMgKGlmIHRoZSBVUkwgaXMgdXNlZCBhcyBhdWRpZW5jZSkgcmVwbGF5aW5n IHRoZSB0b2tlbiBzb21lcGxhY2UgZWxzZSwgYnV0IHRoZXkgZG8gbm90IHByb3RlY3QgZnJvbSBh bGwgb3RoZXIga2luZHMgb2YgbGVha2FnZS9yZXBsYXkgKGUuZy4gbG9nIGZpbGVzKS4NCiAgICA+ Pj4+PiAyLiBNYWtlIHRoZSBEUG9QIHRva2VuIGJlIGEgc2ltcGxlIEpXVCB3aXRoIGFuICJpYXQi IGFuZCB0aGUgb3JpZ2luIG9mIHRoZSBSUy4gVGhpcyBzdG9wcyB0aGUgdG9rZW4gYmVpbmcgcmV1 c2VkIGVsc2V3aGVyZSBidXQgdGhlIGNsaWVudCBjYW4gcmV1c2UgaXQgKHJlcGxheSBpdCkgZm9y IG1hbnkgcmVxdWVzdHMuDQogICAgPj4+Pj4gMy4gSXNzdWUgYSBtYWNhcm9vbi1iYXNlZCBhY2Nl c3MgdG9rZW4gYW5kIHRoZSBjbGllbnQgY2FuIGFkZCBhIGNvcnJlY3QgYXVkaWVuY2UgYW5kIHNj b3BlIHJlc3RyaWN0aW9ucyBhdCB0aGUgcG9pbnQgb2YgdXNlLg0KICAgID4+Pj4gV2h5IGlzIHRo aXMgbmVlZGVkIGlmIHRoZSBhY2Nlc3MgdG9rZW4gaXMgYWxyZWFkeSBhdWRpZW5jZSByZXN0cmlj dGVkPyBPciBkbyB5b3UgcHJvcG9zZSB0aGlzIGFzIGFsdGVybmF0aXZlPw0KICAgID4+Pj4+IFBy b3RlY3RpbmcgYWdhaW5zdCB0aGUgZmlyc3Qga2luZCBvZiByZXBsYXkgYXR0YWNrcyBvbmx5IGJl Y29tZXMgYW4gaXNzdWUgaWYgd2UgYXNzdW1lIHRoZSBwcm90ZWN0aW9ucyBpbiBUTFMgaGF2ZSBm YWlsZWQuIEJ1dCBpZiBEUG9QIGlzIG9ubHkgaW50ZW5kZWQgZm9yIGNhc2VzIHdoZXJlIG1UTFMg Y2FuJ3QgYmUgdXNlZCwgaXQgc2hvdWxkbid0IGhhdmUgdG8gcHJvdGVjdCBhZ2FpbnN0IGEgc3Ry b25nZXIgdGhyZWF0IG1vZGVsIGluIHdoaWNoIHdlIGFzc3VtZSB0aGF0IFRMUyBzZWN1cml0eSBo YXMgYmVlbiBsb3N0Lg0KICAgID4+Pj4gSSBhZ3JlZS4NCiAgICA+Pj4+IGJlc3QgcmVnYXJkcywN CiAgICA+Pj4+IFRvcnN0ZW4uDQogICAgPj4+Pj4gLS0gTmVpbA0KICAgIA0KDQo= From nobody Tue Dec 3 00:26:07 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194FD120178 for ; Tue, 3 Dec 2019 00:26:06 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=JqXbZY2A; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=hzvzGrWl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBk1WvEkDneM for ; Tue, 3 Dec 2019 00:26:03 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00083.outbound.protection.outlook.com [40.107.0.83]) (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 2C29F120131 for ; Tue, 3 Dec 2019 00:25:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fqyxXYWu8WpkJN4wtu1DOtrv5gQ5LAl4LXQhTU3B9jw=; b=JqXbZY2AGdMyo0As5VlEPhOeabh0k8WoJWajbmuVkI3uuZbBD48d/9OuRJnIfP04LLUrEFvVNDv7Q65o42CIceCmLm7WpUs2I56s2j45Kk/VQfodCEJkwnkMSq+vA2ktc1K0KmA2MtFSHQLQ1xDa01jvJ4sUQ3y5P71+CwgrArk= Received: from VE1PR08CA0002.eurprd08.prod.outlook.com (2603:10a6:803:104::15) by AM0PR08MB4579.eurprd08.prod.outlook.com (2603:10a6:208:108::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.20; Tue, 3 Dec 2019 08:25:16 +0000 Received: from DB5EUR03FT043.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::207) by VE1PR08CA0002.outlook.office365.com (2603:10a6:803:104::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.12 via Frontend Transport; Tue, 3 Dec 2019 08:25:16 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT043.mail.protection.outlook.com (10.152.20.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18 via Frontend Transport; Tue, 3 Dec 2019 08:25:15 +0000 Received: ("Tessian outbound d55de055a19b:v37"); Tue, 03 Dec 2019 08:25:15 +0000 X-CR-MTA-TID: 64aa7808 Received: from f0c28adf1415.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 373EC859-0AC2-48F2-8AEE-8286C56E3F95.1; Tue, 03 Dec 2019 08:25:10 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f0c28adf1415.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 03 Dec 2019 08:25:10 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m91vTXTUiWowWb9npw8R2YPBRsuOWsfMW2k4HeVClahPiGJtjz5HN9Y9c5LgHGZALayuiyNbXKsWjHvXTmUeXBa93ia5H0XbRTcPh0QK/iIdcEJ5sk9cGA3RmrCWiHifqES/EQdtyKHvZPIb23JIr5FXKrYfoROYinqKpBVkOOGFE1/EawH8Q6CwNCtJzTM+mIAukxro5jgB3a0NKbYWPeIDLPoHntewLJN+Kv1N1E39D3n8rHULQ8rB3JO1R6+bove7uSSNmvZRSyBdOH3giejXc5c6u3WuydDsuKOKssJKRWMnnCqmKL+F1bRKzjsqooVtVqzCSTDFHBgnOuP/ow== 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=jU9F5iQXDrM2h6LPGmDdzfxgZs59aZtc/gMp4XCCY2E=; b=nR9/cjQ1pB9SyEY1yvSR9OfzSm/Bc24pKZWJdlR+QkIrQ8DTfIIOBLLLmTRpSj651scNZeCTKjSdAZ44yMmfuS5NprFX5W7gbys6aFx2s064eNbZf02WOG++5elt9p1OXp1DbVTLtjp9Ji3bNABUVJ22ZqcS8B4+1S1re2TW6SzjF4rElb7DlQ+8d7Al1qjwExMLHvUxPr+avCq+bxjcQ5286+RCJ5cs7BL1f6xOnxxinMEWEFqd0/B8gz1h+iFVDho5AHjTutkYUJhyELHMNYTK4B9Y8cMfxm+CcU1jj3Ivgd5YNHGeHJEENUhShSOddJYguI5KVCXMqT/iPkRbGg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jU9F5iQXDrM2h6LPGmDdzfxgZs59aZtc/gMp4XCCY2E=; b=hzvzGrWlGqB1yZgPelfWFxBNojTHgDjeFePxPhRd2EZ99GV7HF3KuQ+vDd2b1N9qv63o7DIko4wTt+qINv2pBcJIBRCJXPM5UBDGsPlpXtCfuc2Kt0jcAchKfLO5lmqUXH63MBMyWDztpFak4eKetD9tlEu6VZ86BMAICFr8PCk= Received: from VI1PR08MB5360.eurprd08.prod.outlook.com (52.133.245.74) by VI1PR08MB2637.eurprd08.prod.outlook.com (10.175.243.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18; Tue, 3 Dec 2019 08:25:09 +0000 Received: from VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::4044:55a8:a969:fd1d]) by VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::4044:55a8:a969:fd1d%7]) with mapi id 15.20.2495.014; Tue, 3 Dec 2019 08:25:09 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" Thread-Topic: Meeting Minutes Thread-Index: AdWpsxnoY3xdV5m/R9Wrqb/JoSj/HA== Date: Tue, 3 Dec 2019 08:25:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: e9fbb8a5-4750-40a7-a7f9-619c470c7d46.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.90] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 9f10a597-4d61-4e47-d65c-08d777ca5341 X-MS-TrafficTypeDiagnostic: VI1PR08MB2637:|AM0PR08MB4579: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:6430;OLM:6430; x-forefront-prvs: 02408926C4 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(376002)(366004)(396003)(136003)(189003)(199004)(316002)(86362001)(5640700003)(99286004)(6116002)(55016002)(14454004)(3846002)(606006)(236005)(54896002)(6306002)(9686003)(25786009)(2906002)(790700001)(7116003)(6916009)(33656002)(221733001)(7736002)(74316002)(81156014)(8676002)(966005)(66066001)(8936002)(81166006)(1730700003)(2501003)(478600001)(5660300002)(6436002)(256004)(71200400001)(66446008)(64756008)(66556008)(66476007)(71190400001)(66946007)(558084003)(102836004)(76116006)(6506007)(3480700005)(52536014)(186003)(26005)(2351001)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB2637; H:VI1PR08MB5360.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: wHqE41wAcsFIhnQKtuQ3L2d3WR7qcTmUat83AMWJd2ltKy7AxTd208Y8ezrbCxvIcOvHujXbq8TmyFDfLe55Myb0Xp4Wnw5j0mHjZMllbKguClZBiFqKP+/4hRo/I+OoN7VGIWWCMUyzAQRlGFVoK/yZSBUf6U+UcyAFJXl71dAqYwfatn1qOgyfRrV2RMr4QSwcnqGyvr0Zc3oYTG+n/hvbZ1ELM33TWWiA89Fjrcm8FNKWuwSotfeB3ZmMgoOFK4HQrR2GQHoiWfYrP3EHQ7FETDo47QNGNWQWvKAJ3UKDw0OZjisv10T/rXtN65HxSztwdUAKiiOIY7NGhlT+djtYfFZVEdRWb3WPxy3AvqyKNRql+c5GHi31HczGppN4/9wSpGcYuEYODZAf2+5J3+9wOLXeyDlE/Mb1eNVsNbRRMsWrECaZxYskCSCNS/RIM+XeBaCE6gOJ+q6WmyDlVdSjjZM6pi9U3qE05UmMzGA= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_VI1PR08MB53603D167B53065E04A6C621FA420VI1PR08MB5360eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB2637 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT043.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(396003)(136003)(346002)(40434004)(189003)(199004)(71190400001)(3846002)(790700001)(7736002)(6116002)(74316002)(316002)(16586007)(336012)(70586007)(106002)(76130400001)(70206006)(356004)(99286004)(102836004)(2501003)(236005)(8676002)(1730700003)(81156014)(81166006)(8936002)(5640700003)(55016002)(9686003)(54896002)(6306002)(5000100001)(2351001)(66066001)(5660300002)(52536014)(3480700005)(221733001)(606006)(7116003)(26005)(25786009)(6916009)(26826003)(14454004)(966005)(186003)(478600001)(86362001)(22756006)(5024004)(2906002)(14444005)(33656002)(7696005)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB4579; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; MX:1; A:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: a7afd21c-5614-42af-86e6-08d777ca4f26 X-Forefront-PRVS: 02408926C4 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +gYiHVqBkgvAtlUUP7aI++aiNdrNe+S2EewvdX6B85khTmIQyFeeplfXEAJ9iDPj3HJ4Nj40ltC8S3VJYCz89xVY6bU6YzECroA6mi5wyh2B7DBDUJm3uAn8mON3RN1POZzgFd9evclB+Ay8P2jrmpo+msM3ypcsM3q/lnMIhFCmjT0onvoWQgSd2FxEZQCL0j8W2VJjGCM0mYh8OKJyNR5f07OAPSu2YIZVlFZqfFP1HwFElLSwze4tzkyuKPT7qQzOctvin7hqByYZCCKyUgUzq3xuSGScTw9upCW1plUYI1XAzAFDZkaW+OPjIp+6ax6OuUjYM6prtAVMW6C/f5ICSzEWn6K0cWQ/s0Y5wUsMLphUFFtIH59LCj6nTZvheSieK00D0pLW2VuTeyP0VVhAUwuPnBN/cr1eK/6ckv1NiABjQ4taaSrtab6xnawk+jHFo0XHKRw661hwJij1Aig+Tp+7Uqa+az7w99pqU8mf4NJa0AtGnKCmagxT1ryQK/cRyCT5lP5wQYRTMnqJLcSrdV7jtFzK1kj1Er+XUaE= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2019 08:25:15.9586 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9f10a597-4d61-4e47-d65c-08d777ca5341 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4579 Archived-At: Subject: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 08:26:06 -0000 --_000_VI1PR08MB53603D167B53065E04A6C621FA420VI1PR08MB5360eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are the meeting minutes from the Singapore IETF meeting: https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03 Tony was our scribe. Thanks! IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR08MB53603D167B53065E04A6C621FA420VI1PR08MB5360eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are the meeting minutes from the Singapore IETF= meeting:

https://datatracker.ietf.org/meeting/106/ma= terials/minutes-106-oauth-03

 

Tony was our scribe. Thanks!

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR08MB53603D167B53065E04A6C621FA420VI1PR08MB5360eurp_-- From nobody Tue Dec 3 01:22:05 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644A8120142 for ; Tue, 3 Dec 2019 01:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_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 (1024-bit key) header.d=rub.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stAWvnUMZ8hs for ; Tue, 3 Dec 2019 01:22:01 -0800 (PST) Received: from out2.mail.ruhr-uni-bochum.de (out2.mail.ruhr-uni-bochum.de [134.147.42.229]) (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 079061200B7 for ; Tue, 3 Dec 2019 01:22:01 -0800 (PST) Received: from mx2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out2.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 47RxM94ydzz4yMv; Tue, 3 Dec 2019 10:21:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1575364917; bh=aCX+kD1jK5Sp5fs2XviZ1TKDZdBvNMsCFoKxBypTX3c=; h=Subject:To:References:From:Date:In-Reply-To:From; b=MbaMYS2CJehC3Z0Mk7weEvfAP/QrKt4+KX8NI/mRTwESPM04/mqA6gjA5rz5AOSiW 12iBfGSgVuFNyiV2Aa826J1kpbfZBxKJxNz+E+aqicvcBJhJew4Io/eaaSg7sokD4U TSKZWN/+ASvsNM2VWasyRej9YoWEV81VofX9pck0= Received: from out2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx2.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 47RxM940XDz4xZL; Tue, 3 Dec 2019 10:21:57 +0100 (CET) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail.ruhr-uni-bochum.de [134.147.42.227]) by out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 47RxM92m6Pz4yMv; Tue, 3 Dec 2019 10:21:57 +0100 (CET) Received: from [192.168.93.131] (i577B3101.versanet.de [87.123.49.1]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 47RxM81T12zyrd; Tue, 3 Dec 2019 10:21:56 +0100 (CET) To: fett@danielfett.de, oauth@ietf.org References: <35143dd1-edeb-e0fd-6f36-a39d9b7f7008@hackmanit.de> <4f1d1215-aa23-93ab-ae5b-75426d7f07cc@danielfett.de> <277a3bc8-32fc-8c7c-85dc-5030d2d07728@rub.de> <8047bf89-1120-426d-e020-e58766c2ce3a@danielfett.de> From: Christian Mainka Autocrypt: addr=Christian.Mainka@rub.de; keydata= mQINBEefF5YBEADa0W+FyzUZStHhp8YmnjPZm4Bws4sKmwXRxfSJp89Z5r79kxaXdLErifPS w4uyQuhosugg65KlNwFgtMprtGeEvQpqnsGFz1ZJFnMDZnMho48NDXdFA8KWUUTFHZTlv8fy NOH3EQ/jcWfq2VizuIewJNqyrVpbUimosQmLsBB9xLeiT6u8B0zh0hCYhnX77Y87MnPYlW1T fxT7mjGe2SJnGdm85CH2Q/9aIj7OTA5vZhrCdrbddo0c5h6WMqeYSbxUYrJ0/zBHFpfbWmFD OIEtvYLjKhEtjIpvKL6U7fJaJNPqTFp+Y0T+folxRMYIxWPMtacnvMa9YqBiEmdK8VyFBMmi gkhVqdrTKLtsxQrutKaRxJ+ACbEdNuGpjnK5ON+sNmPTmqs816x+JJGLu1ci03gbCIXXvwXF /pV2tX/dBGbTgYWZ4DAIdIJoHKgAjC0r64409nDwb4BKWtEDTAxbP+2mPVqH0uthGBz8J29Q zWUDztfy3AK7nZjhg0NRabBUYe6PPGaV81tluH5nEMvvcXSstbwAcg8BPmuSGp3G6VE4BxS6 bnRIbL9XQP24xn3TFiAus79Wmzz3yBangmUCo616qWJqpqie6arce+Zce8szwMIJD753gEo8 L+GXJ8H/jQWS8C9qPvmD9GlW+RaWoTRb4BkTds305e0HPyl9aQARAQABtDVDaHJpc3RpYW4g TWFpbmthIChSdWItTWFpbCkgPENocmlzdGlhbi5NYWlua2FAcnViLmRlPokCNgQTAQIAIAUC R58XlgIbIwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEBxg1ZHbyZM9FjIP/3AHN9PRFg3n ld0DQCCGJzu1owT4b1is1pjHC+cpoJE0KqGiYBsPb1x3p/K8+E82ZENXP0s1KMZWEz+6dm+i 5ekb10jlSXppnkoeVBh9ITBjqurRkzSHRAkKtcLLIjYXyLKCQtnMJNCYU4OLA0xqlqcqa6U3 gRHW8mFNRjNkXjxSwGD0+vEeZ1WnfUkuvHYSWAUBn8f3Xn/KP0jlwzi8xZUxZgMcrPhV3s/X dNhQMvkzXUJd61AOCRAU2ZpxTIa57bIwahJ/RLdVzumTJHEMcRJpU6MMgfYnUUHRiiIUkhhB jWrzeSaoFpoHzYwKVflh+T2u/s909sQY17eT4IeVrjT3GZfXO4PnRC85gKqJMUuEE5dYrc/f iwzZdDX1y0zl2j6URITNXKu8s5x89PUzpg/ex22iArRDS8FfQGQXx600OpSWYUYSp4CrmNKK 1M42+caUwS2TysGoH3ebqtQ0Bu4WFxArmbMc9pkgsSuCwRKphBahT0U8JnLOXyqvhVC1A5sU 8HMAPhIg9mKd8swNh+ONGW97KwHONfcJhJ2lDwr8jZYh/6dg0J/wXdnl+naht+oiVnG2dHIQ 95iGFjiILW7OC0laYS0BCFSGJiG/wYr/heGNf+IgIXs1MJUE+AbiwGYE2FZRRA3oonLzQcQ4 xYLG3WKhlG6cUg2tYAKiY7hjtCpDaHJpc3RpYW4gTWFpbmthIDxDaHJpc3RpYW4uTWFpbmth QHJ1Yi5kZT6JAjsEEwECACUCGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJRCCWaAhkB AAoJEBxg1ZHbyZM9PuYP/3a/1kPLhy11Hjqz12SJoQi10JlTpRILcWXAoUOFmOQlPkMzwp+j vyg0XMW7VHfRpNyFDhMofAsibVFj6OvWRmg6Mrpsz0IwbH6k7ukcb0Uvv/EWhBHvqDpkGdIo 0iAkoyuygTIVsLRjJmU0QrnaS9J/QQTQSzpMG0Y/NXmt8a6j0aR92hYllhTdWbHGgQlcMa6R JBBR9fExoOlc9LZM3gyFI89STpWZcvFviO6VYlIKTqCFiH8W4u/yzP3fvjz2JLSS3SAAyd4z oaqMGSDqb97iJI39jja2BrJCkHDGpb0god0IMz+LMSXFc5faewBy5HfIsOj2tt4J9gUoKOwp fIDccOMirO5qywo5w79ofzx4AWDl+O1q4SXJmFUQWdnanM9TwR0wRmFa2q5ZugHlQbIdGMqR py5XrcTBcSoQRxGiFdjchJAYeNNQnOIMdHtolcSHpwKUc0CLIjrzMMnAui1WIr8jcdxiuqrU EJDZWiVZhxetq1An8lDX8q5IDmq1ZnS5PfmlOpMmL3QduEEqQQ40St2pbfCyCMz19jK/d6Kb lVoG4MhGq1ofIKu6KfWZmIEsiLGidNPByL84AB+8B9VArlS5pG4esIF5c5nyv1InlNCz5aNZ XzRxvJVqYEcTnM6f+29BDNGCPGfIVCyiocYCE2Z6TSA//VyQXMGdxB1UuQINBEefF9IBEACa oaSOVrtoEx+1FFoFHro9mI2rViLcHY44EyPBSlgUQgNeyMBnV9yrFf2awpZimXkXYOJ39dtD KOleiJ+XpM7n0tEDJ+tPz4Avc2iQ4RMyIndrM4okmfmTHuWZkV5ZJAERF59hMRDp8dRBzFDB XDEVhFsOZGFaf5qJE78774Jb/I0Sh6wn4FY2Pr/ZdEA5FOlzHNa8LlMv2Qeh8t+HdL/ySTDG JAI2qTeszqWtDSnMT+ExYH+zWCiYYw0/2/U01L/Qn5wNiEihAv4XYkkQsMecMw9H8zZ7Ob1h rSwWR1pYJIiJ94cHDTeLIq2bY0yHuxiQLbUMyCkPQhTXvz1mdkzVHlhMZefHkeo25dvbnCot 6JoWOyyCghEixtMeRpYReKOmkHDVMRLqo1VJSxYhyrmmdZUfJjTBqqpl4nvYPj5cLvogI2Cp GeKFgkfzZ3/OIMamipJOLQHoX80Y04Ug9k5BxUHJPPX054g+GB6YT1xYncPDj+J+aP1EvOSM h4DyAspB9gZoI5Xx8swL3UvQySpakgHoGeOfz0wsYOijoGW9UCkwqIWbrQ44Y+SgjxKEp3rk Z0a5PCcOSNPynIIxyWukbIDk6nhqp/Ni3vzpoAjGHs05w+YqP/sv8wykeK/2JejNkpZIDVop nvXFDc5QLc+cn70X1Ny9sYYj1+/KmS7d4QARAQABiQIfBBgBAgAJBQJHnxfSAhsMAAoJEBxg 1ZHbyZM9DIIP/iBxx1yb3Iy7m23GcNsfWRUnSmkAdkLf9VoEESvxtuC1l8AEUCeoTiQ0LSas Z2asV6yoMQOStv3eW6/WL6ZUL0jTm7x3Ki0/Ej+obnKpCKV3E45ku7unilXI4+TSPXxmwQOi 0ZVa+MwZn7jhwQuk60EgBUW0VyPmpgYnxtcb2HGGRj3V06A+T2963AyrM6gFBDSm5ulSwKyd LBDsbOpD9JXCvVrAFwCs8isa0snhhuipQZR3fKYhQ8pbCGSFYJ+BAgZuj02eeEQZP8J04LAY ItcsuO01B27svDJRF6BcoYljfO6Cat625mxsjYvITTsq0iCTx0d/OOee7nPhChB7bsRm9/F/ /N0STfbQVRyt0RZS0uGzo5lESk+TnlteNx6oJUpWTgO7FXr4j2ZpSGznjV57Sjgh8QttUubI DPrjFSGiY8z0DxZrIdWVtgDj2LeVnjql5eZpOn2BCe/+dRg581t5vZvCaIlpu+YBxWmJHU7V PyAY6Sq4xY6JW6B3yqkqTmOPE/ARUIYRzHPmv15kCINS/Jpw6fWTzsD1HPaRVVEwDuFRSxaK toDFOB7DktTf2NsyKDC0GN3w6x+I9VUHjJePK3wXqjQs0g/DXc7OBJV+1nBkj0ZlHqtuiNom fhycC18ZvUs6re/gu2jSSK3ME5Tll/qYGq5DcuzSTSnNS1Q3 Message-ID: <4300c85a-0942-f1b7-1854-2099107f1551@rub.de> Date: Tue, 3 Dec 2019 10:21:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <8047bf89-1120-426d-e020-e58766c2ce3a@danielfett.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 09:22:03 -0000 Hi, according to [1], countermeasure (1) describes to > configure [the] authorization servers to return an AS identitifier ("iss") and the "client_id" for which a code or token was issued in the authorization response. So if an MixUp attack is running, the victim contacts A-AS but is redirected to to H-AS [2]. The AS adds - according to the countermeasure - two additional parameters to the authorization response: client_id and issuer. Both values are set by H-AS, so it returns H-issuer and H-client_id. But: during the registration of the client on A-AS (rfc7591), it can retu= rn: HTTP/1.1 201 Created =C2=A0=C2=A0=C2=A0=C2=A0 { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "client_id": "H-client_id", =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "redirect_uris": [ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://client.example.org/ho= nest-callback", =C2=A0=C2=A0=C2=A0=C2=A0 } So if the client receives the client_id in the authorization response, it is unable to distinguish to which AS the client_id belongs to - they have the same values. This does not hold for the issuer parameter in the authorization response, because it is set by H-AS and independent of and not set during the Dynamic Client Registration Protocol. So basically, it is the same problem as with the redirect_uri. Regards Christian [1]: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4= =2E4.2 [2]: Step 4 in https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4= =2E4.1 On 02.12.19 11:26, Daniel Fett wrote: > Am 02.12.19 um 10:05 schrieb Christian Mainka: >> I think this problem is not only restricted to the redirect_uri. >> Regarding countermeasure (1), also the A-AS can return the same >> client_id as the client uses on the H-AS. >> >> TL;DR: In countermeasure (1), only the issuer prevents MixUp, the >> client_id parameter can be faked as well during the registration of th= e >> client (especially if Dynamic Client Registration is used). > What would be the issuer identifiers of A-AS and H-AS in this case be, > as seen by the client? > > -Daniel > > > --=20 Dr.-Ing. Christian Mainka Horst G=C3=B6rtz Institute for IT-Security=20 Chair for Network and Data Security=20 Ruhr-University Bochum, Germany Universit=C3=A4tsstr. 150, ID 2/463 D-44801 Bochum, Germany Telefon: +49 (0) 234 / 32-26796 Fax: +49 (0) 234 / 32-14347 http://nds.rub.de/chair/people/cmainka/ @CheariX From nobody Tue Dec 3 01:49:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE7E120233 for ; Tue, 3 Dec 2019 01:49:57 -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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrAE_WXntPY3 for ; Tue, 3 Dec 2019 01:49:56 -0800 (PST) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC0E120236 for ; Tue, 3 Dec 2019 01:49:56 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id B0A614ABC; Tue, 3 Dec 2019 09:49:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1575366594; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nwschxOLcNsi5cUy+qsCEQXzt4Ys7sn7duEhhbXolDM=; b=LPepWORUL7F0rFYnW0Yk8W5MxYEkit8Y7JSH9UzpcK5ElPC8pfAq1d/7xtLJAYTLDL1tao vtvGYmq76K4vgTPaDXZtDQVOnAOew/Ux+7OGkzMWuo5lPP3cBhaETcDdeti0LMjNz4yEF8 dyNmezjWmJ0A2oR7wxoZvR8NsY3vH4I= To: Christian Mainka , oauth@ietf.org References: <35143dd1-edeb-e0fd-6f36-a39d9b7f7008@hackmanit.de> <4f1d1215-aa23-93ab-ae5b-75426d7f07cc@danielfett.de> <277a3bc8-32fc-8c7c-85dc-5030d2d07728@rub.de> <8047bf89-1120-426d-e020-e58766c2ce3a@danielfett.de> <4300c85a-0942-f1b7-1854-2099107f1551@rub.de> From: Daniel Fett Message-ID: <12085fa3-43e8-0621-cb16-8b52ffde8a6f@danielfett.de> Date: Tue, 3 Dec 2019 10:49:54 +0100 MIME-Version: 1.0 In-Reply-To: <4300c85a-0942-f1b7-1854-2099107f1551@rub.de> Content-Type: multipart/alternative; boundary="------------A0C11F09EBB063952EB40700" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1575366594; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nwschxOLcNsi5cUy+qsCEQXzt4Ys7sn7duEhhbXolDM=; b=lNsef7JYyTv+XEvdTejAH8Z+6r0P4uzVA1IS4GR9g1tY67nFm3XfUfsTPe2+87dNQyh6z6 lWV/t9B2HORDo49uWS/oM9RUulnV9haeEDGd2mZjqW/g+jZV1lLCFXfvWHakXjRuSHzJdQ VdEhk35umZFt2DbIuVo2kh92iCLw7W0= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1575366594; a=rsa-sha256; cv=none; b=RIboD+rsngIVFjimDRAP4wdtYHZUH08R/93h9C10JW4NSpnSPGF3hjaScljH9qVSR9z85bSbNYQvlX/yIeK+UZtwIfblF4gQv8oLd2tchkAOgCbYlVrS6ovyuM5StEIgF5R/opSHNzTVrEpc4vTFiqRC6EJaTuSHrZ2liFPc2lw= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: ---- Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 09:49:58 -0000 This is a multi-part message in MIME format. --------------A0C11F09EBB063952EB40700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Am 03.12.19 um 10:21 schrieb Christian Mainka: > Hi, > > according to [1], countermeasure (1) describes to > >> configure [the] authorization servers to return an AS identitifier > ("iss") and the "client_id" for which a code or token was issued in the > authorization response. > > So if an MixUp attack is running, the victim contacts A-AS but is > redirected to to H-AS [2]. > The AS adds - according to the countermeasure - two additional > parameters to the authorization response: client_id and issuer. Both > values are set by H-AS, so it returns H-issuer and H-client_id. I asked for clarification because I would assume that the mix-up attack is twharted at this point. The client would see H-issuer instead of A-issuer, to which it sent the user. I agree that the client_id is not of much value here. -Daniel --------------A0C11F09EBB063952EB40700 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Am 03.12.19 um 10:21 schrieb Christian Mainka:
Hi,

according to [1], countermeasure (1) describes to


configure [the] authorization servers to return an AS identitifier

("iss") and the "client_id" for which a code or token was issued in the
authorization response.

So if an MixUp attack is running, the victim contacts A-AS but is
redirected to to H-AS [2].
The AS adds - according to the countermeasure - two additional
parameters to the authorization response: client_id and issuer. Both
values are set by H-AS, so it returns H-issuer and H-client_id.

I asked for clarification because I would assume that the mix-up attack is twharted at this point. The client would see H-issuer instead of A-issuer, to which it sent the user.

I agree that the client_id is not of much value here.

-Daniel
--------------A0C11F09EBB063952EB40700-- From nobody Tue Dec 3 05:20:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD30C12004F for ; Tue, 3 Dec 2019 05:20:57 -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 wuFSCl8oGXjm for ; Tue, 3 Dec 2019 05:20:54 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0: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 C38C3120019 for ; Tue, 3 Dec 2019 05:20:53 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id b15so3145796iln.3 for ; Tue, 03 Dec 2019 05:20:53 -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=7BHwHuyXqzzejnFsOGvNFROuK/3aUeSo8t5KRvuY3I0=; b=ONj4fa4j5VFb+Ape9jC8FlFaqrWFGPz2zXKPrKdH3IcLC1t9E1xq7HIw+UQeKe22az fs3y7GsAxeFkduc0jlEqIoBlRWxvKin/NP7Mkl7kpVehIazwmY9s6f8rX+90K6SUPFXS lD0LAWSfvX/4S5M6Rffs4c6NIPRTfq3H3Mf8mpDXYVUDF2jS74bNBQzW6AxJ82FIGsoT BWdaD9yvp89+CQlWA1oBdjvRYG+aNbX+441WFkgvF2qCH9mVDosLKCOEEtHeOL/KLL6b /vGU9N2GykLRck7Vllnn1B3xLCt2GWxZ7kWxUiu0R5mMKnMItuhFCy0Kc57VewAALof1 fghQ== 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=7BHwHuyXqzzejnFsOGvNFROuK/3aUeSo8t5KRvuY3I0=; b=eq2d9dKZ+aVeqLyJ37hl4H5OQ97yYU2OuehVir0pgHVAHY/BbzVChD4/FeKarhv7Z0 ulI8lTZlJGoQx1o2iDEGq5zgtcKur444Ng/SkGnqZjCBH1C+3SXi5DmaY5eYBjQ5+3N6 BBVrWtcEUqUCpIblM2EOdqTIKRuib6LhoUc42Uti79KdhzDjID5JU5n/nFBPlGAFhwux yTv9QZu+RSbcMD15CZfslxUKJoF+LqnfjiyqF8UXWptHQ3aX93EbQgXHKGIMTHzhw9zy L1JW7yJWXd2WXcQx83UFVuukOB7GG9Lfhr8bs7vhDbOGXrggZN35tO12/J9Ccffy0+ri x5fA== X-Gm-Message-State: APjAAAXBaBremyAcgup82VpdSafAXMtluyplqdMQnrNbCdXveUFOCnBN obOKJcg6o8xsHzvI5UkBHWlSniKPbVNoG+BGiC4= X-Google-Smtp-Source: APXvYqxRmg0a67GmmctGjAglChKh1/aF6NZbN1SvrGMmzi66fst4Rtwyd2qj+N1FuuVIdvex0w0wq6LaR1D3hYCOoYE= X-Received: by 2002:a92:3a8e:: with SMTP id i14mr4774506ilf.255.1575379252533; Tue, 03 Dec 2019 05:20:52 -0800 (PST) MIME-Version: 1.0 References: <6DD96E5F-2F26-4280-BDF9-41F43CB5A3AF@lodderstedt.net> <3F3A350A-0EF3-4968-968E-9325F8434E80@amazon.com> In-Reply-To: <3F3A350A-0EF3-4968-968E-9325F8434E80@amazon.com> From: Rifaat Shekh-Yusef Date: Tue, 3 Dec 2019 08:20:37 -0500 Message-ID: To: "Richard Backman, Annabelle" Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="000000000000bbdeaa0598cc9008" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: New Version Notification for draft-fett-oauth-dpop-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 13:20:58 -0000 --000000000000bbdeaa0598cc9008 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 2, 2019 at 4:35 PM Richard Backman, Annabelle wrote: > > Session cookies serve the same purpose in web apps as access tokens for > APIs but there are much more web apps than APIs. I use the analogy to > illustrate that either there are security issues with cloud deployments o= f > web apps or the techniques used to secure web apps are ok for APIs as wel= l. > > "Security issues" is a loaded term, but if you mean that there are > practical risks that are not addressed by bearer tokens (whether they be > session cookies or access tokens) then yes, I think we both agree that > there are. Otherwise we wouldn't be discussing PoP, sender-constrained > tokens, etc. TLS-based solutions mitigate some risks, while leaving other= s > unmitigated. Depending on your use case and threat model, these risks may > or may not present practical threats. For my use cases, they do. > > Ultimately I'd like to mitigate these risks for both service APIs and web > applications. My focus is on service APIs for a couple reasons: > > 1. Interoperability is more important when the sender and recipient aren'= t > necessarily owned by a single entity. I can do proprietary things in > JavaScript if I want to just as I can in client SDKs, but this breaks dow= n > if my API implements a standard protocol and is expected to work with > off-the-shelf clients and/or implementations from other vendors. > > 2. Web applications are just a special subset of service APIs that happen= s > to be accessed via a browser. A solution for service APIs ought to be > reusable for web applications, or at least serve as a foundation for thei= r > solution. > > > - Have you seen this kind of proxies intercepting the connection fro= m > on-prem service deployments to service provider? I=E2=80=99m asking becau= se I > thought the main use case was to intercept employees PC internet traffic. > > I'm working from second-hand knowledge here, but like most things in the > enterprise world, it depends. Separating employee device outbound traffic > from internal service outbound traffic requires some level of > sophistication, be it in network topology, routing rules, or configuratio= n > rules on the TLIS appliance. > > Yeah, many major enterprises have these kinds of inspection services, Take a look at the following example: https://www.zscaler.com/resources/data-sheets/zscaler-internet-access.pdf > > - Are you saying this kind of proxy does not support mutual TLS at > all? > > From what I understand, at the very least mTLS is not universally > supported. There may be some vendors that support it, but it's not > guaranteed. The documentation for Symantec's SSL Visibility product [1] > indicates that sessions using client certificates will be rejected unless > they are exempted based on destination whitelisting Yes, that is my experience too. > (which is problematic when the destination may be a general-purpose cloud > service provider). > Is there a use case that would require you to do that? If I have a service that is hosted on AWS, then the exception would be for my service, not for AWS in general. Regards, Rifaat > > > On the other hand, I would expect these kind of proxy to understand a > lot about the protocols running through it, otherwise they cannot fulfil > their task of inspecting this traffic. > > Maybe, maybe not. In any case there's a difference between understanding > HTTP or SMTP or P2P-protocol-du-jour and understanding the > application-level protocol running on top of HTTP. There hasn't been any > need for these proxies to understand OAuth 2.0 thus far. > > [1]: > https://origin-symwisedownload.symantec.com/resources/webguides/sslv/45/C= ontent/Topics/troubleshooting/Support_for_Client_Cert.htm > =E2=80=93 > Annabelle Richard Backman > AWS Identity > > > =EF=BB=BFOn 12/1/19, 7:41 AM, "Torsten Lodderstedt" 40lodderstedt.net@dmarc.ietf.org> wrote: > > > Annabelle, > > > Am 27.11.2019 um 02:46 schrieb Richard Backman, Annabelle < > richanna@amazon.com>: > > > > =EF=BB=BFTorsten, > > > > I'm not tracking how cookies are relevant to the discussion. > > I=E2=80=99m still trying to understand why you and others argue mTLS = cannot be > used in public cloud deployments (and thus focus on application level PoP= ). > > Session cookies serve the same purpose in web apps as access tokens > for APIs but there are much more web apps than APIs. I use the analogy to > illustrate that either there are security issues with cloud deployments o= f > web apps or the techniques used to secure web apps are ok for APIs as wel= l. > > Here are the two main arguments and my conclusions/questions: > > 1) mTLS it=E2=80=99s not end 2 end: although that=E2=80=99s true from= a connection > perspective, there are solutions employed to secure the last hop(s) betwe= en > TLS terminating proxy and service (private net, VPN, TLS). That works and > is considered secure enough for (session) cookies, it should be the same > for access tokens. > > 2) TLS terminating proxies do not forward cert data: if the service > itself terminates TLS this is feasible, we do it for our > public-cloud-hosted mTLS-protected APIs. If TLS termination is provided b= y > a component run by the cloud provider, the question is: is this component > able to forward the client certificate to the service? If not, web apps > using certs for authentication cannot be supported straightway by the clo= ud > provider. Any insights? > > > I'm guessing that's because we're not on the same page regarding us= e > cases, so allow me to clearly state mine: > > I think we are, we are just focusing on different ends of the TLS > tunnel. My focus is on the service provider=E2=80=99s side, esp. public c= loud > hosting, whereas you are focusing on client side TLS terminating proxies. > > > > > The use case I am concerned with is requests between services where > end-to-end TLS cannot be guaranteed. For example, an enterprise service > running on-premise, communicating with a service in the cloud, where the > enterprise's outbound traffic is routed through a TLS Inspection (TLSI) > appliance. The TLSI appliance sits in the middle of the communication, > terminating the TLS session established by the on-premise service and > establishing a separate TLS connection with the cloud service. > > > > In this kind of environment, there is no end-to-end TLS connection > between on-premise service and cloud service, and it is very unlikely tha= t > the TLSI appliance is configurable enough to support TLS-based > sender-constraint mechanisms without significantly compromising on the > scope of "sender" (e.g., "this service at this enterprise" becomes "this > enterprise=E2=80=9D). > > I=E2=80=99m not familiar with these kind of proxies, but happy to lea= rn more > and to discuss potential solutions. > > Here are some questions: > - Have you seen this kind of proxies intercepting the connection from > on-prem service deployments to service provider? I=E2=80=99m asking becau= se I > thought the main use case was to intercept employees PC internet traffic. > - Are you saying this kind of proxy does not support mutual TLS at > all? At least theoretically, the proxy could combine source and destinati= on > to select a cert/key pair to use for outbound TLS client authentication. > > > Even if it is possible, it is likely to require advanced > configuration that is non-trivial for administrators to deploy. It's no > longer as simple as the developer passing a self-signed certificate to th= e > HTTP stack. > > I agree. Cert binding is established in OAuth protocol messages, whic= h > would require the appliance to understand the protocol. On the other hand= , > I would expect these kind of proxy to understand a lot about the protocol= s > running through it, otherwise they cannot fulfil their task of inspecting > this traffic. > > best regards, > Torsten. > > > > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > =EF=BB=BFOn 11/23/19, 9:50 AM, "Torsten Lodderstedt" < > torsten@lodderstedt.net> wrote: > > > > > > > >>>>>>>>> On 23. Nov 2019, at 00:34, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > >>>>>>>>> how are cookies protected from leakage, replay, injection i= n > a setup like this? > >> They aren=E2=80=99t. > > > > Thats very interesting when compared to what we are discussing with > respect to API security. > > > > It effectively means anyone able to capture a session cookie, e.g. > between TLS termination point and application, by way of an HTML injectio= n, > or any other suitable attack is able to impersonate a legitimate user by > injecting the cookie(s) in an arbitrary user agent. The impact of such an > attack might be even worse than abusing an access token given the > (typically) broad scope of a session. > > > > TLS-based methods for sender constrained access tokens, in contrast= , > prevent this type of replay, even if the requests are protected between > client and TLS terminating proxy, only. Ensuring the authenticity of the > client certificate when forwarded from TLS terminating proxy to service, > e.g. through another authenticated TLS connection, will even prevent > injection within the data center/cloud environment. > > > > I come to the conclusion that we already have the mechanism at hand > to implement APIs with a considerable higher security level than what is > accepted today for web applications. So what problem do we want to solve? > > > >> But my primary concern here isn't web browser traffic, it's calls > from services/apps running inside a corporate network to services outside= a > corporate network (e.g., service-to-service API calls that pass through a > corporate TLS gateway). > > > > Can you please describe the challenges arising in these settings? I > assume those proxies won=E2=80=99t support CONNECT style pass through oth= erwise we > wouldn=E2=80=99t talk about them. > > > >>> That=E2=80=99s a totally valid point. But again, such a solution = makes the > life of client developers harder. > >>> I personally think, we as a community need to understand the pros > and cons of both approaches. I also think we have not even come close to > this point, which, in my option, is the prerequisite for making informed > decisions. > >> Agreed. It's clear that there are a number of parties coming at > this from a number of different directions, and that's coloring our > perceptions. That's why I think we need to nail down the scope of what > we're trying to solve with DPoP before we can have a productive > conversation how it should work. > > > > We will do so. > > > >> =E2=80=93 > >> Annabelle Richard Backman > >> AWS Identity > >> =EF=BB=BFOn 11/22/19, 10:51 PM, "Torsten Lodderstedt" < > torsten@lodderstedt.net> wrote: > >>>> On 22. Nov 2019, at 22:12, Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > >>> The service provider doesn't own the entire connection. They have > no control over corporate or government TLS gateways, or other terminator= s > that might exist on the client's side. In larger organizations, or when > cloud hosting is involved, the service team may not even own all the hops > on their side. > >> how are cookies protected from leakage, replay, injection in a > setup like this? > >>> While presumably they have some trust in them, protection against > leaked bearer tokens is an attractive defense-in-depth measure. > >> That=E2=80=99s a totally valid point. But again, such a solution m= akes the > life of client developers harder. > >> I personally think, we as a community need to understand the pros > and cons of both approaches. I also think we have not even come close to > this point, which, in my option, is the prerequisite for making informed > decisions. > >>> =E2=80=93 > >>> Annabelle Richard Backman > >>> AWS Identity > >>> =EF=BB=BFOn 11/22/19, 9:37 PM, "OAuth on behalf of Torsten Lodder= stedt" < > oauth-bounces@ietf.org on behalf of torsten=3D > 40lodderstedt.net@dmarc.ietf.org> wrote: > >>>> On 22. Nov 2019, at 21:21, Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > >>>> The dichotomy of "TLS working" and "TLS failed" only applies to = a > single TLS connection. In non-end-to-end TLS environments, each TLS > terminator between client and RS introduces additional token > leakage/exfiltration risk, irrespective of the quality of the TLS > connections themselves. Each terminator also introduces complexity for > implementing mTLS, Token Binding, or any other TLS-based sender constrain= t > solution, which means developers with non-end-to-end TLS use cases will b= e > more likely to turn to DPoP. > >>> The point is we are talking about different developers here. The > client developer does not need to care about the connection between proxy > and service. She relies on the service provider to get it right. So the > developers (or DevOps or admins) of the service provider need to ensure e= nd > to end security. And if the path is secured once, it will work for all > clients. > >>>> If DPoP is intended to address "cases where neither mTLS nor > OAuth Token Binding are available" [1], then it should address this risk = of > token leakage between client and RS. If on the other hand DPoP is only > intended to support the SPA use case and assumes the use of end-to-end TL= S, > then the document should be updated to reflect that. > >>> I agree. > >>>> [1]: > https://tools.ietf.org/html/draft-fett-oauth-dpop-03#section-1 > >>>> =E2=80=93 > >>>> Annabelle Richard Backman > >>>> AWS Identity > >>>> On 11/22/19, 8:17 PM, "OAuth on behalf of Torsten Lodderstedt" < > oauth-bounces@ietf.org on behalf of torsten=3D > 40lodderstedt.net@dmarc.ietf.org> wrote: > >>>> Hi Neil, > >>>>> On 22. Nov 2019, at 18:08, Neil Madden < > neil.madden@forgerock.com> wrote: > >>>>> On 22 Nov 2019, at 07:53, Torsten Lodderstedt 40lodderstedt.net@dmarc.ietf.org> wrote: > >>>>>>> On 22. Nov 2019, at 15:24, Justin Richer > wrote: > >>>>>>> I=E2=80=99m going to +1 Dick and Annabelle=E2=80=99s question= about the scope > here. That was the one major thing that struck me during the DPoP > discussions in Singapore yesterday: we don=E2=80=99t seem to agree on wha= t DPoP is > for. Some (including the authors, it seems) see it as a quick > point-solution to a specific use case. Others see it as a general PoP > mechanism. > >>>>>>> If it=E2=80=99s the former, then it should be explicitly tied= to one > specific set of things. If it=E2=80=99s the latter, then it needs to be e= xpanded. > >>>>>> as a co-author of the DPoP draft I state again what I said > yesterday: DPoP is a mechanism for sender-constraining access tokens sent > from SPAs only. The threat to be prevented is token replay. > >>>>> I think the phrase "token replay" is ambiguous. Traditionally i= t > refers to an attacker being able to capture a token (or whole requests) i= n > use and then replay it against the same RS. This is already protected > against by the use of normal TLS on the connection between the client and > the RS. I think instead you are referring to a malicious/compromised RS > replaying the token to a different RS - which has more of the flavour of = a > man in the middle attack (of the phishing kind). > >>>> I would argue TLS basically prevents leakage and not replay. The > threats we try to cope with can be found in the Security BCP. There are > multiple ways access tokens can leak, including referrer headers, mix-up, > open redirection, browser history, and all sorts of access token leakage = at > the resource server > >>>> Please have a look at > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4= . > >>>> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4= .8 > also has an extensive discussion of potential counter measures, including > audience restricted access tokens and a conclusion to recommend sender > constrained access tokens over other mechanisms. > >>>>> But if that's the case then there are much simpler defences tha= n > those proposed in the current draft: > >>>>> 1. Get separate access tokens for each RS with correct audience > and scopes. The consensus appears to be that this is hard to do in some > cases, hence the draft. > >>>> How many deployments do you know that today are able to issue > RS-specific access tokens? > >>>> BTW: how would you identify the RS? > >>>> I agree that would be an alternative and I=E2=80=99m a great fan= of such > tokens (and used them a lot at Deutsche Telekom) but in my perception thi= s > pattern needs still to be established in the market. Moreover, they > basically protect from a rough RS (if the URL is used as audience) > replaying the token someplace else, but they do not protect from all othe= r > kinds of leakage/replay (e.g. log files). > >>>>> 2. Make the DPoP token be a simple JWT with an "iat" and the > origin of the RS. This stops the token being reused elsewhere but the > client can reuse it (replay it) for many requests. > >>>>> 3. Issue a macaroon-based access token and the client can add a > correct audience and scope restrictions at the point of use. > >>>> Why is this needed if the access token is already audience > restricted? Or do you propose this as alternative? > >>>>> Protecting against the first kind of replay attacks only become= s > an issue if we assume the protections in TLS have failed. But if DPoP is > only intended for cases where mTLS can't be used, it shouldn't have to > protect against a stronger threat model in which we assume that TLS > security has been lost. > >>>> I agree. > >>>> best regards, > >>>> Torsten. > >>>>> -- Neil > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000bbdeaa0598cc9008 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 2, 2019 at 4:35 PM Richar= d Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
> Session cookies serve the same purp= ose in web apps as access tokens for APIs but there are much more web apps = than APIs. I use the analogy to illustrate that either there are security i= ssues with cloud deployments of web apps or the techniques used to secure w= eb apps are ok for APIs as well.

"Security issues" is a loaded term, but if you mean that there ar= e practical risks that are not addressed by bearer tokens (whether they be = session cookies or access tokens) then yes, I think we both agree that ther= e are. Otherwise we wouldn't be discussing PoP, sender-constrained toke= ns, etc. TLS-based solutions mitigate some risks, while leaving others unmi= tigated. Depending on your use case and threat model, these risks may or ma= y not present practical threats. For my use cases, they do.

Ultimately I'd like to mitigate these risks for both service APIs and w= eb applications. My focus is on service APIs for a couple reasons:

1. Interoperability is more important when the sender and recipient aren= 9;t necessarily owned by a single entity. I can do proprietary things in Ja= vaScript if I want to just as I can in client SDKs, but this breaks down if= my API implements a standard protocol and is expected to work with off-the= -shelf clients and/or implementations from other vendors.

2. Web applications are just a special subset of service APIs that happens = to be accessed via a browser. A solution for service APIs ought to be reusa= ble for web applications, or at least serve as a foundation for their solut= ion.

>=C2=A0 =C2=A0 - Have you seen this kind of proxies intercepting the con= nection from on-prem service deployments to service provider? I=E2=80=99m a= sking because I thought the main use case was to intercept employees PC int= ernet traffic.

I'm working from second-hand knowledge here, but like most things in th= e enterprise world, it depends. Separating employee device outbound traffic= from internal service outbound traffic requires some level of sophisticati= on, be it in network topology, routing rules, or configuration rules on the= TLIS appliance.


Yeah, many major enterprises have thes= e kinds of inspection services, Take a look at the following example:
=
=C2=A0
=C2=A0
>=C2=A0 =C2=A0 - Are you saying this kind of proxy does not support mutu= al TLS at all?

>From what I understand, at the very least mTLS is not universally supported= . There may be some vendors that support it, but it's not guaranteed. T= he documentation for Symantec's SSL Visibility product [1] indicates th= at sessions using client certificates will be rejected unless they are exem= pted based on destination whitelisting

Yes, that is my experience too.=C2=A0
=C2=A0=C2=A0
(which is problematic when the des= tination may be a general-purpose cloud service provider).
=

Is there a use case that would require you to do that?<= /div>
If I have a service that is hosted on AWS, then the exception wou= ld be for my service, not for AWS in general.

Regards,
=C2=A0Rifaat
=C2=A0

> On the other hand, I would expect these kind of proxy to understand a = lot about the protocols running through it, otherwise they cannot fulfil th= eir task of inspecting this traffic.

Maybe, maybe not. In any case there's a difference between understandin= g HTTP or SMTP or P2P-protocol-du-jour and understanding the application-le= vel protocol running on top of HTTP. There hasn't been any need for the= se proxies to understand OAuth 2.0 thus far.

[1]: https://origin-symwisedownload.symantec.= com/resources/webguides/sslv/45/Content/Topics/troubleshooting/Support_for_= Client_Cert.htm
=E2=80=93
Annabelle Richard Backman
AWS Identity


=EF=BB=BFOn 12/1/19, 7:41 AM, "Torsten Lodderstedt" <torsten= =3D40= lodderstedt.net@dmarc.ietf.org> wrote:


=C2=A0 =C2=A0 Annabelle,

=C2=A0 =C2=A0 > Am 27.11.2019 um 02:46 schrieb Richard Backman, Annabell= e <richanna@ama= zon.com>:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > =EF=BB=BFTorsten,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I'm not tracking how cookies are relevant to the dis= cussion.

=C2=A0 =C2=A0 I=E2=80=99m still trying to understand why you and others arg= ue mTLS cannot be used in public cloud deployments (and thus focus on appli= cation level PoP).

=C2=A0 =C2=A0 Session cookies serve the same purpose in web apps as access = tokens for APIs but there are much more web apps than APIs. I use the analo= gy to illustrate that either there are security issues with cloud deploymen= ts of web apps or the techniques used to secure web apps are ok for APIs as= well.

=C2=A0 =C2=A0 Here are the two main arguments and my conclusions/questions:= =C2=A0

=C2=A0 =C2=A0 1) mTLS it=E2=80=99s not end 2 end: although that=E2=80=99s t= rue from a connection perspective, there are solutions employed to secure t= he last hop(s) between TLS terminating proxy and service (private net, VPN,= TLS). That works and is considered secure enough for (session) cookies, it= should be the same for access tokens.

=C2=A0 =C2=A0 2) TLS terminating proxies do not forward cert data: if the s= ervice itself terminates TLS this is feasible, we do it for our public-clou= d-hosted mTLS-protected APIs. If TLS termination is provided by a component= run by the cloud provider, the question is: is this component able to forw= ard the client certificate to the service? If not, web apps using certs for= authentication cannot be supported straightway by the cloud provider. Any = insights?

=C2=A0 =C2=A0 > I'm guessing that's because we're not on the= same page regarding use cases, so allow me to clearly state mine:

=C2=A0 =C2=A0 I think we are, we are just focusing on different ends of the= TLS tunnel. My focus is on the service provider=E2=80=99s side, esp. publi= c cloud hosting, whereas you are focusing on client side TLS terminating pr= oxies.

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The use case I am concerned with is requests between ser= vices where end-to-end TLS cannot be guaranteed. For example, an enterprise= service running on-premise, communicating with a service in the cloud, whe= re the enterprise's outbound traffic is routed through a TLS Inspection= (TLSI) appliance. The TLSI appliance sits in the middle of the communicati= on, terminating the TLS session established by the on-premise service and e= stablishing a separate TLS connection with the cloud service.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > In this kind of environment, there is no end-to-end TLS = connection between on-premise service and cloud service, and it is very unl= ikely that the TLSI appliance is configurable enough to support TLS-based s= ender-constraint mechanisms without significantly compromising on the scope= of "sender" (e.g., "this service at this enterprise" b= ecomes "this enterprise=E2=80=9D).

=C2=A0 =C2=A0 I=E2=80=99m not familiar with these kind of proxies, but happ= y to learn more and to discuss potential solutions.

=C2=A0 =C2=A0 Here are some questions:
=C2=A0 =C2=A0 - Have you seen this kind of proxies intercepting the connect= ion from on-prem service deployments to service provider? I=E2=80=99m askin= g because I thought the main use case was to intercept employees PC interne= t traffic.
=C2=A0 =C2=A0 - Are you saying this kind of proxy does not support mutual T= LS at all? At least theoretically, the proxy could combine source and desti= nation to select a cert/key pair to use for outbound TLS client authenticat= ion.

=C2=A0 =C2=A0 > Even if it is possible, it is likely to require advanced= configuration that is non-trivial for administrators to deploy. It's n= o longer as simple as the developer passing a self-signed certificate to th= e HTTP stack.

=C2=A0 =C2=A0 I agree. Cert binding is established in OAuth protocol messag= es, which would require the appliance to understand the protocol. On the ot= her hand, I would expect these kind of proxy to understand a lot about the = protocols running through it, otherwise they cannot fulfil their task of in= specting this traffic.

=C2=A0 =C2=A0 best regards,
=C2=A0 =C2=A0 Torsten.



=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > =E2=80=93
=C2=A0 =C2=A0 > Annabelle Richard Backman
=C2=A0 =C2=A0 > AWS Identity
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > =EF=BB=BFOn 11/23/19, 9:50 AM, "Torsten Lodderstedt= " <tor= sten@lodderstedt.net> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >>>>>>>>> On 23. Nov 2019, at 00:3= 4, Richard Backman, Annabelle <richanna@amazon.com> wrote:
=C2=A0 =C2=A0 >>>>>>>>> how are cookies protecte= d from leakage, replay, injection in a setup like this?
=C2=A0 =C2=A0 >> They aren=E2=80=99t.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Thats very interesting when compared to what we are disc= ussing with respect to API security.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > It effectively means anyone able to capture a session co= okie, e.g. between TLS termination point and application, by way of an HTML= injection, or any other suitable attack is able to impersonate a legitimat= e user by injecting the cookie(s) in an arbitrary user agent. The impact of= such an attack might be even worse than abusing an access token given the = (typically) broad scope of a session.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > TLS-based methods for sender constrained access tokens, = in contrast, prevent this type of replay, even if the requests are protecte= d between client and TLS terminating proxy, only. Ensuring the authenticity= of the client certificate when forwarded from TLS terminating proxy to ser= vice, e.g. through another authenticated TLS connection, will even prevent = injection within the data center/cloud environment.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I come to the conclusion that we already have the mechan= ism at hand to implement APIs with a considerable higher security level tha= n what is accepted today for web applications. So what problem do we want t= o solve?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >> But my primary concern here isn't web browser tr= affic, it's calls from services/apps running inside a corporate network= to services outside a corporate network (e.g., service-to-service API call= s that pass through a corporate TLS gateway).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Can you please describe the challenges arising in these = settings? I assume those proxies won=E2=80=99t support CONNECT style pass t= hrough otherwise we wouldn=E2=80=99t talk about them.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >>> That=E2=80=99s a totally valid point. But again,= such a solution makes the life of client developers harder.
=C2=A0 =C2=A0 >>> I personally think, we as a community need to un= derstand the pros and cons of both approaches. I also think we have not eve= n come close to this point, which, in my option, is the prerequisite for ma= king informed decisions.
=C2=A0 =C2=A0 >> Agreed. It's clear that there are a number of pa= rties coming at this from a number of different directions, and that's = coloring our perceptions. That's why I think we need to nail down the s= cope of what we're trying to solve with DPoP before we can have a produ= ctive conversation how it should work.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > We will do so.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >> =E2=80=93
=C2=A0 =C2=A0 >> Annabelle Richard Backman
=C2=A0 =C2=A0 >> AWS Identity
=C2=A0 =C2=A0 >> =EF=BB=BFOn 11/22/19, 10:51 PM, "Torsten Lodder= stedt" <torsten@lodderstedt.net> wrote:
=C2=A0 =C2=A0 >>>> On 22. Nov 2019, at 22:12, Richard Backman, = Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >>> The service provider doesn't own the entire = connection. They have no control over corporate or government TLS gateways,= or other terminators that might exist on the client's side. In larger = organizations, or when cloud hosting is involved, the service team may not = even own all the hops on their side.
=C2=A0 =C2=A0 >> how are cookies protected from leakage, replay, inje= ction in a setup like this?
=C2=A0 =C2=A0 >>> While presumably they have some trust in them, p= rotection against leaked bearer tokens is an attractive defense-in-depth me= asure.
=C2=A0 =C2=A0 >> That=E2=80=99s a totally valid point. But again, suc= h a solution makes the life of client developers harder.
=C2=A0 =C2=A0 >> I personally think, we as a community need to unders= tand the pros and cons of both approaches. I also think we have not even co= me close to this point, which, in my option, is the prerequisite for making= informed decisions.
=C2=A0 =C2=A0 >>> =E2=80=93
=C2=A0 =C2=A0 >>> Annabelle Richard Backman
=C2=A0 =C2=A0 >>> AWS Identity
=C2=A0 =C2=A0 >>> =EF=BB=BFOn 11/22/19, 9:37 PM, "OAuth on be= half of Torsten Lodderstedt" <oauth-bounces@ietf.org on behalf of torsten=3D40lodde= rstedt.net@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >>>> On 22. Nov 2019, at 21:21, Richard Backman, = Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >>>> The dichotomy of "TLS working" and= "TLS failed" only applies to a single TLS connection. In non-end= -to-end TLS environments, each TLS terminator between client and RS introdu= ces additional token leakage/exfiltration risk, irrespective of the quality= of the TLS connections themselves. Each terminator also introduces complex= ity for implementing mTLS, Token Binding, or any other TLS-based sender con= straint solution, which means developers with non-end-to-end TLS use cases = will be more likely to turn to DPoP.
=C2=A0 =C2=A0 >>> The point is we are talking about different deve= lopers here. The client developer does not need to care about the connectio= n between proxy and service. She relies on the service provider to get it r= ight. So the developers (or DevOps or admins) of the service provider need = to ensure end to end security. And if the path is secured once, it will wor= k for all clients.
=C2=A0 =C2=A0 >>>> If DPoP is intended to address "cases w= here neither mTLS nor OAuth Token Binding are available" [1], then it = should address this risk of token leakage between client and RS. If on the = other hand DPoP is only intended to support the SPA use case and assumes th= e use of end-to-end TLS, then the document should be updated to reflect tha= t.
=C2=A0 =C2=A0 >>> I agree.
=C2=A0 =C2=A0 >>>> [1]: ht= tps://tools.ietf.org/html/draft-fett-oauth-dpop-03#section-1
=C2=A0 =C2=A0 >>>> =E2=80=93
=C2=A0 =C2=A0 >>>> Annabelle Richard Backman
=C2=A0 =C2=A0 >>>> AWS Identity
=C2=A0 =C2=A0 >>>> On 11/22/19, 8:17 PM, "OAuth on behalf = of Torsten Lodderstedt" <oauth-bounces@ietf.org on behalf of torsten=3D40loddersted= t.net@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >>>> Hi Neil,
=C2=A0 =C2=A0 >>>>> On 22. Nov 2019, at 18:08, Neil Madden &= lt;neil.madd= en@forgerock.com> wrote:
=C2=A0 =C2=A0 >>>>> On 22 Nov 2019, at 07:53, Torsten Lodder= stedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >>>>>>> On 22. Nov 2019, at 15:24, Justi= n Richer <jricher@m= it.edu> wrote:
=C2=A0 =C2=A0 >>>>>>> I=E2=80=99m going to +1 Dick and= Annabelle=E2=80=99s question about the scope here. That was the one major = thing that struck me during the DPoP discussions in Singapore yesterday: we= don=E2=80=99t seem to agree on what DPoP is for. Some (including the autho= rs, it seems) see it as a quick point-solution to a specific use case. Othe= rs see it as a general PoP mechanism.
=C2=A0 =C2=A0 >>>>>>> If it=E2=80=99s the former, then= it should be explicitly tied to one specific set of things. If it=E2=80=99= s the latter, then it needs to be expanded.
=C2=A0 =C2=A0 >>>>>> as a co-author of the DPoP draft I s= tate again what I said yesterday: DPoP is a mechanism for sender-constraini= ng access tokens sent from SPAs only. The threat to be prevented is token r= eplay.
=C2=A0 =C2=A0 >>>>> I think the phrase "token replay&qu= ot; is ambiguous. Traditionally it refers to an attacker being able to capt= ure a token (or whole requests) in use and then replay it against the same = RS. This is already protected against by the use of normal TLS on the conne= ction between the client and the RS. I think instead you are referring to a= malicious/compromised RS replaying the token to a different RS - which has= more of the flavour of a man in the middle attack (of the phishing kind).<= br> =C2=A0 =C2=A0 >>>> I would argue TLS basically prevents leakage= and not replay. The threats we try to cope with can be found in the Securi= ty BCP. There are multiple ways access tokens can leak, including referrer = headers, mix-up, open redirection, browser history, and all sorts of access= token leakage at the resource server
=C2=A0 =C2=A0 >>>> Please have a look at https://tools.ietf.org/html/draft-ietf-oauth-secu= rity-topics-13#section-4.
=C2=A0 =C2=A0 >>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#secti= on-4.8 also has an extensive discussion of potential counter measures, = including audience restricted access tokens and a conclusion to recommend s= ender constrained access tokens over other mechanisms.
=C2=A0 =C2=A0 >>>>> But if that's the case then there ar= e much simpler defences than those proposed in the current draft:
=C2=A0 =C2=A0 >>>>> 1. Get separate access tokens for each R= S with correct audience and scopes. The consensus appears to be that this i= s hard to do in some cases, hence the draft.
=C2=A0 =C2=A0 >>>> How many deployments do you know that today = are able to issue RS-specific access tokens?
=C2=A0 =C2=A0 >>>> BTW: how would you identify the RS?
=C2=A0 =C2=A0 >>>> I agree that would be an alternative and I= =E2=80=99m a great fan of such tokens (and used them a lot at Deutsche Tele= kom) but in my perception this pattern needs still to be established in the= market. Moreover, they basically protect from a rough RS (if the URL is us= ed as audience) replaying the token someplace else, but they do not protect= from all other kinds of leakage/replay (e.g. log files).
=C2=A0 =C2=A0 >>>>> 2. Make the DPoP token be a simple JWT w= ith an "iat" and the origin of the RS. This stops the token being= reused elsewhere but the client can reuse it (replay it) for many requests= .
=C2=A0 =C2=A0 >>>>> 3. Issue a macaroon-based access token a= nd the client can add a correct audience and scope restrictions at the poin= t of use.
=C2=A0 =C2=A0 >>>> Why is this needed if the access token is al= ready audience restricted? Or do you propose this as alternative?
=C2=A0 =C2=A0 >>>>> Protecting against the first kind of rep= lay attacks only becomes an issue if we assume the protections in TLS have = failed. But if DPoP is only intended for cases where mTLS can't be used= , it shouldn't have to protect against a stronger threat model in which= we assume that TLS security has been lost.
=C2=A0 =C2=A0 >>>> I agree.
=C2=A0 =C2=A0 >>>> best regards,
=C2=A0 =C2=A0 >>>> Torsten.
=C2=A0 =C2=A0 >>>>> -- Neil


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000bbdeaa0598cc9008-- From nobody Tue Dec 3 10:47:14 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4AB1200A3 for ; Tue, 3 Dec 2019 10:47:13 -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 fKT5UbBKqLKM for ; Tue, 3 Dec 2019 10:47:11 -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 CCFBD12000F for ; Tue, 3 Dec 2019 10:47:10 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id a13so4985371ljm.10 for ; Tue, 03 Dec 2019 10:47:10 -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=iytROZKWIGaYvoAiO4M/mRZxiJrKTIS7rZf126se3u4=; b=FHlxBL2L494IMue2BOYM2ggS9LhhyfhiZWdy9O61GIysfk0zPUw2B7ygOlesa3IfG2 cAn+ngna+5mwqvL+RhwC1cl3WtrSj2mXGiH30Mjvfkbq5OHo1y5wulpR/K3V4sXvf1Q4 iRFRQlwa5cQ//CBpS1OrJZQp4c4iBDyoKipkFksPYa60V5XrtkJm+cwF+DlOiyP8TKD2 8BjS+MUCX1QUFpum6cMKaRXFVjHK1fUyC6li2buxeRCk2auilP+Hp1cacwFm9faRmqDI /H/67YlSw7XUx3pXkcmR/H70UBe1zpdxqEQdzCwrr2JT3A85DiRrSRuZnC8XMrUN3yOP n/Og== 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=iytROZKWIGaYvoAiO4M/mRZxiJrKTIS7rZf126se3u4=; b=NVQFckbtVwIthGY76e0tiCX8wXGuM48ChpFT9G8sJ/Q59Kp/mL4ga2I1EIxq2rJzVD dEO5kEtb7SZ5RUEJ6XmO+0PTe4DyMbOxTftXmRlNZlgrZKshwXXeu3VPgQDPb3SOXm2N XDQMwxTegQRJDDDs7NxIsm68I5wlJYmnYoSqnZhkFoEcJbNYzojT688Ud52JtXlxnT0K TVVeqxXFlkwbjVfOWDwUiaw3gX3Q4N0H2UBK9uWruYkYNLKihs34pDGck8CSi3XFbhDS 7tsfDDIEWVWW/31HRlynK7LrUiinpcBvNZb8iib++aokxA6AKO9EhYODlQbUto08uW0C PN7Q== X-Gm-Message-State: APjAAAU1WHAwin1Sxjrtld6Nw4diROH3TGPujdjIy2zBxtmCYgfuPZmU uXn/cmPavdWbLiJmL/q5xikk4mNwHzOANrLFkOdUHFndcWkSlwOzZlPBCUHTYfEiamIUesEdzzN Bcq4qAPcLDqVKsQ== X-Google-Smtp-Source: APXvYqzNnLqt33qkozrFdK+NeQnwx1fkZr58YKWmXCGhM7MEEdv2hDXjbcsM1icAyE+2jgGHI9BXhHmNGFB8Ld/WGKE= X-Received: by 2002:a2e:9592:: with SMTP id w18mr3441410ljh.98.1575398828820; Tue, 03 Dec 2019 10:47:08 -0800 (PST) MIME-Version: 1.0 References: <35143dd1-edeb-e0fd-6f36-a39d9b7f7008@hackmanit.de> <4f1d1215-aa23-93ab-ae5b-75426d7f07cc@danielfett.de> In-Reply-To: <4f1d1215-aa23-93ab-ae5b-75426d7f07cc@danielfett.de> From: Brian Campbell Date: Tue, 3 Dec 2019 11:46:41 -0700 Message-ID: To: Daniel Fett Cc: oauth Content-Type: multipart/alternative; boundary="0000000000009261050598d11f9c" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 18:47:13 -0000 --0000000000009261050598d11f9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 26, 2019 at 7:20 AM Daniel Fett wrote: > Am 26.11.19 um 14:24 schrieb Karsten Meyer zu Selhausen: > > Depending on its implementation the client might simply extract all dat= a > > contained in the Client Information Response and use it for > > authorizations with the specific AS. > > We were able to confirm that one popular open-source library behaves in > > this exact way. It stores the redirect URI contained in the Client > > Information Response and uses it for Authorization Requests with the > > A-AS although it differs from the redirect URI in the Client > > Registration Request. > > The client uses untrusted, unverified data to make its decision on what > redirect URI to use. > > Nonetheless, we should definitely mention this in the BCP! > RFC 7591 basically says that the AS can replace/substitute/augment any of the client registration info and leaves it up to the client as to how to handle differences from what was requested. There are quite a few things that just wouldn't make sense for the AS to change and some like redirect URI that could potentially be dangerous. Perhaps the BCP should mention the situation and recommend that a client not proceed if the redirect URIs (and others?) don't align with what was requested. --=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._ --0000000000009261050598d11f9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Nov 26, 2019 at 7:20 AM Daniel Fe= tt <fett@danielf= ett.de> wrote:
Am 26.11.19 um 14:24 schrieb Karsten Meyer zu Selhausen:
> Depending on its implementation the client might simply extract all da= ta
> contained in the Client Information Response and use it for
> authorizations with the specific AS.
> We were able to confirm that one popular open-source library behaves i= n
> this exact way. It stores the redirect URI contained in the Client
> Information Response and uses it for Authorization Requests with the > A-AS although it differs from the redirect URI in the Client
> Registration Request.

The client uses untrusted, unverified data to make its decision on what
redirect URI to use.

Nonetheless, we should definitely mention this in the BCP!
=


RFC 7591 basically says that the AS can = replace/substitute/augment any of the client registration info and leaves i= t up to the client as to how to handle differences from what was requested.= There are quite a few things that just wouldn't make sense for the AS = to change and some like redirect URI that could potentially be dangerous.= =C2=A0 Perhaps the BCP should mention the situation and recommend that a cl= ient not proceed if the redirect URIs (and others?) don't align with wh= at was requested.
=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000009261050598d11f9c-- From nobody Tue Dec 3 12:46:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E63120044 for ; Tue, 3 Dec 2019 12:46:56 -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, 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 Q_8RxL_k7J9o for ; Tue, 3 Dec 2019 12:46:50 -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 4760F12007A for ; Tue, 3 Dec 2019 12:46:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1575406011; x=1606942011; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EJsf42Q4Knyyo68xOEjnMyV2BitiK/27FklW2VKphYs=; b=YPU0JLuTa8/L255Xvhr5klSFkwXUyarYLlUOebwwCN2AZXVxj2tSSIkJ E0K0N5vy+5C1dWm5UEWWnPPsZL3xtyWyBWUFhLmWYYpCsZh5EktCEeFEh Z7kchzi537G6Bhm1KiV2+h4avA1Da0d1EzRKUx6LWQ4DYPgPLuPDYxfML o=; IronPort-SDR: 3FT5yDIVJisqNnL9pHHdIQiP42n1B1MBas4BLW4dXl2eXMG72SYrrV+/bSU9fB5KIiPbbrA+Uw SFy+NOkHpC/A== X-IronPort-AV: E=Sophos; i="5.69,274,1571702400"; d="scan'208,217"; a="12757598" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2a-c5104f52.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 03 Dec 2019 20:46:40 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2a-c5104f52.us-west-2.amazon.com (Postfix) with ESMTPS id 55E3CA1EAE; Tue, 3 Dec 2019 20:46:39 +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, 3 Dec 2019 20:46:38 +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, 3 Dec 2019 20:46:38 +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, 3 Dec 2019 20:46:38 +0000 From: "Richard Backman, Annabelle" To: Rifaat Shekh-Yusef CC: Torsten Lodderstedt , oauth Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: New Version Notification for draft-fett-oauth-dpop-03.txt Thread-Index: AQHVqdyJhx+uhCYmXkugUYc7Lr7X1aeoW64A Date: Tue, 3 Dec 2019 20:46:38 +0000 Message-ID: <6C747BDA-478A-4E5F-9438-8D766520DB27@amazon.com> References: <6DD96E5F-2F26-4280-BDF9-41F43CB5A3AF@lodderstedt.net> <3F3A350A-0EF3-4968-968E-9325F8434E80@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.162.171] Content-Type: multipart/alternative; boundary="_000_6C747BDA478A4E5F94388D766520DB27amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: New Version Notification for draft-fett-oauth-dpop-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 20:46:57 -0000 --_000_6C747BDA478A4E5F94388D766520DB27amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gVGhlIGRvY3VtZW50YXRpb24gZm9yIFN5bWFudGVjJ3MgU1NMIFZpc2liaWxpdHkgcHJvZHVj dCBbMV0gaW5kaWNhdGVzIHRoYXQgc2Vzc2lvbnMgdXNpbmcgY2xpZW50IGNlcnRpZmljYXRlcyB3 aWxsIGJlIHJlamVjdGVkIHVubGVzcyB0aGV5IGFyZSBleGVtcHRlZCBiYXNlZCBvbiBkZXN0aW5h dGlvbiB3aGl0ZWxpc3RpbmcgKHdoaWNoIGlzIHByb2JsZW1hdGljIHdoZW4gdGhlIGRlc3RpbmF0 aW9uIG1heSBiZSBhIGdlbmVyYWwtcHVycG9zZSBjbG91ZCBzZXJ2aWNlIHByb3ZpZGVyKS4NCg0K PiBJcyB0aGVyZSBhIHVzZSBjYXNlIHRoYXQgd291bGQgcmVxdWlyZSB5b3UgdG8gZG8gdGhhdD8N Cj4gSWYgSSBoYXZlIGEgc2VydmljZSB0aGF0IGlzIGhvc3RlZCBvbiBBV1MsIHRoZW4gdGhlIGV4 Y2VwdGlvbiB3b3VsZCBiZSBmb3IgbXkgc2VydmljZSwgbm90IGZvciBBV1MgaW4gZ2VuZXJhbC4N Cg0KWWVzLiBDb25zaWRlciBhbiBvbi1wcmVtaXNlIHNlcnZpY2UgdGhhdCB1c2VzIGEgdmVuZG9y IHNlcnZpY2UgaG9zdGVkIGluIHRoZSBjbG91ZC4gV2hpbGUgc29tZSBTYWFTIEFQSSBlbmRwb2lu dHMgYXJlIHRlbmFudC1zcGVjaWZpYywgbWFueSAobW9zdD8pIGFyZSBub3QsIG1lYW5pbmcgZnJv bSBhIGRlc3RpbmF0aW9uIHBlcnNwZWN0aXZlIHRoZSBlbnRlcnByaXNl4oCZcyBsZWdpdGltYXRl IHRyYWZmaWMgbG9va3MganVzdCBsaWtlIHF1ZXN0aW9uYWJsZSB0cmFmZmljLg0KDQrigJMNCkFu bmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IFJpZmFhdCBT aGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPg0KRGF0ZTogVHVlc2RheSwgRGVjZW1i ZXIgMywgMjAxOSBhdCA1OjIxIEFNDQpUbzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8 cmljaGFubmFAYW1hem9uLmNvbT4NCkNjOiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxv ZGRlcnN0ZWR0Lm5ldD4sIG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFtVTlZFUklG SUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gW1VOVkVSSUZJRUQgU0VOREVSXSBSZTogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1mZXR0LW9hdXRoLWRwb3AtMDMudHh0DQoNCg0K DQpPbiBNb24sIERlYyAyLCAyMDE5IGF0IDQ6MzUgUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24u Y29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQo+IFNlc3Npb24gY29va2llcyBzZXJ2ZSB0aGUg c2FtZSBwdXJwb3NlIGluIHdlYiBhcHBzIGFzIGFjY2VzcyB0b2tlbnMgZm9yIEFQSXMgYnV0IHRo ZXJlIGFyZSBtdWNoIG1vcmUgd2ViIGFwcHMgdGhhbiBBUElzLiBJIHVzZSB0aGUgYW5hbG9neSB0 byBpbGx1c3RyYXRlIHRoYXQgZWl0aGVyIHRoZXJlIGFyZSBzZWN1cml0eSBpc3N1ZXMgd2l0aCBj bG91ZCBkZXBsb3ltZW50cyBvZiB3ZWIgYXBwcyBvciB0aGUgdGVjaG5pcXVlcyB1c2VkIHRvIHNl Y3VyZSB3ZWIgYXBwcyBhcmUgb2sgZm9yIEFQSXMgYXMgd2VsbC4NCg0KIlNlY3VyaXR5IGlzc3Vl cyIgaXMgYSBsb2FkZWQgdGVybSwgYnV0IGlmIHlvdSBtZWFuIHRoYXQgdGhlcmUgYXJlIHByYWN0 aWNhbCByaXNrcyB0aGF0IGFyZSBub3QgYWRkcmVzc2VkIGJ5IGJlYXJlciB0b2tlbnMgKHdoZXRo ZXIgdGhleSBiZSBzZXNzaW9uIGNvb2tpZXMgb3IgYWNjZXNzIHRva2VucykgdGhlbiB5ZXMsIEkg dGhpbmsgd2UgYm90aCBhZ3JlZSB0aGF0IHRoZXJlIGFyZS4gT3RoZXJ3aXNlIHdlIHdvdWxkbid0 IGJlIGRpc2N1c3NpbmcgUG9QLCBzZW5kZXItY29uc3RyYWluZWQgdG9rZW5zLCBldGMuIFRMUy1i YXNlZCBzb2x1dGlvbnMgbWl0aWdhdGUgc29tZSByaXNrcywgd2hpbGUgbGVhdmluZyBvdGhlcnMg dW5taXRpZ2F0ZWQuIERlcGVuZGluZyBvbiB5b3VyIHVzZSBjYXNlIGFuZCB0aHJlYXQgbW9kZWws IHRoZXNlIHJpc2tzIG1heSBvciBtYXkgbm90IHByZXNlbnQgcHJhY3RpY2FsIHRocmVhdHMuIEZv ciBteSB1c2UgY2FzZXMsIHRoZXkgZG8uDQoNClVsdGltYXRlbHkgSSdkIGxpa2UgdG8gbWl0aWdh dGUgdGhlc2Ugcmlza3MgZm9yIGJvdGggc2VydmljZSBBUElzIGFuZCB3ZWIgYXBwbGljYXRpb25z LiBNeSBmb2N1cyBpcyBvbiBzZXJ2aWNlIEFQSXMgZm9yIGEgY291cGxlIHJlYXNvbnM6DQoNCjEu IEludGVyb3BlcmFiaWxpdHkgaXMgbW9yZSBpbXBvcnRhbnQgd2hlbiB0aGUgc2VuZGVyIGFuZCBy ZWNpcGllbnQgYXJlbid0IG5lY2Vzc2FyaWx5IG93bmVkIGJ5IGEgc2luZ2xlIGVudGl0eS4gSSBj YW4gZG8gcHJvcHJpZXRhcnkgdGhpbmdzIGluIEphdmFTY3JpcHQgaWYgSSB3YW50IHRvIGp1c3Qg YXMgSSBjYW4gaW4gY2xpZW50IFNES3MsIGJ1dCB0aGlzIGJyZWFrcyBkb3duIGlmIG15IEFQSSBp bXBsZW1lbnRzIGEgc3RhbmRhcmQgcHJvdG9jb2wgYW5kIGlzIGV4cGVjdGVkIHRvIHdvcmsgd2l0 aCBvZmYtdGhlLXNoZWxmIGNsaWVudHMgYW5kL29yIGltcGxlbWVudGF0aW9ucyBmcm9tIG90aGVy IHZlbmRvcnMuDQoNCjIuIFdlYiBhcHBsaWNhdGlvbnMgYXJlIGp1c3QgYSBzcGVjaWFsIHN1YnNl dCBvZiBzZXJ2aWNlIEFQSXMgdGhhdCBoYXBwZW5zIHRvIGJlIGFjY2Vzc2VkIHZpYSBhIGJyb3dz ZXIuIEEgc29sdXRpb24gZm9yIHNlcnZpY2UgQVBJcyBvdWdodCB0byBiZSByZXVzYWJsZSBmb3Ig d2ViIGFwcGxpY2F0aW9ucywgb3IgYXQgbGVhc3Qgc2VydmUgYXMgYSBmb3VuZGF0aW9uIGZvciB0 aGVpciBzb2x1dGlvbi4NCg0KPiAgICAtIEhhdmUgeW91IHNlZW4gdGhpcyBraW5kIG9mIHByb3hp ZXMgaW50ZXJjZXB0aW5nIHRoZSBjb25uZWN0aW9uIGZyb20gb24tcHJlbSBzZXJ2aWNlIGRlcGxv eW1lbnRzIHRvIHNlcnZpY2UgcHJvdmlkZXI/IEnigJltIGFza2luZyBiZWNhdXNlIEkgdGhvdWdo dCB0aGUgbWFpbiB1c2UgY2FzZSB3YXMgdG8gaW50ZXJjZXB0IGVtcGxveWVlcyBQQyBpbnRlcm5l dCB0cmFmZmljLg0KDQpJJ20gd29ya2luZyBmcm9tIHNlY29uZC1oYW5kIGtub3dsZWRnZSBoZXJl LCBidXQgbGlrZSBtb3N0IHRoaW5ncyBpbiB0aGUgZW50ZXJwcmlzZSB3b3JsZCwgaXQgZGVwZW5k cy4gU2VwYXJhdGluZyBlbXBsb3llZSBkZXZpY2Ugb3V0Ym91bmQgdHJhZmZpYyBmcm9tIGludGVy bmFsIHNlcnZpY2Ugb3V0Ym91bmQgdHJhZmZpYyByZXF1aXJlcyBzb21lIGxldmVsIG9mIHNvcGhp c3RpY2F0aW9uLCBiZSBpdCBpbiBuZXR3b3JrIHRvcG9sb2d5LCByb3V0aW5nIHJ1bGVzLCBvciBj b25maWd1cmF0aW9uIHJ1bGVzIG9uIHRoZSBUTElTIGFwcGxpYW5jZS4NCg0KWWVhaCwgbWFueSBt YWpvciBlbnRlcnByaXNlcyBoYXZlIHRoZXNlIGtpbmRzIG9mIGluc3BlY3Rpb24gc2VydmljZXMs IFRha2UgYSBsb29rIGF0IHRoZSBmb2xsb3dpbmcgZXhhbXBsZToNCmh0dHBzOi8vd3d3LnpzY2Fs ZXIuY29tL3Jlc291cmNlcy9kYXRhLXNoZWV0cy96c2NhbGVyLWludGVybmV0LWFjY2Vzcy5wZGYN Cg0KDQo+ICAgIC0gQXJlIHlvdSBzYXlpbmcgdGhpcyBraW5kIG9mIHByb3h5IGRvZXMgbm90IHN1 cHBvcnQgbXV0dWFsIFRMUyBhdCBhbGw/DQoNCj5Gcm9tIHdoYXQgSSB1bmRlcnN0YW5kLCBhdCB0 aGUgdmVyeSBsZWFzdCBtVExTIGlzIG5vdCB1bml2ZXJzYWxseSBzdXBwb3J0ZWQuLiBUaGVyZSBt YXkgYmUgc29tZSB2ZW5kb3JzIHRoYXQgc3VwcG9ydCBpdCwgYnV0IGl0J3Mgbm90IGd1YXJhbnRl ZWQuIFRoZSBkb2N1bWVudGF0aW9uIGZvciBTeW1hbnRlYydzIFNTTCBWaXNpYmlsaXR5IHByb2R1 Y3QgWzFdIGluZGljYXRlcyB0aGF0IHNlc3Npb25zIHVzaW5nIGNsaWVudCBjZXJ0aWZpY2F0ZXMg d2lsbCBiZSByZWplY3RlZCB1bmxlc3MgdGhleSBhcmUgZXhlbXB0ZWQgYmFzZWQgb24gZGVzdGlu YXRpb24gd2hpdGVsaXN0aW5nDQoNClllcywgdGhhdCBpcyBteSBleHBlcmllbmNlIHRvby4NCg0K KHdoaWNoIGlzIHByb2JsZW1hdGljIHdoZW4gdGhlIGRlc3RpbmF0aW9uIG1heSBiZSBhIGdlbmVy YWwtcHVycG9zZSBjbG91ZCBzZXJ2aWNlIHByb3ZpZGVyKS4NCg0KSXMgdGhlcmUgYSB1c2UgY2Fz ZSB0aGF0IHdvdWxkIHJlcXVpcmUgeW91IHRvIGRvIHRoYXQ/DQpJZiBJIGhhdmUgYSBzZXJ2aWNl IHRoYXQgaXMgaG9zdGVkIG9uIEFXUywgdGhlbiB0aGUgZXhjZXB0aW9uIHdvdWxkIGJlIGZvciBt eSBzZXJ2aWNlLCBub3QgZm9yIEFXUyBpbiBnZW5lcmFsLg0KDQpSZWdhcmRzLA0KIFJpZmFhdA0K DQoNCj4gT24gdGhlIG90aGVyIGhhbmQsIEkgd291bGQgZXhwZWN0IHRoZXNlIGtpbmQgb2YgcHJv eHkgdG8gdW5kZXJzdGFuZCBhIGxvdCBhYm91dCB0aGUgcHJvdG9jb2xzIHJ1bm5pbmcgdGhyb3Vn aCBpdCwgb3RoZXJ3aXNlIHRoZXkgY2Fubm90IGZ1bGZpbCB0aGVpciB0YXNrIG9mIGluc3BlY3Rp bmcgdGhpcyB0cmFmZmljLg0KDQpNYXliZSwgbWF5YmUgbm90LiBJbiBhbnkgY2FzZSB0aGVyZSdz IGEgZGlmZmVyZW5jZSBiZXR3ZWVuIHVuZGVyc3RhbmRpbmcgSFRUUCBvciBTTVRQIG9yIFAyUC1w cm90b2NvbC1kdS1qb3VyIGFuZCB1bmRlcnN0YW5kaW5nIHRoZSBhcHBsaWNhdGlvbi1sZXZlbCBw cm90b2NvbCBydW5uaW5nIG9uIHRvcCBvZiBIVFRQLiBUaGVyZSBoYXNuJ3QgYmVlbiBhbnkgbmVl ZCBmb3IgdGhlc2UgcHJveGllcyB0byB1bmRlcnN0YW5kIE9BdXRoIDIuMCB0aHVzIGZhci4NCg0K WzFdOiBodHRwczovL29yaWdpbi1zeW13aXNlZG93bmxvYWQuc3ltYW50ZWMuY29tL3Jlc291cmNl cy93ZWJndWlkZXMvc3Nsdi80NS9Db250ZW50L1RvcGljcy90cm91Ymxlc2hvb3RpbmcvU3VwcG9y dF9mb3JfQ2xpZW50X0NlcnQuaHRtDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFX UyBJZGVudGl0eQ0KDQoNCk9uIDEyLzEvMTksIDc6NDEgQU0sICJUb3JzdGVuIExvZGRlcnN0ZWR0 IiA8dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBsb2Rk ZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KDQogICAgQW5uYWJlbGxlLA0K DQogICAgPiBBbSAyNy4xMS4yMDE5IHVtIDAyOjQ2IHNjaHJpZWIgUmljaGFyZCBCYWNrbWFuLCBB bm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+ PjoNCiAgICA+DQogICAgPiBUb3JzdGVuLA0KICAgID4NCiAgICA+IEknbSBub3QgdHJhY2tpbmcg aG93IGNvb2tpZXMgYXJlIHJlbGV2YW50IHRvIHRoZSBkaXNjdXNzaW9uLg0KDQogICAgSeKAmW0g c3RpbGwgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgd2h5IHlvdSBhbmQgb3RoZXJzIGFyZ3VlIG1UTFMg Y2Fubm90IGJlIHVzZWQgaW4gcHVibGljIGNsb3VkIGRlcGxveW1lbnRzIChhbmQgdGh1cyBmb2N1 cyBvbiBhcHBsaWNhdGlvbiBsZXZlbCBQb1ApLg0KDQogICAgU2Vzc2lvbiBjb29raWVzIHNlcnZl IHRoZSBzYW1lIHB1cnBvc2UgaW4gd2ViIGFwcHMgYXMgYWNjZXNzIHRva2VucyBmb3IgQVBJcyBi dXQgdGhlcmUgYXJlIG11Y2ggbW9yZSB3ZWIgYXBwcyB0aGFuIEFQSXMuIEkgdXNlIHRoZSBhbmFs b2d5IHRvIGlsbHVzdHJhdGUgdGhhdCBlaXRoZXIgdGhlcmUgYXJlIHNlY3VyaXR5IGlzc3VlcyB3 aXRoIGNsb3VkIGRlcGxveW1lbnRzIG9mIHdlYiBhcHBzIG9yIHRoZSB0ZWNobmlxdWVzIHVzZWQg dG8gc2VjdXJlIHdlYiBhcHBzIGFyZSBvayBmb3IgQVBJcyBhcyB3ZWxsLg0KDQogICAgSGVyZSBh cmUgdGhlIHR3byBtYWluIGFyZ3VtZW50cyBhbmQgbXkgY29uY2x1c2lvbnMvcXVlc3Rpb25zOg0K DQogICAgMSkgbVRMUyBpdOKAmXMgbm90IGVuZCAyIGVuZDogYWx0aG91Z2ggdGhhdOKAmXMgdHJ1 ZSBmcm9tIGEgY29ubmVjdGlvbiBwZXJzcGVjdGl2ZSwgdGhlcmUgYXJlIHNvbHV0aW9ucyBlbXBs b3llZCB0byBzZWN1cmUgdGhlIGxhc3QgaG9wKHMpIGJldHdlZW4gVExTIHRlcm1pbmF0aW5nIHBy b3h5IGFuZCBzZXJ2aWNlIChwcml2YXRlIG5ldCwgVlBOLCBUTFMpLiBUaGF0IHdvcmtzIGFuZCBp cyBjb25zaWRlcmVkIHNlY3VyZSBlbm91Z2ggZm9yIChzZXNzaW9uKSBjb29raWVzLCBpdCBzaG91 bGQgYmUgdGhlIHNhbWUgZm9yIGFjY2VzcyB0b2tlbnMuDQoNCiAgICAyKSBUTFMgdGVybWluYXRp bmcgcHJveGllcyBkbyBub3QgZm9yd2FyZCBjZXJ0IGRhdGE6IGlmIHRoZSBzZXJ2aWNlIGl0c2Vs ZiB0ZXJtaW5hdGVzIFRMUyB0aGlzIGlzIGZlYXNpYmxlLCB3ZSBkbyBpdCBmb3Igb3VyIHB1Ymxp Yy1jbG91ZC1ob3N0ZWQgbVRMUy1wcm90ZWN0ZWQgQVBJcy4gSWYgVExTIHRlcm1pbmF0aW9uIGlz IHByb3ZpZGVkIGJ5IGEgY29tcG9uZW50IHJ1biBieSB0aGUgY2xvdWQgcHJvdmlkZXIsIHRoZSBx dWVzdGlvbiBpczogaXMgdGhpcyBjb21wb25lbnQgYWJsZSB0byBmb3J3YXJkIHRoZSBjbGllbnQg Y2VydGlmaWNhdGUgdG8gdGhlIHNlcnZpY2U/IElmIG5vdCwgd2ViIGFwcHMgdXNpbmcgY2VydHMg Zm9yIGF1dGhlbnRpY2F0aW9uIGNhbm5vdCBiZSBzdXBwb3J0ZWQgc3RyYWlnaHR3YXkgYnkgdGhl IGNsb3VkIHByb3ZpZGVyLiBBbnkgaW5zaWdodHM/DQoNCiAgICA+IEknbSBndWVzc2luZyB0aGF0 J3MgYmVjYXVzZSB3ZSdyZSBub3Qgb24gdGhlIHNhbWUgcGFnZSByZWdhcmRpbmcgdXNlIGNhc2Vz LCBzbyBhbGxvdyBtZSB0byBjbGVhcmx5IHN0YXRlIG1pbmU6DQoNCiAgICBJIHRoaW5rIHdlIGFy ZSwgd2UgYXJlIGp1c3QgZm9jdXNpbmcgb24gZGlmZmVyZW50IGVuZHMgb2YgdGhlIFRMUyB0dW5u ZWwuIE15IGZvY3VzIGlzIG9uIHRoZSBzZXJ2aWNlIHByb3ZpZGVy4oCZcyBzaWRlLCBlc3AuIHB1 YmxpYyBjbG91ZCBob3N0aW5nLCB3aGVyZWFzIHlvdSBhcmUgZm9jdXNpbmcgb24gY2xpZW50IHNp ZGUgVExTIHRlcm1pbmF0aW5nIHByb3hpZXMuDQoNCiAgICA+DQogICAgPiBUaGUgdXNlIGNhc2Ug SSBhbSBjb25jZXJuZWQgd2l0aCBpcyByZXF1ZXN0cyBiZXR3ZWVuIHNlcnZpY2VzIHdoZXJlIGVu ZC10by1lbmQgVExTIGNhbm5vdCBiZSBndWFyYW50ZWVkLiBGb3IgZXhhbXBsZSwgYW4gZW50ZXJw cmlzZSBzZXJ2aWNlIHJ1bm5pbmcgb24tcHJlbWlzZSwgY29tbXVuaWNhdGluZyB3aXRoIGEgc2Vy dmljZSBpbiB0aGUgY2xvdWQsIHdoZXJlIHRoZSBlbnRlcnByaXNlJ3Mgb3V0Ym91bmQgdHJhZmZp YyBpcyByb3V0ZWQgdGhyb3VnaCBhIFRMUyBJbnNwZWN0aW9uIChUTFNJKSBhcHBsaWFuY2UuIFRo ZSBUTFNJIGFwcGxpYW5jZSBzaXRzIGluIHRoZSBtaWRkbGUgb2YgdGhlIGNvbW11bmljYXRpb24s IHRlcm1pbmF0aW5nIHRoZSBUTFMgc2Vzc2lvbiBlc3RhYmxpc2hlZCBieSB0aGUgb24tcHJlbWlz ZSBzZXJ2aWNlIGFuZCBlc3RhYmxpc2hpbmcgYSBzZXBhcmF0ZSBUTFMgY29ubmVjdGlvbiB3aXRo IHRoZSBjbG91ZCBzZXJ2aWNlLg0KICAgID4NCiAgICA+IEluIHRoaXMga2luZCBvZiBlbnZpcm9u bWVudCwgdGhlcmUgaXMgbm8gZW5kLXRvLWVuZCBUTFMgY29ubmVjdGlvbiBiZXR3ZWVuIG9uLXBy ZW1pc2Ugc2VydmljZSBhbmQgY2xvdWQgc2VydmljZSwgYW5kIGl0IGlzIHZlcnkgdW5saWtlbHkg dGhhdCB0aGUgVExTSSBhcHBsaWFuY2UgaXMgY29uZmlndXJhYmxlIGVub3VnaCB0byBzdXBwb3J0 IFRMUy1iYXNlZCBzZW5kZXItY29uc3RyYWludCBtZWNoYW5pc21zIHdpdGhvdXQgc2lnbmlmaWNh bnRseSBjb21wcm9taXNpbmcgb24gdGhlIHNjb3BlIG9mICJzZW5kZXIiIChlLmcuLCAidGhpcyBz ZXJ2aWNlIGF0IHRoaXMgZW50ZXJwcmlzZSIgYmVjb21lcyAidGhpcyBlbnRlcnByaXNl4oCdKS4N Cg0KICAgIEnigJltIG5vdCBmYW1pbGlhciB3aXRoIHRoZXNlIGtpbmQgb2YgcHJveGllcywgYnV0 IGhhcHB5IHRvIGxlYXJuIG1vcmUgYW5kIHRvIGRpc2N1c3MgcG90ZW50aWFsIHNvbHV0aW9ucy4N Cg0KICAgIEhlcmUgYXJlIHNvbWUgcXVlc3Rpb25zOg0KICAgIC0gSGF2ZSB5b3Ugc2VlbiB0aGlz IGtpbmQgb2YgcHJveGllcyBpbnRlcmNlcHRpbmcgdGhlIGNvbm5lY3Rpb24gZnJvbSBvbi1wcmVt IHNlcnZpY2UgZGVwbG95bWVudHMgdG8gc2VydmljZSBwcm92aWRlcj8gSeKAmW0gYXNraW5nIGJl Y2F1c2UgSSB0aG91Z2h0IHRoZSBtYWluIHVzZSBjYXNlIHdhcyB0byBpbnRlcmNlcHQgZW1wbG95 ZWVzIFBDIGludGVybmV0IHRyYWZmaWMuDQogICAgLSBBcmUgeW91IHNheWluZyB0aGlzIGtpbmQg b2YgcHJveHkgZG9lcyBub3Qgc3VwcG9ydCBtdXR1YWwgVExTIGF0IGFsbD8gQXQgbGVhc3QgdGhl b3JldGljYWxseSwgdGhlIHByb3h5IGNvdWxkIGNvbWJpbmUgc291cmNlIGFuZCBkZXN0aW5hdGlv biB0byBzZWxlY3QgYSBjZXJ0L2tleSBwYWlyIHRvIHVzZSBmb3Igb3V0Ym91bmQgVExTIGNsaWVu dCBhdXRoZW50aWNhdGlvbi4NCg0KICAgID4gRXZlbiBpZiBpdCBpcyBwb3NzaWJsZSwgaXQgaXMg bGlrZWx5IHRvIHJlcXVpcmUgYWR2YW5jZWQgY29uZmlndXJhdGlvbiB0aGF0IGlzIG5vbi10cml2 aWFsIGZvciBhZG1pbmlzdHJhdG9ycyB0byBkZXBsb3kuIEl0J3Mgbm8gbG9uZ2VyIGFzIHNpbXBs ZSBhcyB0aGUgZGV2ZWxvcGVyIHBhc3NpbmcgYSBzZWxmLXNpZ25lZCBjZXJ0aWZpY2F0ZSB0byB0 aGUgSFRUUCBzdGFjay4NCg0KICAgIEkgYWdyZWUuIENlcnQgYmluZGluZyBpcyBlc3RhYmxpc2hl ZCBpbiBPQXV0aCBwcm90b2NvbCBtZXNzYWdlcywgd2hpY2ggd291bGQgcmVxdWlyZSB0aGUgYXBw bGlhbmNlIHRvIHVuZGVyc3RhbmQgdGhlIHByb3RvY29sLiBPbiB0aGUgb3RoZXIgaGFuZCwgSSB3 b3VsZCBleHBlY3QgdGhlc2Uga2luZCBvZiBwcm94eSB0byB1bmRlcnN0YW5kIGEgbG90IGFib3V0 IHRoZSBwcm90b2NvbHMgcnVubmluZyB0aHJvdWdoIGl0LCBvdGhlcndpc2UgdGhleSBjYW5ub3Qg ZnVsZmlsIHRoZWlyIHRhc2sgb2YgaW5zcGVjdGluZyB0aGlzIHRyYWZmaWMuDQoNCiAgICBiZXN0 IHJlZ2FyZHMsDQogICAgVG9yc3Rlbi4NCg0KDQoNCiAgICA+DQogICAgPiDigJMNCiAgICA+IEFu bmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCiAgICA+IEFXUyBJZGVudGl0eQ0KICAgID4NCiAgICA+ DQogICAgPiBPbiAxMS8yMy8xOSwgOTo1MCBBTSwgIlRvcnN0ZW4gTG9kZGVyc3RlZHQiIDx0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3cm90 ZToNCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+Pj4+Pj4+Pj4gT24gMjMuIE5vdiAyMDE5LCBh dCAwMDozNCwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208 bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiB3cm90ZToNCiAgICA+Pj4+Pj4+Pj4gaG93IGFy ZSBjb29raWVzIHByb3RlY3RlZCBmcm9tIGxlYWthZ2UsIHJlcGxheSwgaW5qZWN0aW9uIGluIGEg c2V0dXAgbGlrZSB0aGlzPw0KICAgID4+IFRoZXkgYXJlbuKAmXQuDQogICAgPg0KICAgID4gVGhh dHMgdmVyeSBpbnRlcmVzdGluZyB3aGVuIGNvbXBhcmVkIHRvIHdoYXQgd2UgYXJlIGRpc2N1c3Np bmcgd2l0aCByZXNwZWN0IHRvIEFQSSBzZWN1cml0eS4NCiAgICA+DQogICAgPiBJdCBlZmZlY3Rp dmVseSBtZWFucyBhbnlvbmUgYWJsZSB0byBjYXB0dXJlIGEgc2Vzc2lvbiBjb29raWUsIGUuZy4g YmV0d2VlbiBUTFMgdGVybWluYXRpb24gcG9pbnQgYW5kIGFwcGxpY2F0aW9uLCBieSB3YXkgb2Yg YW4gSFRNTCBpbmplY3Rpb24sIG9yIGFueSBvdGhlciBzdWl0YWJsZSBhdHRhY2sgaXMgYWJsZSB0 byBpbXBlcnNvbmF0ZSBhIGxlZ2l0aW1hdGUgdXNlciBieSBpbmplY3RpbmcgdGhlIGNvb2tpZShz KSBpbiBhbiBhcmJpdHJhcnkgdXNlciBhZ2VudC4gVGhlIGltcGFjdCBvZiBzdWNoIGFuIGF0dGFj ayBtaWdodCBiZSBldmVuIHdvcnNlIHRoYW4gYWJ1c2luZyBhbiBhY2Nlc3MgdG9rZW4gZ2l2ZW4g dGhlICh0eXBpY2FsbHkpIGJyb2FkIHNjb3BlIG9mIGEgc2Vzc2lvbi4NCiAgICA+DQogICAgPiBU TFMtYmFzZWQgbWV0aG9kcyBmb3Igc2VuZGVyIGNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMsIGlu IGNvbnRyYXN0LCBwcmV2ZW50IHRoaXMgdHlwZSBvZiByZXBsYXksIGV2ZW4gaWYgdGhlIHJlcXVl c3RzIGFyZSBwcm90ZWN0ZWQgYmV0d2VlbiBjbGllbnQgYW5kIFRMUyB0ZXJtaW5hdGluZyBwcm94 eSwgb25seS4gRW5zdXJpbmcgdGhlIGF1dGhlbnRpY2l0eSBvZiB0aGUgY2xpZW50IGNlcnRpZmlj YXRlIHdoZW4gZm9yd2FyZGVkIGZyb20gVExTIHRlcm1pbmF0aW5nIHByb3h5IHRvIHNlcnZpY2Us IGUuZy4gdGhyb3VnaCBhbm90aGVyIGF1dGhlbnRpY2F0ZWQgVExTIGNvbm5lY3Rpb24sIHdpbGwg ZXZlbiBwcmV2ZW50IGluamVjdGlvbiB3aXRoaW4gdGhlIGRhdGEgY2VudGVyL2Nsb3VkIGVudmly b25tZW50Lg0KICAgID4NCiAgICA+IEkgY29tZSB0byB0aGUgY29uY2x1c2lvbiB0aGF0IHdlIGFs cmVhZHkgaGF2ZSB0aGUgbWVjaGFuaXNtIGF0IGhhbmQgdG8gaW1wbGVtZW50IEFQSXMgd2l0aCBh IGNvbnNpZGVyYWJsZSBoaWdoZXIgc2VjdXJpdHkgbGV2ZWwgdGhhbiB3aGF0IGlzIGFjY2VwdGVk IHRvZGF5IGZvciB3ZWIgYXBwbGljYXRpb25zLiBTbyB3aGF0IHByb2JsZW0gZG8gd2Ugd2FudCB0 byBzb2x2ZT8NCiAgICA+DQogICAgPj4gQnV0IG15IHByaW1hcnkgY29uY2VybiBoZXJlIGlzbid0 IHdlYiBicm93c2VyIHRyYWZmaWMsIGl0J3MgY2FsbHMgZnJvbSBzZXJ2aWNlcy9hcHBzIHJ1bm5p bmcgaW5zaWRlIGEgY29ycG9yYXRlIG5ldHdvcmsgdG8gc2VydmljZXMgb3V0c2lkZSBhIGNvcnBv cmF0ZSBuZXR3b3JrIChlLmcuLCBzZXJ2aWNlLXRvLXNlcnZpY2UgQVBJIGNhbGxzIHRoYXQgcGFz cyB0aHJvdWdoIGEgY29ycG9yYXRlIFRMUyBnYXRld2F5KS4NCiAgICA+DQogICAgPiBDYW4geW91 IHBsZWFzZSBkZXNjcmliZSB0aGUgY2hhbGxlbmdlcyBhcmlzaW5nIGluIHRoZXNlIHNldHRpbmdz PyBJIGFzc3VtZSB0aG9zZSBwcm94aWVzIHdvbuKAmXQgc3VwcG9ydCBDT05ORUNUIHN0eWxlIHBh c3MgdGhyb3VnaCBvdGhlcndpc2Ugd2Ugd291bGRu4oCZdCB0YWxrIGFib3V0IHRoZW0uDQogICAg Pg0KICAgID4+PiBUaGF04oCZcyBhIHRvdGFsbHkgdmFsaWQgcG9pbnQuIEJ1dCBhZ2Fpbiwgc3Vj aCBhIHNvbHV0aW9uIG1ha2VzIHRoZSBsaWZlIG9mIGNsaWVudCBkZXZlbG9wZXJzIGhhcmRlci4N CiAgICA+Pj4gSSBwZXJzb25hbGx5IHRoaW5rLCB3ZSBhcyBhIGNvbW11bml0eSBuZWVkIHRvIHVu ZGVyc3RhbmQgdGhlIHByb3MgYW5kIGNvbnMgb2YgYm90aCBhcHByb2FjaGVzLiBJIGFsc28gdGhp bmsgd2UgaGF2ZSBub3QgZXZlbiBjb21lIGNsb3NlIHRvIHRoaXMgcG9pbnQsIHdoaWNoLCBpbiBt eSBvcHRpb24sIGlzIHRoZSBwcmVyZXF1aXNpdGUgZm9yIG1ha2luZyBpbmZvcm1lZCBkZWNpc2lv bnMuDQogICAgPj4gQWdyZWVkLiBJdCdzIGNsZWFyIHRoYXQgdGhlcmUgYXJlIGEgbnVtYmVyIG9m IHBhcnRpZXMgY29taW5nIGF0IHRoaXMgZnJvbSBhIG51bWJlciBvZiBkaWZmZXJlbnQgZGlyZWN0 aW9ucywgYW5kIHRoYXQncyBjb2xvcmluZyBvdXIgcGVyY2VwdGlvbnMuIFRoYXQncyB3aHkgSSB0 aGluayB3ZSBuZWVkIHRvIG5haWwgZG93biB0aGUgc2NvcGUgb2Ygd2hhdCB3ZSdyZSB0cnlpbmcg dG8gc29sdmUgd2l0aCBEUG9QIGJlZm9yZSB3ZSBjYW4gaGF2ZSBhIHByb2R1Y3RpdmUgY29udmVy c2F0aW9uIGhvdyBpdCBzaG91bGQgd29yay4NCiAgICA+DQogICAgPiBXZSB3aWxsIGRvIHNvLg0K ICAgID4NCiAgICA+PiDigJMNCiAgICA+PiBBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQogICAg Pj4gQVdTIElkZW50aXR5DQogICAgPj4gT24gMTEvMjIvMTksIDEwOjUxIFBNLCAiVG9yc3RlbiBM b2RkZXJzdGVkdCIgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldD4+IHdyb3RlOg0KICAgID4+Pj4gT24gMjIuIE5vdiAyMDE5LCBhdCAyMjoxMiwg UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5p ZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQogICAg Pj4+IFRoZSBzZXJ2aWNlIHByb3ZpZGVyIGRvZXNuJ3Qgb3duIHRoZSBlbnRpcmUgY29ubmVjdGlv bi4gVGhleSBoYXZlIG5vIGNvbnRyb2wgb3ZlciBjb3Jwb3JhdGUgb3IgZ292ZXJubWVudCBUTFMg Z2F0ZXdheXMsIG9yIG90aGVyIHRlcm1pbmF0b3JzIHRoYXQgbWlnaHQgZXhpc3Qgb24gdGhlIGNs aWVudCdzIHNpZGUuIEluIGxhcmdlciBvcmdhbml6YXRpb25zLCBvciB3aGVuIGNsb3VkIGhvc3Rp bmcgaXMgaW52b2x2ZWQsIHRoZSBzZXJ2aWNlIHRlYW0gbWF5IG5vdCBldmVuIG93biBhbGwgdGhl IGhvcHMgb24gdGhlaXIgc2lkZS4NCiAgICA+PiBob3cgYXJlIGNvb2tpZXMgcHJvdGVjdGVkIGZy b20gbGVha2FnZSwgcmVwbGF5LCBpbmplY3Rpb24gaW4gYSBzZXR1cCBsaWtlIHRoaXM/DQogICAg Pj4+IFdoaWxlIHByZXN1bWFibHkgdGhleSBoYXZlIHNvbWUgdHJ1c3QgaW4gdGhlbSwgcHJvdGVj dGlvbiBhZ2FpbnN0IGxlYWtlZCBiZWFyZXIgdG9rZW5zIGlzIGFuIGF0dHJhY3RpdmUgZGVmZW5z ZS1pbi1kZXB0aCBtZWFzdXJlLg0KICAgID4+IFRoYXTigJlzIGEgdG90YWxseSB2YWxpZCBwb2lu dC4gQnV0IGFnYWluLCBzdWNoIGEgc29sdXRpb24gbWFrZXMgdGhlIGxpZmUgb2YgY2xpZW50IGRl dmVsb3BlcnMgaGFyZGVyLg0KICAgID4+IEkgcGVyc29uYWxseSB0aGluaywgd2UgYXMgYSBjb21t dW5pdHkgbmVlZCB0byB1bmRlcnN0YW5kIHRoZSBwcm9zIGFuZCBjb25zIG9mIGJvdGggYXBwcm9h Y2hlcy4gSSBhbHNvIHRoaW5rIHdlIGhhdmUgbm90IGV2ZW4gY29tZSBjbG9zZSB0byB0aGlzIHBv aW50LCB3aGljaCwgaW4gbXkgb3B0aW9uLCBpcyB0aGUgcHJlcmVxdWlzaXRlIGZvciBtYWtpbmcg aW5mb3JtZWQgZGVjaXNpb25zLg0KICAgID4+PiDigJMNCiAgICA+Pj4gQW5uYWJlbGxlIFJpY2hh cmQgQmFja21hbg0KICAgID4+PiBBV1MgSWRlbnRpdHkNCiAgICA+Pj4gT24gMTEvMjIvMTksIDk6 MzcgUE0sICJPQXV0aCBvbiBiZWhhbGYgb2YgVG9yc3RlbiBMb2RkZXJzdGVkdCIgPG9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiB0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGxvZGRl cnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KICAgID4+Pj4gT24gMjIuIE5vdiAy MDE5LCBhdCAyMToyMSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1h em9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3Jn Pj4gd3JvdGU6DQogICAgPj4+PiBUaGUgZGljaG90b215IG9mICJUTFMgd29ya2luZyIgYW5kICJU TFMgZmFpbGVkIiBvbmx5IGFwcGxpZXMgdG8gYSBzaW5nbGUgVExTIGNvbm5lY3Rpb24uIEluIG5v bi1lbmQtdG8tZW5kIFRMUyBlbnZpcm9ubWVudHMsIGVhY2ggVExTIHRlcm1pbmF0b3IgYmV0d2Vl biBjbGllbnQgYW5kIFJTIGludHJvZHVjZXMgYWRkaXRpb25hbCB0b2tlbiBsZWFrYWdlL2V4Zmls dHJhdGlvbiByaXNrLCBpcnJlc3BlY3RpdmUgb2YgdGhlIHF1YWxpdHkgb2YgdGhlIFRMUyBjb25u ZWN0aW9ucyB0aGVtc2VsdmVzLiBFYWNoIHRlcm1pbmF0b3IgYWxzbyBpbnRyb2R1Y2VzIGNvbXBs ZXhpdHkgZm9yIGltcGxlbWVudGluZyBtVExTLCBUb2tlbiBCaW5kaW5nLCBvciBhbnkgb3RoZXIg VExTLWJhc2VkIHNlbmRlciBjb25zdHJhaW50IHNvbHV0aW9uLCB3aGljaCBtZWFucyBkZXZlbG9w ZXJzIHdpdGggbm9uLWVuZC10by1lbmQgVExTIHVzZSBjYXNlcyB3aWxsIGJlIG1vcmUgbGlrZWx5 IHRvIHR1cm4gdG8gRFBvUC4NCiAgICA+Pj4gVGhlIHBvaW50IGlzIHdlIGFyZSB0YWxraW5nIGFi b3V0IGRpZmZlcmVudCBkZXZlbG9wZXJzIGhlcmUuIFRoZSBjbGllbnQgZGV2ZWxvcGVyIGRvZXMg bm90IG5lZWQgdG8gY2FyZSBhYm91dCB0aGUgY29ubmVjdGlvbiBiZXR3ZWVuIHByb3h5IGFuZCBz ZXJ2aWNlLiBTaGUgcmVsaWVzIG9uIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIHRvIGdldCBpdCByaWdo dC4gU28gdGhlIGRldmVsb3BlcnMgKG9yIERldk9wcyBvciBhZG1pbnMpIG9mIHRoZSBzZXJ2aWNl IHByb3ZpZGVyIG5lZWQgdG8gZW5zdXJlIGVuZCB0byBlbmQgc2VjdXJpdHkuIEFuZCBpZiB0aGUg cGF0aCBpcyBzZWN1cmVkIG9uY2UsIGl0IHdpbGwgd29yayBmb3IgYWxsIGNsaWVudHMuDQogICAg Pj4+PiBJZiBEUG9QIGlzIGludGVuZGVkIHRvIGFkZHJlc3MgImNhc2VzIHdoZXJlIG5laXRoZXIg bVRMUyBub3IgT0F1dGggVG9rZW4gQmluZGluZyBhcmUgYXZhaWxhYmxlIiBbMV0sIHRoZW4gaXQg c2hvdWxkIGFkZHJlc3MgdGhpcyByaXNrIG9mIHRva2VuIGxlYWthZ2UgYmV0d2VlbiBjbGllbnQg YW5kIFJTLiBJZiBvbiB0aGUgb3RoZXIgaGFuZCBEUG9QIGlzIG9ubHkgaW50ZW5kZWQgdG8gc3Vw cG9ydCB0aGUgU1BBIHVzZSBjYXNlIGFuZCBhc3N1bWVzIHRoZSB1c2Ugb2YgZW5kLXRvLWVuZCBU TFMsIHRoZW4gdGhlIGRvY3VtZW50IHNob3VsZCBiZSB1cGRhdGVkIHRvIHJlZmxlY3QgdGhhdC4N CiAgICA+Pj4gSSBhZ3JlZS4NCiAgICA+Pj4+IFsxXTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWZldHQtb2F1dGgtZHBvcC0wMyNzZWN0aW9uLTENCiAgICA+Pj4+IOKAkw0KICAg ID4+Pj4gQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KICAgID4+Pj4gQVdTIElkZW50aXR5DQog ICAgPj4+PiBPbiAxMS8yMi8xOSwgODoxNyBQTSwgIk9BdXRoIG9uIGJlaGFsZiBvZiBUb3JzdGVu IExvZGRlcnN0ZWR0IiA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIHRvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMu aWV0Zi5vcmc8bWFpbHRvOjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6 DQogICAgPj4+PiBIaSBOZWlsLA0KICAgID4+Pj4+IE9uIDIyLiBOb3YgMjAxOSwgYXQgMTg6MDgs IE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPG1haWx0bzpuZWlsLm1hZGRl bkBmb3JnZXJvY2suY29tPj4gd3JvdGU6DQogICAgPj4+Pj4gT24gMjIgTm92IDIwMTksIGF0IDA3 OjUzLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJj LmlldGYub3JnPG1haWx0bzo0MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZz4+IHdyb3Rl Og0KICAgID4+Pj4+Pj4gT24gMjIuIE5vdiAyMDE5LCBhdCAxNToyNCwgSnVzdGluIFJpY2hlciA8 anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCiAgICA+Pj4+ Pj4+IEnigJltIGdvaW5nIHRvICsxIERpY2sgYW5kIEFubmFiZWxsZeKAmXMgcXVlc3Rpb24gYWJv dXQgdGhlIHNjb3BlIGhlcmUuIFRoYXQgd2FzIHRoZSBvbmUgbWFqb3IgdGhpbmcgdGhhdCBzdHJ1 Y2sgbWUgZHVyaW5nIHRoZSBEUG9QIGRpc2N1c3Npb25zIGluIFNpbmdhcG9yZSB5ZXN0ZXJkYXk6 IHdlIGRvbuKAmXQgc2VlbSB0byBhZ3JlZSBvbiB3aGF0IERQb1AgaXMgZm9yLiBTb21lIChpbmNs dWRpbmcgdGhlIGF1dGhvcnMsIGl0IHNlZW1zKSBzZWUgaXQgYXMgYSBxdWljayBwb2ludC1zb2x1 dGlvbiB0byBhIHNwZWNpZmljIHVzZSBjYXNlLiBPdGhlcnMgc2VlIGl0IGFzIGEgZ2VuZXJhbCBQ b1AgbWVjaGFuaXNtLg0KICAgID4+Pj4+Pj4gSWYgaXTigJlzIHRoZSBmb3JtZXIsIHRoZW4gaXQg c2hvdWxkIGJlIGV4cGxpY2l0bHkgdGllZCB0byBvbmUgc3BlY2lmaWMgc2V0IG9mIHRoaW5ncy4g SWYgaXTigJlzIHRoZSBsYXR0ZXIsIHRoZW4gaXQgbmVlZHMgdG8gYmUgZXhwYW5kZWQuDQogICAg Pj4+Pj4+IGFzIGEgY28tYXV0aG9yIG9mIHRoZSBEUG9QIGRyYWZ0IEkgc3RhdGUgYWdhaW4gd2hh dCBJIHNhaWQgeWVzdGVyZGF5OiBEUG9QIGlzIGEgbWVjaGFuaXNtIGZvciBzZW5kZXItY29uc3Ry YWluaW5nIGFjY2VzcyB0b2tlbnMgc2VudCBmcm9tIFNQQXMgb25seS4gVGhlIHRocmVhdCB0byBi ZSBwcmV2ZW50ZWQgaXMgdG9rZW4gcmVwbGF5Lg0KICAgID4+Pj4+IEkgdGhpbmsgdGhlIHBocmFz ZSAidG9rZW4gcmVwbGF5IiBpcyBhbWJpZ3VvdXMuIFRyYWRpdGlvbmFsbHkgaXQgcmVmZXJzIHRv IGFuIGF0dGFja2VyIGJlaW5nIGFibGUgdG8gY2FwdHVyZSBhIHRva2VuIChvciB3aG9sZSByZXF1 ZXN0cykgaW4gdXNlIGFuZCB0aGVuIHJlcGxheSBpdCBhZ2FpbnN0IHRoZSBzYW1lIFJTLiBUaGlz IGlzIGFscmVhZHkgcHJvdGVjdGVkIGFnYWluc3QgYnkgdGhlIHVzZSBvZiBub3JtYWwgVExTIG9u IHRoZSBjb25uZWN0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIFJTLiBJIHRoaW5rIGlu c3RlYWQgeW91IGFyZSByZWZlcnJpbmcgdG8gYSBtYWxpY2lvdXMvY29tcHJvbWlzZWQgUlMgcmVw bGF5aW5nIHRoZSB0b2tlbiB0byBhIGRpZmZlcmVudCBSUyAtIHdoaWNoIGhhcyBtb3JlIG9mIHRo ZSBmbGF2b3VyIG9mIGEgbWFuIGluIHRoZSBtaWRkbGUgYXR0YWNrIChvZiB0aGUgcGhpc2hpbmcg a2luZCkuDQogICAgPj4+PiBJIHdvdWxkIGFyZ3VlIFRMUyBiYXNpY2FsbHkgcHJldmVudHMgbGVh a2FnZSBhbmQgbm90IHJlcGxheS4gVGhlIHRocmVhdHMgd2UgdHJ5IHRvIGNvcGUgd2l0aCBjYW4g YmUgZm91bmQgaW4gdGhlIFNlY3VyaXR5IEJDUC4gVGhlcmUgYXJlIG11bHRpcGxlIHdheXMgYWNj ZXNzIHRva2VucyBjYW4gbGVhaywgaW5jbHVkaW5nIHJlZmVycmVyIGhlYWRlcnMsIG1peC11cCwg b3BlbiByZWRpcmVjdGlvbiwgYnJvd3NlciBoaXN0b3J5LCBhbmQgYWxsIHNvcnRzIG9mIGFjY2Vz cyB0b2tlbiBsZWFrYWdlIGF0IHRoZSByZXNvdXJjZSBzZXJ2ZXINCiAgICA+Pj4+IFBsZWFzZSBo YXZlIGEgbG9vayBhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0 aC1zZWN1cml0eS10b3BpY3MtMTMjc2VjdGlvbi00Lg0KICAgID4+Pj4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTEzI3NlY3Rpb24t NC44IGFsc28gaGFzIGFuIGV4dGVuc2l2ZSBkaXNjdXNzaW9uIG9mIHBvdGVudGlhbCBjb3VudGVy IG1lYXN1cmVzLCBpbmNsdWRpbmcgYXVkaWVuY2UgcmVzdHJpY3RlZCBhY2Nlc3MgdG9rZW5zIGFu ZCBhIGNvbmNsdXNpb24gdG8gcmVjb21tZW5kIHNlbmRlciBjb25zdHJhaW5lZCBhY2Nlc3MgdG9r ZW5zIG92ZXIgb3RoZXIgbWVjaGFuaXNtcy4NCiAgICA+Pj4+PiBCdXQgaWYgdGhhdCdzIHRoZSBj YXNlIHRoZW4gdGhlcmUgYXJlIG11Y2ggc2ltcGxlciBkZWZlbmNlcyB0aGFuIHRob3NlIHByb3Bv c2VkIGluIHRoZSBjdXJyZW50IGRyYWZ0Og0KICAgID4+Pj4+IDEuIEdldCBzZXBhcmF0ZSBhY2Nl c3MgdG9rZW5zIGZvciBlYWNoIFJTIHdpdGggY29ycmVjdCBhdWRpZW5jZSBhbmQgc2NvcGVzLiBU aGUgY29uc2Vuc3VzIGFwcGVhcnMgdG8gYmUgdGhhdCB0aGlzIGlzIGhhcmQgdG8gZG8gaW4gc29t ZSBjYXNlcywgaGVuY2UgdGhlIGRyYWZ0Lg0KICAgID4+Pj4gSG93IG1hbnkgZGVwbG95bWVudHMg ZG8geW91IGtub3cgdGhhdCB0b2RheSBhcmUgYWJsZSB0byBpc3N1ZSBSUy1zcGVjaWZpYyBhY2Nl c3MgdG9rZW5zPw0KICAgID4+Pj4gQlRXOiBob3cgd291bGQgeW91IGlkZW50aWZ5IHRoZSBSUz8N CiAgICA+Pj4+IEkgYWdyZWUgdGhhdCB3b3VsZCBiZSBhbiBhbHRlcm5hdGl2ZSBhbmQgSeKAmW0g YSBncmVhdCBmYW4gb2Ygc3VjaCB0b2tlbnMgKGFuZCB1c2VkIHRoZW0gYSBsb3QgYXQgRGV1dHNj aGUgVGVsZWtvbSkgYnV0IGluIG15IHBlcmNlcHRpb24gdGhpcyBwYXR0ZXJuIG5lZWRzIHN0aWxs IHRvIGJlIGVzdGFibGlzaGVkIGluIHRoZSBtYXJrZXQuIE1vcmVvdmVyLCB0aGV5IGJhc2ljYWxs eSBwcm90ZWN0IGZyb20gYSByb3VnaCBSUyAoaWYgdGhlIFVSTCBpcyB1c2VkIGFzIGF1ZGllbmNl KSByZXBsYXlpbmcgdGhlIHRva2VuIHNvbWVwbGFjZSBlbHNlLCBidXQgdGhleSBkbyBub3QgcHJv dGVjdCBmcm9tIGFsbCBvdGhlciBraW5kcyBvZiBsZWFrYWdlL3JlcGxheSAoZS5nLiBsb2cgZmls ZXMpLg0KICAgID4+Pj4+IDIuIE1ha2UgdGhlIERQb1AgdG9rZW4gYmUgYSBzaW1wbGUgSldUIHdp dGggYW4gImlhdCIgYW5kIHRoZSBvcmlnaW4gb2YgdGhlIFJTLiBUaGlzIHN0b3BzIHRoZSB0b2tl biBiZWluZyByZXVzZWQgZWxzZXdoZXJlIGJ1dCB0aGUgY2xpZW50IGNhbiByZXVzZSBpdCAocmVw bGF5IGl0KSBmb3IgbWFueSByZXF1ZXN0cy4uDQogICAgPj4+Pj4gMy4gSXNzdWUgYSBtYWNhcm9v bi1iYXNlZCBhY2Nlc3MgdG9rZW4gYW5kIHRoZSBjbGllbnQgY2FuIGFkZCBhIGNvcnJlY3QgYXVk aWVuY2UgYW5kIHNjb3BlIHJlc3RyaWN0aW9ucyBhdCB0aGUgcG9pbnQgb2YgdXNlLg0KICAgID4+ Pj4gV2h5IGlzIHRoaXMgbmVlZGVkIGlmIHRoZSBhY2Nlc3MgdG9rZW4gaXMgYWxyZWFkeSBhdWRp ZW5jZSByZXN0cmljdGVkPyBPciBkbyB5b3UgcHJvcG9zZSB0aGlzIGFzIGFsdGVybmF0aXZlPw0K ICAgID4+Pj4+IFByb3RlY3RpbmcgYWdhaW5zdCB0aGUgZmlyc3Qga2luZCBvZiByZXBsYXkgYXR0 YWNrcyBvbmx5IGJlY29tZXMgYW4gaXNzdWUgaWYgd2UgYXNzdW1lIHRoZSBwcm90ZWN0aW9ucyBp biBUTFMgaGF2ZSBmYWlsZWQuIEJ1dCBpZiBEUG9QIGlzIG9ubHkgaW50ZW5kZWQgZm9yIGNhc2Vz IHdoZXJlIG1UTFMgY2FuJ3QgYmUgdXNlZCwgaXQgc2hvdWxkbid0IGhhdmUgdG8gcHJvdGVjdCBh Z2FpbnN0IGEgc3Ryb25nZXIgdGhyZWF0IG1vZGVsIGluIHdoaWNoIHdlIGFzc3VtZSB0aGF0IFRM UyBzZWN1cml0eSBoYXMgYmVlbiBsb3N0Lg0KICAgID4+Pj4gSSBhZ3JlZS4NCiAgICA+Pj4+IGJl c3QgcmVnYXJkcywNCiAgICA+Pj4+IFRvcnN0ZW4uDQogICAgPj4+Pj4gLS0gTmVpbA0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_6C747BDA478A4E5F94388D766520DB27amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <8CEA96C82037294DB702FD26412E6055@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 dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xp c3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eToz NDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206 MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0OyZndDsgVGhlIGRvY3VtZW50YXRpb24gZm9yIFN5bWFudGVjJ3MgU1NMIFZp c2liaWxpdHkgcHJvZHVjdCBbMV0gaW5kaWNhdGVzIHRoYXQgc2Vzc2lvbnMgdXNpbmcgY2xpZW50 IGNlcnRpZmljYXRlcyB3aWxsIGJlIHJlamVjdGVkIHVubGVzcyB0aGV5IGFyZSBleGVtcHRlZCBi YXNlZCBvbiBkZXN0aW5hdGlvbiB3aGl0ZWxpc3RpbmcgKHdoaWNoIGlzIHByb2JsZW1hdGljIHdo ZW4gdGhlIGRlc3RpbmF0aW9uIG1heQ0KIGJlIGEgZ2VuZXJhbC1wdXJwb3NlIGNsb3VkIHNlcnZp Y2UgcHJvdmlkZXIpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IElzIHRoZXJlIGEgdXNl IGNhc2UgdGhhdCB3b3VsZCByZXF1aXJlIHlvdSB0byBkbyB0aGF0PzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJZiBJIGhhdmUgYSBzZXJ2aWNlIHRoYXQgaXMgaG9z dGVkIG9uIEFXUywgdGhlbiB0aGUgZXhjZXB0aW9uIHdvdWxkIGJlIGZvciBteSBzZXJ2aWNlLCBu b3QgZm9yIEFXUyBpbiBnZW5lcmFsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMuIENvbnNp ZGVyIGFuIG9uLXByZW1pc2Ugc2VydmljZSB0aGF0IHVzZXMgYSB2ZW5kb3Igc2VydmljZSBob3N0 ZWQgaW4gdGhlIGNsb3VkLiBXaGlsZSBzb21lIFNhYVMgQVBJIGVuZHBvaW50cyBhcmUgdGVuYW50 LXNwZWNpZmljLCBtYW55IChtb3N0PykgYXJlIG5vdCwgbWVhbmluZyBmcm9tIGEgZGVzdGluYXRp b24gcGVyc3BlY3RpdmUgdGhlIGVudGVycHJpc2XigJlzIGxlZ2l0aW1hdGUgdHJhZmZpYyBsb29r cw0KIGp1c3QgbGlrZSBxdWVzdGlvbmFibGUgdHJhZmZpYy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5B V1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJv bTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ UmlmYWF0IFNoZWtoLVl1c2VmICZsdDtyaWZhYXQuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+ RGF0ZTogPC9iPlR1ZXNkYXksIERlY2VtYmVyIDMsIDIwMTkgYXQgNToyMSBBTTxicj4NCjxiPlRv OiA8L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5h QGFtYXpvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5Ub3JzdGVuIExvZGRlcnN0ZWR0ICZsdDt0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCZndDssIG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W1VOVkVSSUZJRUQgU0VOREVSXSBSZTogW09BVVRILVdHXSBb VU5WRVJJRklFRCBTRU5ERVJdIFJlOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWZldHQtb2F1dGgtZHBvcC0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRGVjIDIsIDIwMTkgYXQgNDoz NSBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFp bHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyI+NDBhbWF6b24uY29tQGRtYXJjLmlldGYu b3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZndDsgU2Vz c2lvbiBjb29raWVzIHNlcnZlIHRoZSBzYW1lIHB1cnBvc2UgaW4gd2ViIGFwcHMgYXMgYWNjZXNz IHRva2VucyBmb3IgQVBJcyBidXQgdGhlcmUgYXJlIG11Y2ggbW9yZSB3ZWIgYXBwcyB0aGFuIEFQ SXMuIEkgdXNlIHRoZSBhbmFsb2d5IHRvIGlsbHVzdHJhdGUgdGhhdCBlaXRoZXIgdGhlcmUgYXJl IHNlY3VyaXR5IGlzc3VlcyB3aXRoIGNsb3VkIGRlcGxveW1lbnRzDQogb2Ygd2ViIGFwcHMgb3Ig dGhlIHRlY2huaXF1ZXMgdXNlZCB0byBzZWN1cmUgd2ViIGFwcHMgYXJlIG9rIGZvciBBUElzIGFz IHdlbGwuPGJyPg0KPGJyPg0KJnF1b3Q7U2VjdXJpdHkgaXNzdWVzJnF1b3Q7IGlzIGEgbG9hZGVk IHRlcm0sIGJ1dCBpZiB5b3UgbWVhbiB0aGF0IHRoZXJlIGFyZSBwcmFjdGljYWwgcmlza3MgdGhh dCBhcmUgbm90IGFkZHJlc3NlZCBieSBiZWFyZXIgdG9rZW5zICh3aGV0aGVyIHRoZXkgYmUgc2Vz c2lvbiBjb29raWVzIG9yIGFjY2VzcyB0b2tlbnMpIHRoZW4geWVzLCBJIHRoaW5rIHdlIGJvdGgg YWdyZWUgdGhhdCB0aGVyZSBhcmUuIE90aGVyd2lzZSB3ZSB3b3VsZG4ndCBiZSBkaXNjdXNzaW5n DQogUG9QLCBzZW5kZXItY29uc3RyYWluZWQgdG9rZW5zLCBldGMuIFRMUy1iYXNlZCBzb2x1dGlv bnMgbWl0aWdhdGUgc29tZSByaXNrcywgd2hpbGUgbGVhdmluZyBvdGhlcnMgdW5taXRpZ2F0ZWQu IERlcGVuZGluZyBvbiB5b3VyIHVzZSBjYXNlIGFuZCB0aHJlYXQgbW9kZWwsIHRoZXNlIHJpc2tz IG1heSBvciBtYXkgbm90IHByZXNlbnQgcHJhY3RpY2FsIHRocmVhdHMuIEZvciBteSB1c2UgY2Fz ZXMsIHRoZXkgZG8uPGJyPg0KPGJyPg0KVWx0aW1hdGVseSBJJ2QgbGlrZSB0byBtaXRpZ2F0ZSB0 aGVzZSByaXNrcyBmb3IgYm90aCBzZXJ2aWNlIEFQSXMgYW5kIHdlYiBhcHBsaWNhdGlvbnMuIE15 IGZvY3VzIGlzIG9uIHNlcnZpY2UgQVBJcyBmb3IgYSBjb3VwbGUgcmVhc29uczo8YnI+DQo8YnI+ DQoxLiBJbnRlcm9wZXJhYmlsaXR5IGlzIG1vcmUgaW1wb3J0YW50IHdoZW4gdGhlIHNlbmRlciBh bmQgcmVjaXBpZW50IGFyZW4ndCBuZWNlc3NhcmlseSBvd25lZCBieSBhIHNpbmdsZSBlbnRpdHku IEkgY2FuIGRvIHByb3ByaWV0YXJ5IHRoaW5ncyBpbiBKYXZhU2NyaXB0IGlmIEkgd2FudCB0byBq dXN0IGFzIEkgY2FuIGluIGNsaWVudCBTREtzLCBidXQgdGhpcyBicmVha3MgZG93biBpZiBteSBB UEkgaW1wbGVtZW50cyBhIHN0YW5kYXJkIHByb3RvY29sDQogYW5kIGlzIGV4cGVjdGVkIHRvIHdv cmsgd2l0aCBvZmYtdGhlLXNoZWxmIGNsaWVudHMgYW5kL29yIGltcGxlbWVudGF0aW9ucyBmcm9t IG90aGVyIHZlbmRvcnMuPGJyPg0KPGJyPg0KMi4gV2ViIGFwcGxpY2F0aW9ucyBhcmUganVzdCBh IHNwZWNpYWwgc3Vic2V0IG9mIHNlcnZpY2UgQVBJcyB0aGF0IGhhcHBlbnMgdG8gYmUgYWNjZXNz ZWQgdmlhIGEgYnJvd3Nlci4gQSBzb2x1dGlvbiBmb3Igc2VydmljZSBBUElzIG91Z2h0IHRvIGJl IHJldXNhYmxlIGZvciB3ZWIgYXBwbGljYXRpb25zLCBvciBhdCBsZWFzdCBzZXJ2ZSBhcyBhIGZv dW5kYXRpb24gZm9yIHRoZWlyIHNvbHV0aW9uLjxicj4NCjxicj4NCiZndDsmbmJzcDsgJm5ic3A7 IC0gSGF2ZSB5b3Ugc2VlbiB0aGlzIGtpbmQgb2YgcHJveGllcyBpbnRlcmNlcHRpbmcgdGhlIGNv bm5lY3Rpb24gZnJvbSBvbi1wcmVtIHNlcnZpY2UgZGVwbG95bWVudHMgdG8gc2VydmljZSBwcm92 aWRlcj8gSeKAmW0gYXNraW5nIGJlY2F1c2UgSSB0aG91Z2h0IHRoZSBtYWluIHVzZSBjYXNlIHdh cyB0byBpbnRlcmNlcHQgZW1wbG95ZWVzIFBDIGludGVybmV0IHRyYWZmaWMuPGJyPg0KPGJyPg0K SSdtIHdvcmtpbmcgZnJvbSBzZWNvbmQtaGFuZCBrbm93bGVkZ2UgaGVyZSwgYnV0IGxpa2UgbW9z dCB0aGluZ3MgaW4gdGhlIGVudGVycHJpc2Ugd29ybGQsIGl0IGRlcGVuZHMuIFNlcGFyYXRpbmcg ZW1wbG95ZWUgZGV2aWNlIG91dGJvdW5kIHRyYWZmaWMgZnJvbSBpbnRlcm5hbCBzZXJ2aWNlIG91 dGJvdW5kIHRyYWZmaWMgcmVxdWlyZXMgc29tZSBsZXZlbCBvZiBzb3BoaXN0aWNhdGlvbiwgYmUg aXQgaW4gbmV0d29yayB0b3BvbG9neSwgcm91dGluZw0KIHJ1bGVzLCBvciBjb25maWd1cmF0aW9u IHJ1bGVzIG9uIHRoZSBUTElTIGFwcGxpYW5jZS4gPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZWFoLCBtYW55IG1ham9yIGVudGVy cHJpc2VzIGhhdmUgdGhlc2Uga2luZHMgb2YgaW5zcGVjdGlvbiBzZXJ2aWNlcywgVGFrZSBhIGxv b2sgYXQgdGhlIGZvbGxvd2luZyBleGFtcGxlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuenNjYWxlci5jb20v cmVzb3VyY2VzL2RhdGEtc2hlZXRzL3pzY2FsZXItaW50ZXJuZXQtYWNjZXNzLnBkZiI+aHR0cHM6 Ly93d3cuenNjYWxlci5jb20vcmVzb3VyY2VzL2RhdGEtc2hlZXRzL3pzY2FsZXItaW50ZXJuZXQt YWNjZXNzLnBkZjwvYT4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7ICZuYnNwOyAtIEFyZSB5b3Ugc2F5 aW5nIHRoaXMga2luZCBvZiBwcm94eSBkb2VzIG5vdCBzdXBwb3J0IG11dHVhbCBUTFMgYXQgYWxs Pzxicj4NCjxicj4NCiZndDtGcm9tIHdoYXQgSSB1bmRlcnN0YW5kLCBhdCB0aGUgdmVyeSBsZWFz dCBtVExTIGlzIG5vdCB1bml2ZXJzYWxseSBzdXBwb3J0ZWQuLiBUaGVyZSBtYXkgYmUgc29tZSB2 ZW5kb3JzIHRoYXQgc3VwcG9ydCBpdCwgYnV0IGl0J3Mgbm90IGd1YXJhbnRlZWQuIFRoZSBkb2N1 bWVudGF0aW9uIGZvciBTeW1hbnRlYydzIFNTTCBWaXNpYmlsaXR5IHByb2R1Y3QgWzFdIGluZGlj YXRlcyB0aGF0IHNlc3Npb25zIHVzaW5nIGNsaWVudCBjZXJ0aWZpY2F0ZXMNCiB3aWxsIGJlIHJl amVjdGVkIHVubGVzcyB0aGV5IGFyZSBleGVtcHRlZCBiYXNlZCBvbiBkZXN0aW5hdGlvbiB3aGl0 ZWxpc3RpbmcgPG86cD4NCjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlllcywgdGhhdCBpcyBteSBleHBlcmllbmNlIHRvby4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+KHdoaWNoIGlzIHByb2JsZW1hdGljIHdoZW4gdGhlIGRlc3RpbmF0aW9uIG1heSBiZSBh IGdlbmVyYWwtcHVycG9zZSBjbG91ZCBzZXJ2aWNlIHByb3ZpZGVyKS48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHRoZXJlIGEg dXNlIGNhc2UgdGhhdCB3b3VsZCByZXF1aXJlIHlvdSB0byBkbyB0aGF0PzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgSSBoYXZlIGEgc2Vydmlj ZSB0aGF0IGlzIGhvc3RlZCBvbiBBV1MsIHRoZW4gdGhlIGV4Y2VwdGlvbiB3b3VsZCBiZSBmb3Ig bXkgc2VydmljZSwgbm90IGZvciBBV1MgaW4gZ2VuZXJhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1JpZmFhdDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQomZ3Q7IE9uIHRoZSBvdGhlciBoYW5kLCBJIHdvdWxkIGV4cGVjdCB0aGVzZSBraW5kIG9mIHBy b3h5IHRvIHVuZGVyc3RhbmQgYSBsb3QgYWJvdXQgdGhlIHByb3RvY29scyBydW5uaW5nIHRocm91 Z2ggaXQsIG90aGVyd2lzZSB0aGV5IGNhbm5vdCBmdWxmaWwgdGhlaXIgdGFzayBvZiBpbnNwZWN0 aW5nIHRoaXMgdHJhZmZpYy48YnI+DQo8YnI+DQpNYXliZSwgbWF5YmUgbm90LiBJbiBhbnkgY2Fz ZSB0aGVyZSdzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIHVuZGVyc3RhbmRpbmcgSFRUUCBvciBTTVRQ IG9yIFAyUC1wcm90b2NvbC1kdS1qb3VyIGFuZCB1bmRlcnN0YW5kaW5nIHRoZSBhcHBsaWNhdGlv bi1sZXZlbCBwcm90b2NvbCBydW5uaW5nIG9uIHRvcCBvZiBIVFRQLiBUaGVyZSBoYXNuJ3QgYmVl biBhbnkgbmVlZCBmb3IgdGhlc2UgcHJveGllcyB0byB1bmRlcnN0YW5kIE9BdXRoIDIuMCB0aHVz DQogZmFyLjxicj4NCjxicj4NClsxXTogPGEgaHJlZj0iaHR0cHM6Ly9vcmlnaW4tc3ltd2lzZWRv d25sb2FkLnN5bWFudGVjLmNvbS9yZXNvdXJjZXMvd2ViZ3VpZGVzL3NzbHYvNDUvQ29udGVudC9U b3BpY3MvdHJvdWJsZXNob290aW5nL1N1cHBvcnRfZm9yX0NsaWVudF9DZXJ0Lmh0bSIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cHM6Ly9vcmlnaW4tc3ltd2lzZWRvd25sb2FkLnN5bWFudGVjLmNvbS9y ZXNvdXJjZXMvd2ViZ3VpZGVzL3NzbHYvNDUvQ29udGVudC9Ub3BpY3MvdHJvdWJsZXNob290aW5n L1N1cHBvcnRfZm9yX0NsaWVudF9DZXJ0Lmh0bTwvYT48YnI+DQrigJMgPGJyPg0KQW5uYWJlbGxl IFJpY2hhcmQgQmFja21hbjxicj4NCkFXUyBJZGVudGl0eTxicj4NCjxicj4NCjxicj4NCk9uIDEy LzEvMTksIDc6NDEgQU0sICZxdW90O1RvcnN0ZW4gTG9kZGVyc3RlZHQmcXVvdDsgJmx0O3RvcnN0 ZW49PGEgaHJlZj0ibWFpbHRvOjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90 ZTo8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEFubmFiZWxsZSw8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgQW0gMjcuMTEuMjAxOSB1bSAwMjo0NiBzY2hyaWViIFJpY2hhcmQg QmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0Ozo8YnI+DQombmJz cDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFRvcnN0ZW4sPGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBJJ20gbm90IHRyYWNraW5n IGhvdyBjb29raWVzIGFyZSByZWxldmFudCB0byB0aGUgZGlzY3Vzc2lvbi48YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7IEnigJltIHN0aWxsIHRyeWluZyB0byB1bmRlcnN0YW5kIHdoeSB5b3UgYW5k IG90aGVycyBhcmd1ZSBtVExTIGNhbm5vdCBiZSB1c2VkIGluIHB1YmxpYyBjbG91ZCBkZXBsb3lt ZW50cyAoYW5kIHRodXMgZm9jdXMgb24gYXBwbGljYXRpb24gbGV2ZWwgUG9QKS48YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7IFNlc3Npb24gY29va2llcyBzZXJ2ZSB0aGUgc2FtZSBwdXJwb3NlIGlu IHdlYiBhcHBzIGFzIGFjY2VzcyB0b2tlbnMgZm9yIEFQSXMgYnV0IHRoZXJlIGFyZSBtdWNoIG1v cmUgd2ViIGFwcHMgdGhhbiBBUElzLiBJIHVzZSB0aGUgYW5hbG9neSB0byBpbGx1c3RyYXRlIHRo YXQgZWl0aGVyIHRoZXJlIGFyZSBzZWN1cml0eSBpc3N1ZXMgd2l0aCBjbG91ZCBkZXBsb3ltZW50 cyBvZiB3ZWIgYXBwcyBvciB0aGUgdGVjaG5pcXVlcyB1c2VkIHRvIHNlY3VyZQ0KIHdlYiBhcHBz IGFyZSBvayBmb3IgQVBJcyBhcyB3ZWxsLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSGVyZSBh cmUgdGhlIHR3byBtYWluIGFyZ3VtZW50cyBhbmQgbXkgY29uY2x1c2lvbnMvcXVlc3Rpb25zOiZu YnNwOyA8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IDEpIG1UTFMgaXTigJlzIG5vdCBlbmQgMiBl bmQ6IGFsdGhvdWdoIHRoYXTigJlzIHRydWUgZnJvbSBhIGNvbm5lY3Rpb24gcGVyc3BlY3RpdmUs IHRoZXJlIGFyZSBzb2x1dGlvbnMgZW1wbG95ZWQgdG8gc2VjdXJlIHRoZSBsYXN0IGhvcChzKSBi ZXR3ZWVuIFRMUyB0ZXJtaW5hdGluZyBwcm94eSBhbmQgc2VydmljZSAocHJpdmF0ZSBuZXQsIFZQ TiwgVExTKS4gVGhhdCB3b3JrcyBhbmQgaXMgY29uc2lkZXJlZCBzZWN1cmUgZW5vdWdoIGZvciAo c2Vzc2lvbikNCiBjb29raWVzLCBpdCBzaG91bGQgYmUgdGhlIHNhbWUgZm9yIGFjY2VzcyB0b2tl bnMuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAyKSBUTFMgdGVybWluYXRpbmcgcHJveGllcyBk byBub3QgZm9yd2FyZCBjZXJ0IGRhdGE6IGlmIHRoZSBzZXJ2aWNlIGl0c2VsZiB0ZXJtaW5hdGVz IFRMUyB0aGlzIGlzIGZlYXNpYmxlLCB3ZSBkbyBpdCBmb3Igb3VyIHB1YmxpYy1jbG91ZC1ob3N0 ZWQgbVRMUy1wcm90ZWN0ZWQgQVBJcy4gSWYgVExTIHRlcm1pbmF0aW9uIGlzIHByb3ZpZGVkIGJ5 IGEgY29tcG9uZW50IHJ1biBieSB0aGUgY2xvdWQgcHJvdmlkZXIsIHRoZSBxdWVzdGlvbiBpczoN CiBpcyB0aGlzIGNvbXBvbmVudCBhYmxlIHRvIGZvcndhcmQgdGhlIGNsaWVudCBjZXJ0aWZpY2F0 ZSB0byB0aGUgc2VydmljZT8gSWYgbm90LCB3ZWIgYXBwcyB1c2luZyBjZXJ0cyBmb3IgYXV0aGVu dGljYXRpb24gY2Fubm90IGJlIHN1cHBvcnRlZCBzdHJhaWdodHdheSBieSB0aGUgY2xvdWQgcHJv dmlkZXIuIEFueSBpbnNpZ2h0cz88YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgSSdtIGd1 ZXNzaW5nIHRoYXQncyBiZWNhdXNlIHdlJ3JlIG5vdCBvbiB0aGUgc2FtZSBwYWdlIHJlZ2FyZGlu ZyB1c2UgY2FzZXMsIHNvIGFsbG93IG1lIHRvIGNsZWFybHkgc3RhdGUgbWluZTo8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7IEkgdGhpbmsgd2UgYXJlLCB3ZSBhcmUganVzdCBmb2N1c2luZyBvbiBk aWZmZXJlbnQgZW5kcyBvZiB0aGUgVExTIHR1bm5lbC4gTXkgZm9jdXMgaXMgb24gdGhlIHNlcnZp Y2UgcHJvdmlkZXLigJlzIHNpZGUsIGVzcC4gcHVibGljIGNsb3VkIGhvc3RpbmcsIHdoZXJlYXMg eW91IGFyZSBmb2N1c2luZyBvbiBjbGllbnQgc2lkZSBUTFMgdGVybWluYXRpbmcgcHJveGllcy48 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFRo ZSB1c2UgY2FzZSBJIGFtIGNvbmNlcm5lZCB3aXRoIGlzIHJlcXVlc3RzIGJldHdlZW4gc2Vydmlj ZXMgd2hlcmUgZW5kLXRvLWVuZCBUTFMgY2Fubm90IGJlIGd1YXJhbnRlZWQuIEZvciBleGFtcGxl LCBhbiBlbnRlcnByaXNlIHNlcnZpY2UgcnVubmluZyBvbi1wcmVtaXNlLCBjb21tdW5pY2F0aW5n IHdpdGggYSBzZXJ2aWNlIGluIHRoZSBjbG91ZCwgd2hlcmUgdGhlIGVudGVycHJpc2UncyBvdXRi b3VuZCB0cmFmZmljIGlzIHJvdXRlZA0KIHRocm91Z2ggYSBUTFMgSW5zcGVjdGlvbiAoVExTSSkg YXBwbGlhbmNlLiBUaGUgVExTSSBhcHBsaWFuY2Ugc2l0cyBpbiB0aGUgbWlkZGxlIG9mIHRoZSBj b21tdW5pY2F0aW9uLCB0ZXJtaW5hdGluZyB0aGUgVExTIHNlc3Npb24gZXN0YWJsaXNoZWQgYnkg dGhlIG9uLXByZW1pc2Ugc2VydmljZSBhbmQgZXN0YWJsaXNoaW5nIGEgc2VwYXJhdGUgVExTIGNv bm5lY3Rpb24gd2l0aCB0aGUgY2xvdWQgc2VydmljZS48YnI+DQombmJzcDsgJm5ic3A7ICZndDsg PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IEluIHRoaXMga2luZCBvZiBlbnZpcm9ubWVudCwgdGhl cmUgaXMgbm8gZW5kLXRvLWVuZCBUTFMgY29ubmVjdGlvbiBiZXR3ZWVuIG9uLXByZW1pc2Ugc2Vy dmljZSBhbmQgY2xvdWQgc2VydmljZSwgYW5kIGl0IGlzIHZlcnkgdW5saWtlbHkgdGhhdCB0aGUg VExTSSBhcHBsaWFuY2UgaXMgY29uZmlndXJhYmxlIGVub3VnaCB0byBzdXBwb3J0IFRMUy1iYXNl ZCBzZW5kZXItY29uc3RyYWludCBtZWNoYW5pc21zIHdpdGhvdXQgc2lnbmlmaWNhbnRseQ0KIGNv bXByb21pc2luZyBvbiB0aGUgc2NvcGUgb2YgJnF1b3Q7c2VuZGVyJnF1b3Q7IChlLmcuLCAmcXVv dDt0aGlzIHNlcnZpY2UgYXQgdGhpcyBlbnRlcnByaXNlJnF1b3Q7IGJlY29tZXMgJnF1b3Q7dGhp cyBlbnRlcnByaXNl4oCdKS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEnigJltIG5vdCBmYW1p bGlhciB3aXRoIHRoZXNlIGtpbmQgb2YgcHJveGllcywgYnV0IGhhcHB5IHRvIGxlYXJuIG1vcmUg YW5kIHRvIGRpc2N1c3MgcG90ZW50aWFsIHNvbHV0aW9ucy48YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7IEhlcmUgYXJlIHNvbWUgcXVlc3Rpb25zOjxicj4NCiZuYnNwOyAmbmJzcDsgLSBIYXZlIHlv dSBzZWVuIHRoaXMga2luZCBvZiBwcm94aWVzIGludGVyY2VwdGluZyB0aGUgY29ubmVjdGlvbiBm cm9tIG9uLXByZW0gc2VydmljZSBkZXBsb3ltZW50cyB0byBzZXJ2aWNlIHByb3ZpZGVyPyBJ4oCZ bSBhc2tpbmcgYmVjYXVzZSBJIHRob3VnaHQgdGhlIG1haW4gdXNlIGNhc2Ugd2FzIHRvIGludGVy Y2VwdCBlbXBsb3llZXMgUEMgaW50ZXJuZXQgdHJhZmZpYy4NCjxicj4NCiZuYnNwOyAmbmJzcDsg LSBBcmUgeW91IHNheWluZyB0aGlzIGtpbmQgb2YgcHJveHkgZG9lcyBub3Qgc3VwcG9ydCBtdXR1 YWwgVExTIGF0IGFsbD8gQXQgbGVhc3QgdGhlb3JldGljYWxseSwgdGhlIHByb3h5IGNvdWxkIGNv bWJpbmUgc291cmNlIGFuZCBkZXN0aW5hdGlvbiB0byBzZWxlY3QgYSBjZXJ0L2tleSBwYWlyIHRv IHVzZSBmb3Igb3V0Ym91bmQgVExTIGNsaWVudCBhdXRoZW50aWNhdGlvbi4NCjxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgJmd0OyBFdmVuIGlmIGl0IGlzIHBvc3NpYmxlLCBpdCBpcyBsaWtlbHkg dG8gcmVxdWlyZSBhZHZhbmNlZCBjb25maWd1cmF0aW9uIHRoYXQgaXMgbm9uLXRyaXZpYWwgZm9y IGFkbWluaXN0cmF0b3JzIHRvIGRlcGxveS4gSXQncyBubyBsb25nZXIgYXMgc2ltcGxlIGFzIHRo ZSBkZXZlbG9wZXIgcGFzc2luZyBhIHNlbGYtc2lnbmVkIGNlcnRpZmljYXRlIHRvIHRoZSBIVFRQ IHN0YWNrLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSSBhZ3JlZS4gQ2VydCBiaW5kaW5nIGlz IGVzdGFibGlzaGVkIGluIE9BdXRoIHByb3RvY29sIG1lc3NhZ2VzLCB3aGljaCB3b3VsZCByZXF1 aXJlIHRoZSBhcHBsaWFuY2UgdG8gdW5kZXJzdGFuZCB0aGUgcHJvdG9jb2wuIE9uIHRoZSBvdGhl ciBoYW5kLCBJIHdvdWxkIGV4cGVjdCB0aGVzZSBraW5kIG9mIHByb3h5IHRvIHVuZGVyc3RhbmQg YSBsb3QgYWJvdXQgdGhlIHByb3RvY29scyBydW5uaW5nIHRocm91Z2ggaXQsIG90aGVyd2lzZSB0 aGV5DQogY2Fubm90IGZ1bGZpbCB0aGVpciB0YXNrIG9mIGluc3BlY3RpbmcgdGhpcyB0cmFmZmlj LiA8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IGJlc3QgcmVnYXJkcyw8YnI+DQombmJzcDsgJm5i c3A7IFRvcnN0ZW4uIDxicj4NCjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8 YnI+DQombmJzcDsgJm5ic3A7ICZndDsg4oCTIDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBBbm5h YmVsbGUgUmljaGFyZCBCYWNrbWFuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IEFXUyBJZGVudGl0 eTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0K Jm5ic3A7ICZuYnNwOyAmZ3Q7IE9uIDExLzIzLzE5LCA5OjUwIEFNLCAmcXVvdDtUb3JzdGVuIExv ZGRlcnN0ZWR0JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5u ZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0K Jm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDIzLiBOb3YgMjAxOSwgYXQgMDA6MzQsIFJpY2hhcmQgQmFj a21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQom bmJzcDsgJm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBob3cgYXJl IGNvb2tpZXMgcHJvdGVjdGVkIGZyb20gbGVha2FnZSwgcmVwbGF5LCBpbmplY3Rpb24gaW4gYSBz ZXR1cCBsaWtlIHRoaXM/PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBUaGV5IGFyZW7igJl0 Ljxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgVGhhdHMg dmVyeSBpbnRlcmVzdGluZyB3aGVuIGNvbXBhcmVkIHRvIHdoYXQgd2UgYXJlIGRpc2N1c3Npbmcg d2l0aCByZXNwZWN0IHRvIEFQSSBzZWN1cml0eS4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8 YnI+DQombmJzcDsgJm5ic3A7ICZndDsgSXQgZWZmZWN0aXZlbHkgbWVhbnMgYW55b25lIGFibGUg dG8gY2FwdHVyZSBhIHNlc3Npb24gY29va2llLCBlLmcuIGJldHdlZW4gVExTIHRlcm1pbmF0aW9u IHBvaW50IGFuZCBhcHBsaWNhdGlvbiwgYnkgd2F5IG9mIGFuIEhUTUwgaW5qZWN0aW9uLCBvciBh bnkgb3RoZXIgc3VpdGFibGUgYXR0YWNrIGlzIGFibGUgdG8gaW1wZXJzb25hdGUgYSBsZWdpdGlt YXRlIHVzZXIgYnkgaW5qZWN0aW5nIHRoZSBjb29raWUocykgaW4gYW4gYXJiaXRyYXJ5DQogdXNl ciBhZ2VudC4gVGhlIGltcGFjdCBvZiBzdWNoIGFuIGF0dGFjayBtaWdodCBiZSBldmVuIHdvcnNl IHRoYW4gYWJ1c2luZyBhbiBhY2Nlc3MgdG9rZW4gZ2l2ZW4gdGhlICh0eXBpY2FsbHkpIGJyb2Fk IHNjb3BlIG9mIGEgc2Vzc2lvbi48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7IFRMUy1iYXNlZCBtZXRob2RzIGZvciBzZW5kZXIgY29uc3RyYWluZWQgYWNj ZXNzIHRva2VucywgaW4gY29udHJhc3QsIHByZXZlbnQgdGhpcyB0eXBlIG9mIHJlcGxheSwgZXZl biBpZiB0aGUgcmVxdWVzdHMgYXJlIHByb3RlY3RlZCBiZXR3ZWVuIGNsaWVudCBhbmQgVExTIHRl cm1pbmF0aW5nIHByb3h5LCBvbmx5LiBFbnN1cmluZyB0aGUgYXV0aGVudGljaXR5IG9mIHRoZSBj bGllbnQgY2VydGlmaWNhdGUgd2hlbiBmb3J3YXJkZWQgZnJvbQ0KIFRMUyB0ZXJtaW5hdGluZyBw cm94eSB0byBzZXJ2aWNlLCBlLmcuIHRocm91Z2ggYW5vdGhlciBhdXRoZW50aWNhdGVkIFRMUyBj b25uZWN0aW9uLCB3aWxsIGV2ZW4gcHJldmVudCBpbmplY3Rpb24gd2l0aGluIHRoZSBkYXRhIGNl bnRlci9jbG91ZCBlbnZpcm9ubWVudC4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgSSBjb21lIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgd2UgYWxyZWFk eSBoYXZlIHRoZSBtZWNoYW5pc20gYXQgaGFuZCB0byBpbXBsZW1lbnQgQVBJcyB3aXRoIGEgY29u c2lkZXJhYmxlIGhpZ2hlciBzZWN1cml0eSBsZXZlbCB0aGFuIHdoYXQgaXMgYWNjZXB0ZWQgdG9k YXkgZm9yIHdlYiBhcHBsaWNhdGlvbnMuIFNvIHdoYXQgcHJvYmxlbSBkbyB3ZSB3YW50IHRvIHNv bHZlPzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7 IEJ1dCBteSBwcmltYXJ5IGNvbmNlcm4gaGVyZSBpc24ndCB3ZWIgYnJvd3NlciB0cmFmZmljLCBp dCdzIGNhbGxzIGZyb20gc2VydmljZXMvYXBwcyBydW5uaW5nIGluc2lkZSBhIGNvcnBvcmF0ZSBu ZXR3b3JrIHRvIHNlcnZpY2VzIG91dHNpZGUgYSBjb3Jwb3JhdGUgbmV0d29yayAoZS5nLiwgc2Vy dmljZS10by1zZXJ2aWNlIEFQSSBjYWxscyB0aGF0IHBhc3MgdGhyb3VnaCBhIGNvcnBvcmF0ZSBU TFMgZ2F0ZXdheSkuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyBDYW4geW91IHBsZWFzZSBkZXNjcmliZSB0aGUgY2hhbGxlbmdlcyBhcmlzaW5nIGluIHRo ZXNlIHNldHRpbmdzPyBJIGFzc3VtZSB0aG9zZSBwcm94aWVzIHdvbuKAmXQgc3VwcG9ydCBDT05O RUNUIHN0eWxlIHBhc3MgdGhyb3VnaCBvdGhlcndpc2Ugd2Ugd291bGRu4oCZdCB0YWxrIGFib3V0 IHRoZW0uPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZn dDsmZ3Q7IFRoYXTigJlzIGEgdG90YWxseSB2YWxpZCBwb2ludC4gQnV0IGFnYWluLCBzdWNoIGEg c29sdXRpb24gbWFrZXMgdGhlIGxpZmUgb2YgY2xpZW50IGRldmVsb3BlcnMgaGFyZGVyLjxicj4N CiZuYnNwOyAmbmJzcDsgJmd0OyZndDsmZ3Q7IEkgcGVyc29uYWxseSB0aGluaywgd2UgYXMgYSBj b21tdW5pdHkgbmVlZCB0byB1bmRlcnN0YW5kIHRoZSBwcm9zIGFuZCBjb25zIG9mIGJvdGggYXBw cm9hY2hlcy4gSSBhbHNvIHRoaW5rIHdlIGhhdmUgbm90IGV2ZW4gY29tZSBjbG9zZSB0byB0aGlz IHBvaW50LCB3aGljaCwgaW4gbXkgb3B0aW9uLCBpcyB0aGUgcHJlcmVxdWlzaXRlIGZvciBtYWtp bmcgaW5mb3JtZWQgZGVjaXNpb25zLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgQWdyZWVk LiBJdCdzIGNsZWFyIHRoYXQgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHBhcnRpZXMgY29taW5nIGF0 IHRoaXMgZnJvbSBhIG51bWJlciBvZiBkaWZmZXJlbnQgZGlyZWN0aW9ucywgYW5kIHRoYXQncyBj b2xvcmluZyBvdXIgcGVyY2VwdGlvbnMuIFRoYXQncyB3aHkgSSB0aGluayB3ZSBuZWVkIHRvIG5h aWwgZG93biB0aGUgc2NvcGUgb2Ygd2hhdCB3ZSdyZSB0cnlpbmcgdG8gc29sdmUgd2l0aCBEUG9Q IGJlZm9yZSB3ZSBjYW4gaGF2ZQ0KIGEgcHJvZHVjdGl2ZSBjb252ZXJzYXRpb24gaG93IGl0IHNo b3VsZCB3b3JrLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgV2Ugd2lsbCBkbyBzby48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZu YnNwOyAmZ3Q7Jmd0OyDigJM8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IEFubmFiZWxsZSBS aWNoYXJkIEJhY2ttYW48YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IEFXUyBJZGVudGl0eTxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgT24gMTEvMjIvMTksIDEwOjUxIFBNLCAmcXVvdDtU b3JzdGVuIExvZGRlcnN0ZWR0JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2Rk ZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4m Z3Q7IHdyb3RlOjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBPbiAyMi4gTm92 IDIwMTksIGF0IDIyOjEyLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmE9 PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyZndDsmZ3Q7IFRoZSBzZXJ2aWNlIHByb3ZpZGVyIGRvZXNuJ3Qgb3duIHRo ZSBlbnRpcmUgY29ubmVjdGlvbi4gVGhleSBoYXZlIG5vIGNvbnRyb2wgb3ZlciBjb3Jwb3JhdGUg b3IgZ292ZXJubWVudCBUTFMgZ2F0ZXdheXMsIG9yIG90aGVyIHRlcm1pbmF0b3JzIHRoYXQgbWln aHQgZXhpc3Qgb24gdGhlIGNsaWVudCdzIHNpZGUuIEluIGxhcmdlciBvcmdhbml6YXRpb25zLCBv ciB3aGVuIGNsb3VkIGhvc3RpbmcgaXMgaW52b2x2ZWQsIHRoZSBzZXJ2aWNlDQogdGVhbSBtYXkg bm90IGV2ZW4gb3duIGFsbCB0aGUgaG9wcyBvbiB0aGVpciBzaWRlLjxicj4NCiZuYnNwOyAmbmJz cDsgJmd0OyZndDsgaG93IGFyZSBjb29raWVzIHByb3RlY3RlZCBmcm9tIGxlYWthZ2UsIHJlcGxh eSwgaW5qZWN0aW9uIGluIGEgc2V0dXAgbGlrZSB0aGlzPzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyZndDsmZ3Q7IFdoaWxlIHByZXN1bWFibHkgdGhleSBoYXZlIHNvbWUgdHJ1c3QgaW4gdGhlbSwg cHJvdGVjdGlvbiBhZ2FpbnN0IGxlYWtlZCBiZWFyZXIgdG9rZW5zIGlzIGFuIGF0dHJhY3RpdmUg ZGVmZW5zZS1pbi1kZXB0aCBtZWFzdXJlLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgVGhh dOKAmXMgYSB0b3RhbGx5IHZhbGlkIHBvaW50LiBCdXQgYWdhaW4sIHN1Y2ggYSBzb2x1dGlvbiBt YWtlcyB0aGUgbGlmZSBvZiBjbGllbnQgZGV2ZWxvcGVycyBoYXJkZXIuPGJyPg0KJm5ic3A7ICZu YnNwOyAmZ3Q7Jmd0OyBJIHBlcnNvbmFsbHkgdGhpbmssIHdlIGFzIGEgY29tbXVuaXR5IG5lZWQg dG8gdW5kZXJzdGFuZCB0aGUgcHJvcyBhbmQgY29ucyBvZiBib3RoIGFwcHJvYWNoZXMuIEkgYWxz byB0aGluayB3ZSBoYXZlIG5vdCBldmVuIGNvbWUgY2xvc2UgdG8gdGhpcyBwb2ludCwgd2hpY2gs IGluIG15IG9wdGlvbiwgaXMgdGhlIHByZXJlcXVpc2l0ZSBmb3IgbWFraW5nIGluZm9ybWVkIGRl Y2lzaW9ucy48YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7Jmd0OyDigJM8YnI+DQombmJzcDsg Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7Jmd0OyZndDsgQVdTIElkZW50aXR5PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 Jmd0OyZndDsgT24gMTEvMjIvMTksIDk6MzcgUE0sICZxdW90O09BdXRoIG9uIGJlaGFsZiBvZiBU b3JzdGVuIExvZGRlcnN0ZWR0JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9u IGJlaGFsZiBvZiB0b3JzdGVuPTxhIGhyZWY9Im1haWx0bzo0MGxvZGRlcnN0ZWR0Lm5ldEBkbWFy Yy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYu b3JnPC9hPiZndDsNCiB3cm90ZTo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsg T24gMjIuIE5vdiAyMDE5LCBhdCAyMToyMSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0 O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj40MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8 YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgVGhlIGRpY2hvdG9teSBvZiAmcXVv dDtUTFMgd29ya2luZyZxdW90OyBhbmQgJnF1b3Q7VExTIGZhaWxlZCZxdW90OyBvbmx5IGFwcGxp ZXMgdG8gYSBzaW5nbGUgVExTIGNvbm5lY3Rpb24uIEluIG5vbi1lbmQtdG8tZW5kIFRMUyBlbnZp cm9ubWVudHMsIGVhY2ggVExTIHRlcm1pbmF0b3IgYmV0d2VlbiBjbGllbnQgYW5kIFJTIGludHJv ZHVjZXMgYWRkaXRpb25hbCB0b2tlbiBsZWFrYWdlL2V4ZmlsdHJhdGlvbiByaXNrLCBpcnJlc3Bl Y3RpdmUgb2YgdGhlIHF1YWxpdHkNCiBvZiB0aGUgVExTIGNvbm5lY3Rpb25zIHRoZW1zZWx2ZXMu IEVhY2ggdGVybWluYXRvciBhbHNvIGludHJvZHVjZXMgY29tcGxleGl0eSBmb3IgaW1wbGVtZW50 aW5nIG1UTFMsIFRva2VuIEJpbmRpbmcsIG9yIGFueSBvdGhlciBUTFMtYmFzZWQgc2VuZGVyIGNv bnN0cmFpbnQgc29sdXRpb24sIHdoaWNoIG1lYW5zIGRldmVsb3BlcnMgd2l0aCBub24tZW5kLXRv LWVuZCBUTFMgdXNlIGNhc2VzIHdpbGwgYmUgbW9yZSBsaWtlbHkgdG8gdHVybiB0byBEUG9QLjxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsmZ3Q7IFRoZSBwb2ludCBpcyB3ZSBhcmUgdGFsa2lu ZyBhYm91dCBkaWZmZXJlbnQgZGV2ZWxvcGVycyBoZXJlLiBUaGUgY2xpZW50IGRldmVsb3BlciBk b2VzIG5vdCBuZWVkIHRvIGNhcmUgYWJvdXQgdGhlIGNvbm5lY3Rpb24gYmV0d2VlbiBwcm94eSBh bmQgc2VydmljZS4gU2hlIHJlbGllcyBvbiB0aGUgc2VydmljZSBwcm92aWRlciB0byBnZXQgaXQg cmlnaHQuIFNvIHRoZSBkZXZlbG9wZXJzIChvciBEZXZPcHMgb3IgYWRtaW5zKSBvZiB0aGUNCiBz ZXJ2aWNlIHByb3ZpZGVyIG5lZWQgdG8gZW5zdXJlIGVuZCB0byBlbmQgc2VjdXJpdHkuIEFuZCBp ZiB0aGUgcGF0aCBpcyBzZWN1cmVkIG9uY2UsIGl0IHdpbGwgd29yayBmb3IgYWxsIGNsaWVudHMu PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IElmIERQb1AgaXMgaW50ZW5kZWQg dG8gYWRkcmVzcyAmcXVvdDtjYXNlcyB3aGVyZSBuZWl0aGVyIG1UTFMgbm9yIE9BdXRoIFRva2Vu IEJpbmRpbmcgYXJlIGF2YWlsYWJsZSZxdW90OyBbMV0sIHRoZW4gaXQgc2hvdWxkIGFkZHJlc3Mg dGhpcyByaXNrIG9mIHRva2VuIGxlYWthZ2UgYmV0d2VlbiBjbGllbnQgYW5kIFJTLiBJZiBvbiB0 aGUgb3RoZXIgaGFuZCBEUG9QIGlzIG9ubHkgaW50ZW5kZWQgdG8gc3VwcG9ydCB0aGUgU1BBIHVz ZSBjYXNlIGFuZA0KIGFzc3VtZXMgdGhlIHVzZSBvZiBlbmQtdG8tZW5kIFRMUywgdGhlbiB0aGUg ZG9jdW1lbnQgc2hvdWxkIGJlIHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGF0Ljxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyZndDsmZ3Q7IEkgYWdyZWUuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7IFsxXTogPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZl dHQtb2F1dGgtZHBvcC0wMyNzZWN0aW9uLTEiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mZXR0LW9hdXRoLWRwb3AtMDMjc2VjdGlvbi0xPC9hPjxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyDigJM8YnI+DQombmJzcDsgJm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsgQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBBV1MgSWRlbnRpdHk8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsgT24gMTEvMjIvMTksIDg6MTcgUE0sICZxdW90O09BdXRoIG9uIGJlaGFs ZiBvZiBUb3JzdGVuIExvZGRlcnN0ZWR0JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+IG9uIGJlaGFsZiBvZiB0b3JzdGVuPTxhIGhyZWY9Im1haWx0bzo0MGxvZGRlcnN0ZWR0Lm5l dEBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbG9kZGVyc3RlZHQubmV0QGRtYXJj LmlldGYub3JnPC9hPiZndDsNCiB3cm90ZTo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsgSGkgTmVpbCw8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9u IDIyLiBOb3YgMjAxOSwgYXQgMTg6MDgsIE5laWwgTWFkZGVuICZsdDs8YSBocmVmPSJtYWlsdG86 bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5laWwubWFkZGVuQGZv cmdlcm9jay5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IE9uIDIyIE5vdiAyMDE5LCBhdCAwNzo1MywgVG9yc3RlbiBMb2RkZXJzdGVkdCAm bHQ7dG9yc3Rlbj08YSBocmVmPSJtYWlsdG86NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj40MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZzwvYT4m Z3Q7IHdyb3RlOjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBPbiAyMi4gTm92IDIwMTksIGF0IDE1OjI0LCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJt YWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9h PiZndDsgd3JvdGU6PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IEnigJltIGdvaW5nIHRvICYjNDM7MSBEaWNrIGFuZCBBbm5hYmVsbGXigJlzIHF1ZXN0aW9u IGFib3V0IHRoZSBzY29wZSBoZXJlLiBUaGF0IHdhcyB0aGUgb25lIG1ham9yIHRoaW5nIHRoYXQg c3RydWNrIG1lIGR1cmluZyB0aGUgRFBvUCBkaXNjdXNzaW9ucyBpbiBTaW5nYXBvcmUgeWVzdGVy ZGF5OiB3ZSBkb27igJl0IHNlZW0gdG8gYWdyZWUgb24gd2hhdCBEUG9QIGlzIGZvci4gU29tZSAo aW5jbHVkaW5nIHRoZSBhdXRob3JzLCBpdCBzZWVtcykNCiBzZWUgaXQgYXMgYSBxdWljayBwb2lu dC1zb2x1dGlvbiB0byBhIHNwZWNpZmljIHVzZSBjYXNlLiBPdGhlcnMgc2VlIGl0IGFzIGEgZ2Vu ZXJhbCBQb1AgbWVjaGFuaXNtLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBJZiBpdOKAmXMgdGhlIGZvcm1lciwgdGhlbiBpdCBzaG91bGQgYmUgZXhwbGlj aXRseSB0aWVkIHRvIG9uZSBzcGVjaWZpYyBzZXQgb2YgdGhpbmdzLiBJZiBpdOKAmXMgdGhlIGxh dHRlciwgdGhlbiBpdCBuZWVkcyB0byBiZSBleHBhbmRlZC48YnI+DQombmJzcDsgJm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcyBhIGNvLWF1dGhvciBvZiB0aGUgRFBvUCBkcmFmdCBJ IHN0YXRlIGFnYWluIHdoYXQgSSBzYWlkIHllc3RlcmRheTogRFBvUCBpcyBhIG1lY2hhbmlzbSBm b3Igc2VuZGVyLWNvbnN0cmFpbmluZyBhY2Nlc3MgdG9rZW5zIHNlbnQgZnJvbSBTUEFzIG9ubHku IFRoZSB0aHJlYXQgdG8gYmUgcHJldmVudGVkIGlzIHRva2VuIHJlcGxheS48YnI+DQombmJzcDsg Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgdGhpbmsgdGhlIHBocmFzZSAmcXVvdDt0b2tl biByZXBsYXkmcXVvdDsgaXMgYW1iaWd1b3VzLiBUcmFkaXRpb25hbGx5IGl0IHJlZmVycyB0byBh biBhdHRhY2tlciBiZWluZyBhYmxlIHRvIGNhcHR1cmUgYSB0b2tlbiAob3Igd2hvbGUgcmVxdWVz dHMpIGluIHVzZSBhbmQgdGhlbiByZXBsYXkgaXQgYWdhaW5zdCB0aGUgc2FtZSBSUy4gVGhpcyBp cyBhbHJlYWR5IHByb3RlY3RlZCBhZ2FpbnN0IGJ5IHRoZSB1c2Ugb2Ygbm9ybWFsIFRMUyBvbiB0 aGUNCiBjb25uZWN0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIFJTLiBJIHRoaW5rIGlu c3RlYWQgeW91IGFyZSByZWZlcnJpbmcgdG8gYSBtYWxpY2lvdXMvY29tcHJvbWlzZWQgUlMgcmVw bGF5aW5nIHRoZSB0b2tlbiB0byBhIGRpZmZlcmVudCBSUyAtIHdoaWNoIGhhcyBtb3JlIG9mIHRo ZSBmbGF2b3VyIG9mIGEgbWFuIGluIHRoZSBtaWRkbGUgYXR0YWNrIChvZiB0aGUgcGhpc2hpbmcg a2luZCkuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IEkgd291bGQgYXJndWUg VExTIGJhc2ljYWxseSBwcmV2ZW50cyBsZWFrYWdlIGFuZCBub3QgcmVwbGF5LiBUaGUgdGhyZWF0 cyB3ZSB0cnkgdG8gY29wZSB3aXRoIGNhbiBiZSBmb3VuZCBpbiB0aGUgU2VjdXJpdHkgQkNQLiBU aGVyZSBhcmUgbXVsdGlwbGUgd2F5cyBhY2Nlc3MgdG9rZW5zIGNhbiBsZWFrLCBpbmNsdWRpbmcg cmVmZXJyZXIgaGVhZGVycywgbWl4LXVwLCBvcGVuIHJlZGlyZWN0aW9uLCBicm93c2VyIGhpc3Rv cnksIGFuZA0KIGFsbCBzb3J0cyBvZiBhY2Nlc3MgdG9rZW4gbGVha2FnZSBhdCB0aGUgcmVzb3Vy Y2Ugc2VydmVyPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IFBsZWFzZSBoYXZl IGEgbG9vayBhdCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTMjc2VjdGlvbi00IiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3Bp Y3MtMTMjc2VjdGlvbi00PC9hPi48YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsg PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2Vj dXJpdHktdG9waWNzLTEzI3NlY3Rpb24tNC44IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTMjc2Vj dGlvbi00Ljg8L2E+IGFsc28gaGFzIGFuIGV4dGVuc2l2ZSBkaXNjdXNzaW9uIG9mIHBvdGVudGlh bCBjb3VudGVyIG1lYXN1cmVzLCBpbmNsdWRpbmcgYXVkaWVuY2UgcmVzdHJpY3RlZCBhY2Nlc3Mg dG9rZW5zIGFuZCBhIGNvbmNsdXNpb24gdG8gcmVjb21tZW5kIHNlbmRlciBjb25zdHJhaW5lZCBh Y2Nlc3MgdG9rZW5zIG92ZXIgb3RoZXINCiBtZWNoYW5pc21zLjxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQnV0IGlmIHRoYXQncyB0aGUgY2FzZSB0aGVuIHRoZXJlIGFy ZSBtdWNoIHNpbXBsZXIgZGVmZW5jZXMgdGhhbiB0aG9zZSBwcm9wb3NlZCBpbiB0aGUgY3VycmVu dCBkcmFmdDo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDEuIEdldCBz ZXBhcmF0ZSBhY2Nlc3MgdG9rZW5zIGZvciBlYWNoIFJTIHdpdGggY29ycmVjdCBhdWRpZW5jZSBh bmQgc2NvcGVzLiBUaGUgY29uc2Vuc3VzIGFwcGVhcnMgdG8gYmUgdGhhdCB0aGlzIGlzIGhhcmQg dG8gZG8gaW4gc29tZSBjYXNlcywgaGVuY2UgdGhlIGRyYWZ0Ljxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyBIb3cgbWFueSBkZXBsb3ltZW50cyBkbyB5b3Uga25vdyB0aGF0IHRv ZGF5IGFyZSBhYmxlIHRvIGlzc3VlIFJTLXNwZWNpZmljIGFjY2VzcyB0b2tlbnM/PGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IEJUVzogaG93IHdvdWxkIHlvdSBpZGVudGlmeSB0 aGUgUlM/PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IEkgYWdyZWUgdGhhdCB3 b3VsZCBiZSBhbiBhbHRlcm5hdGl2ZSBhbmQgSeKAmW0gYSBncmVhdCBmYW4gb2Ygc3VjaCB0b2tl bnMgKGFuZCB1c2VkIHRoZW0gYSBsb3QgYXQgRGV1dHNjaGUgVGVsZWtvbSkgYnV0IGluIG15IHBl cmNlcHRpb24gdGhpcyBwYXR0ZXJuIG5lZWRzIHN0aWxsIHRvIGJlIGVzdGFibGlzaGVkIGluIHRo ZSBtYXJrZXQuIE1vcmVvdmVyLCB0aGV5IGJhc2ljYWxseSBwcm90ZWN0IGZyb20gYSByb3VnaCBS UyAoaWYgdGhlDQogVVJMIGlzIHVzZWQgYXMgYXVkaWVuY2UpIHJlcGxheWluZyB0aGUgdG9rZW4g c29tZXBsYWNlIGVsc2UsIGJ1dCB0aGV5IGRvIG5vdCBwcm90ZWN0IGZyb20gYWxsIG90aGVyIGtp bmRzIG9mIGxlYWthZ2UvcmVwbGF5IChlLmcuIGxvZyBmaWxlcykuPGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAyLiBNYWtlIHRoZSBEUG9QIHRva2VuIGJlIGEgc2ltcGxl IEpXVCB3aXRoIGFuICZxdW90O2lhdCZxdW90OyBhbmQgdGhlIG9yaWdpbiBvZiB0aGUgUlMuIFRo aXMgc3RvcHMgdGhlIHRva2VuIGJlaW5nIHJldXNlZCBlbHNld2hlcmUgYnV0IHRoZSBjbGllbnQg Y2FuIHJldXNlIGl0IChyZXBsYXkgaXQpIGZvciBtYW55IHJlcXVlc3RzLi48YnI+DQombmJzcDsg Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDMuIElzc3VlIGEgbWFjYXJvb24tYmFzZWQgYWNj ZXNzIHRva2VuIGFuZCB0aGUgY2xpZW50IGNhbiBhZGQgYSBjb3JyZWN0IGF1ZGllbmNlIGFuZCBz Y29wZSByZXN0cmljdGlvbnMgYXQgdGhlIHBvaW50IG9mIHVzZS48YnI+DQombmJzcDsgJm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsgV2h5IGlzIHRoaXMgbmVlZGVkIGlmIHRoZSBhY2Nlc3MgdG9rZW4g aXMgYWxyZWFkeSBhdWRpZW5jZSByZXN0cmljdGVkPyBPciBkbyB5b3UgcHJvcG9zZSB0aGlzIGFz IGFsdGVybmF0aXZlPzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgUHJv dGVjdGluZyBhZ2FpbnN0IHRoZSBmaXJzdCBraW5kIG9mIHJlcGxheSBhdHRhY2tzIG9ubHkgYmVj b21lcyBhbiBpc3N1ZSBpZiB3ZSBhc3N1bWUgdGhlIHByb3RlY3Rpb25zIGluIFRMUyBoYXZlIGZh aWxlZC4gQnV0IGlmIERQb1AgaXMgb25seSBpbnRlbmRlZCBmb3IgY2FzZXMgd2hlcmUgbVRMUyBj YW4ndCBiZSB1c2VkLCBpdCBzaG91bGRuJ3QgaGF2ZSB0byBwcm90ZWN0IGFnYWluc3QgYSBzdHJv bmdlciB0aHJlYXQgbW9kZWwNCiBpbiB3aGljaCB3ZSBhc3N1bWUgdGhhdCBUTFMgc2VjdXJpdHkg aGFzIGJlZW4gbG9zdC48YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgSSBhZ3Jl ZS48YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgYmVzdCByZWdhcmRzLDxicj4N CiZuYnNwOyAmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBUb3JzdGVuLjxicj4NCiZuYnNwOyAmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0gTmVpbDxicj4NCjxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6C747BDA478A4E5F94388D766520DB27amazoncom_-- From nobody Wed Dec 4 02:09:14 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441EF120170 for ; Wed, 4 Dec 2019 02:09:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 3gnyp1enoYxe for ; Wed, 4 Dec 2019 02:09:10 -0800 (PST) Received: from nrifs01.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF0F12016E for ; Wed, 4 Dec 2019 02:09:09 -0800 (PST) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs01.index.or.jp (Postfix) with ESMTP id ADE4177EE4; Wed, 4 Dec 2019 19:09:08 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 8A1824E0046; Wed, 4 Dec 2019 19:09:08 +0900 (JST) Received: from nriea04.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id xB4A98He024587; Wed, 4 Dec 2019 19:09:08 +0900 Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea04.index.or.jp with ESMTP id xB4A98FB024580; Wed, 04 Dec 2019 19:09:08 +0900 Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id xB4A98Os040489; Wed, 4 Dec 2019 19:09:08 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id xB4A98jq040488; Wed, 4 Dec 2019 19:09:08 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf15.index.or.jp ([172.100.25.24]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id xB4A98FL040485; Wed, 4 Dec 2019 19:09:08 +0900 Received: from CUEXE02PA.cu.nri.co.jp (192.51.23.32) by CUEXM03PA.cu.nri.co.jp (172.159.253.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 4 Dec 2019 19:09:07 +0900 Received: from JPN01-OS2-obe.outbound.protection.outlook.com (104.47.92.56) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 4 Dec 2019 19:09:07 +0900 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jjEbvQpO0nHvN+MhgkqYlVyEwGHrDlbTtgQ2PD5bG2DbJqocL0lDNFLA5dYms5HHefi6XuwjoK6CjNj7gFrqKY2lI/2qNjHlE9wGKLmvj8A+m36RXo4xACwbfFxfgiIbvM+agKd4BPA05G5Vki7Y3QvayOjWnXB6c7gUDEjKvRVLOskV7vhp6tIKI1gLUT2CqcN1UoHBqvzw4P4LfpI7KYLInHU8Gxa9LZqvs27cReofjZuX+7DrjQE+IJ0fAfrXcSyvtk3zzdfC3XGfz8XpGpii958yZuJZjDDqtUzHXbdPbPdT3Wbyw0cqQ/Z7yR/BYSDmbWSudCeyIaUA8pgFmQ== 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=sccRYvbHO7M3V+7OqQWUBQrJp0sWFiLpqxwLjkbIKHU=; b=A3lIip3zcaivA91QditykmIP5sufUWqcEN8gb3Zx9tlxCn9PTim3o5CUoD3fStMMzYc50ryfVZpVaAUBWWK42+C3b3yEjAzM/yvRMx0fi/U0sW0Hf3eW/83aDnNodU5lY6qx4BGN9PimPfyOThWL9Pi+JAEO3OBqPpeVHL4h4F4sodQmAA8Xdlx+TchuzOF1yqNx0gteuavepTIGgQVjdv6J22TCio/BDi83JP70DQcFbv3Yh5lCXpaLhedl2SZYPJbWjmEqsCtFEybUYZ6YpJTaGM7vLoHnCLR40o17PjAoz++LEfJDgTBrM2YUqQ6CZ71Oasz/6UKv9kN2i7Na/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cu.nri.co.jp; dmarc=pass action=none header.from=cu.nri.co.jp; dkim=pass header.d=cu.nri.co.jp; arc=none Received: from TYAPR01MB4413.jpnprd01.prod.outlook.com (20.179.187.79) by TYAPR01MB3152.jpnprd01.prod.outlook.com (20.177.104.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.20; Wed, 4 Dec 2019 10:09:06 +0000 Received: from TYAPR01MB4413.jpnprd01.prod.outlook.com ([fe80::6172:bb3b:698e:e9e3]) by TYAPR01MB4413.jpnprd01.prod.outlook.com ([fe80::6172:bb3b:698e:e9e3%7]) with mapi id 15.20.2495.014; Wed, 4 Dec 2019 10:09:06 +0000 From: n-sakimura To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: WGLC for "OAuth 2.0 Security Best Current Practice" Thread-Index: AdWUe7vJeyT5tvxoSSGfe7d18Ckk5QWDfArw Date: Wed, 4 Dec 2019 10:09:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailadviser: Ver 3.40R03 authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-originating-ip: [133.250.166.13] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 88cdb3ae-d119-453e-9149-08d778a1ff83 x-ms-traffictypediagnostic: TYAPR01MB3152: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(396003)(39860400002)(366004)(376002)(13464003)(365934003)(199004)(189003)(53754006)(40434004)(966005)(446003)(256004)(14444005)(11346002)(5024004)(229853002)(6436002)(55016002)(25786009)(8936002)(110136005)(81156014)(81166006)(33656002)(478600001)(14454004)(8676002)(9686003)(6306002)(7736002)(74316002)(316002)(6246003)(71200400001)(15650500001)(52536014)(7696005)(102836004)(76176011)(26005)(2501003)(5660300002)(53546011)(6506007)(6116002)(3846002)(76116006)(86362001)(64756008)(66476007)(66556008)(66446008)(71190400001)(66946007)(305945005)(186003)(2906002)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:TYAPR01MB3152; H:TYAPR01MB4413.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bH8CVDceZ3h/bSs0SFwh8RCmUH6/Ty88jk0TyZZskfXH3+ZVTO4B5e/FpOSYpdFH90R50GNKkx7EZoY59b0E5IBqkCv5XXhxncoM/JeMtJW/xhb7vJ4NPsfR/EdCBZutRggVq5tPjKa88lp92avsVgsvb79l+OP75z7EgGitjsV6paZxiHcXUebPLKvjBqj/wJd/Zhhn4cxSPUGRkyCVAW0PMz6rn2sXbBK8uDFipeUHx/yWXR+KKX/ppHrEehSmZgfgq+Rm6sHqaN+XDQ0JDyp3pSmDP/pC1g06aECUmv11Oj8fQdoJvO27vEDAoLygqN05g9WYd21C9AQlkPKucm/VvqToGPYZ3a8iBSYzdi2GfZPIVen3vTBIX6VYUSHLVqo+M7sBhOfuTJ/6i1SS51aPQOZTLlbfaVQXN69R/2/oTD9pd65pxjD0UNzCIrp9LNO97u4J07GPOFNd/5l9RY7duusiLqgJfKTLkGZW80rR2TeAZWQJMiYEbkU6c1M5ehN7hJi1h5aoTbmkJTDy3z5pXiryH10Tx98VnkwaPf3gy259uJC3OSLwLaUsvri4yGsvYDXfgQProk1E6q+QltXYSEd4QFXcSkYfLVXsiYE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 88cdb3ae-d119-453e-9149-08d778a1ff83 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2019 10:09:06.7655 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /LjTwJQ4xB2lUGRAL9jZUHA73TYNT5dEfg8L0ds4e4x2jIjpaE3fEtpKBv7Gw8CN6mgYg0BWFeg51JV5h/KhlQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB3152 X-OrganizationHeadersPreserved: TYAPR01MB3152.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE02PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE02PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 10:09:12 -0000 Sorry to chime in so late as well as I have not been able to follow up all = the mail in the tread, so it may have come up before but just for the sake.= ..=20 1) Spelling of "OpenID" "OpenID" is sometimes spelled "OpenID" and sometimes " OpenId".=20 Please unify to "OpenID" as that is the official way of expressing it.=20 Of course, it does not apply to the URIs.=20 2) Has WPAD/PAC attack been mitigated in all user-agents?=20 WPAD/PAC used to trivially leak the request URIs (in terms of HTTP, not OAu= th) in some browsers that were configured to use proxy auto-config. So, in = that kind of scenario, both Authorization Request URI and Authorization Res= ponse URI would have leaked.=20 (Depending on the HTTP agent that the client uses, it would have leaked its= requests as well though they are typically not auto-configured so are save= in most cases.)=20 Did those browsers disappeared? (Hopefully yes but not sure.)=20 If not, it might be worth adding it.=20 Best,=20 Nat Sakimura --------------------------------------------------------- PLEASE READ:This e-mail is confidential and intended for the named recipien= t only. If you are not an intended recipient, please notify the sender and = delete this e-mail. -----Original Message----- From: OAuth On Behalf Of Hannes Tschofenig Sent: Wednesday, November 6, 2019 5:27 PM To: oauth@ietf.org Subject: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice" Hi all, this is a working group last call for "OAuth 2.0 Security Best Current Prac= tice". Here is the document: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 Please send you comments to the OAuth mailing list by Nov. 27, 2019. (We use a three week WGLC because of the IETF meeting.) Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Dec 4 07:19:11 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0354B120820 for ; Wed, 4 Dec 2019 07:19:10 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6aaGK_ckHCb for ; Wed, 4 Dec 2019 07:19:08 -0800 (PST) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BFE712008C for ; Wed, 4 Dec 2019 07:19:08 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 6557D540F for ; Wed, 4 Dec 2019 15:19:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1575472745; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QHHWY3Uv3v/Uui7T2byFVZU7U60ooyQr25lnknEi3Ro=; b=l9SDWOZRuNRmxHesMto46a19v7vZSLm5ZhTjUI5SH8oxOscK+Os/bCJk09S9MA/vc6sDIZ ZKSziv4cYg9N+mEuTq+qP3mgv8+xWRs3NXyFXfgTnUpV9eW7nLHKNfYzyGBRJPyJCS8IaV fVDxdKqmRCPAa9UFgAa6HGaBSbfmeaM= To: oauth@ietf.org References: <35143dd1-edeb-e0fd-6f36-a39d9b7f7008@hackmanit.de> <4f1d1215-aa23-93ab-ae5b-75426d7f07cc@danielfett.de> <277a3bc8-32fc-8c7c-85dc-5030d2d07728@rub.de> <8047bf89-1120-426d-e020-e58766c2ce3a@danielfett.de> <4300c85a-0942-f1b7-1854-2099107f1551@rub.de> <12085fa3-43e8-0621-cb16-8b52ffde8a6f@danielfett.de> From: Daniel Fett Message-ID: <77551719-9f81-8ec1-efca-266a8141892c@danielfett.de> Date: Wed, 4 Dec 2019 16:19:04 +0100 MIME-Version: 1.0 In-Reply-To: <12085fa3-43e8-0621-cb16-8b52ffde8a6f@danielfett.de> Content-Type: multipart/alternative; boundary="------------4E7059F99BA90F8BE500661E" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1575472745; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QHHWY3Uv3v/Uui7T2byFVZU7U60ooyQr25lnknEi3Ro=; b=ieg3ewZ/SnKk9QDqO6pPK0XYq/8hlUrx692dFh1FmVtBfqYeMBdIvlviOKLyBMWHCnPhIH gQ0oWf2GRlxJ+jgvUCuMjxHNv8EmgcFS03SaAZQFjqxsHakvezad7kNMCcAZ4c/5Ros7K2 4sAFgEqudbcWWJfUXOSnLCZoKj4Lcz8= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1575472745; a=rsa-sha256; cv=none; b=Ddbm/EAjiPBa6vTTHW0Ni7yjKI+49Nm+8P2krc+i4Pfo5HJR8AnQU6J75xj7Nmer9iaLsyv/xE0W0fR2zsLyxIE29/uczcYYXBABZn7wl7ndV6ish9FFenV7zo6jUnKrnBDGIhu8JLdIQCl4FoFyePUpPd/6hj6Xm7uAQe7cCw4= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 15:19:10 -0000 This is a multi-part message in MIME format. --------------4E7059F99BA90F8BE500661E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Am 03.12.19 um 10:49 schrieb Daniel Fett: > Am 03.12.19 um 10:21 schrieb Christian Mainka: >> Hi, >> >> according to [1], countermeasure (1) describes to >> >>> configure [the] authorization servers to return an AS identitifier >> ("iss") and the "client_id" for which a code or token was issued in the >> authorization response. >> >> So if an MixUp attack is running, the victim contacts A-AS but is >> redirected to to H-AS [2]. >> The AS adds - according to the countermeasure - two additional >> parameters to the authorization response: client_id and issuer. Both >> values are set by H-AS, so it returns H-issuer and H-client_id. > > I asked for clarification because I would assume that the mix-up > attack is twharted at this point. The client would see H-issuer > instead of A-issuer, to which it sent the user. > > I agree that the client_id is not of much value here. > Looking back at our analysis of OIDC [1], we actually included the option that attacker choses the client_id, even for the honest AS. This is a safe overapproximation, of course. Obviously an attacker-controlled AS can also issue arbitrary client_ids. So I suspect that there is no further attack hidden here. [1] https://arxiv.org/pdf/1704.08539 -Daniel --------------4E7059F99BA90F8BE500661E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Am 03.12.19 um 10:49 schrieb Daniel Fett:
Am 03.12.19 um 10:21 schrieb Christian Mainka:
Hi,

according to [1], countermeasure (1) describes to


configure [the] authorization servers to return an AS identitifier

("iss") and the "client_id" for which a code or token was issued in the
authorization response.

So if an MixUp attack is running, the victim contacts A-AS but is
redirected to to H-AS [2].
The AS adds - according to the countermeasure - two additional
parameters to the authorization response: client_id and issuer. Both
values are set by H-AS, so it returns H-issuer and H-client_id.

I asked for clarification because I would assume that the mix-up attack is twharted at this point. The client would see H-issuer instead of A-issuer, to which it sent the user.

I agree that the client_id is not of much value here.

Looking back at our analysis of OIDC [1], we actually included the option that attacker choses the client_id, even for the honest AS. This is a safe overapproximation, of course. Obviously an attacker-controlled AS can also issue arbitrary client_ids. So I suspect that there is no further attack hidden here.

[1] https://arxiv.org/pdf/1704.08539

-Daniel

--------------4E7059F99BA90F8BE500661E-- From nobody Thu Dec 5 03:38:28 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCCE120105 for ; Thu, 5 Dec 2019 03:38:25 -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 5pKb1DsvPI2a for ; Thu, 5 Dec 2019 03:38:21 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968DC12004A for ; Thu, 5 Dec 2019 03:38:21 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id u16so2674264ilg.10 for ; Thu, 05 Dec 2019 03:38:21 -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=lz8OnM39yZRuMBh7l/z7QFbFeiE203wlmhJrDT/na1w=; b=TB8SbBhtsN+dr+7SmKdVG1IwAPfQYuxBzQmChtaHmDEWx06NTglq/8E2feQyJNeF9x VVH93iaqq84Q1zClzONA43Nc1IcdRGmE0altbIw3uSCzRaVGdpBFjBdhP6FLVLi8f8/d BD/xf/sRvjmpJM55m2pygD1l4DuWooZSYxunl+K2t5SSM1Y4bPt7bT7jl7wGybTBtSCA H14z7mNiWtGn58dTIkoPkCsJFN4iKdFivKTxuV3eI0i0BnN66m1YU6UCvutexTIJJ0kd SIzXCNUsMa8nQa7mRtsyTW5zO+PZrplLBk2ia5+SdVvkQ3gA6fYeg2tmIruaeKXBv0gz DWww== 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=lz8OnM39yZRuMBh7l/z7QFbFeiE203wlmhJrDT/na1w=; b=gjV5uuDIQ+8hRe1Q7iOjmpZX3Qrr6e8vwQVT+Wwr83AA9Aa/xf9FWJOc05BuKcjYb2 MOg/oX03NER+Kgno88uWrM1s8908n6uxdnkhWWifmDhJHKRSZPt1RlYn6URuHpYugb6v bphwrJNFyp6O9eHPH0jt1YEMvDNDdWt+4eOFk0Ubdld1JHZ3yRe3Pr5URYrkjogqL+CM b+bRsXKPh62+ygJCWW7NYX2FCJthm1vKc0mhKrlRnXPbg4jNQRJZyvOSRkfn/die+Ij1 /a4HOnqGcHlL/QinujALY64IxCpiOOUzc0/l4og1XJSfg0eEaYKgMvZRegZ15jwYmdA+ Mntg== X-Gm-Message-State: APjAAAVXvC0+EEDzuR6RGKxUtzIIPQpgls09y0KoL/+QUPJms7+2sZfN +c3AlCURxhBH0tMmsyizDgysc3roMxGEquKC1mA= X-Google-Smtp-Source: APXvYqyb+gKRWuPjF/e90bedE4osM5ZOVf68VRLC0ZwLdJMi6G5B6Z1ZkGFIWYk0/4c6HgyGpyZQ4uHfBjs8/D0jTiE= X-Received: by 2002:a92:3984:: with SMTP id h4mr7855644ilf.36.1575545900718; Thu, 05 Dec 2019 03:38:20 -0800 (PST) MIME-Version: 1.0 References: <6DD96E5F-2F26-4280-BDF9-41F43CB5A3AF@lodderstedt.net> <3F3A350A-0EF3-4968-968E-9325F8434E80@amazon.com> <6C747BDA-478A-4E5F-9438-8D766520DB27@amazon.com> In-Reply-To: <6C747BDA-478A-4E5F-9438-8D766520DB27@amazon.com> From: Rifaat Shekh-Yusef Date: Thu, 5 Dec 2019 06:38:08 -0500 Message-ID: To: "Richard Backman, Annabelle" Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="000000000000bd60df0598f35dba" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: New Version Notification for draft-fett-oauth-dpop-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 11:38:26 -0000 --000000000000bd60df0598f35dba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I see what you meant. Thanks, Rifaat On Tue, Dec 3, 2019 at 3:46 PM Richard Backman, Annabelle < richanna@amazon.com> wrote: > >> The documentation for Symantec's SSL Visibility product [1] indicates > that sessions using client certificates will be rejected unless they are > exempted based on destination whitelisting (which is problematic when the > destination may be a general-purpose cloud service provider). > > > > > Is there a use case that would require you to do that? > > > If I have a service that is hosted on AWS, then the exception would be > for my service, not for AWS in general. > > > > Yes. Consider an on-premise service that uses a vendor service hosted in > the cloud. While some SaaS API endpoints are tenant-specific, many (most?= ) > are not, meaning from a destination perspective the enterprise=E2=80=99s = legitimate > traffic looks just like questionable traffic. > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Rifaat Shekh-Yusef > *Date: *Tuesday, December 3, 2019 at 5:21 AM > *To: *"Richard Backman, Annabelle" > *Cc: *Torsten Lodderstedt , oauth > > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: New > Version Notification for draft-fett-oauth-dpop-03.txt > > > > > > > > On Mon, Dec 2, 2019 at 4:35 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > > Session cookies serve the same purpose in web apps as access tokens for > APIs but there are much more web apps than APIs. I use the analogy to > illustrate that either there are security issues with cloud deployments o= f > web apps or the techniques used to secure web apps are ok for APIs as wel= l. > > "Security issues" is a loaded term, but if you mean that there are > practical risks that are not addressed by bearer tokens (whether they be > session cookies or access tokens) then yes, I think we both agree that > there are. Otherwise we wouldn't be discussing PoP, sender-constrained > tokens, etc. TLS-based solutions mitigate some risks, while leaving other= s > unmitigated. Depending on your use case and threat model, these risks may > or may not present practical threats. For my use cases, they do. > > Ultimately I'd like to mitigate these risks for both service APIs and web > applications. My focus is on service APIs for a couple reasons: > > 1. Interoperability is more important when the sender and recipient aren'= t > necessarily owned by a single entity. I can do proprietary things in > JavaScript if I want to just as I can in client SDKs, but this breaks dow= n > if my API implements a standard protocol and is expected to work with > off-the-shelf clients and/or implementations from other vendors. > > 2. Web applications are just a special subset of service APIs that happen= s > to be accessed via a browser. A solution for service APIs ought to be > reusable for web applications, or at least serve as a foundation for thei= r > solution. > > > - Have you seen this kind of proxies intercepting the connection fro= m > on-prem service deployments to service provider? I=E2=80=99m asking becau= se I > thought the main use case was to intercept employees PC internet traffic. > > I'm working from second-hand knowledge here, but like most things in the > enterprise world, it depends. Separating employee device outbound traffic > from internal service outbound traffic requires some level of > sophistication, be it in network topology, routing rules, or configuratio= n > rules on the TLIS appliance. > > > > Yeah, many major enterprises have these kinds of inspection services, Tak= e > a look at the following example: > > https://www.zscaler.com/resources/data-sheets/zscaler-internet-access.pdf > > > > > > > - Are you saying this kind of proxy does not support mutual TLS at > all? > > >From what I understand, at the very least mTLS is not universally > supported.. There may be some vendors that support it, but it's not > guaranteed. The documentation for Symantec's SSL Visibility product [1] > indicates that sessions using client certificates will be rejected unless > they are exempted based on destination whitelisting > > > > Yes, that is my experience too. > > > > (which is problematic when the destination may be a general-purpose cloud > service provider). > > > > Is there a use case that would require you to do that? > > If I have a service that is hosted on AWS, then the exception would be fo= r > my service, not for AWS in general. > > > > Regards, > > Rifaat > > > > > > On the other hand, I would expect these kind of proxy to understand a > lot about the protocols running through it, otherwise they cannot fulfil > their task of inspecting this traffic. > > Maybe, maybe not. In any case there's a difference between understanding > HTTP or SMTP or P2P-protocol-du-jour and understanding the > application-level protocol running on top of HTTP. There hasn't been any > need for these proxies to understand OAuth 2.0 thus far. > > [1]: > https://origin-symwisedownload.symantec.com/resources/webguides/sslv/45/C= ontent/Topics/troubleshooting/Support_for_Client_Cert.htm > =E2=80=93 > Annabelle Richard Backman > AWS Identity > > > On 12/1/19, 7:41 AM, "Torsten Lodderstedt" 40lodderstedt.net@dmarc.ietf.org> wrote: > > > Annabelle, > > > Am 27.11.2019 um 02:46 schrieb Richard Backman, Annabelle < > richanna@amazon.com>: > > > > Torsten, > > > > I'm not tracking how cookies are relevant to the discussion. > > I=E2=80=99m still trying to understand why you and others argue mTLS = cannot be > used in public cloud deployments (and thus focus on application level PoP= ). > > Session cookies serve the same purpose in web apps as access tokens > for APIs but there are much more web apps than APIs. I use the analogy to > illustrate that either there are security issues with cloud deployments o= f > web apps or the techniques used to secure web apps are ok for APIs as wel= l. > > Here are the two main arguments and my conclusions/questions: > > 1) mTLS it=E2=80=99s not end 2 end: although that=E2=80=99s true from= a connection > perspective, there are solutions employed to secure the last hop(s) betwe= en > TLS terminating proxy and service (private net, VPN, TLS). That works and > is considered secure enough for (session) cookies, it should be the same > for access tokens. > > 2) TLS terminating proxies do not forward cert data: if the service > itself terminates TLS this is feasible, we do it for our > public-cloud-hosted mTLS-protected APIs. If TLS termination is provided b= y > a component run by the cloud provider, the question is: is this component > able to forward the client certificate to the service? If not, web apps > using certs for authentication cannot be supported straightway by the clo= ud > provider. Any insights? > > > I'm guessing that's because we're not on the same page regarding us= e > cases, so allow me to clearly state mine: > > I think we are, we are just focusing on different ends of the TLS > tunnel. My focus is on the service provider=E2=80=99s side, esp. public c= loud > hosting, whereas you are focusing on client side TLS terminating proxies. > > > > > The use case I am concerned with is requests between services where > end-to-end TLS cannot be guaranteed. For example, an enterprise service > running on-premise, communicating with a service in the cloud, where the > enterprise's outbound traffic is routed through a TLS Inspection (TLSI) > appliance. The TLSI appliance sits in the middle of the communication, > terminating the TLS session established by the on-premise service and > establishing a separate TLS connection with the cloud service. > > > > In this kind of environment, there is no end-to-end TLS connection > between on-premise service and cloud service, and it is very unlikely tha= t > the TLSI appliance is configurable enough to support TLS-based > sender-constraint mechanisms without significantly compromising on the > scope of "sender" (e.g., "this service at this enterprise" becomes "this > enterprise=E2=80=9D). > > I=E2=80=99m not familiar with these kind of proxies, but happy to lea= rn more > and to discuss potential solutions. > > Here are some questions: > - Have you seen this kind of proxies intercepting the connection from > on-prem service deployments to service provider? I=E2=80=99m asking becau= se I > thought the main use case was to intercept employees PC internet traffic. > - Are you saying this kind of proxy does not support mutual TLS at > all? At least theoretically, the proxy could combine source and destinati= on > to select a cert/key pair to use for outbound TLS client authentication. > > > Even if it is possible, it is likely to require advanced > configuration that is non-trivial for administrators to deploy. It's no > longer as simple as the developer passing a self-signed certificate to th= e > HTTP stack. > > I agree. Cert binding is established in OAuth protocol messages, whic= h > would require the appliance to understand the protocol. On the other hand= , > I would expect these kind of proxy to understand a lot about the protocol= s > running through it, otherwise they cannot fulfil their task of inspecting > this traffic. > > best regards, > Torsten. > > > > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > On 11/23/19, 9:50 AM, "Torsten Lodderstedt" > wrote: > > > > > > > >>>>>>>>> On 23. Nov 2019, at 00:34, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > >>>>>>>>> how are cookies protected from leakage, replay, injection i= n > a setup like this? > >> They aren=E2=80=99t. > > > > Thats very interesting when compared to what we are discussing with > respect to API security. > > > > It effectively means anyone able to capture a session cookie, e.g. > between TLS termination point and application, by way of an HTML injectio= n, > or any other suitable attack is able to impersonate a legitimate user by > injecting the cookie(s) in an arbitrary user agent. The impact of such an > attack might be even worse than abusing an access token given the > (typically) broad scope of a session. > > > > TLS-based methods for sender constrained access tokens, in contrast= , > prevent this type of replay, even if the requests are protected between > client and TLS terminating proxy, only. Ensuring the authenticity of the > client certificate when forwarded from TLS terminating proxy to service, > e.g. through another authenticated TLS connection, will even prevent > injection within the data center/cloud environment. > > > > I come to the conclusion that we already have the mechanism at hand > to implement APIs with a considerable higher security level than what is > accepted today for web applications. So what problem do we want to solve? > > > >> But my primary concern here isn't web browser traffic, it's calls > from services/apps running inside a corporate network to services outside= a > corporate network (e.g., service-to-service API calls that pass through a > corporate TLS gateway). > > > > Can you please describe the challenges arising in these settings? I > assume those proxies won=E2=80=99t support CONNECT style pass through oth= erwise we > wouldn=E2=80=99t talk about them. > > > >>> That=E2=80=99s a totally valid point. But again, such a solution = makes the > life of client developers harder. > >>> I personally think, we as a community need to understand the pros > and cons of both approaches. I also think we have not even come close to > this point, which, in my option, is the prerequisite for making informed > decisions. > >> Agreed. It's clear that there are a number of parties coming at > this from a number of different directions, and that's coloring our > perceptions. That's why I think we need to nail down the scope of what > we're trying to solve with DPoP before we can have a productive > conversation how it should work. > > > > We will do so. > > > >> =E2=80=93 > >> Annabelle Richard Backman > >> AWS Identity > >> On 11/22/19, 10:51 PM, "Torsten Lodderstedt" < > torsten@lodderstedt.net> wrote: > >>>> On 22. Nov 2019, at 22:12, Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > >>> The service provider doesn't own the entire connection. They have > no control over corporate or government TLS gateways, or other terminator= s > that might exist on the client's side. In larger organizations, or when > cloud hosting is involved, the service team may not even own all the hops > on their side. > >> how are cookies protected from leakage, replay, injection in a > setup like this? > >>> While presumably they have some trust in them, protection against > leaked bearer tokens is an attractive defense-in-depth measure. > >> That=E2=80=99s a totally valid point. But again, such a solution m= akes the > life of client developers harder. > >> I personally think, we as a community need to understand the pros > and cons of both approaches. I also think we have not even come close to > this point, which, in my option, is the prerequisite for making informed > decisions. > >>> =E2=80=93 > >>> Annabelle Richard Backman > >>> AWS Identity > >>> On 11/22/19, 9:37 PM, "OAuth on behalf of Torsten Lodderstedt" < > oauth-bounces@ietf.org on behalf of torsten=3D > 40lodderstedt.net@dmarc.ietf.org> wrote: > >>>> On 22. Nov 2019, at 21:21, Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > >>>> The dichotomy of "TLS working" and "TLS failed" only applies to = a > single TLS connection. In non-end-to-end TLS environments, each TLS > terminator between client and RS introduces additional token > leakage/exfiltration risk, irrespective of the quality of the TLS > connections themselves. Each terminator also introduces complexity for > implementing mTLS, Token Binding, or any other TLS-based sender constrain= t > solution, which means developers with non-end-to-end TLS use cases will b= e > more likely to turn to DPoP. > >>> The point is we are talking about different developers here. The > client developer does not need to care about the connection between proxy > and service. She relies on the service provider to get it right. So the > developers (or DevOps or admins) of the service provider need to ensure e= nd > to end security. And if the path is secured once, it will work for all > clients. > >>>> If DPoP is intended to address "cases where neither mTLS nor > OAuth Token Binding are available" [1], then it should address this risk = of > token leakage between client and RS. If on the other hand DPoP is only > intended to support the SPA use case and assumes the use of end-to-end TL= S, > then the document should be updated to reflect that. > >>> I agree. > >>>> [1]: > https://tools.ietf.org/html/draft-fett-oauth-dpop-03#section-1 > >>>> =E2=80=93 > >>>> Annabelle Richard Backman > >>>> AWS Identity > >>>> On 11/22/19, 8:17 PM, "OAuth on behalf of Torsten Lodderstedt" < > oauth-bounces@ietf.org on behalf of torsten=3D > 40lodderstedt.net@dmarc.ietf.org> wrote: > >>>> Hi Neil, > >>>>> On 22. Nov 2019, at 18:08, Neil Madden < > neil.madden@forgerock.com> wrote: > >>>>> On 22 Nov 2019, at 07:53, Torsten Lodderstedt 40lodderstedt.net@dmarc.ietf.org> wrote: > >>>>>>> On 22. Nov 2019, at 15:24, Justin Richer > wrote: > >>>>>>> I=E2=80=99m going to +1 Dick and Annabelle=E2=80=99s question= about the scope > here. That was the one major thing that struck me during the DPoP > discussions in Singapore yesterday: we don=E2=80=99t seem to agree on wha= t DPoP is > for. Some (including the authors, it seems) see it as a quick > point-solution to a specific use case. Others see it as a general PoP > mechanism. > >>>>>>> If it=E2=80=99s the former, then it should be explicitly tied= to one > specific set of things. If it=E2=80=99s the latter, then it needs to be e= xpanded. > >>>>>> as a co-author of the DPoP draft I state again what I said > yesterday: DPoP is a mechanism for sender-constraining access tokens sent > from SPAs only. The threat to be prevented is token replay. > >>>>> I think the phrase "token replay" is ambiguous. Traditionally i= t > refers to an attacker being able to capture a token (or whole requests) i= n > use and then replay it against the same RS. This is already protected > against by the use of normal TLS on the connection between the client and > the RS. I think instead you are referring to a malicious/compromised RS > replaying the token to a different RS - which has more of the flavour of = a > man in the middle attack (of the phishing kind). > >>>> I would argue TLS basically prevents leakage and not replay. The > threats we try to cope with can be found in the Security BCP. There are > multiple ways access tokens can leak, including referrer headers, mix-up, > open redirection, browser history, and all sorts of access token leakage = at > the resource server > >>>> Please have a look at > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4= . > >>>> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4= .8 > also has an extensive discussion of potential counter measures, including > audience restricted access tokens and a conclusion to recommend sender > constrained access tokens over other mechanisms. > >>>>> But if that's the case then there are much simpler defences tha= n > those proposed in the current draft: > >>>>> 1. Get separate access tokens for each RS with correct audience > and scopes. The consensus appears to be that this is hard to do in some > cases, hence the draft. > >>>> How many deployments do you know that today are able to issue > RS-specific access tokens? > >>>> BTW: how would you identify the RS? > >>>> I agree that would be an alternative and I=E2=80=99m a great fan= of such > tokens (and used them a lot at Deutsche Telekom) but in my perception thi= s > pattern needs still to be established in the market. Moreover, they > basically protect from a rough RS (if the URL is used as audience) > replaying the token someplace else, but they do not protect from all othe= r > kinds of leakage/replay (e.g. log files). > >>>>> 2. Make the DPoP token be a simple JWT with an "iat" and the > origin of the RS. This stops the token being reused elsewhere but the > client can reuse it (replay it) for many requests.. > >>>>> 3. Issue a macaroon-based access token and the client can add a > correct audience and scope restrictions at the point of use. > >>>> Why is this needed if the access token is already audience > restricted? Or do you propose this as alternative? > >>>>> Protecting against the first kind of replay attacks only become= s > an issue if we assume the protections in TLS have failed. But if DPoP is > only intended for cases where mTLS can't be used, it shouldn't have to > protect against a stronger threat model in which we assume that TLS > security has been lost. > >>>> I agree. > >>>> best regards, > >>>> Torsten. > >>>>> -- Neil > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000000000000bd60df0598f35dba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I see what you meant.=C2=A0

Thanks,
=C2=A0Rifaat


On Tue, Dec 3, 2019 at 3:46 PM Rich= ard Backman, Annabelle <richanna@= amazon.com> wrote:

>> The documentation for Symantec's SSL Vi= sibility product [1] indicates that sessions using client certificates will= be rejected unless they are exempted based on destination whitelisting (wh= ich is problematic when the destination may be a general-purpose cloud service provider).

=C2=A0

> Is there a use case that would require you to d= o that?

> If I have a service that is hosted on AWS, then= the exception would be for my service, not for AWS in general.

=C2=A0

Yes. Consider an on-premise service that uses a vend= or service hosted in the cloud. While some SaaS API endpoints are tenant-sp= ecific, many (most?) are not, meaning from a destination perspective the en= terprise=E2=80=99s legitimate traffic looks just like questionable traffic.

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Bac= kman

AWS Identity

=C2=A0

=C2=A0

From: = Rifaat Shekh-Yusef &l= t;rifaat.ietf@gm= ail.com>
Date: Tuesday, December 3, 2019 at 5:21 AM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: = New Version Notification for draft-fett-oauth-dpop-03.txt

=C2=A0

=C2=A0

=C2=A0

On Mon, Dec 2, 2019 at 4:35 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

> Session cookies se= rve the same purpose in web apps as access tokens for APIs but there are mu= ch more web apps than APIs. I use the analogy to illustrate that either the= re are security issues with cloud deployments of web apps or the techniques used to secure web apps are ok for APIs as w= ell.

"Security issues" is a loaded term, but if you mean that there ar= e practical risks that are not addressed by bearer tokens (whether they be = session cookies or access tokens) then yes, I think we both agree that ther= e are. Otherwise we wouldn't be discussing PoP, sender-constrained tokens, etc. TLS-based solutions mitigate some ris= ks, while leaving others unmitigated. Depending on your use case and threat= model, these risks may or may not present practical threats. For my use ca= ses, they do.

Ultimately I'd like to mitigate these risks for both service APIs and w= eb applications. My focus is on service APIs for a couple reasons:

1. Interoperability is more important when the sender and recipient aren= 9;t necessarily owned by a single entity. I can do proprietary things in Ja= vaScript if I want to just as I can in client SDKs, but this breaks down if= my API implements a standard protocol and is expected to work with off-the-shelf clients and/or implementations = from other vendors.

2. Web applications are just a special subset of service APIs that happens = to be accessed via a browser. A solution for service APIs ought to be reusa= ble for web applications, or at least serve as a foundation for their solut= ion.

>=C2=A0 =C2=A0 - Have you seen this kind of proxies intercepting the con= nection from on-prem service deployments to service provider? I=E2=80=99m a= sking because I thought the main use case was to intercept employees PC int= ernet traffic.

I'm working from second-hand knowledge here, but like most things in th= e enterprise world, it depends. Separating employee device outbound traffic= from internal service outbound traffic requires some level of sophisticati= on, be it in network topology, routing rules, or configuration rules on the TLIS appliance.

=C2=A0

Yeah, many major enterprises have these kinds of ins= pection services, Take a look at the following example:

=C2=A0

=C2=A0

>=C2=A0 =C2=A0 - Are you saying this kind of prox= y does not support mutual TLS at all?

>From what I understand, at the very least mTLS is not universally suppo= rted.. There may be some vendors that support it, but it's not guarante= ed. The documentation for Symantec's SSL Visibility product [1] indicat= es that sessions using client certificates will be rejected unless they are exempted based on destination whitelistin= g

=C2=A0

Yes, that is my experience too.=C2=A0<= /p>

=C2=A0=C2=A0

(which is problematic when the destination may be a = general-purpose cloud service provider).

=C2=A0

Is there a use case that would require you to do tha= t?

If I have a service that is hosted on AWS, then the = exception would be for my service, not for AWS in general.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0


> On the other hand, I would expect these kind of proxy to understand a = lot about the protocols running through it, otherwise they cannot fulfil th= eir task of inspecting this traffic.

Maybe, maybe not. In any case there's a difference between understandin= g HTTP or SMTP or P2P-protocol-du-jour and understanding the application-le= vel protocol running on top of HTTP. There hasn't been any need for the= se proxies to understand OAuth 2.0 thus far.

[1]: https://origin-symwisedownload.symantec.com/resources/webguides/sslv/45/Con= tent/Topics/troubleshooting/Support_for_Client_Cert.htm
=E2=80=93
Annabelle Richard Backman
AWS Identity


On 12/1/19, 7:41 AM, "Torsten Lodderstedt" <torsten=3D40loddersted= t.net@dmarc.ietf.org> wrote:


=C2=A0 =C2=A0 Annabelle,

=C2=A0 =C2=A0 > Am 27.11.2019 um 02:46 schrieb Richard Backman, Annabell= e <richanna@ama= zon.com>:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Torsten,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I'm not tracking how cookies are relevant to the dis= cussion.

=C2=A0 =C2=A0 I=E2=80=99m still trying to understand why you and others arg= ue mTLS cannot be used in public cloud deployments (and thus focus on appli= cation level PoP).

=C2=A0 =C2=A0 Session cookies serve the same purpose in web apps as access = tokens for APIs but there are much more web apps than APIs. I use the analo= gy to illustrate that either there are security issues with cloud deploymen= ts of web apps or the techniques used to secure web apps are ok for APIs as well.

=C2=A0 =C2=A0 Here are the two main arguments and my conclusions/questions:= =C2=A0

=C2=A0 =C2=A0 1) mTLS it=E2=80=99s not end 2 end: although that=E2=80=99s t= rue from a connection perspective, there are solutions employed to secure t= he last hop(s) between TLS terminating proxy and service (private net, VPN,= TLS). That works and is considered secure enough for (session) cookies, it should be the same for access tokens.

=C2=A0 =C2=A0 2) TLS terminating proxies do not forward cert data: if the s= ervice itself terminates TLS this is feasible, we do it for our public-clou= d-hosted mTLS-protected APIs. If TLS termination is provided by a component= run by the cloud provider, the question is: is this component able to forward the client certificate to the service? I= f not, web apps using certs for authentication cannot be supported straight= way by the cloud provider. Any insights?

=C2=A0 =C2=A0 > I'm guessing that's because we're not on the= same page regarding use cases, so allow me to clearly state mine:

=C2=A0 =C2=A0 I think we are, we are just focusing on different ends of the= TLS tunnel. My focus is on the service provider=E2=80=99s side, esp. publi= c cloud hosting, whereas you are focusing on client side TLS terminating pr= oxies.

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The use case I am concerned with is requests between ser= vices where end-to-end TLS cannot be guaranteed. For example, an enterprise= service running on-premise, communicating with a service in the cloud, whe= re the enterprise's outbound traffic is routed through a TLS Inspection (TLSI) appliance. The TLSI appliance sits in the = middle of the communication, terminating the TLS session established by the= on-premise service and establishing a separate TLS connection with the clo= ud service.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > In this kind of environment, there is no end-to-end TLS = connection between on-premise service and cloud service, and it is very unl= ikely that the TLSI appliance is configurable enough to support TLS-based s= ender-constraint mechanisms without significantly compromising on the scope of "sender" (e.g., "this service = at this enterprise" becomes "this enterprise=E2=80=9D).

=C2=A0 =C2=A0 I=E2=80=99m not familiar with these kind of proxies, but happ= y to learn more and to discuss potential solutions.

=C2=A0 =C2=A0 Here are some questions:
=C2=A0 =C2=A0 - Have you seen this kind of proxies intercepting the connect= ion from on-prem service deployments to service provider? I=E2=80=99m askin= g because I thought the main use case was to intercept employees PC interne= t traffic.
=C2=A0 =C2=A0 - Are you saying this kind of proxy does not support mutual T= LS at all? At least theoretically, the proxy could combine source and desti= nation to select a cert/key pair to use for outbound TLS client authenticat= ion.

=C2=A0 =C2=A0 > Even if it is possible, it is likely to require advanced= configuration that is non-trivial for administrators to deploy. It's n= o longer as simple as the developer passing a self-signed certificate to th= e HTTP stack.

=C2=A0 =C2=A0 I agree. Cert binding is established in OAuth protocol messag= es, which would require the appliance to understand the protocol. On the ot= her hand, I would expect these kind of proxy to understand a lot about the = protocols running through it, otherwise they cannot fulfil their task of inspecting this traffic.

=C2=A0 =C2=A0 best regards,
=C2=A0 =C2=A0 Torsten.



=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > =E2=80=93
=C2=A0 =C2=A0 > Annabelle Richard Backman
=C2=A0 =C2=A0 > AWS Identity
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On 11/23/19, 9:50 AM, "Torsten Lodderstedt" &l= t;torsten@lodd= erstedt.net> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >>>>>>>>> On 23. Nov 2019, at 00:3= 4, Richard Backman, Annabelle <richanna@amazon.com> wrote:
=C2=A0 =C2=A0 >>>>>>>>> how are cookies protecte= d from leakage, replay, injection in a setup like this?
=C2=A0 =C2=A0 >> They aren=E2=80=99t.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Thats very interesting when compared to what we are disc= ussing with respect to API security.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > It effectively means anyone able to capture a session co= okie, e.g. between TLS termination point and application, by way of an HTML= injection, or any other suitable attack is able to impersonate a legitimat= e user by injecting the cookie(s) in an arbitrary user agent. The impact of such an attack might be even worse than abusing = an access token given the (typically) broad scope of a session.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > TLS-based methods for sender constrained access tokens, = in contrast, prevent this type of replay, even if the requests are protecte= d between client and TLS terminating proxy, only. Ensuring the authenticity= of the client certificate when forwarded from TLS terminating proxy to service, e.g. through another authenticated TLS c= onnection, will even prevent injection within the data center/cloud environ= ment.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I come to the conclusion that we already have the mechan= ism at hand to implement APIs with a considerable higher security level tha= n what is accepted today for web applications. So what problem do we want t= o solve?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >> But my primary concern here isn't web browser tr= affic, it's calls from services/apps running inside a corporate network= to services outside a corporate network (e.g., service-to-service API call= s that pass through a corporate TLS gateway).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Can you please describe the challenges arising in these = settings? I assume those proxies won=E2=80=99t support CONNECT style pass t= hrough otherwise we wouldn=E2=80=99t talk about them.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >>> That=E2=80=99s a totally valid point. But again,= such a solution makes the life of client developers harder.
=C2=A0 =C2=A0 >>> I personally think, we as a community need to un= derstand the pros and cons of both approaches. I also think we have not eve= n come close to this point, which, in my option, is the prerequisite for ma= king informed decisions.
=C2=A0 =C2=A0 >> Agreed. It's clear that there are a number of pa= rties coming at this from a number of different directions, and that's = coloring our perceptions. That's why I think we need to nail down the s= cope of what we're trying to solve with DPoP before we can have a productive conversation how it should work.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > We will do so.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >> =E2=80=93
=C2=A0 =C2=A0 >> Annabelle Richard Backman
=C2=A0 =C2=A0 >> AWS Identity
=C2=A0 =C2=A0 >> On 11/22/19, 10:51 PM, "Torsten Lodderstedt&quo= t; <torsten= @lodderstedt.net> wrote:
=C2=A0 =C2=A0 >>>> On 22. Nov 2019, at 22:12, Richard Backman, = Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >>> The service provider doesn't own the entire = connection. They have no control over corporate or government TLS gateways,= or other terminators that might exist on the client's side. In larger = organizations, or when cloud hosting is involved, the service team may not even own all the hops on their side.
=C2=A0 =C2=A0 >> how are cookies protected from leakage, replay, inje= ction in a setup like this?
=C2=A0 =C2=A0 >>> While presumably they have some trust in them, p= rotection against leaked bearer tokens is an attractive defense-in-depth me= asure.
=C2=A0 =C2=A0 >> That=E2=80=99s a totally valid point. But again, suc= h a solution makes the life of client developers harder.
=C2=A0 =C2=A0 >> I personally think, we as a community need to unders= tand the pros and cons of both approaches. I also think we have not even co= me close to this point, which, in my option, is the prerequisite for making= informed decisions.
=C2=A0 =C2=A0 >>> =E2=80=93
=C2=A0 =C2=A0 >>> Annabelle Richard Backman
=C2=A0 =C2=A0 >>> AWS Identity
=C2=A0 =C2=A0 >>> On 11/22/19, 9:37 PM, "OAuth on behalf of T= orsten Lodderstedt" <oauth-bounces@ietf.org on behalf of torsten=3D40lodderstedt.ne= t@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >>>> On 22. Nov 2019, at 21:21, Richard Backman, = Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >>>> The dichotomy of "TLS working" and= "TLS failed" only applies to a single TLS connection. In non-end= -to-end TLS environments, each TLS terminator between client and RS introdu= ces additional token leakage/exfiltration risk, irrespective of the quality of the TLS connections themselves. Each terminator also introduces complex= ity for implementing mTLS, Token Binding, or any other TLS-based sender con= straint solution, which means developers with non-end-to-end TLS use cases = will be more likely to turn to DPoP.
=C2=A0 =C2=A0 >>> The point is we are talking about different deve= lopers here. The client developer does not need to care about the connectio= n between proxy and service. She relies on the service provider to get it r= ight. So the developers (or DevOps or admins) of the service provider need to ensure end to end security. And if the path is se= cured once, it will work for all clients.
=C2=A0 =C2=A0 >>>> If DPoP is intended to address "cases w= here neither mTLS nor OAuth Token Binding are available" [1], then it = should address this risk of token leakage between client and RS. If on the = other hand DPoP is only intended to support the SPA use case and assumes the use of end-to-end TLS, then the document should be updated to = reflect that.
=C2=A0 =C2=A0 >>> I agree.
=C2=A0 =C2=A0 >>>> [1]: https://tools.ietf.org/html/draft-fett-oauth-dpop-03#section-1
=C2=A0 =C2=A0 >>>> =E2=80=93
=C2=A0 =C2=A0 >>>> Annabelle Richard Backman
=C2=A0 =C2=A0 >>>> AWS Identity
=C2=A0 =C2=A0 >>>> On 11/22/19, 8:17 PM, "OAuth on behalf = of Torsten Lodderstedt" <oauth-bounces@ietf.org on behalf of torsten=3D40loddersted= t.net@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >>>> Hi Neil,
=C2=A0 =C2=A0 >>>>> On 22. Nov 2019, at 18:08, Neil Madden &= lt;neil.madd= en@forgerock.com> wrote:
=C2=A0 =C2=A0 >>>>> On 22 Nov 2019, at 07:53, Torsten Lodder= stedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >>>>>>> On 22. Nov 2019, at 15:24, Justi= n Richer <jricher@m= it.edu> wrote:
=C2=A0 =C2=A0 >>>>>>> I=E2=80=99m going to +1 Dick and= Annabelle=E2=80=99s question about the scope here. That was the one major = thing that struck me during the DPoP discussions in Singapore yesterday: we= don=E2=80=99t seem to agree on what DPoP is for. Some (including the autho= rs, it seems) see it as a quick point-solution to a specific use case. Others see it as = a general PoP mechanism.
=C2=A0 =C2=A0 >>>>>>> If it=E2=80=99s the former, then= it should be explicitly tied to one specific set of things. If it=E2=80=99= s the latter, then it needs to be expanded.
=C2=A0 =C2=A0 >>>>>> as a co-author of the DPoP draft I s= tate again what I said yesterday: DPoP is a mechanism for sender-constraini= ng access tokens sent from SPAs only. The threat to be prevented is token r= eplay.
=C2=A0 =C2=A0 >>>>> I think the phrase "token replay&qu= ot; is ambiguous. Traditionally it refers to an attacker being able to capt= ure a token (or whole requests) in use and then replay it against the same = RS. This is already protected against by the use of normal TLS on the connection between the client and the RS. I think instead you are referrin= g to a malicious/compromised RS replaying the token to a different RS - whi= ch has more of the flavour of a man in the middle attack (of the phishing k= ind).
=C2=A0 =C2=A0 >>>> I would argue TLS basically prevents leakage= and not replay. The threats we try to cope with can be found in the Securi= ty BCP. There are multiple ways access tokens can leak, including referrer = headers, mix-up, open redirection, browser history, and all sorts of access token leakage at the resource server
=C2=A0 =C2=A0 >>>> Please have a look at https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.
=C2=A0 =C2=A0 >>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8= also has an extensive discussion of potential counter measures, includ= ing audience restricted access tokens and a conclusion to recommend sender = constrained access tokens over other mechanisms.
=C2=A0 =C2=A0 >>>>> But if that's the case then there ar= e much simpler defences than those proposed in the current draft:
=C2=A0 =C2=A0 >>>>> 1. Get separate access tokens for each R= S with correct audience and scopes. The consensus appears to be that this i= s hard to do in some cases, hence the draft.
=C2=A0 =C2=A0 >>>> How many deployments do you know that today = are able to issue RS-specific access tokens?
=C2=A0 =C2=A0 >>>> BTW: how would you identify the RS?
=C2=A0 =C2=A0 >>>> I agree that would be an alternative and I= =E2=80=99m a great fan of such tokens (and used them a lot at Deutsche Tele= kom) but in my perception this pattern needs still to be established in the= market. Moreover, they basically protect from a rough RS (if the URL is used as audience) replaying the token someplace else, but they do n= ot protect from all other kinds of leakage/replay (e.g. log files).
=C2=A0 =C2=A0 >>>>> 2. Make the DPoP token be a simple JWT w= ith an "iat" and the origin of the RS. This stops the token being= reused elsewhere but the client can reuse it (replay it) for many requests= ..
=C2=A0 =C2=A0 >>>>> 3. Issue a macaroon-based access token a= nd the client can add a correct audience and scope restrictions at the poin= t of use.
=C2=A0 =C2=A0 >>>> Why is this needed if the access token is al= ready audience restricted? Or do you propose this as alternative?
=C2=A0 =C2=A0 >>>>> Protecting against the first kind of rep= lay attacks only becomes an issue if we assume the protections in TLS have = failed. But if DPoP is only intended for cases where mTLS can't be used= , it shouldn't have to protect against a stronger threat model in which we assume that TLS security has been lost.
=C2=A0 =C2=A0 >>>> I agree.
=C2=A0 =C2=A0 >>>> best regards,
=C2=A0 =C2=A0 >>>> Torsten.
=C2=A0 =C2=A0 >>>>> -- Neil


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

--000000000000bd60df0598f35dba-- From nobody Thu Dec 5 08:27:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D42D12013A for ; Thu, 5 Dec 2019 08:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.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 EIF1-3H8Acgt for ; Thu, 5 Dec 2019 08:27:37 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D32120130 for ; Thu, 5 Dec 2019 08:27:37 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8164733203F for ; Thu, 5 Dec 2019 11:27:36 -0500 (EST) Received: from smtprhbv1.mitre.org (unknown [129.83.19.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpvbsrv1.mitre.org (Postfix) with ESMTPS id 7267B33203D for ; Thu, 5 Dec 2019 11:27:36 -0500 (EST) Received: from mbfesmtp-mgt.mitre.org (unknown [198.49.146.235]) by smtprhbv1.mitre.org (Postfix) with ESMTP id 6E13980BE9B for ; Thu, 5 Dec 2019 11:27:36 -0500 (EST) Received: by mbfesmtp-mgt.mitre.org (Postfix, from userid 600) id 47TLjN35HTzl1Y; Thu, 5 Dec 2019 16:27:31 +0000 (UTC) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02lp2106.outbound.protection.outlook.com [104.47.65.106]) by mbfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 47TLjC06w9zl39 for ; Thu, 5 Dec 2019 16:27:27 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OaQgukZJIwLuYxpSvoRJFNXROZ7HPlnM6odbUDpVgPhIOg9TCQOFmAFuNESAFQwdExAvFT+SWOzLx1LG+5VjrIOZtAOPpWiXS5rDcV8DFNFCL3Up7+Mj5YS5+FyqoYuMVxT5Lof3tlv0m+k4HDIVCDBbWRa3oHnyGrz9bmeqCoEVGKBm5ibo04Daugtm5BuH7kBsy10iS7Ga0XVGO0pmER9qhUG8JamSJdH/k0Dhq+tVxfSHvVrDENvcp3aKcV6Yw+PuxB4Ennm3h+rtymUDNu9nVQz9Er6NmKy7VynwDy7P9a6V/1/fOwfTGBgVtiPBiaE0fXbHrNfnk8RBC1MFTw== 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=XX/bJe2pANYuBZmHiSG2Hc4nB+Bv8CqlYmUGkF37+do=; b=IUwaRpHRJX+UaRhCeEAe8KNQuXmsX4QwLBQYNbCHKMXP/XUvwASPGz7+Z8PA4ky5S43OKPu01yLXtfbAx+vvGOFCRsSEWWj/ZrMyuMpT5j2pX/w714DHRDHpcqTb976a0cwtDYJTmXpu0onQQnOIHNLyOiHiP1/+2UpU7IneMTVIq+LJo9yxGuqiOHEzgeobK8nqclYZxhCMosMEI1T6K/hciXUOosN+sZW/mXOrdshBPZwn8XaW/3CtU7GhUK3h0T7CvbWlmfpJbxIix1oQE65qAvbMTmSH6LQsi/ThODx0OGe/9WqDgMi+Nqs3+4KZv7YfATu2r57SsROn+7/Jhg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from BL0PR0901MB4435.namprd09.prod.outlook.com (52.135.45.75) by BL0PR0901MB2516.namprd09.prod.outlook.com (52.132.19.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.21; Thu, 5 Dec 2019 16:27:25 +0000 Received: from BL0PR0901MB4435.namprd09.prod.outlook.com ([fe80::dd58:fb2f:b6bf:9394]) by BL0PR0901MB4435.namprd09.prod.outlook.com ([fe80::dd58:fb2f:b6bf:9394%7]) with mapi id 15.20.2516.014; Thu, 5 Dec 2019 16:27:25 +0000 From: "Peck, Michael A" To: "oauth@ietf.org" Thread-Topic: Comments on draft-ietf-oauth-security-topics-13 Thread-Index: AQHVo6/pGuyf7IJtTkumwEWcFNIHMg== Date: Thu, 5 Dec 2019 16:27:25 +0000 Message-ID: <7E7543E9-E0F6-43C8-BA51-DA5F4F93FC1B@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mpeck@mitre.org; x-originating-ip: [192.80.55.88] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0f1eafa7-7206-4309-8278-08d779a0037e x-ms-traffictypediagnostic: BL0PR0901MB2516: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02426D11FE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(199004)(189003)(8936002)(14444005)(58126008)(1730700003)(15650500001)(305945005)(6512007)(6916009)(5640700003)(14454004)(2616005)(25786009)(498600001)(99286004)(5660300002)(186003)(6506007)(6486002)(8676002)(86362001)(2906002)(71200400001)(81156014)(102836004)(81166006)(71190400001)(66946007)(66446008)(66476007)(64756008)(36756003)(76116006)(66556008)(33656002)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR0901MB2516; H:BL0PR0901MB4435.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KS9KIOmTVk6lgj80Wc3dqisj/R4NnWmnKsjAs2DJIMaJ5lIpw7+OsB0YJ9vE0nLynGD/uE4iEyWgtdAuvA6rAw6tUgBzj8Tl3PYHySOIB5UgUiU7MN5v8d60ZWFNKr6PZanYNMOdasF0PQaw0H4E9qA9QhXMZxo97tieQbkPD7fYAy0Y9e6xeJBBA+ufGdhaS0Aptvi0ahP0BJKWRfKQFbDZF9oMB76uY8b4WUsDy0jZUAvmV4t8A3KhkOMN1JZs9cDF8s2ulPrOfdwkpik25+PjYC6z2Ie0H2eVWDioIkELT6h2whjTFnPGStYe2pqlC2S8Ai26GOwKkah+UxBVS2nSf7TdbsU3D/SLLwnjlQOg3rRQZJWjAUiYcdrQDfJk3GPOObHZM2qCXDM8emcvRTi9r/cUJWDPD33SXZ6xfBZ6Ce9Hbw2hCGE14Mt13FIz x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3D19D2907A7C1B4CBEEFC1AED006FEE4@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-Network-Message-Id: 0f1eafa7-7206-4309-8278-08d779a0037e X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2019 16:27:25.4703 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ghOc7bSRmpcbjflv/fBcyt9gO/tFr0Yo60Lpj34tjrNIaBx5wxGYkFTyuWafoMs0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB2516 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:subject:date:message-id:content-type:content-id:content-transfer-encoding:mime-version; s=selector1; bh=XX/bJe2pANYuBZmHiSG2Hc4nB+Bv8CqlYmUGkF37+do=; b=wKvccF8E2znL8HqMBvVHpzinqn5V1fN5vK/6gxwVxgRN2yO18GMxBtg84NCKHNru72pNqdm8okiGmnNH1aFzmWXkrOgoYMG0xhQxYP3CFL2xJZUsJGJDdNMvc8TG+vaNslBPQexdQRKJ8vZeHmEJnnYB0Ifid4U2kOe6KWA/z1Q= Archived-At: Subject: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-13 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 16:27:40 -0000 VGhhbmsgeW91IGZvciB3cml0aW5nIHRoaXMgQkNQLiBJIGJlbGlldmUgaXQgcHJvdmlkZXMgaW1w b3J0YW50IGd1aWRhbmNlIGFuZCBzdXBwb3J0IGl0cyBwdWJsaWNhdGlvbi4NCg0KSSBoYXZlIHRo ZSBmb2xsb3dpbmcgY29tbWVudHMgb24gZHJhZnQgLTEzOg0KDQpPdmVyYWxsOg0KVGhlIGRyYWZ0 IHVzZXMgdGhlIHRlcm0g4oCcYWR2ZXJzYXJ54oCdICgzIHRpbWVzKSBhbmQgdGhlIHRlcm0g4oCc YXR0YWNrZXLigJ0gKD4xMDAgdGltZXMpLiBJIHN1Z2dlc3QgdXNpbmcgb25lIHRlcm0gY29uc2lz dGVudGx5Lg0KDQpNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBkb2N1bWVudCBzdHJ1Y3R1cmUgaXMg dGhhdCBTZWN0aW9uIDMgcHJvdmlkZXMgc3BlY2lmaWMgaW1wbGVtZW50YWJsZSByZWNvbW1lbmRh dGlvbnMgdXAtZnJvbnQsIHdoaWxlIFNlY3Rpb24gNCBkZXNjcmliZXMgaW4gZGV0YWlsIHRoZSB0 aHJlYXRzIHRoYXQgcHJvdmlkZSB0aGUgcmF0aW9uYWxlIGZvciB0aG9zZSByZWNvbW1lbmRhdGlv bnMgYWxvbmcgd2l0aCBhIGRpc2N1c3Npb24gb2YgdmFyaW91cyBwb3RlbnRpYWwgY291bnRlcm1l YXN1cmVzIGFuZCB0aGVpciB0cmFkZW9mZnMuIElmIHRoYXQgdW5kZXJzdGFuZGluZyBpcyBjb3Jy ZWN0LCBJIGJlbGlldmUgbXVjaCBvZiB0aGUgc3BlY2lmaWMgcmVjb21tZW5kYXRpb24gdGV4dCBp biB0aGUgY291bnRlcm1lYXN1cmVzIHNlY3Rpb25zICg0LjEuMywgNC4yLjQsIDQuNC4yLCA0LjUu Mykgd291bGQgYmUgYSBiZXR0ZXIgZml0IGluIFNlY3Rpb24gMy4NCg0KU2VjdGlvbiAzLjU6DQpJ dCBpcyBub3QgY2xlYXIgdG8gbWUgaG93IE1UTFMgb3Ig4oCccHJpdmF0ZV9rZXlfand04oCdIHBy b3ZpZGUgbm9uLXJlcHVkaWF0aW9uLCBvciB3aGF0IGl0IGlzIHRoYXQgbm9uLXJlcHVkaWF0aW9u IGlzIGJlaW5nIHByb3ZpZGVkIGZvci4gQ291bGQgeW91IGV4cGxhaW4gb3IgY29uc2lkZXIgcmVt b3ZpbmcgdGhlIG5vbi1yZXB1ZGlhdGlvbiBkaXNjdXNzaW9uPw0KDQpJdCBpcyBjbGVhciB0byBt ZSBob3cgTVRMUyBlbmFibGVzIHVzZSBvZiBzZW5kZXItY29uc3RyYWluZWQgYWNjZXNzIHRva2Vu cy4gSG93ZXZlciBpdOKAmXMgbm90IGNsZWFyIHRvIG1lIGhvdyBwcml2YXRlX2tleV9qd3QgZG9l cyBzbyDigJMgYXQgbGVhc3Qgbm90IHdpdGhvdXQgc29tZXRoaW5nIGxpa2UgRFBvUCB0aGF0IGhh c27igJl0IHlldCBiZWVuIGZpbmFsaXplZD8gDQoNCk1heWJlIGNoYW5nZSB0aGUgdGV4dCB0byBz b21ldGhpbmcgbGlrZSDigJxBZGRpdGlvbmFsbHksIE1UTFMgZW5hYmxlcyB1c2Ugb2Ygc2VuZGVy LWNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMgKHdpdGhvdXQgcmVxdWlyaW5nIGFkZGl0aW9uYWwg a2V5cyB0byBiZSBkaXN0cmlidXRlZCku4oCdPw0KDQpTZWN0aW9uIDQuNToNCuKAnEluIHN1Y2gg YW4gYXR0YWNrLCB0aGUgYWR2ZXJzYXJ5IGF0dGVtcHRzIHRvIGluamVjdCBhIHN0b2xlbiBhdXRo b3JpemF0aW9uIGNvZGUgaW50byBhIGxlZ2l0aW1hdGUgY2xpZW50IG9uIGEgZGV2aWNlIHVuZGVy IGhpcyBjb250cm9sLuKAnQ0KDQpUaGlzIHRleHQgaW1wbGllcyB0byBtZSB0aGF0IHRoZSBjbGll bnQgaXMgcnVubmluZyBvbiBhIGRldmljZSB1bmRlciB0aGUgYWR2ZXJzYXJ54oCZcyBjb250cm9s IChidXQgdGhhdCB0aGUgYWR2ZXJzYXJ5IHByZXN1bWFibHkgY2Fu4oCZdCBkaXJlY3RseSBjb250 cm9sIHRoZSBjbGllbnTigJlzIGJlaGF2aW9yKT8gQnV0IEkgdGhpbmsgdGhlIGludGVudGlvbiBp cyB0aGF0IHRoZSBhZHZlcnNhcnkgaXMgdXNpbmcgYSBkZXZpY2UvdXNlciBhZ2VudCB1bmRlciB0 aGUgYWR2ZXJzYXJ54oCZcyBjb250cm9sIHRvIHBlcmZvcm0gdGhlIGNvZGUgaW5qZWN0aW9uLCBu b3QgdGhhdCB0aGUgY2xpZW50IGlzIHJ1bm5pbmcgb24gdGhlIGFkdmVyc2FyeeKAmXMgZGV2aWNl PyAoZS5nLiBwcmV2aW91c2x5IGRpc2N1c3NlZCBjdXQgYW5kIHBhc3RlIGF0dGFja3Mgd2hlcmUg dGhlIGFkdmVyc2FyeSBoYXMgYSBzZXNzaW9uIHdpdGggdGhlIGNsaWVudCBhbmQgaW5qZWN0cyBh IHN0b2xlbiBhdXRob3JpemF0aW9uIGNvZGUgaW50byB0aGF0IHNlc3Npb24pDQoNCklmIEnigJlt IHVuZGVyc3RhbmRpbmcgY29ycmVjdGx5IGhvdyBhYm91dCB0ZXh0IGxpa2Ug4oCcSW4gc3VjaCBh biBhdHRhY2ssIHRoZSBhZHZlcnNhcnkgYXR0ZW1wdHMgdG8gaW5qZWN0IGEgc3RvbGVuIGF1dGhv cml6YXRpb24gY29kZSBpbnRvIHRoZSBhZHZlcnNhcnnigJlzIG93biBzZXNzaW9uIHdpdGggdGhl IGNsaWVudCwgaW4gYW4gYXR0ZW1wdCB0byBhc3NvY2lhdGUgdGhlIGFkdmVyc2FyeeKAmXMgc2Vz c2lvbiB3aXRoIHRoZSBjbGllbnQgdG8gdGhlIHZpY3RpbeKAmXMgcmVzb3VyY2VzIG9yIGlkZW50 aXR5LuKAnT8NCg0KU2VjdGlvbiA0LjUuMToNCuKAnFRoZSBhdHRhY2tlciBvYnRhaW5zIGFuIGF1 dGhvcml6YXRpb24gY29kZSBieSBwZXJmb3JtaW5nIGFueSBvZiB0aGUgYXR0YWNrcyBkZXNjcmli ZWQgYWJvdmUu4oCdDQpTZWN0aW9uIDQuNSBzYXlzIOKAnGFuIGF0dGFja2VyIHdpdGggYWR2YW5j ZWQgY2FwYWJpbGl0aWVzIChBMy1BNSnigJ0gYXJlIG91dCBvZiBzY29wZSwgYnV0IHdvdWxkIHRo b3NlIGFkdmFuY2VkIGNhcGFiaWxpdGllcyAoZS5nLiBBMyDigJMgYWJpbGl0eSB0byByZWFkIHRo ZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlKSBwb3RlbnRpYWxseSBiZSB1c2VmdWwgdG8gc3RlYWwg dGhlIGF1dGhvcml6YXRpb24gY29kZT8gU2hvdWxkIHRoZSB0ZXh0IGFib3V0IGF0dGFja2VyIGNh cGFiaWxpdGllcyBBMy1BNSBiZWluZyBvdXQgb2Ygc2NvcGUgYmUgcmVtb3ZlZD8NCg0KU2VjdGlv biA0LjUuMzoNCkl0IG1heSBiZSB3b3J0aCBub3RpbmcgdGhhdCBQS0NFIGlzIHZlcmlmaWVkIGJ5 IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgd2hpbGUgdGhlIE9wZW5JRCBDb25uZWN0IG5vbmNl IGlzIHZlcmlmaWVkIGJ5IHRoZSBjbGllbnQuIFRoZXJlIGNvdWxkIGJlIGFuIGFyZ3VtZW50IHRv IGJlIG1hZGUgdGhhdCBhdXRob3JpemF0aW9uIHNlcnZlcnMgYXJlIG1vcmUgbGlrZWx5IHRoYW4g Y2xpZW50cyB0byBwcm9wZXJseSBpbXBsZW1lbnQgY2hlY2tzIChlLmcuIHRoZSBwYXBlcnMgY2l0 ZWQgaW4gc2VjdGlvbiA0LjguMS4xPyksIGFuZCBzbyBQS0NFIHNob3VsZCBiZSBwcmVmZXJyZWQu IFRoZXJlIGNvdWxkIGFsc28gYmUgYSBkZWZlbnNlLWluLWRlcHRoIGFyZ3VtZW50IHRvd2FyZHMg dXNpbmcgYm90aCBQS0NFIGFuZCBub25jZS4NCg0K4oCcUEtDRSBpcyBhIGRlcGxveWVkIE9BdXRo IGZlYXR1cmUsIGV2ZW4gdGhvdWdoIGl0IGlzIHVzZWQgdG9kYXkgdG8gc2VjdXJlIG5hdGl2ZSBh cHBzIG9ubHku4oCdDQpUaGF0IGlzIG5vdCBuZWNlc3NhcmlseSB0cnVlIGFueW1vcmUgKHRoZSBy ZWNvbW1lbmRhdGlvbnMgaW4gdGhpcyBkcmFmdCBhcmUgYWxyZWFkeSBiZWluZyBhZG9wdGVkIGlu IG90aGVyIHdvcmsgc3VjaCBhcyBGQVBJKS4gSG93IGFib3V0IHNvbWV0aGluZyBsaWtlOg0K4oCc UEtDRSBpcyBhIGRlcGxveWVkIE9BdXRoIGZlYXR1cmUsIGFsdGhvdWdoIGl0cyBvcmlnaW5hbCBp bnRlbmRlZCB1c2Ugd2FzIHNvbGVseSBmb2N1c2VkIG9uIHNlY3VyaW5nIG5hdGl2ZSBhcHBzLCBu b3QgdGhlIGJyb2FkZXIgdXNlIHJlY29tbWVuZGVkIGJ5IHRoaXMgZG9jdW1lbnQu4oCdDQoNClNl Y3Rpb24gNC42Og0KU2ltaWxhciBjb25jZXJucyBhYm91dCB0aGUg4oCcb24gYSBkZXZpY2UgdW5k ZXIgaGlzIGNvbnRyb2zigJ0gdGV4dCBhcyBleHByZXNzZWQgYWJvdmUgZm9yIHNlY3Rpb24gNC41 Lg0KDQpUaGFua3MsDQpNaWtlDQoNCg== From nobody Tue Dec 10 18:29:09 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA101200F5 for ; Tue, 10 Dec 2019 18:29:06 -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_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YR3oZ5Ki6ubi for ; Tue, 10 Dec 2019 18:29:04 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC740120059 for ; Tue, 10 Dec 2019 18:29:03 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id d16so22267557wre.10 for ; Tue, 10 Dec 2019 18:29:03 -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=mxjk57s6MD42qAN2qwyyT65jNeeyyNhDlJyyYZ5JKR4=; b=sR7hJXcKXhmS4a1cTWXrVGbzvP6H0HeYC5zrsm5yImBG+aq2tKBPsvpQCD+Ctj02Vj hF8/y0npZxZBCSnqMvgCzBtdb/++kV/xQDO0xaXocN6p1VnB5OB5rhWApiaJTZ/hIBF3 iYcidFY3mCWlpd0lY/rUWmEybQhneKIBOUPZqt462OZUKhyZ0eIvWd3jf+FnWcOsRQkI ewVglq6TGCJ4R+H7jdHFvDigu7JMsI0eddN/IfiAteynBJswJ2IlIoBOy7ysTDVfcz0i jBJVDIoF7l1jPxm5sHgqeDyXexT1e/9X5ebBrL6o5td5CBsVfCRqhjamGj/YvAqUycPf W8Ug== 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=mxjk57s6MD42qAN2qwyyT65jNeeyyNhDlJyyYZ5JKR4=; b=jVoBMyXwND/xsVUXz2BlaxJ4VCcJ8HBORDWyQU/c7/VUci70hOGgbwaVD0ayVP+OHW GefMpJpQ84K2wrhgTJElJ5pmcImLT7F8UF6Jn3zM870kb/cMNeT/eGlk6K2PVhBQLFwO 0gtzd0cLnySv7w6M9BB4B6gISiSs+wQ3XIkLgbJuVcEaCNhRS59XiHueRT+NSnoJlHzt eMMKnQOaiOh4WwkhwtwS5S5UadbZW7heW8MAcy2+zdCH5+4Ynu3M1UU7hUOACGZBx12K MUBEoCh7AvMd1hO7HTGcTNZhhVkwd2SdGP3yDHlCNlYIEM+GCY7j/7OWTS4A0rGEYCnf uYmA== X-Gm-Message-State: APjAAAUnczXrSnT7XK1bXWDJAqCpG4FsZEDgTJn0vdWnjlnlY1yMpngr 3k2/oGAXpB1Usr0SUK8+23bzrhAcgZWl5sZcLnw= X-Google-Smtp-Source: APXvYqxT8SILb2tZ2mF4/ejrz2oo4c3kCZs1EY+RH8o2CP1KOFli/N6VLRYySg1W03bkZiPlFOcd535RCchTbRFhEdk= X-Received: by 2002:a5d:4b45:: with SMTP id w5mr753303wrs.224.1576031341778; Tue, 10 Dec 2019 18:29:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Wed, 11 Dec 2019 11:28:46 +0900 Message-ID: To: Brian Campbell Cc: Filip Skokan , Nat Sakimura , oauth Content-Type: multipart/alternative; boundary="000000000000481b8505996464fa" Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 02:29:07 -0000 --000000000000481b8505996464fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Correct. The WG supported the precedence approach and even merge just like OIDC as it is very useful from the implementation point of view and helps with a bunch of deployment patter. The push back came in from the Ben Campbell=E2=80=99s DISCUSS. See https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actual= ly-specifies-the I am willing to go either way as long as people agree. My slight preference is to the original approach. Best, Nat Sakimura 2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell : > FWIW, as best I can remember the change in question came as I result of d= irectorate/IESG > review rather than a WG decision/discussion. Which is likely why you can'= t > find the "why" anywhere in the mailing list archive. > > On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan wrote: > >> Well it kind of blows, doesn't it? I wasn't able to find the "why" >> anywhere in the mailing list archive around the time this was changed. >> >> My take on satisfying both worlds looks like this >> >> - allow just JAR - no other params when possible. >> (which btw isn't possible to do with request_uri when enforcing >> client based uri whitelist and the jwsreq 5.2.2 shows as much) >> - enforce the "dupe behaviours" defined in OIDC (if response_type or >> client_id is in request object it must either be missing or the same in >> regular request). >> - allows merging request object and regular parameters with request >> object taking precedence since it is a very useful feature when having >> pre-signed request object that's not one time use and clients using it w= ish >> to vary state/nonce per-request. >> >> I wish the group reconsidered making this breaking change from OIDC's >> take on request objects - allow combination of parameters from the reque= st >> object with ones from regular parameters (if not present in request obje= ct). >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Wed, 28 Aug 2019 at 23:02, Brian Campbell >> wrote: >> > Filip, for better or worse, I believe your assessment of the situation is >>> correct. I know of one AS that didn't choose which of the two to follow= but >>> rather implemented a bit of a hybrid where it basically ignores everyth= ing >>> outside of the request object per JAR but also checks for and enforces = the >>> presence and value of the few regular parameters (client_id, response_t= ype) >>> that OIDC mandates. >>> >>> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan wrote= : >>> >>>> Hello everyone, >>>> >>>> in an earlier thread I've posed the following question that might have >>>> gotten missed, this might have consequences for the existing >>>> implementations of Request Objects in OIDC implementations - its makin= g >>>> pure JAR requests incompatible with OIDC Core implementations. >>>> >>>> draft 14 of jwsreq (JAR) introduced this language >>>> >>>> The client MAY send the parameters included in the request object >>>>> duplicated in the query parameters as well for the backward >>>>> compatibility etc. >>>>> >>>>> *However, the authorization server supporting thisspecification MUST >>>>> only use the parameters included in the requestobject. * >>>> >>>> >>>> Server MUST only use the parameters in the Request Object even if the >>>>> same parameter is provided in the query parameter. The Authorization >>>> >>>> >>>> The client MAY send the parameters included in the request object >>>>> duplicated in the query parameters as well for the backward >>>>> compatibility etc. >>>>> >>>>> *However, the authorization server supporting thisspecification MUST >>>>> only use the parameters included in the requestobject. * >>>> >>>> >>>> Nat, John, everyone - *does this mean a JAR compliant AS ignores >>>> everything outside of the request object while OIDC Request Object one >>>> merges the two with the ones in the request object being used over one= s >>>> that are sent in clear?* The OIDC language also includes sections >>>> which make sure that some required arguments are still passed outside = of >>>> the request object with the same value to make sure the request is "va= lid" >>>> OAuth 2.0 request (client_id, response_type), something which an examp= le in >>>> the JAR spec does not do. Not having this language means that existing >>>> authorization request pipelines can't simply be extended with e.g. a >>>> middleware, they need to branch their codepaths. >>>> >>>> Is an AS required to choose which of the two it follows? >>>> >>>> Thank you for clarifying this in advance. I think if either the >>>> behaviour is the same as in OIDC or different this should be called ou= t in >>>> the language to avoid confusion, especially since this already exists = in >>>> OIDC and likely isn't going to be read in isolation, especially becaus= e the >>>> Request Object is even called out to be already in place in OIDC in th= e JAR >>>> draft. >>>> >>>> Best, >>>> *Filip* >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d. >>> 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 f= rom >>> your computer. Thank you.* >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --000000000000481b8505996464fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Correct. The WG supported the precedence approa= ch and even merge just like OIDC as it is very useful from the implementati= on point of view and helps with a bunch of deployment patter.=C2=A0

The push back came in fro= m the Ben Campbell=E2=80=99s DISCUSS.=C2=A0
See=C2= =A0

I am willing to go either way as long as = people agree. My slight preference is to the original approach.=C2=A0
=

Best,=C2=A0

Nat Sakimura

2019=E5=B9=B48=E6= =9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell <bcampbell=3D40pingidentity= .com@dmarc.ietf.org>:
FWIW, as best I can rem= ember the change in question came as I result of directorate/IESG rev= iew rather than a WG decision/discussion. Which is likely why you can't= find the "why" anywhere in the mailing list archive.
=

On Wed, Aug 28, 2019 at 3:23 PM Filip Skok= an <panva.ip@gma= il.com> wrote:
Well it kind of blows, doesn't it? I wasn't able to= find the "why" anywhere in the mailing list archive around the t= ime this was changed.

My take on satisfying both w= orlds looks like this

- allow just JAR - no other = params when possible.
=C2=A0 =C2=A0 (which btw isn't possible= to do with request_uri when enforcing client based uri whitelist and the j= wsreq 5.2.2 shows as much)
- enforce the "dupe behaviours&qu= ot; defined in OIDC (if response_type or client_id is in request object it = must either be missing or the same in regular request).
- allows = merging request object and regular parameters with request object taking=C2= =A0precedence since it is a very useful feature when having pre-signed requ= est object that's not one time use and clients using it wish to vary st= ate/nonce per-request.

I wish the group reconsider= ed making this breaking change from OIDC's take on request objects - al= low combination of parameters from the request object with ones from regula= r parameters (if not present in request object).

S pozdravem,
Filip Skokan


On Wed, 28 Aug 2019 at 23:02, Brian Campbell <bcampbell@pingidentity.com>= ; wrote:
=
Filip, for better or wor= se, I believe your assessment of the situation is correct. I know of one AS= that didn't choose which of the two to follow but rather implemented a= bit of a hybrid where it basically ignores everything outside of the reque= st object per JAR but also checks for and enforces the presence and value o= f the few regular parameters (client_id, response_type) that OIDC mandates.=

On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan <panva.ip@gmail.com> wrote:
Hello = everyone,

in an earlier thread I've posed the following question th= at might have gotten missed, this might have consequences for the existing = implementations of Request Objects in OIDC implementations - its making pur= e JAR requests incompatible with OIDC Core implementations.

draft 14 of= jwsreq (JAR) introduced this language

The client MAY send the parameters incl= uded in the request object
duplicated in the query parameters as well fo= r the backward
compatibility etc. =C2=A0However, the authorization se= rver supporting this
specification MUST only use the parameters included= in the request
object.=C2=A0

Server MUST only use the parameters in the Re= quest Object even if the
same parameter is provided in the query paramet= er.=C2=A0 The Authorization
=

The client MAY send the parameters included= in the request object
duplicated in the query parameters as well for th= e backward
compatibility etc. =C2=A0However, the authorization server= supporting this
specification MUST only use the parameters included in = the request
object.=C2=A0

Nat, John, everyone -=C2=A0does this mean a JAR = compliant AS ignores everything outside of the request object while OIDC Re= quest Object one merges the two with the ones in the request object being u= sed over ones that are sent in clear?=C2=A0The OIDC language also inclu= des sections which make sure that some required arguments are still passed = outside of the request object with the same value to make sure the request = is "valid" OAuth 2.0 request (client_id, response_type), somethin= g which an example in the JAR spec does not do. Not having this language me= ans that existing authorization request pipelines can't simply be exten= ded with e.g. a middleware, they need to branch their codepaths.

Is an = AS required to choose which of the two it follows?

Thank you for clarif= ying this in advance. I think if either the behaviour is the same as in OID= C or different this should be called out in the language to avoid confusion= , especially since this already exists in OIDC and likely isn't going t= o be read in isolation, especially because the Request Object is even calle= d out to be already in place in OIDC in the JAR draft.

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

CONFIDENTIALITY NOTICE: This = email may contain confidential and privileged material for the sole use of = the intended recipient(s). Any review, use, distribution or disclosure by o= thers is strictly prohibited.=C2=A0 If you have received this communication= in error, please notify the sender immediately by e-mail and delete the me= ssage and any file attachments from your computer. Thank you.=

CONFIDENTIALITY NOTICE: This email may contain confidential and= privileged material for the sole use of the intended recipient(s). Any rev= iew, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 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 f= rom your computer. Thank you.____________________________= ___________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.or= g/
@_nat_en
--000000000000481b8505996464fa-- From nobody Wed Dec 11 01:01:28 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B423B12086F for ; Wed, 11 Dec 2019 01:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9VXwgCRXEUN for ; Wed, 11 Dec 2019 01:01:22 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02561207FE for ; Wed, 11 Dec 2019 01:01:21 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id p5so5581484qtq.12 for ; Wed, 11 Dec 2019 01:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=klzcoQBRoAT1ECSfv4RgD6HVjc6VFYIh2lyvOa9o+R4=; b=kmGnJVmTuVDzojqNr89k1LIfpyOB0a8GKHyzYlmcllGUvJ1Mn9+1EerQcbjDoViTtd 0qp1yq0L8rmQx3QHL+1j+k6sYpbsdz/EAHjWjZy2k0QTnEBvUKfFn6KlQ7RnvczLdk2D T/YSC+EaVLCsO+bEP3brKC6r44qgrw8XpVlll7nQe9yHy1oyynxqmRnNEZ+rFTG0cMUU gHJlHl72YWvCqto77riY1JQdkA4ZM6bOgRDcxm3P0d7eYbfLkw+LD1GkDyaqO1BLfFRu Ict6EZixCXpIAX6O3/Ziy0CXNLqRdh+E3X55Mc/sWSI6X6N5kSbNtVZ2Ctp1UpDozy64 6Byg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=klzcoQBRoAT1ECSfv4RgD6HVjc6VFYIh2lyvOa9o+R4=; b=gJyyK7qRbtPKznq/G99jTfJHJ4GiYAzjr149vijVYFMElGWNk+IqSZC8TkGITpmWvL sic5+vj06SMKhzenq+daSzWM/23n14s7dLqp9ppq099eR4zRLg29UbkdLcOp9y8xVQCj HOlOpjh4Nsddt1VkCULkNaFylneVGdTzBj8J4yfx6kWT3r6RexhjrrS1mvt3VwDL8E17 6A09rPmFHuq5qMcB22+rsu5UeUNVq6iYHghj/aR+vwAL2oS68qf5WQcqt1YHNFPFGIyn YLBuqSRbtiWhZ/lArO46T3jWplyBnRmtvfWZZtAbJboALcu9AhCqBt+rGihDbIw9+Tq8 rZQA== X-Gm-Message-State: APjAAAX/4IqdQW7/bIcwmw0PfrfzzD9r8WXHKvHb8vGfDG+wTOzuzv5m FpvJaGzhH29o3qJyYWP8ORsSSb76W06twUV2l/44 X-Google-Smtp-Source: APXvYqy/tCgvs7AEXiiidtkJrnvHwE1wJIjkBcgy7aF6yR9cYWjHnaPoZ3d/jTQpxQIkRMaxP6SLl3nbJp3PlqTYdZ4= X-Received: by 2002:ac8:5243:: with SMTP id y3mr1721367qtn.356.1576054880656; Wed, 11 Dec 2019 01:01:20 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 11 Dec 2019 01:01:19 -0800 From: Dominick Baier In-Reply-To: References: MIME-Version: 1.0 Date: Wed, 11 Dec 2019 01:01:19 -0800 Message-ID: To: Brian Campbell , Nat Sakimura Cc: Nat Sakimura , oauth Content-Type: multipart/alternative; boundary="0000000000004ef1d2059969df14" Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 09:01:26 -0000 --0000000000004ef1d2059969df14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My preference would be that if a request object is used, all parameters must go in there a) makes the AS implementation easier b) there is really no point (IMO) to have a mixture of signed and unsigned parameters c) certain parameters should go into the RO - e.g. the code_challenge to prevent the =E2=80=9Cchosen code challenge attack=E2=80=9D (at least that= =E2=80=99s how I understood it) - again enforcing that makes the AS logic more complicated d) it=E2=80=99s a clear statement cheers =E2=80=94=E2=80=94=E2=80=94 Dominick Baier On 11. December 2019 at 03:29:14, Nat Sakimura (sakimura@gmail.com) wrote: Correct. The WG supported the precedence approach and even merge just like OIDC as it is very useful from the implementation point of view and helps with a bunch of deployment patter. The push back came in from the Ben Campbell=E2=80=99s DISCUSS. See https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actual= ly-specifies-the I am willing to go either way as long as people agree. My slight preference is to the original approach. Best, Nat Sakimura 2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell >: > FWIW, as best I can remember the change in question came as I result of d= irectorate/IESG > review rather than a WG decision/discussion. Which is likely why you can'= t > find the "why" anywhere in the mailing list archive. > > On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan wrote: > >> Well it kind of blows, doesn't it? I wasn't able to find the "why" >> anywhere in the mailing list archive around the time this was changed. >> >> My take on satisfying both worlds looks like this >> >> - allow just JAR - no other params when possible. >> (which btw isn't possible to do with request_uri when enforcing >> client based uri whitelist and the jwsreq 5.2.2 shows as much) >> - enforce the "dupe behaviours" defined in OIDC (if response_type or >> client_id is in request object it must either be missing or the same in >> regular request). >> - allows merging request object and regular parameters with request >> object taking precedence since it is a very useful feature when having >> pre-signed request object that's not one time use and clients using it w= ish >> to vary state/nonce per-request. >> >> I wish the group reconsidered making this breaking change from OIDC's >> take on request objects - allow combination of parameters from the reque= st >> object with ones from regular parameters (if not present in request obje= ct). >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Wed, 28 Aug 2019 at 23:02, Brian Campbell >> wrote: >> > Filip, for better or worse, I believe your assessment of the situation is >>> correct. I know of one AS that didn't choose which of the two to follow= but >>> rather implemented a bit of a hybrid where it basically ignores everyth= ing >>> outside of the request object per JAR but also checks for and enforces = the >>> presence and value of the few regular parameters (client_id, response_t= ype) >>> that OIDC mandates. >>> >>> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan wrote= : >>> >>>> Hello everyone, >>>> >>>> in an earlier thread I've posed the following question that might have >>>> gotten missed, this might have consequences for the existing >>>> implementations of Request Objects in OIDC implementations - its makin= g >>>> pure JAR requests incompatible with OIDC Core implementations. >>>> >>>> draft 14 of jwsreq (JAR) introduced this language >>>> >>>> The client MAY send the parameters included in the request object >>>>> duplicated in the query parameters as well for the backward >>>>> compatibility etc. >>>>> >>>>> *However, the authorization server supporting this specification MUST >>>>> only use the parameters included in the request object. * >>>> >>>> >>>> Server MUST only use the parameters in the Request Object even if the >>>>> same parameter is provided in the query parameter. The Authorization >>>> >>>> >>>> The client MAY send the parameters included in the request object >>>>> duplicated in the query parameters as well for the backward >>>>> compatibility etc. >>>>> >>>>> *However, the authorization server supporting this specification MUST >>>>> only use the parameters included in the request object. * >>>> >>>> >>>> Nat, John, everyone - *does this mean a JAR compliant AS ignores >>>> everything outside of the request object while OIDC Request Object one >>>> merges the two with the ones in the request object being used over one= s >>>> that are sent in clear?* The OIDC language also includes sections >>>> which make sure that some required arguments are still passed outside = of >>>> the request object with the same value to make sure the request is "va= lid" >>>> OAuth 2.0 request (client_id, response_type), something which an examp= le in >>>> the JAR spec does not do. Not having this language means that existing >>>> authorization request pipelines can't simply be extended with e.g. a >>>> middleware, they need to branch their codepaths. >>>> >>>> Is an AS required to choose which of the two it follows? >>>> >>>> Thank you for clarifying this in advance. I think if either the >>>> behaviour is the same as in OIDC or different this should be called ou= t in >>>> the language to avoid confusion, especially since this already exists = in >>>> OIDC and likely isn't going to be read in isolation, especially becaus= e the >>>> Request Object is even called out to be already in place in OIDC in th= e JAR >>>> draft. >>>> >>>> Best, >>>> *Filip* >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> * CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d. >>> 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 f= rom >>> your computer. Thank you.* >> >> > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --0000000000004ef1d2059969df14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
My p= reference would be that if a request object is used, all parameters must go= in there
a) makes = the AS implementation easier
b) there is really no point (IMO) to have a mixture of sig= ned and unsigned parameters
c) certain parameters should go into the RO - e.g. the code= _challenge to prevent the =E2=80=9Cchosen code challenge attack=E2=80=9D (a= t least that=E2=80=99s how I understood it) - again enforcing that makes th= e AS logic more complicated
d) it=E2=80=99s a clear statement

cheers=C2=A0
=E2=80=94= =E2=80=94=E2=80=94
Dominick Baier

On 11. December 2019 at 03:29:14, Nat Sakimura (sakimura@gmail.com) wrote:

Correct. The WG supported the precedence approach and even merge just like OIDC as it is very useful from the implementation point of view and helps with a bunch of deployment patter.=C2=A0

The push back came in from the Ben Campbell=E2=80=99s DISCUSS.=C2=A0
See=C2=A0

I am willing to go either way as long as people agree. My slight preference is to the original approach.=C2=A0

Best,=C2=A0

Nat Sakimura

2019=E5=B9=B48=E6=9C=8829=E6=97=A5(= =E6=9C=A8) 6:56 Brian Campbell <bcampbell=3D40pingidentity..com@dmarc.ietf.org>:
FWIW, as best I can remember the change in question came as I result of directorate/IESG review rather than a WG decision/discussion. Which is likely why you can't find the "why&q= uot; anywhere in the mailing list archive.

On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan <pa= nva.ip@gmail.com> wrote:
Well it kind of blows, doesn't it? I wasn't able to find the "why" anywhere in the mailing list archive around the time this w= as changed.

My take on satisfying both worlds looks like this

- allow just JAR - no other params when possible.
=C2=A0 =C2=A0 (which btw isn't possible to do with request_uri when enforcing client based uri whitelist and the jwsreq 5.2.2 shows as much)
- enforce the "dupe behaviours" defined in OIDC (if response_type or client_id is in request object it must either be missing or the same in regular request).
- allows merging request object and regular parameters with request object taking=C2=A0precedence since it is a very useful feature when having pre-signed request object that's not one time use and clients using it wish to vary state/nonce per-request.

I wish the group reconsidered making this breaking change from OIDC's take on request objects - allow combination of parameters from the request object with ones from regular parameters (if not present in request object).

S pozdravem,
Filip Skokan


On Wed, 28 Aug 2019 at 23:02, Brian Campbell <bcampbell@pingidentity.com> wrote:
Filip, for better or worse, I believe your assessment of the situation is correct. I know of one AS that didn't choose which of the two to follow but rather implemented a bit of a hybrid where it basically ignores everything outside of the request object per JAR but also checks for and enforces the presence and value of the few regular parameters (client_id, response_type) that OIDC mandates.

On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan <pa= nva.ip@gmail.com> wrote:
Hello everyone,

in an earlier thread I've posed the following question that might have gotten missed, this might have consequences for the existing implementations of Request Objects in OIDC implementations - its making pure JAR requests incompatible with OIDC Core implementations.

draft 14 of jwsreq (JAR) introduced this language

The client MAY send the parameters included in the request object
duplicated in the query parameters as well for the backward
compatibility etc. =C2=A0However, the authorization server supporting this
specification MUST only use the parameters included in the request
object.=C2=A0

Server MUST only use the parameters in the Request Object even if the
same parameter is provided in the query parameter.=C2=A0 The Authorization

The client MAY send the parameters included in the request object
duplicated in the query parameters as well for the backward
compatibility etc. =C2=A0However, the authorization server supporting this
specification MUST only use the parameters included in the request
object.=C2=A0

Nat, John, everyone -=C2=A0does this mean a JAR compliant AS ignores everything outside of the request object while OIDC Request Object one merges the two with the ones in the request object being used over ones that are sent in clear?=C2=A0The OIDC language also includes sections which make sure that some required arguments are still passed outside of the request object with the same value to make sure the request is "valid" OAuth 2.0 request (client_id, response_type), something which an example in the JAR spec does not do. Not having this language means that existing authorization request pipelines can't simply be extended with e.g. a middleware, they need to branch their codepaths.

Is an AS required to choose which of the two it follows?

Thank you for clarifying this in advance. I think if either the behaviour is the same as in OIDC or different this should be called out in the language to avoid confusion, especially since this already exists in OIDC and likely isn't going to be read in isolation, especially because the Request Object is even called out to be already in place in OIDC in the JAR draft.

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

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=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 attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=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 attachments from your computer. Thank you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
--0000000000004ef1d2059969df14-- From nobody Wed Dec 11 05:01:49 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3735D120112 for ; Wed, 11 Dec 2019 05:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 0m4AuVeImNas for ; Wed, 11 Dec 2019 05:01:43 -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 64BF2120074 for ; Wed, 11 Dec 2019 05:01:43 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id d16so23914272wre.10 for ; Wed, 11 Dec 2019 05:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=paP3WAStEgIkCLk5AkISIyMbGx1EvRkjm8LL66a8VUg=; b=dfnr8qmKRMWVtetTHlKzEJV8KPXF1smc05u59zeNTDU3SX8KW5d+GdkjqBieuukJKV hoO0AOwrNWjCxnAGeP1THFW4SUmOya8T1jvU9PjmiQK3JaKev9AFNMvFSqoLyJs7L4dy t9MQotw7AnesblAYXUf/5smP/HORXsKI3wDvFX/YxnC/k0CR89Xy0nNfwm/5rwjnbADy ek3DcESe0nrU467CGhStWYun56MMdmaWIbEzZ/6CeWyhLCS7SEjHNqGk++R3koa4vgO9 o/IuhuC7ooY6AylKrS1PDxa/3BOIng5xH5imR6lkgg5pUHeTJpBoknsKcRTV8pPSSik4 1NVA== 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=paP3WAStEgIkCLk5AkISIyMbGx1EvRkjm8LL66a8VUg=; b=ntVGCJL324zQLjp3oNJiNJIN0F4h+mw5jEO3PTyqScOr2YXgUhHwX2nq6mkc7CzcUs tRLZYrJbrRjm7Ko58Je/Bf/Pf8ii2jo4TdXMnX8OcXN20BFUtNeb1MFI8OWWZdOJIEF3 qhzKnv+s/HktvGAuCOVhqQuvivypwG1sOje1eUrI7/COhJEDIAmvFzIMEUzx/FQTa4Tw P+OeKh9bPK4QwdF29IFnMtgpRvj+Oh/rQFlm+Ttdq0+uBEsAUnQXJn4nN+de9UyCwH+9 MH3Byss8oLnyhJTnJZN86mqlqaPjXyAkbjKE73iouTQWAbAneQy6fg84T7E0kTrCXCI7 nFbA== X-Gm-Message-State: APjAAAXSfYkbomMkocSKhlJNeevJqKlXv1xQhd9K5GBwF5uvMChr61U8 7zfoszxN6tK05trm1PNSAjON7zWLnLp40OLD5+Usxg== X-Google-Smtp-Source: APXvYqyAVh9aHpALYQtQ/cdN3UcUAeO3az6cyVsQy0DLboNyAYgscFEOh1ZHMhjdgRIe3hhhPbqIdANXbS3D3wHyYeo= X-Received: by 2002:adf:f58a:: with SMTP id f10mr3877398wro.105.1576069301523; Wed, 11 Dec 2019 05:01:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: John Bradley Date: Wed, 11 Dec 2019 10:01:28 -0300 Message-ID: To: Nat Sakimura Cc: Brian Campbell , oauth , Nat Sakimura Content-Type: multipart/alternative; boundary="000000000000dbf46c05996d3a15" Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 13:01:48 -0000 --000000000000dbf46c05996d3a15 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I also slightly prefer the merge approach. There are plusses and minuses to both. Changing again now that it is past ISEG review and backing out a Discuss will add another three to six months at this point, if we can get them to agree to the change. John B. On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura wrote: > Correct. The WG supported the precedence approach and even merge just lik= e > OIDC as it is very useful from the implementation point of view and helps > with a bunch of deployment patter. > > The push back came in from the Ben Campbell=E2=80=99s DISCUSS. > See > > https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actu= ally-specifies-the > > I am willing to go either way as long as people agree. My slight > preference is to the original approach. > > Best, > > Nat Sakimura > > 2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell 40pingidentity..com@dmarc.ietf.org <40pingidentity.com@dmarc.ietf.org>>: > >> FWIW, as best I can remember the change in question came as I result of = directorate/IESG >> review rather than a WG decision/discussion. Which is likely why you can= 't >> find the "why" anywhere in the mailing list archive. >> >> On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan wrote: >> >>> Well it kind of blows, doesn't it? I wasn't able to find the "why" >>> anywhere in the mailing list archive around the time this was changed. >>> >>> My take on satisfying both worlds looks like this >>> >>> - allow just JAR - no other params when possible. >>> (which btw isn't possible to do with request_uri when enforcing >>> client based uri whitelist and the jwsreq 5.2.2 shows as much) >>> - enforce the "dupe behaviours" defined in OIDC (if response_type or >>> client_id is in request object it must either be missing or the same in >>> regular request). >>> - allows merging request object and regular parameters with request >>> object taking precedence since it is a very useful feature when having >>> pre-signed request object that's not one time use and clients using it = wish >>> to vary state/nonce per-request. >>> >>> I wish the group reconsidered making this breaking change from OIDC's >>> take on request objects - allow combination of parameters from the requ= est >>> object with ones from regular parameters (if not present in request obj= ect). >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Wed, 28 Aug 2019 at 23:02, Brian Campbell >>> wrote: >>> >> Filip, for better or worse, I believe your assessment of the situation i= s >>>> correct. I know of one AS that didn't choose which of the two to follo= w but >>>> rather implemented a bit of a hybrid where it basically ignores everyt= hing >>>> outside of the request object per JAR but also checks for and enforces= the >>>> presence and value of the few regular parameters (client_id, response_= type) >>>> that OIDC mandates. >>>> >>>> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan >>>> wrote: >>>> >>>>> Hello everyone, >>>>> >>>>> in an earlier thread I've posed the following question that might hav= e >>>>> gotten missed, this might have consequences for the existing >>>>> implementations of Request Objects in OIDC implementations - its maki= ng >>>>> pure JAR requests incompatible with OIDC Core implementations. >>>>> >>>>> draft 14 of jwsreq (JAR) introduced this language >>>>> >>>>> The client MAY send the parameters included in the request object >>>>>> duplicated in the query parameters as well for the backward >>>>>> compatibility etc. >>>>>> >>>>>> *However, the authorization server supporting thisspecification MUST >>>>>> only use the parameters included in the requestobject. * >>>>> >>>>> >>>>> Server MUST only use the parameters in the Request Object even if the >>>>>> same parameter is provided in the query parameter. The Authorizatio= n >>>>> >>>>> >>>>> The client MAY send the parameters included in the request object >>>>>> duplicated in the query parameters as well for the backward >>>>>> compatibility etc. >>>>>> >>>>>> *However, the authorization server supporting thisspecification MUST >>>>>> only use the parameters included in the requestobject. * >>>>> >>>>> >>>>> Nat, John, everyone - *does this mean a JAR compliant AS ignores >>>>> everything outside of the request object while OIDC Request Object on= e >>>>> merges the two with the ones in the request object being used over on= es >>>>> that are sent in clear?* The OIDC language also includes sections >>>>> which make sure that some required arguments are still passed outside= of >>>>> the request object with the same value to make sure the request is "v= alid" >>>>> OAuth 2.0 request (client_id, response_type), something which an exam= ple in >>>>> the JAR spec does not do. Not having this language means that existin= g >>>>> authorization request pipelines can't simply be extended with e.g. a >>>>> middleware, they need to branch their codepaths. >>>>> >>>>> Is an AS required to choose which of the two it follows? >>>>> >>>>> Thank you for clarifying this in advance. I think if either the >>>>> behaviour is the same as in OIDC or different this should be called o= ut in >>>>> the language to avoid confusion, especially since this already exists= in >>>>> OIDC and likely isn't going to be read in isolation, especially becau= se the >>>>> Request Object is even called out to be already in place in OIDC in t= he JAR >>>>> draft. >>>>> >>>>> Best, >>>>> *Filip* >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly prohibit= ed. >>>> If you have received this communication in error, please notify the se= nder >>>> immediately by e-mail and delete the message and any file attachments = from >>>> your computer. Thank you.* >>> >>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.*______________________________________________= _ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000dbf46c05996d3a15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also slightly prefer the merge approach.=C2=A0

There are plusses and minuses to both= .=C2=A0

Changing again n= ow that it is past ISEG review and backing out a Discuss will add another t= hree to six months at this point, if we can get them to agree to the change= .=C2=A0

John B.=C2=A0

On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura <sakimura@gmail.com> wrote:
Correct. The WG supported the pre= cedence approach and even merge just like OIDC as it is very useful from th= e implementation point of view and helps with a bunch of deployment patter.= =C2=A0

The push ba= ck came in from the Ben Campbell=E2=80=99s DISCUSS.=C2=A0
See=C2=A0

I am willing to go either way as long as people agree. My slight = preference is to the original approach.=C2=A0

Best,=C2=A0

Nat Sakimura

2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C= =A8) 6:56 Brian Campbell <bcampbell=3D40pingidentity..com= @dmarc.ietf.org>:
FWIW, as best I can remembe= r the change in question came as I result of directorate/IESG review = rather than a WG decision/discussion. Which is likely why you can't fin= d the "why" anywhere in the mailing list archive.

On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan = <panva.ip@gmail.com> wrote:
Well it kind of blows, doesn't it? I wa= sn't able to find the "why" anywhere in the mailing list arch= ive around the time this was changed.

My take on s= atisfying both worlds looks like this

- allow just= JAR - no other params when possible.
=C2=A0 =C2=A0 (which btw is= n't possible to do with request_uri when enforcing client based uri whi= telist and the jwsreq 5.2.2 shows as much)
- enforce the "du= pe behaviours" defined in OIDC (if response_type or client_id is in re= quest object it must either be missing or the same in regular request).
- allows merging request object and regular parameters with request = object taking=C2=A0precedence since it is a very useful feature when having= pre-signed request object that's not one time use and clients using it= wish to vary state/nonce per-request.

I wish the = group reconsidered making this breaking change from OIDC's take on requ= est objects - allow combination of parameters from the request object with = ones from regular parameters (if not present in request object).

S pozdravem,
Filip Skokan


On Wed, 28 Aug 2019 at 23:02, Brian Campbell <bcampbell@pingidentity.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rg= b(204,204,204)">
Filip, for better or worse, I believe your assessment of the situa= tion is correct. I know of one AS that didn't choose which of the two t= o follow but rather implemented a bit of a hybrid where it basically ignore= s everything outside of the request object per JAR but also checks for and = enforces the presence and value of the few regular parameters (client_id, r= esponse_type) that OIDC mandates.

=
On Tue, Aug 27, 2019 at 5:47 AM Filip= Skokan <panva.ip@gmail.com> wrote:
Hello everyone,

in an ear= lier thread I've posed the following question that might have gotten mi= ssed, this might have consequences for the existing implementations of Requ= est Objects in OIDC implementations - its making pure JAR requests incompat= ible with OIDC Core implementations.
<= br>
draft 14 of jwsreq (JAR) introduce= d this language

The client MAY send the parameters included in the request obj= ect
duplicated in the query parameters as well for the backward
compa= tibility etc. =C2=A0However, the authorization server supporting thisspecification MUST only use the parameters included in the request
obje= ct.=C2=A0

Server MUST only use the parameters in the Request Object even if th= e
same parameter is provided in the query parameter.=C2=A0 The Authoriza= tion

The client MAY send the parameters included in the request object<= br>duplicated in the query parameters as well for the backward
compatibi= lity etc. =C2=A0However, the authorization server supporting this
spe= cification MUST only use the parameters included in the request
object.= =C2=A0

Nat, John, everyone -=C2=A0does this mean a JAR compliant AS ignores e= verything outside of the request object while OIDC Request Object one merge= s the two with the ones in the request object being used over ones that are= sent in clear?=C2=A0The OIDC language also includes sections which mak= e sure that some required arguments are still passed outside of the request= object with the same value to make sure the request is "valid" O= Auth 2.0 request (client_id, response_type), something which an example in = the JAR spec does not do. Not having this language means that existing auth= orization request pipelines can't simply be extended with e.g. a middle= ware, they need to branch their codepaths.

Is an AS required to choose = which of the two it follows?

Thank you for clarifying this in advance. = I think if either the behaviour is the same as in OIDC or different this sh= ould be called out in the language to avoid confusion, especially since thi= s already exists in OIDC and likely isn't going to be read in isolation= , especially because the Request Object is even called out to be already in= place in OIDC in the JAR draft.

Best,
Filip
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This = email may contain confidential and privileged material for the sole use of = the intended recipient(s). Any review, use, distribution or disclosure by o= thers is strictly prohibited.=C2=A0 If you have received this communication= in error, please notify the sender immediately by e-mail and delete the me= ssage and any file attachments from your computer. Thank you.=

CONFIDENTIALITY NOTICE: This email may contain confidential and= privileged material for the sole use of the intended recipient(s). Any rev= iew, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 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 f= rom your computer. Thank you.____________________________= ___________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000dbf46c05996d3a15-- From nobody Wed Dec 11 07:26:17 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC933120A21 for ; Wed, 11 Dec 2019 07:26:15 -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 ES8MxtSVEIZo for ; Wed, 11 Dec 2019 07:26:15 -0800 (PST) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0: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 F17B01209C7 for ; Wed, 11 Dec 2019 07:26:14 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id z12so19751505iln.11 for ; Wed, 11 Dec 2019 07:26:14 -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=qZieeijiXPX7aKWHWPQBFxnkBAUf0HJPKe41IxP0+50=; b=RM98JxWVCKoJX/8kW2mceUNgGf/0EuioWRMDyV2uQvHFIT9xxMveGYchKt6Lq3Ql4k 6hmaxPHUrt1dIWIiNUFOtveS/qIOGF8e9tIAwhx0Jrcn64BMcaPxn/dkcFpx6UQ3sTE/ nqbMuE7R38RZOQ3J5/BMpqVsESHUxoHIbKTlN6fhwelqHpncl2GP/JxBB5htIlpkCNtA jrvjDLO3itLOO1l3JuV+P4U2GwepSOCbfJ78mLsaOkHr7s0Ky75uTSs5qzkuZgHroeCz pjk5/JZGYXquRe+EKnWrncm786IXKQPlEQG7JP6vzDdQovrC/KOgfYPPJISs9sykhbI8 SbRQ== 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=qZieeijiXPX7aKWHWPQBFxnkBAUf0HJPKe41IxP0+50=; b=mH68sxkk5cZRoVM2r2x56x18ct36LmF3X5DbuQ9+H+0+fVnMTcc7xF/lcjZ+gMP3j5 A9AWiMEWrlho8Q3rJ6zanYcCcGEDvDFAOaS5FOfEtyjEr7u3sEFmeN94j71bxN4obMEQ gwaYR/sB+w5I4VFQxVIQQvyVUxVyybX4OgX2/BwNios7XuZkczsjYrAiYZafCJC3cgZ+ CFQRb48rjLN/BADRsk9nIvccZSIUQO8Zvsrb5CCMrMu4fqxICU8kt+2rIcUrf6v01sff /rDsRBYlvLzSScYrZHqcZFXBPIqYkG2M/6QM4chu+G5cHQPxX6Z62Yg3BDpi4TF5LJTi nsAg== X-Gm-Message-State: APjAAAU/VRMKpkJ8us45jgEzwc0j2JtMNSL73O7yyIYARkiWA8oqxlPC XgygCjYnEVsrY90cWl4e6CXwqumRusCblC0gmJz9ijjz X-Google-Smtp-Source: APXvYqw//LF7mq8hps7OJ/YQOg99iY5unOtGXsWgqDmh8wioE4xBFhjn8js2o9IZragV4qtOK+jz+7gBRzECLhgK6wk= X-Received: by 2002:a92:3b0c:: with SMTP id i12mr3617092ila.194.1576077973952; Wed, 11 Dec 2019 07:26:13 -0800 (PST) MIME-Version: 1.0 From: Anggi Setiady Makmur Date: Wed, 11 Dec 2019 23:26:02 +0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000c69e5e05996f3ffb" Archived-At: Subject: [OAUTH-WG] Good X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 15:26:16 -0000 --000000000000c69e5e05996f3ffb Content-Type: text/plain; charset="UTF-8" I Like it -- Anggi Makmur --000000000000c69e5e05996f3ffb Content-Type: text/html; charset="UTF-8"
I Like it
--
Anggi Makmur
--000000000000c69e5e05996f3ffb-- From nobody Mon Dec 16 08:27:00 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5C91200C4 for ; Mon, 16 Dec 2019 08:26:59 -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 7QXRiXltHs5S for ; Mon, 16 Dec 2019 08:26:57 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C74120020 for ; Mon, 16 Dec 2019 08:26:57 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id e10so7474739ljj.6 for ; Mon, 16 Dec 2019 08:26:56 -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=N9Rx6Fd7MPKB6T6GHebaGvb9kIgvTCZUysC3gJv1ing=; b=Daw6kLiJdVWRj78sCFG5jSwSzjXsjley535TcZTxXR9FU0KV6BqU6kjLSokpnc7Uil N3sJFJE/i1NnzL318In66ujMwxI2PXxgkud4v9Vj12GIiB5a22yUgFjjbNuWvvVZeV/V mEpMuWf733Xj8OL4bJexEdkYOtWQrSpy6sIO+beKbqEYZT0KNTy+eawFPWj9mbtpaDSQ 6qWxz+rOJ898Tkw37OEAPlL7QnLQiZiYeEQuxtsIC/YZSHHLe1UJW9ctEkg+h2TEhnL/ CDtlMuYCd9p1xiKAUTvnIYIRTDcC6wBptbZDru5Z8Ith373k8RfbWVT/1NfnSfyiC7qh zjkw== 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=N9Rx6Fd7MPKB6T6GHebaGvb9kIgvTCZUysC3gJv1ing=; b=L15x4esRS7dPF+rBuHy9jxrKkYudgjHWX3mluHPjcBlSqQVMUBhmigEKas8TP8BCB6 fCiURYIhymmIlZUp9TkfWP8hOoxj9wWBJ8kMtyPbNVrWJSI3syCvIziNGKt8OSa2IthH 5YRXYvitH5ucm6MWKG02pPHQkUnmGPNIbsaM0jRH4ydl/Xn/9qlj2g5/ssSrYBkWripX h3vSHu9DqkBbv/3ShgpNbOjV4k8Uu0Q64FgpzaHQ++Ow8t3kk8Oy0GilYqU5RtWVsph0 F+wDDBOJeqAEjCJfW8/aXpkRzhaNy1gdGjcPmiJNEJuPxHJfas8YceW8Ku33H/Rl67+g EIpQ== X-Gm-Message-State: APjAAAWY6YTa8ORBE65xglNXm+7Kdc2Qx4q9q5gWfygQ43BEoJkDKbYg 85szH213qRB7L8B7ixfEnV0eL/pIv1LTc7UYKqrtbHEw38HbxtBYoz4JJxpLgUYBK0dDWpteCWb YbgJLBlFKxGC4Ew== X-Google-Smtp-Source: APXvYqzextSYptAh804a9SOZZu1hTLBVTX+Q2qqTsgAzuXH+ek64+jOGL2IlWKokEb9CuqJBkrzRg6Uvbc/ZJ1eemi4= X-Received: by 2002:a2e:99c3:: with SMTP id l3mr20330446ljj.250.1576513615025; Mon, 16 Dec 2019 08:26:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 16 Dec 2019 09:26:28 -0700 Message-ID: To: Hannes Tschofenig Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000001fad30599d4ae77" Archived-At: Subject: Re: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 16:26:59 -0000 --00000000000001fad30599d4ae77 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable With respect to the Pushed Authorization Requests (PAR) draft the minutes do capture an individual comment that it's a "no brainer to adopt this work" but as I recall there was also a hum to gauge the room's interest in adoption, which was largely in favor of such. Of course, one hum in Singapore isn't the final word but, following from that, I was hoping/expecting to see a call for adoption go out to the mailing list? On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig wrote: > Here are the meeting minutes from the Singapore IETF meeting: > > https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03 > > > > Tony was our scribe. Thanks! > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=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._ --00000000000001fad30599d4ae77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With respect to the Pushed Authorization Requests (PAR) dr= aft the minutes do capture an individual comment that it's a "no b= rainer to adopt this work" but as I recall there was also a hum to gau= ge the room's interest in adoption, which was largely in favor of such.= Of course, one hum in Singapore isn't the final word but, following fr= om that, I was hoping/expecting to see a call for adoption go out to the ma= iling list?

On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wr= ote:

Here are the meeting minutes from the Singapore IETF= meeting:

https://datatracker.ietf.= org/meeting/106/materials/minutes-106-oauth-03

=C2=A0

Tony was our scribe. Thanks!

=C2=A0

=C2=A0

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= 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. --00000000000001fad30599d4ae77-- From nobody Mon Dec 16 10:12:12 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD69312089A for ; Mon, 16 Dec 2019 10:12:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=KB5RlKcs; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=UlSK1Rb+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML9Xi4MpM9CM for ; Mon, 16 Dec 2019 10:12:07 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130043.outbound.protection.outlook.com [40.107.13.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8E112086D for ; Mon, 16 Dec 2019 10:12:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uo9zFpTjX4lr7zLjnaShDIVM9uaHWB7SSVwEgieAyFU=; b=KB5RlKcslgyY57kwbAFaZ9wt+XifHgjIv7HkGKpCaWG03u95Qs2YIZy5V6Zy+95DvcJ0BnRFUeAEvV6DDE8W3NZ6bRd7nDQ2PrVWshFEgHebmv3398YjyMoK4MascWWGgYaiT1BfgqBVj/vNLk/w3fkHp5OjfQM9OEJpfCS1xaw= Received: from HE1PR08CA0062.eurprd08.prod.outlook.com (2603:10a6:7:2a::33) by AM0PR08MB3570.eurprd08.prod.outlook.com (2603:10a6:208:e0::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.20; Mon, 16 Dec 2019 18:12:03 +0000 Received: from AM5EUR03FT056.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::204) by HE1PR08CA0062.outlook.office365.com (2603:10a6:7:2a::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.16 via Frontend Transport; Mon, 16 Dec 2019 18:12:03 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT056.mail.protection.outlook.com (10.152.17.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.18 via Frontend Transport; Mon, 16 Dec 2019 18:12:03 +0000 Received: ("Tessian outbound 28955e0c1ca8:v40"); Mon, 16 Dec 2019 18:12:03 +0000 X-CR-MTA-TID: 64aa7808 Received: from 1424fc3308d5.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 907FC765-6447-44A8-84B9-4C3FF6A171FD.1; Mon, 16 Dec 2019 18:11:58 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 1424fc3308d5.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 16 Dec 2019 18:11:58 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dMnWJ2qGNn6L/xY16nZJI19k7LbBefrF/bG4uA+Xm0Kv0dwjYY6h8mYFlLlmnZ6VCEpRfcTe+cN6r6dixr5GlCQYFQQhCxFDY9Gkylh6mTreM2s1ucru2qwFyD3fSf3JNxdKCDEgprKrXdA7rEb7Ok0HU8Hl9KALEbSIsVHXXr4tNz7whIuyphhX+w2rm6Dxm0CJ+SrK87nIoW//Flo5wLPFo6cTtqYdqXf338MqdTRenq1UJwAHox2YuaHrmObaQbcvhX3vZxfgKy/MoTI6kCa1iYyyJvg0LpYrFeXZw0Cqivzdx+XBp65Z9R2NON8EOtxZhV6icoEOyNO/GNgY1Q== 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=eyAGQxGiDEbveZhC8rsmnm7Phojf2iOuvzxI42IH64Q=; b=NiRwlh6yWn/PJ0ENUMmnCbw8BHL0dKAev3zVHkJlQAtWWYNJwZcLdIVcmPL1w4CDEW6/So30KhJ/0AGdEoCDnUY25lW3odLmlu8zyvVkY2yaHekIvdNaUM3vup7jTQ9+Bj6BXAkspfuo8hqJqxQ9C6y2vaNPo/hABG1XBsg13k6qicr41KxtGdktlYwV0qLUeVzcjxhMWEORC+/J0tXZmlzuqqjeYr9QEc9wHrchv/f/qkN3s2w4fm/PTI47+5D0bpfYQSIjGKVfIsmVbZrTC+NbkdfzwLbjczDAFsBCsgtmZBpy+g38dBwY83spGwEPuvwjj2XoeB53X6elaWt4FQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eyAGQxGiDEbveZhC8rsmnm7Phojf2iOuvzxI42IH64Q=; b=UlSK1Rb+wcExNw04V5cWnV0us1erWOE5gwlCzVsvwkKQT0vKFhUc9pOdyZ8pc/AXlWVMCfWNZLDzOfBtdoq0n/c7RV1xaUQXDMWGcDPdXvlcoKxUjN9JEk8I4k+O12ESrefMhY0rWetuB0O+WHVC0ORkJvEP0ZNoJrscjRQsW5E= Received: from AM6PR08MB5285.eurprd08.prod.outlook.com (20.179.0.161) by AM6PR08MB3591.eurprd08.prod.outlook.com (20.177.115.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.20; Mon, 16 Dec 2019 18:11:57 +0000 Received: from AM6PR08MB5285.eurprd08.prod.outlook.com ([fe80::1581:c3da:22ee:41b9]) by AM6PR08MB5285.eurprd08.prod.outlook.com ([fe80::1581:c3da:22ee:41b9%7]) with mapi id 15.20.2538.019; Mon, 16 Dec 2019 18:11:57 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" Thread-Topic: Doodle Poll for OAuth Virtual Interim Meeting Thread-Index: AdW0Oz45HKRgAXCsR6CnGXONoCCMnQ== Date: Mon, 16 Dec 2019 18:11:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 29b805c6-c8fb-4451-9921-c7d2c2674513.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [195.149.223.43] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 270827af-8ac0-4d45-3fe2-08d7825373ea X-MS-TrafficTypeDiagnostic: AM6PR08MB3591:|AM0PR08MB3570: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:7691;OLM:7691; x-forefront-prvs: 02530BD3AA X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(396003)(136003)(366004)(346002)(189003)(199004)(53754006)(7696005)(26005)(81166006)(81156014)(5660300002)(8676002)(316002)(966005)(2906002)(6506007)(8936002)(478600001)(6916009)(66946007)(66476007)(66556008)(64756008)(66446008)(33656002)(186003)(76116006)(4744005)(9686003)(55016002)(71200400001)(52536014)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3591; H:AM6PR08MB5285.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: dbWuWEy9vnS3moeQNaKYDIHOKz8WjLrOkxQXzrOJwjh8KcMjZSFwP1n8YKrekWnvuny1kkzme3rVypkv4DqJruxOMow8uzk9J4RlmKaZA/FV1pQWkL1Kra9F0S2IWxOKWJquVa9wcuhzu9dBQdHG5Y6waXZALoX3HaDxqfYTV2u/+gkJQEWUwlRi0x6ekvNE2Tqfjz/t+zrYHT3dHGZCAWxRTHM6I5QBE1MnmHJcbwGyDvwFKigAoIX1/orUVqqGSfV4o2n5YTwXK2VL/Vatc0O24RLYQ7DuA8FOJMcAJcwqWx5wcBFMyk8PETzb3rQpQs8KejxTvsuywX9St55Ftneu/moMa5E5R9ecMHow7pyoAtANNRaHYPU5/Zf7bubzoe8+d5rKRk8NiR1X1INYMLfvKiaihtKi8HSvg50MRDhRaH/RUajzJDE0xmLeiJZCMCilOyovZA8B9J0I4xlg278FU7dEjYJO5+YvL1mUEw05/EdVpfkFn3zuBjGpz0Y6jt9HmMfF+pCEr9hNqyw/O6V/grYf0+fdSuLoqw7SrL0= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB5285CBAF9FFCB0445ADCB858FA510AM6PR08MB5285eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3591 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT056.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(346002)(376002)(396003)(40434004)(189003)(199004)(53754006)(7696005)(36906005)(5660300002)(55016002)(9686003)(8676002)(478600001)(316002)(26826003)(8936002)(86362001)(70586007)(33656002)(356004)(81166006)(81156014)(336012)(52536014)(2906002)(966005)(6916009)(76130400001)(26005)(6506007)(70206006)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB3570; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; MX:1; A:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 7c282d9f-a381-4270-1b68-08d782537014 X-Forefront-PRVS: 02530BD3AA X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: khOZaGuHTNwEfStoKxUHRWLJrh4muhYGLD7A3aQQpYsJMb+Pk5bI8seaZ1XOiD8Svdf1lcwJOxvqeul5oMbXxREbCCQmkWw9HOYN+VbmDg48RYxZ3bOvy7FyJ+tEcBtdb/XEJySX7RtHHevRJfmYk7Y2rszAqcv8O45B6n1IpLRgRX9zAt85A9YeMWYUQI6lrLqkpq5BZ9wQMv6lh3e0cIPOlh7RcT98LtKO2ydXf/pqTT5mwCPzDYoqC9IKZWX7UbEar+RRxGzGMBeAwxO6Ih8AnqcIKf8vSnc9ZF68FW2OiyHHAvj2oEMKzi33Nu/kZbdYUOEI48+i/ps8Q8BXWIfLTxlFHhIDp5zeg37xqmQg1Ngss7GDS57Lbic49q2p3MUcYF7Wh2+3PAahujk5Bpy4Phn6R6JDDWA07kXo37iRk45F5z3O/tGtRWqzf/KrZajU9ZhAybzSEcl4O7sCPirjdE5Nt9f7QK3XsTwuVgD95o7tguc0SYrBN0uovt1jXkEF78VLypAMu/VgtLMJC35pnJEafDx7lQgzLY1R2o/rnO22/4YTs9ZCDqwsExHl X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Dec 2019 18:12:03.4242 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 270827af-8ac0-4d45-3fe2-08d7825373ea X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3570 Archived-At: Subject: [OAUTH-WG] Doodle Poll for OAuth Virtual Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 18:12:11 -0000 --_000_AM6PR08MB5285CBAF9FFCB0445ADCB858FA510AM6PR08MB5285eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, at the Singapore IETF meeting we had a discussion about a possible update o= f RFC 6749 (with the codename of "OAuth 2.1"). A discussion at a side-meeti= ng in Singapore made clear that there is no common view about the goals of = such an effort and whether there are other options to reach the same benefi= ts. To continue the discussion and to provide some clarity in our decision maki= ng progress we would like to schedule a virtual interim meeting early next = year. Here is a Doodle poll: https://doodle.com/poll/z7ue3gsu5tuskq79 Please indicate your preference by the end of the year. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM6PR08MB5285CBAF9FFCB0445ADCB858FA510AM6PR08MB5285eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

at the Singapore IETF meeting we had a discussion ab= out a possible update of RFC 6749 (with the codename of “OAuth 2.1= 221;). A discussion at a side-meeting in Singapore made clear that there is= no common view about the goals of such an effort and whether there are other options to reach the same benefits.

 

To continue the discussion and to provide some clari= ty in our decision making progress we would like to schedule a virtual inte= rim meeting early next year. Here is a Doodle poll: https://doodle.com/pol= l/z7ue3gsu5tuskq79

 

Please indicate your preference by the end of the ye= ar.

 

Ciao

Hannes & Rifaat<= /span>

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM6PR08MB5285CBAF9FFCB0445ADCB858FA510AM6PR08MB5285eurp_-- From nobody Mon Dec 16 12:35:56 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B27120924 for ; Mon, 16 Dec 2019 12:35: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, 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 AGFsBhuIIctH for ; Mon, 16 Dec 2019 12:35:53 -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 F054D120922 for ; Mon, 16 Dec 2019 12:35:52 -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 xBGKZlds024946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Dec 2019 15:35:48 -0500 From: Justin Richer Message-Id: <4FD03604-C0A3-4A0A-9598-8ECD8137581F@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_209D5848-125E-45D7-9611-F4B91B4A81B9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 16 Dec 2019 15:35:47 -0500 In-Reply-To: Cc: Hannes Tschofenig , "oauth@ietf.org" To: Brian Campbell References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 20:35:55 -0000 --Apple-Mail=_209D5848-125E-45D7-9611-F4B91B4A81B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 to this. My take away was that PAR was pretty clear for adoption = right now, RAR had interest but more question/debate.=20 FWIW I=E2=80=99m in favor of both of them. =E2=80=94 Justin > On Dec 16, 2019, at 11:26 AM, Brian Campbell = wrote: >=20 > With respect to the Pushed Authorization Requests (PAR) draft the = minutes do capture an individual comment that it's a "no brainer to = adopt this work" but as I recall there was also a hum to gauge the = room's interest in adoption, which was largely in favor of such. Of = course, one hum in Singapore isn't the final word but, following from = that, I was hoping/expecting to see a call for adoption go out to the = mailing list?=20 >=20 > On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig = > wrote: > Here are the meeting minutes from the Singapore IETF meeting: >=20 > = https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03 = > =20 >=20 > Tony was our scribe. Thanks! >=20 > =20 >=20 > =20 >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_209D5848-125E-45D7-9611-F4B91B4A81B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 = to this. My take away was that PAR was pretty clear for adoption right = now, RAR had interest but more question/debate. 

FWIW I=E2=80=99m in favor of both of = them.

 =E2=80= =94 Justin

On Dec 16, 2019, at 11:26 AM, Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

With respect to the Pushed = Authorization Requests (PAR) draft the minutes do capture an individual = comment that it's a "no brainer to adopt this work" but as I recall = there was also a hum to gauge the room's interest in adoption, which was = largely in favor of such. Of course, one hum in Singapore isn't the = final word but, following from that, I was hoping/expecting to see a = call for adoption go out to the mailing list?

On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig = <Hannes.Tschofenig@arm.com> wrote:

Here are the meeting minutes from = the Singapore IETF meeting:

https://datatracker.ietf.org/meeting/106/materials/minutes-106-= oauth-03

 

Tony was our scribe. Thanks!

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited..  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_209D5848-125E-45D7-9611-F4B91B4A81B9-- From nobody Mon Dec 16 13:56:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63978120931 for ; Mon, 16 Dec 2019 13:56:57 -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 XwxwYP5u5Rl8 for ; Mon, 16 Dec 2019 13:56:55 -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 2F568120026 for ; Mon, 16 Dec 2019 13:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1576533415; x=1608069415; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=puNFaTNWZadrPMUZ2BJpWi8Un3KNwqzVSnWVo1DXDWA=; b=M9wAViZqGftP4qQTWEJE5ToGP6izQt5bP1eHByIVjFFpYN7a+3d19Vty 6Sghp4Uu2AbNxKXInme2MX3SK217WER05DbLFr7hVALS3i4JjNUi5sphc gfCPmfRs8iCnZW8KB/PvOkFnOiZLZkEc2zCuevt67nJl36JgtVoXL2oF1 o=; IronPort-SDR: UqhMA1hr5ecbu/uWNeLrV6wlykpJC4V++PNb+6LNe20ZVvhizgAZXEuI5wuX6vF4BYPNJ/aSrx lA/EkjjTZJJg== X-IronPort-AV: E=Sophos; i="5.69,323,1571702400"; d="scan'208,217"; a="13877379" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2a-6e2fc477.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 16 Dec 2019 21:56:44 +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-6e2fc477.us-west-2.amazon.com (Postfix) with ESMTPS id C7AD5A1F23; Mon, 16 Dec 2019 21:56:43 +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, 16 Dec 2019 21:56:43 +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, 16 Dec 2019 21:56:43 +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, 16 Dec 2019 21:56:42 +0000 From: "Richard Backman, Annabelle" To: Justin Richer , Brian Campbell CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Meeting Minutes Thread-Index: AdWpsxnoY3xdV5m/R9Wrqb/JoSj/HAKendMAAAi1EID//8LJAA== Date: Mon, 16 Dec 2019 21:56:42 +0000 Message-ID: References: <4FD03604-C0A3-4A0A-9598-8ECD8137581F@mit.edu> In-Reply-To: <4FD03604-C0A3-4A0A-9598-8ECD8137581F@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.161.179] Content-Type: multipart/alternative; boundary="_000_B0F399FA250A4648B34740E07DBBC95Famazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 21:56:58 -0000 --_000_B0F399FA250A4648B34740E07DBBC95Famazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIGEgY2FsbCBmb3IgYWRvcHRpb24gb24gUEFSLg0KDQpJ4oCZZCBhbHNvIGxpa2UgdG8g c2VlIG9uZSBmb3IgUkFSOyB3aGlsZSB0aGVyZSBhcmUgcXVlc3Rpb25zIHRoYXQgbmVlZCB0byBi ZSByZXNvbHZlZCwgdGhlcmUgc2VlbXMgdG8gYmUgc3Ryb25nIGludGVyZXN0IGluIHRoaXMgd29y ayBhbmQgYWRvcHRpb24gbWVhbnMgd2UgY2FuIGhhdmUgdGhvc2UgZGlzY3Vzc2lvbnMgd2l0aGlu IHRoZSBXRyB3aGVyZSB0aGV5IGJlbG9uZy4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNr bWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9y Zz4gb24gYmVoYWxmIG9mIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4NCkRhdGU6IE1v bmRheSwgRGVjZW1iZXIgMTYsIDIwMTkgYXQgMTI6MzYgUE0NClRvOiBCcmlhbiBDYW1wYmVsbCA8 YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiAib2F1dGhA aWV0Zi5vcmciIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE1lZXRp bmcgTWludXRlcw0KDQorMSB0byB0aGlzLiBNeSB0YWtlIGF3YXkgd2FzIHRoYXQgUEFSIHdhcyBw cmV0dHkgY2xlYXIgZm9yIGFkb3B0aW9uIHJpZ2h0IG5vdywgUkFSIGhhZCBpbnRlcmVzdCBidXQg bW9yZSBxdWVzdGlvbi9kZWJhdGUuDQoNCkZXSVcgSeKAmW0gaW4gZmF2b3Igb2YgYm90aCBvZiB0 aGVtLg0KDQog4oCUIEp1c3Rpbg0KDQoNCk9uIERlYyAxNiwgMjAxOSwgYXQgMTE6MjYgQU0sIEJy aWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3Jn PG1haWx0bzpiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPj4gd3Jv dGU6DQoNCldpdGggcmVzcGVjdCB0byB0aGUgUHVzaGVkIEF1dGhvcml6YXRpb24gUmVxdWVzdHMg KFBBUikgZHJhZnQgdGhlIG1pbnV0ZXMgZG8gY2FwdHVyZSBhbiBpbmRpdmlkdWFsIGNvbW1lbnQg dGhhdCBpdCdzIGEgIm5vIGJyYWluZXIgdG8gYWRvcHQgdGhpcyB3b3JrIiBidXQgYXMgSSByZWNh bGwgdGhlcmUgd2FzIGFsc28gYSBodW0gdG8gZ2F1Z2UgdGhlIHJvb20ncyBpbnRlcmVzdCBpbiBh ZG9wdGlvbiwgd2hpY2ggd2FzIGxhcmdlbHkgaW4gZmF2b3Igb2Ygc3VjaC4gT2YgY291cnNlLCBv bmUgaHVtIGluIFNpbmdhcG9yZSBpc24ndCB0aGUgZmluYWwgd29yZCBidXQsIGZvbGxvd2luZyBm cm9tIHRoYXQsIEkgd2FzIGhvcGluZy9leHBlY3RpbmcgdG8gc2VlIGEgY2FsbCBmb3IgYWRvcHRp b24gZ28gb3V0IHRvIHRoZSBtYWlsaW5nIGxpc3Q/DQoNCk9uIFR1ZSwgRGVjIDMsIDIwMTkgYXQg MToyNiBBTSBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTxtYWls dG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4+IHdyb3RlOg0KSGVyZSBhcmUgdGhlIG1lZXRp bmcgbWludXRlcyBmcm9tIHRoZSBTaW5nYXBvcmUgSUVURiBtZWV0aW5nOg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwNi9tYXRlcmlhbHMvbWludXRlcy0xMDYtb2F1dGgt MDMNCg0KVG9ueSB3YXMgb3VyIHNjcmliZS4gVGhhbmtzIQ0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6 IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBp dCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFu eSBtZWRpdW0uIFRoYW5rIHlvdS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUg aW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBk aXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBh bnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs aXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_B0F399FA250A4648B34740E07DBBC95Famazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <75CD955502949B4AA48638AC124E7483@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9zZS0xOjIg MCA1IDMgMCAwIDAgMiAwIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mIzQzOzEgZm9yIGEgY2FsbCBmb3IgYWRvcHRpb24gb24gUEFSLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5J4oCZZCBhbHNvIGxpa2UgdG8gc2VlIG9uZSBmb3IgUkFSOyB3aGlsZSB0 aGVyZSBhcmUgcXVlc3Rpb25zIHRoYXQgbmVlZCB0byBiZSByZXNvbHZlZCwgdGhlcmUgc2VlbXMg dG8gYmUgc3Ryb25nIGludGVyZXN0IGluIHRoaXMgd29yayBhbmQgYWRvcHRpb24gbWVhbnMgd2Ug Y2FuIGhhdmUgdGhvc2UgZGlzY3Vzc2lvbnMgd2l0aGluIHRoZSBXRyB3aGVyZSB0aGV5IGJlbG9u Zy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij7igJMmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJlbGxlIFJpY2hhcmQgQmFj a21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7IG9uIGJlaGFsZiBvZiBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgRGVjZW1iZXIgMTYsIDIwMTkgYXQgMTI6MzYgUE08YnI+ DQo8Yj5UbzogPC9iPkJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHku Y29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7b2F1dGhAaWV0Zi5v cmcmcXVvdDsgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog W09BVVRILVdHXSBNZWV0aW5nIE1pbnV0ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxIHRvIHRoaXMuIE15IHRha2UgYXdheSB3YXMg dGhhdCBQQVIgd2FzIHByZXR0eSBjbGVhciBmb3IgYWRvcHRpb24gcmlnaHQgbm93LCBSQVIgaGFk IGludGVyZXN0IGJ1dCBtb3JlIHF1ZXN0aW9uL2RlYmF0ZS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RldJVyBJ4oCZbSBpbiBmYXZvciBvZiBi b3RoIG9mIHRoZW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIERlYyAxNiwgMjAxOSwgYXQgMTE6MjYgQU0sIEJyaWFuIENhbXBi ZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFy Yy5pZXRmLm9yZyI+YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2l0aCByZXNwZWN0IHRvIHRoZSBQdXNoZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0cyAoUEFS KSBkcmFmdCB0aGUgbWludXRlcyBkbyBjYXB0dXJlIGFuIGluZGl2aWR1YWwgY29tbWVudCB0aGF0 IGl0J3MgYSAmcXVvdDtubyBicmFpbmVyIHRvIGFkb3B0IHRoaXMgd29yayZxdW90OyBidXQgYXMg SSByZWNhbGwgdGhlcmUgd2FzIGFsc28gYSBodW0gdG8gZ2F1Z2UgdGhlIHJvb20ncyBpbnRlcmVz dCBpbiBhZG9wdGlvbiwgd2hpY2gNCiB3YXMgbGFyZ2VseSBpbiBmYXZvciBvZiBzdWNoLiBPZiBj b3Vyc2UsIG9uZSBodW0gaW4gU2luZ2Fwb3JlIGlzbid0IHRoZSBmaW5hbCB3b3JkIGJ1dCwgZm9s bG93aW5nIGZyb20gdGhhdCwgSSB3YXMgaG9waW5nL2V4cGVjdGluZyB0byBzZWUgYSBjYWxsIGZv ciBhZG9wdGlvbiBnbyBvdXQgdG8gdGhlIG1haWxpbmcgbGlzdD8NCjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBEZWMgMywgMjAxOSBhdCAxOjI2 IEFNIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hvZmVu aWdAYXJtLmNvbSI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkhlcmUgYXJlIHRoZSBtZWV0aW5nIG1pbnV0ZXMgZnJvbSB0aGUgU2luZ2Fw b3JlIElFVEYgbWVldGluZzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwNi9tYXRlcmlh bHMvbWludXRlcy0xMDYtb2F1dGgtMDMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL21lZXRpbmcvMTA2L21hdGVyaWFscy9taW51dGVzLTEwNi1vYXV0aC0wMzwv YT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvbnkgd2FzIG91ciBzY3JpYmUuIFRoYW5r cyE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMg b2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1h eSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Ns b3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLA0KIHVzZSBpdCBmb3IgYW55IHB1 cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRo YW5rIHlvdS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRo IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1 ZSZxdW90Oztjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGlu ZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhl IGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBv ciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3Nh Z2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91 Ljwvc3Bhbj48L2k+PC9iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRo QGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B0F399FA250A4648B34740E07DBBC95Famazoncom_-- From nobody Mon Dec 16 14:02:53 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F90120937 for ; Mon, 16 Dec 2019 14:02: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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3j4XhH-Hq1h4 for ; Mon, 16 Dec 2019 14:02:49 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296FA120934 for ; Mon, 16 Dec 2019 14:02:49 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id j11so3623030pjs.1 for ; Mon, 16 Dec 2019 14:02:49 -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=jfCkKnKbupkzkc2q5cd9Qmu3drKivmI9HVEi3efoNo0=; b=cK1k74XWNCTpqAExGM9uMNFtze8NyQTmNZEaJHDRQ2TIsjZ4n7zEjLQncrwxrfboQp dJtlrrLLnXwbKOkrPGRtWfPGzjwwaW9aY8sTiMHgpAQUi9RQ3ROkoC++VKXcKfP1/3wZ CPX+0/iQC2DmIQDizhlr3+a4qqo9xGzg0Drb7f6bYQUyz8rN+9/lDvnCeZ+5ylu8SplT D8Fo3MANzqwU30BFaImcYmeOTgapDAVUkVCRJjOPgg64H9+qyfLqostKZ9nhV3WZATR0 K6gH6x62qQ0SDiO3wUSefr6S/vVRclG4hNIyxOAV6nqehUcJ75at3MpS6QB9kRR8yNQV 4etQ== 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=jfCkKnKbupkzkc2q5cd9Qmu3drKivmI9HVEi3efoNo0=; b=lbrf/sHRPhlzUzSKToStQVAr5gErPFMS5LZSXQbLOgVlvecKSCJPhYeceDqPjnjFw7 CjgLJTn6xgRb1AjM+mEQjKtMTviBYDurDGVbjHDptYZjQtuApa94eY4tr/gMwDx+ef91 yTgrUGF9r9uTtcDp+kPgzecFGdwofykD3kxMkyeCZiLE2F2p0soLuP8812PE+Q0ZGX+x InKtOF2yelPM0Najixfw2YTjCfzeGEsO+ZR8R//HFRIvX53fnX2CzMzG630J4AfHadiP YPKHZf6fojBni6tT3lu0zcvfg712U8psMfhwRgs/SZldjJojjsPJWpB0FWDS8f924xVo p6kQ== X-Gm-Message-State: APjAAAV3DyiUfjQJcEEYY8ng0XgkoPUvkFMgkoNPYL7QVMUbqQXx/uLB 5QGO6djm8XjLYvOlq6SiWCYsF2Tjng4toxSxm7jK4hQZ+qH5OS+iEqcqeAO/th3nxxVxd9mtqcv vXw3n5QOswuWxdg== X-Google-Smtp-Source: APXvYqwxDU/2luJbMk1wmvMiEalZfKckF3EvbDBOM0QkD5BwptRdkB1Bb59QSqPcyIe7JfiMtinpDGxijTV2gZJlmno= X-Received: by 2002:a17:90a:2710:: with SMTP id o16mr1834234pje.110.1576533768603; Mon, 16 Dec 2019 14:02:48 -0800 (PST) MIME-Version: 1.0 References: <4FD03604-C0A3-4A0A-9598-8ECD8137581F@mit.edu> In-Reply-To: From: Rob Otto Date: Mon, 16 Dec 2019 22:02:37 +0000 Message-ID: To: "Richard Backman, Annabelle" Cc: Brian Campbell , Justin Richer , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004120e80599d95ff4" Archived-At: Subject: Re: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 22:02:52 -0000 --0000000000004120e80599d95ff4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99d support adoption of both PAR and RAR. On Mon, 16 Dec 2019 at 21:57, Richard Backman, Annabelle wrote: > +1 for a call for adoption on PAR. > > > > I=E2=80=99d also like to see one for RAR; while there are questions that = need to > be resolved, there seems to be strong interest in this work and adoption > means we can have those discussions within the WG where they belong. > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Justin Richer < > jricher@mit.edu> > *Date: *Monday, December 16, 2019 at 12:36 PM > *To: *Brian Campbell > *Cc: *"oauth@ietf.org" > *Subject: *Re: [OAUTH-WG] Meeting Minutes > > > > +1 to this. My take away was that PAR was pretty clear for adoption right > now, RAR had interest but more question/debate. > > > > FWIW I=E2=80=99m in favor of both of them. > > > > =E2=80=94 Justin > > > > On Dec 16, 2019, at 11:26 AM, Brian Campbell < > bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote: > > > > With respect to the Pushed Authorization Requests (PAR) draft the minutes > do capture an individual comment that it's a "no brainer to adopt this > work" but as I recall there was also a hum to gauge the room's interest i= n > adoption, which was largely in favor of such. Of course, one hum in > Singapore isn't the final word but, following from that, I was > hoping/expecting to see a call for adoption go out to the mailing list? > > > > On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Here are the meeting minutes from the Singapore IETF meeting: > > https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03 > > > > Tony was our scribe. Thanks! > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Rob Otto EMEA Field CTO - Ping Identity +44 777 135 6092 --=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._ --0000000000004120e80599d95ff4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99d support adoption of both PAR and RAR.=C2= =A0

On Mon, 16 Dec 2019 at 21:57, Richard Backman, Annabelle &l= t;richanna=3D40amazon.com@dm= arc.ietf.org> wrote:

+1 for a call for adoption on PAR.

=C2=A0

I=E2=80=99d also like to see one for RAR; while ther= e are questions that need to be resolved, there seems to be strong interest= in this work and adoption means we can have those discussions within the W= G where they belong.

=C2=A0

=E2=80=93=C2=A0<= /u>

Annabelle Richard B= ackman

AWS Identity=

=C2=A0

=C2=A0

From= : OAuth <oauth-bounces@ietf.org= > on behalf of Justin Richer <jricher@mit.edu>
Date: Monday, December 16, 2019 at 12:36 PM
To: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org= >
Cc: "oauth@= ietf.org" <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Meeting Minutes

=C2=A0

+1 to this. My take away was that PAR was pretty cle= ar for adoption right now, RAR had interest but more question/debate.=C2=A0

=C2=A0

FWIW I=E2=80=99m in favor of both of them.=

=C2=A0

=C2=A0=E2=80=94 Justin



On Dec 16, 2019, at 11:26 AM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:=

=C2=A0

With respect to the Pushed Authorization Requests (P= AR) draft the minutes do capture an individual comment that it's a &quo= t;no brainer to adopt this work" but as I recall there was also a hum = to gauge the room's interest in adoption, which was largely in favor of such. Of course, one hum in Singapore isn't th= e final word but, following from that, I was hoping/expecting to see a call= for adoption go out to the mailing list?

=C2=A0

On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig <= ;Hannes.Tsch= ofenig@arm.com> wrote:

Here are the meeting minutes from the Singapore IETF= meeting:

https://datatracker.ietf.= org/meeting/106/materials/minutes-106-oauth-03

=C2=A0

Tony was our scribe. Thanks!

=C2=A0

=C2=A0

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

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


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the = sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.____________________________________= ___________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Rob Otto
EMEA Field CTO - Ping Identi= ty
+44 777 135 6092

<= 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. --0000000000004120e80599d95ff4-- From nobody Mon Dec 16 14:48:59 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BA412003F; Mon, 16 Dec 2019 14:48:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <157653653318.24509.15075582637514649078@ietfa.amsl.com> Date: Mon, 16 Dec 2019 14:48:53 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 22:48:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens Author : Vittorio Bertocci Filename : draft-ietf-oauth-access-token-jwt-03.txt Pages : 16 Date : 2019-12-16 Abstract: This specification defines a profile for issuing OAuth 2.0 access tokens in JSON web token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in interoperable manner. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-03 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 16 14:50:43 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD70612093B for ; Mon, 16 Dec 2019 14:50: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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sA9dU6bbfzT9 for ; Mon, 16 Dec 2019 14:50:38 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938F912093C for ; Mon, 16 Dec 2019 14:50:38 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id t26so8427620ioi.13 for ; Mon, 16 Dec 2019 14:50:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3x8R7UQbK7eO+NJ5Z26uE8L1rpaGHyRu7r/05171yEk=; b=NmaGk2VF22gj+/GYWtBioxQaulRkIuX30RtX0NZa+l8HRk5I1hOkbEFF93TWQ8fAw/ g8jF19Vu8Cbcxuh4i4W8liNJSauZqyWGvRMIyE/7g0JX2zVM/T1e609IXwgrq0DS4bnO itb/NYM13/5PcEeuwt3KFv309uojDrCwShzLnIiRSxhwVQQWrg3dPjSk7b4OeZH0N9Qg akbGxUYor+6cnHEMwYoD+vhxPHkz14FFQSMbn+qE+NauwrktA7QLKv0P+TxyeCnEmxIA 3kAXs82t5HN8SE0vd5LWkUelwUS3Z3Mmj9taIc7tUyBhbzxM5PnVAAnWaGCQP3tgtXZN pJlg== 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=3x8R7UQbK7eO+NJ5Z26uE8L1rpaGHyRu7r/05171yEk=; b=JC2VPKNE5Qzi1oxikh67R13z9ujXIgPhFQWjhRRYLK9+tD0ivUEpV05mNgh34HDMZa oAPQPswCbROAdah/hU7WtGDeOLyZmsOzjCjsCa+dww95X83eKCGTA6FAY/tmbxfKWHnh oQWJSgVe5VCxKC0+oaDnBcIQTCqoybLBL4zK5PMFj2gofN7494a1gdAMom/LecUiAgd6 RzwFu0vsrCXI0OcseLOvw/olvsRwP6N2Zcf4pe0l8Dx1ldUOqqrw07aD0Knc8si471WY NY+auNhiDE+yF8rOCKX7ZKb2QLwoA63SYA7YeMAsPWbS7cEUNuI/YUBFWFdKJZDDHseV 6I3Q== X-Gm-Message-State: APjAAAVCBGLjURLBDFgubkg2c5ZTywkFcgTBsrynlo5q3r9iCY8Oc03+ ckrVs7MpWM3306j5a5IJYI/fmlcRe/J2vzf+Ry4BMvJHpz0mJQ== X-Google-Smtp-Source: APXvYqxg20MvU+x9IwgiEEGu6OEvPcI7BVBlAd86rQTkyxqSwvIsrBlhvBp/6HG6O/HKCHTGBEhzpkduacL2D+xf3zE= X-Received: by 2002:a02:8525:: with SMTP id g34mr13826253jai.72.1576536637386; Mon, 16 Dec 2019 14:50:37 -0800 (PST) MIME-Version: 1.0 References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> In-Reply-To: <157653653318.24509.15075582637514649078@ietfa.amsl.com> From: Vittorio Bertocci Date: Mon, 16 Dec 2019 14:50:26 -0800 Message-ID: To: IETF oauth WG Cc: i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="0000000000003f4a300599da0afb" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 22:50:42 -0000 --0000000000003f4a300599da0afb Content-Type: text/plain; charset="UTF-8" Dear all, I finally found the time to push a new draft of the JWT profile for ATs. This version incorporates the feedback kindly provided by Brian and Aaron at IETF105. Unfortunately I didn't have a chance to participate to IETF106, hence we didn't do much progress since then. There are still two areas we didn't manage to reach consensus on: 1. Mechanisms for signaling whether the AT was obtained by a user or an application This point was the subject of intense debate on the list leading to IETF105. One insight that emerged from the IETF105 discussion was that the use case here is more about whether the AT has been obtained via a grant that authenticated the client (regardless of what specific grant was used) vs a public client grant- that information can be relevant to a resource as it determines whether the identity of the client can be used in authorization decisions (in the former case) or not (in the public client case). If that's the scenario we are truly after, a simple, possibly optional boolean claim (say AuthenticatedClient) would suffice. Note for the people who didn't read the spec: I removed any reference to this already in draft-ietf-oauth-access-token-jwt-01. I think this is an important and useful info and standardizing it would be beneficial for middleware and SDK creators, but ultimately this is an interop profile hence if there's no strong desire to reach an agreement here, I am also OK with dropping the matter and not address this function in the spec. To summarize, I have two questions here: A. Do we believe it's worth it to formalize in the profile a mechanism to indicate whether the client th obtained the AT authenticated itself with the AS? B. If yes, are you OK wiht an optional bool claim here? 2. Claims indicating session properties This is one area where I am far more passionate about, as it represents a fundamental aspect that production systems (and in particular 1st party solutions) already rely on in the current proprietary JTW ATs. The profile currently includes the claims auth_time, acr and amr - capturing the values of those properties at the time of the latest authentication the user performed in the session used to issue the current AT: at session creation, at auth step up time and so on. Those are values that API need in order to make authorization decisions; in the case of 1st party APIs, the AT is the only artifact they ever receive hence there is no other way for an API to determine whether the caller performed say MFA in order to obtain the current AT. Since the first draft, some people signaled concerns about the current mechanisms thru which those claims get their value. For example, it has been proposed to maintain the original values of auth_time, acr & amr and introduce additional claims to indicate changes (like stepup). I am not clear on what cold go wrong with the current approach, hence I don't have an immediate grasp of how changes like the above would help. If the people uncomfortable with the current proposal could detail their concern, we can brainstorm ways to make that info available to API in a safer way. To summarize: A. Do you have concerns with the current auth_time, arm, acr proposal? Can you spell them out? (please read the relevant parts of the spec before chiming in :)) B. If yes, what can we do to make that info available to RSs in a way that makes you comfortable? Thanks V. On Mon, Dec 16, 2019 at 2:49 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : JSON Web Token (JWT) Profile for OAuth 2.0 > Access Tokens > Author : Vittorio Bertocci > Filename : draft-ietf-oauth-access-token-jwt-03.txt > Pages : 16 > Date : 2019-12-16 > > Abstract: > This specification defines a profile for issuing OAuth 2.0 access > tokens in JSON web token (JWT) format. Authorization servers and > resource servers from different vendors can leverage this profile to > issue and consume access tokens in interoperable manner. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-03 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000003f4a300599da0afb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,
I finally found the time to push a new draft = of the JWT profile for ATs. This version incorporates the feedback kindly p= rovided by Brian and Aaron at IETF105.
Unfortunately I didn't have a= chance to participate to IETF106, hence we didn't do much progress sin= ce then.
There are still two areas we didn't manage to reach consens= us on:

1. Mechanisms for signaling whether the AT was obtained by a = user or an application

This point was the subject of intense debate = on the list leading to IETF105.
One insight that emerged from the IETF10= 5 discussion was that the use case here is more about whether the AT has be= en obtained via a grant that authenticated the client (regardless of what s= pecific grant was used) vs a public client grant- that information can be r= elevant to a resource as it determines whether the identity of the client c= an be used in authorization decisions (in the former case) or not (in the p= ublic client case). If that's the scenario we are truly after, a simple= , possibly optional boolean claim (say AuthenticatedClient) would suffice.<= br>Note for the people who didn't read the spec: I removed any referenc= e to this already in draft-ietf-oauth-access-token-jwt-01. I think this is = an important and useful info and standardizing it would be beneficial for m= iddleware and SDK creators, but ultimately this is an interop profile hence= if there's no strong desire to reach an agreement here, I am also OK w= ith dropping the matter and not address this function in the spec.
To su= mmarize, I have two questions here:

A. Do we believe it's worth it to forma= lize in the profile a mechanism to indicate whether the client th obtained = the AT authenticated itself with the AS?
B. If yes, are you OK wiht an o= ptional bool claim here?

2. Claims indicating session prope= rties

This is one area where I am far more passionate about, as it r= epresents a fundamental aspect that production systems (and in particular 1= st party solutions) already rely on in the current proprietary JTW ATs.
= The profile currently includes the claims auth_time, acr and amr - capturin= g the values of those properties at the time of the latest authentication t= he user performed in the session used to issue the current AT: at session c= reation, at auth step up time and so on.
Those are values that API need = in order to make authorization decisions; in the case of 1st party APIs, th= e AT is the only artifact they ever receive hence there is no other way for= an API to determine whether the caller performed say MFA in order to obtai= n the current AT.
Since the first draft, some people signaled concerns a= bout the current mechanisms thru which those claims get their value. For ex= ample, it has been proposed to maintain the original values of auth_time, a= cr & amr and introduce additional claims to indicate changes (like step= up).
I am not clear on what cold go wrong with the current approach, hen= ce I don't have an immediate grasp of how changes like the above would = help.
If the people uncomfortable with the current proposal could detail= their concern, we can brainstorm ways to make that info available to API i= n a safer way. To summarize:

A. Do you have concerns with the current auth_time= , arm, acr proposal? Can you spell them out? (please read the relevant part= s of the spec before chiming in :))
B. If yes, what can we do to make th= at info available to RSs in a way that makes you comfortable?
<= br>
Thanks

V.

On Mon, Dec 16, 2019 at 2:49 PM <internet-drafts@ietf.org> wrote:
=

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Vitt= orio Bertocci
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-access-token-jwt-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-12-16

Abstract:
=C2=A0 =C2=A0This specification defines a profile for issuing OAuth 2.0 acc= ess
=C2=A0 =C2=A0tokens in JSON web token (JWT) format.=C2=A0 Authorization ser= vers and
=C2=A0 =C2=A0resource servers from different vendors can leverage this prof= ile to
=C2=A0 =C2=A0issue and consume access tokens in interoperable manner.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-oauth-access-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-oauth-access-token-jwt-03
https://datatracker.ietf.o= rg/doc/html/draft-ietf-oauth-access-token-jwt-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-oauth-access-token-jwt-03


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

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000003f4a300599da0afb-- From nobody Mon Dec 16 17:28:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D09A12095C; Mon, 16 Dec 2019 17:28:46 -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 a0lskAzPtfq3; Mon, 16 Dec 2019 17:28:43 -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 3F28A12090A; Mon, 16 Dec 2019 17:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1576546124; x=1608082124; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AXs2Bruwa+MKBUCCvfLrGOE3eGOc4skKCTGY1WTIJKU=; b=tFP14bUfnBWflhajLygxLeiTJElzWs8tajCuVcUbfw3u1mnSj721TL9D vcst+5waXJ27kq9iZtVsnI2120uwfnlN3pEHmWvOyZj+dJcT1jylDIRiv DD0NgeBZEcghaF2UYLhCNxO5hh4g0deffGETxDPjCzWBH1Wdqus5nEpg7 0=; IronPort-SDR: PjwYoq4NYyGQZXn8741ATCULaVZG8vuf7R5CBn6BClAusDN48DpZP+CXQc2hd2fdo7EQaYr4JO vuRNZ18h69Bg== X-IronPort-AV: E=Sophos;i="5.69,323,1571702400"; d="scan'208,217";a="8854407" Received: from iad6-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-2a-8549039f.us-west-2.amazon.com) ([10.124.125.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 17 Dec 2019 01:28:39 +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-8549039f.us-west-2.amazon.com (Postfix) with ESMTPS id 55036A1CB7; Tue, 17 Dec 2019 01:28:38 +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, 17 Dec 2019 01:28:37 +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, 17 Dec 2019 01:28: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; Tue, 17 Dec 2019 01:28:37 +0000 From: "Richard Backman, Annabelle" To: Vittorio Bertocci , IETF oauth WG CC: "i-d-announce@ietf.org" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt Thread-Index: AQHVtGMkx0ZM11MJ9UuFnmHDKBqGmae9XaMA///YXwA= Date: Tue, 17 Dec 2019 01:28:37 +0000 Message-ID: References: <157653653318.24509.15075582637514649078@ietfa.amsl.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.205] Content-Type: multipart/alternative; boundary="_000_AE9BAC2950B04DADB27D02EC803537A9amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 01:28:46 -0000 --_000_AE9BAC2950B04DADB27D02EC803537A9amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MS4gUmVnYXJkaW5nIEF1dGhlbnRpY2F0ZWRDbGllbnQ6DQpEb2VzIGEgbW9iaWxlIGFwcCB0aGF0 IHVzZXMgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIHRvIGVzdGFibGlzaCBhIGNsaWVudCBz ZWNyZXQgY291bnQgYXMgYW4g4oCcYXV0aGVudGljYXRlZCBjbGllbnTigJ0/IFdoYXQgaWYgdGhh dCByZWdpc3RyYXRpb24gaW5jbHVkZWQgYW4gYXNzZXJ0aW9uIHNpZ25lZCBieSBhIHRydXN0ZWQg ZW50aXR5IChlLmcuLCBkZXZpY2UgbWFuYWdlbWVudCBzb2Z0d2FyZSkgdXNpbmcgYSBjZXJ0aWZp Y2F0ZSB0aGF0IGhhZCBiZWVuIHB1c2hlZCB0byB0aGUgZGV2aWNlPyBXaXRob3V0IHNvbWUga2lu ZCBvZiBOSVNUIExvQS1zdHlsZSBkZWZpbml0aW9uIG9mIOKAnGF1dGhlbnRpY2F0ZWTigJ0sIGEg c2luZ2xlIEJvb2xlYW4g4oCcQXV0aGVudGljYXRlZENsaWVudOKAnSB2YWx1ZSBpcyB0b28gYW1i aWd1b3VzIHRvIGJlIHVzZWZ1bC4gSG93ZXZlciwgSeKAmW0gc2tlcHRpY2FsIHRoYXQgd2UgY291 bGQgZmluZCBjb25zZW5zdXMgb24gd2hhdCB0aGF0IGRlZmluaXRpb24gc2hvdWxkIGJlLCBhbmQg aXQgbWF5IGJlIGJldHRlciB0byBkZWZpbmUgY2xpZW50IGFuYWxvZ3MgdG8gYGFjcmAgYW5kIGBh bXJgIHRoYXQgcHJvdmlkZSBzdGFuZGFyZCB3YXlzIG9mIGV4cHJlc3NpbmcgY2xpZW50IGF1dGhl bnRpY2F0aW9uIGRldGFpbHMgd2l0aG91dCBnZXR0aW5nIHByZXNjcmlwdGl2ZSBhYm91dCB3aGF0 IGtpbmQgb2YgYXV0aGVudGljYXRpb24gaXMg4oCcZ29vZCBlbm91Z2gu4oCdDQoNCjIuIFJlZ2Fy ZGluZyBhdXRoZW50aWNhdGlvbiBzZXNzaW9uIHByb3BlcnRpZXM6DQpJ4oCZbSBjb25mdXNlZCBi eSB0aGUgZGVmaW5pdGlvbnMgZ2l2ZW4gZm9yIGBhdXRoX3RpbWVgLCBgYWNyYCwgYW5kIGBhbXJg LiBGb3IgYGF1dGhfdGltZWAsIGl0IHNheXM6DQoNCuKAnOKApml0cyB2YWx1ZSB3aWxsIGVpdGhl ciByZW1haW4gdGhlIHNhbWUgZm9yIGFsbCB0aGUgSldUIGFjY2VzcyB0b2tlbnMgaXNzdWVkIHdp dGhpbiB0aGF0IHNlc3Npb24gb3IgYmUgdXBkYXRlZCB0byB0aGUgdGltZSBvZiBsYXRlc3QgYXV0 aGVudGljYXRpb24gaWYgcmVhdXRoZW50aWNhdGlvbiBvY2N1cnJlZCBtaWQtc2Vzc2lvbuKApuKA nQ0KDQpCdXQgdGhlIOKAnEZvciBleGFtcGxl4oCdIGF0IHRoZSBlbmQgb2YgdGhhdCBkZWZpbml0 aW9uIGltcGxpZXMgdGhhdCBgYXV0aF90aW1lYCB3aWxsIG5vdCBiZSB1cGRhdGVkLiBUaGUgZGVm aW5pdGlvbnMgZm9yIGBhY3JgIGFuZCBgYW1yYCBzYXkgdGhlIHNhbWUsIGJ1dCBhbHNvIHNheSB0 aGF0IHRoZSDigJzigKZzYW1lIGNvbnNpZGVyYXRpb25zIHByZXNlbnRlZCBmb3IgYXV0aF90aW1l IGFwcGx54oCm4oCdIFdoYXTigJlzIHRoZSBpbnRlbnRpb24gaGVyZTogYXJlIHRoZXkgZml4ZWQs IHVwZGF0ZWQsIG9yIGlzIGl0IHVwIHRvIHRoZSBkZXBsb3ltZW50IHRvIGRlY2lkZT8NCg0KSeKA mWQgbGlrZSB0byBiZXR0ZXIgdW5kZXJzdGFuZCB0aGUgdXNlIGNhc2UgZm9yIHB1dHRpbmcgdGhl c2UgaW4gdGhlIGFjY2VzcyB0b2tlbi4gSWYgdGhlIFJTIGlzIG1ha2luZyBhdXRob3JpemF0aW9u IGRlY2lzaW9ucyBiYXNlZCBvbiB0aGVzZSBjbGFpbXMsIHRoYXQgaW1wbGllcyB0aGF0IHRoZSBS UyBjYW5ub3QgcmVseSBvbiB0aGUgQVMgdG8gZGV0ZXJtaW5lIChlLmcuLCBmcm9tIHRoZSByZXF1 ZXN0ZWQgc2NvcGUpIHRoZSByZXF1aXJlZCBhdXRoZW50aWNhdGlvbiBtZXRob2QocyksIGZyZXNo bmVzcywgZXRjLiBJZiB0aGUgQVMgY291bGQgYmUgcmVsaWVkIHVwb24gZm9yIHRoaXMsIHRoZW4g cHJlc3VtYWJseSBpdCB3b3VsZCBub3QgaXNzdWUgUlRzIGFuZCBBVHMgZm9yIGEgc2NvcGUgd2l0 aG91dCByZXF1aXJpbmcgdGhlIGVuZCB1c2VyIHRvIG1lZXQgdGhlIGFwcHJvcHJpYXRlIGF1dGhl bnRpY2F0aW9uIHJlcXVpcmVtZW50cy4gSWYgdGhpcyBpcyB0aGUgY2FzZSwgdGhlbiB0aGUgUlMg bXVzdCBoYXZlIGEgd2F5IHRvIHNpZ25hbCB0byB0aGUgY2xpZW50IChhbmQgdGhlbiB0aGUgQVMp IHRoYXQgYSBzdGVwLXVwIGF1dGhlbnRpY2F0aW9uIGlzIHJlcXVpcmVkLiBJcyB0aGVyZSBhbiBl eGlzdGluZyBtZWNoYW5pc20gdGhyb3VnaCB3aGljaCB0aGV5IGNvdWxkIGRvIHRoaXM/IEFsbCBJ IGNhbiBjb21lIHVwIHdpdGggaXMgY3JhbW1pbmcgdGhlIGluZm9ybWF0aW9uIGludG8gdGhlIHNj b3BlIGF0dHJpYnV0ZSBvZiBhIFdXVy1BdXRoZW50aWNhdGUgY2hhbGxlbmdlLCBidXQgdGhhdCBo YXMgdGhlIHNhbWUgc2NvcGUgb3BhY2l0eSB2aW9sYXRpb24gcHJvYmxlbSBhcyBkZXNjcmliZWQg aW4gdGhpcyBkcmFmdOKAmXMgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuIFdpdGhvdXQgYSBjbGVh ciB3YXkgdG8gZXhwcmVzcyB0aGUgc3RlcC11cCByZXF1aXJlbWVudHMsIHRoaXMgZmVlbHMgaW5j b21wbGV0ZS4NCg0KMy4gUmVnYXJkaW5nIGFjY2VzcyB0b2tlbnMgdGhhdCBhcmUgdXNlZCB0byBh Y2Nlc3MgZGlmZmVyZW50IHJlc291cmNlIHNlcnZlcnM6DQpSZWFkaW5nIGJldHdlZW4gdGhlIGxp bmVzLCBJICp0aGluayogdGhlIGludGVudGlvbiBpcyB0aGF0IGEgSldUIGFjY2VzcyB0b2tlbiB0 aGF0IGlzIGludGVuZGVkIHRvIGJlIHVzZWQgdG8gYWNjZXNzIHR3byBkaWZmZXJlbnQgcmVzb3Vy Y2VzIGF0IHR3byBkaWZmZXJlbnQgUlNlcyBzaG91bGQgbG9vayBzb21ldGhpbmcgbGlrZToNCg0K ew0KImF1ZCI6ICJodHRwczovL2dlbmVyaWMtcmVzb3VyY2UtaW5kaWNhdG9yLmV4YW1wbGUuY29t LyIsDQoic2NvcGUiOiAicmVzb3VyY2VfZm9vIHJlc291cmNlX2JhciIsDQouLi4NCn0NCg0KQW5k IHRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IGVhY2ggUlMgc2hvdWxkIHJlY29nbml6ZSB0aGF0IGdl bmVyaWMgYXVkaWVuY2UuIElzIHRoaXMgY29ycmVjdD8gSWYgc28gaXQgc2VlbXMgdG8gZ28gYWdh aW5zdCB0aGUgc3Bpcml0IG9mIHJlc291cmNlIGluZGljYXRvcnMgYXMgaW5kaWNhdGluZyB0aGUg dGFyZ2V0IG9yIGxvY2F0aW9uIG9mIGEgcmVzb3VyY2UuIEl04oCZcyBzdHJldGNoaW5nIHRoYXQg ZGVmaW5pdGlvbiwgYXQgdGhlIHZlcnkgbGVhc3QuDQoNCkJ1dCBhcyBJIHNhaWQsIEnigJltIHJl YWRpbmcgYmV0d2VlbiB0aGUgbGluZXMgaGVyZS4gSWYgdGhpcyBpcyB0aGUgaW50ZW50aW9uLCBp dCBzaG91bGQgYmUgY2xlYXJseSBzdGF0ZWQuIEFsdGVybmF0aXZlbHksIHJlbW92ZSAob3IgY2hh bmdlIHRvIGEgU0hPVUxEKSB0aGUgcmVxdWlyZW1lbnQgdGhhdCBtdWx0aS12YWx1ZSBgYXVkYCBj bGFpbXMgbXVzdCBvbmx5IGNvbnRhaW4gYWxpYXNlcyBmb3IgdGhlIHNhbWUgcmVzb3VyY2UgaW5k aWNhdG9yLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0K DQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgVml0 dG9yaW8gQmVydG9jY2kgPFZpdHRvcmlvPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPg0KRGF0 ZTogTW9uZGF5LCBEZWNlbWJlciAxNiwgMjAxOSBhdCAyOjUxIFBNDQpUbzogSUVURiBvYXV0aCBX RyA8b2F1dGhAaWV0Zi5vcmc+DQpDYzogImktZC1hbm5vdW5jZUBpZXRmLm9yZyIgPGktZC1hbm5v dW5jZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMy50eHQNCg0KRGVhciBhbGwsDQpJIGZpbmFs bHkgZm91bmQgdGhlIHRpbWUgdG8gcHVzaCBhIG5ldyBkcmFmdCBvZiB0aGUgSldUIHByb2ZpbGUg Zm9yIEFUcy4gVGhpcyB2ZXJzaW9uIGluY29ycG9yYXRlcyB0aGUgZmVlZGJhY2sga2luZGx5IHBy b3ZpZGVkIGJ5IEJyaWFuIGFuZCBBYXJvbiBhdCBJRVRGMTA1Lg0KVW5mb3J0dW5hdGVseSBJIGRp ZG4ndCBoYXZlIGEgY2hhbmNlIHRvIHBhcnRpY2lwYXRlIHRvIElFVEYxMDYsIGhlbmNlIHdlIGRp ZG4ndCBkbyBtdWNoIHByb2dyZXNzIHNpbmNlIHRoZW4uDQpUaGVyZSBhcmUgc3RpbGwgdHdvIGFy ZWFzIHdlIGRpZG4ndCBtYW5hZ2UgdG8gcmVhY2ggY29uc2Vuc3VzIG9uOg0KDQoxLiBNZWNoYW5p c21zIGZvciBzaWduYWxpbmcgd2hldGhlciB0aGUgQVQgd2FzIG9idGFpbmVkIGJ5IGEgdXNlciBv ciBhbiBhcHBsaWNhdGlvbg0KDQpUaGlzIHBvaW50IHdhcyB0aGUgc3ViamVjdCBvZiBpbnRlbnNl IGRlYmF0ZSBvbiB0aGUgbGlzdCBsZWFkaW5nIHRvIElFVEYxMDUuDQpPbmUgaW5zaWdodCB0aGF0 IGVtZXJnZWQgZnJvbSB0aGUgSUVURjEwNSBkaXNjdXNzaW9uIHdhcyB0aGF0IHRoZSB1c2UgY2Fz ZSBoZXJlIGlzIG1vcmUgYWJvdXQgd2hldGhlciB0aGUgQVQgaGFzIGJlZW4gb2J0YWluZWQgdmlh IGEgZ3JhbnQgdGhhdCBhdXRoZW50aWNhdGVkIHRoZSBjbGllbnQgKHJlZ2FyZGxlc3Mgb2Ygd2hh dCBzcGVjaWZpYyBncmFudCB3YXMgdXNlZCkgdnMgYSBwdWJsaWMgY2xpZW50IGdyYW50LSB0aGF0 IGluZm9ybWF0aW9uIGNhbiBiZSByZWxldmFudCB0byBhIHJlc291cmNlIGFzIGl0IGRldGVybWlu ZXMgd2hldGhlciB0aGUgaWRlbnRpdHkgb2YgdGhlIGNsaWVudCBjYW4gYmUgdXNlZCBpbiBhdXRo b3JpemF0aW9uIGRlY2lzaW9ucyAoaW4gdGhlIGZvcm1lciBjYXNlKSBvciBub3QgKGluIHRoZSBw dWJsaWMgY2xpZW50IGNhc2UpLiBJZiB0aGF0J3MgdGhlIHNjZW5hcmlvIHdlIGFyZSB0cnVseSBh ZnRlciwgYSBzaW1wbGUsIHBvc3NpYmx5IG9wdGlvbmFsIGJvb2xlYW4gY2xhaW0gKHNheSBBdXRo ZW50aWNhdGVkQ2xpZW50KSB3b3VsZCBzdWZmaWNlLg0KTm90ZSBmb3IgdGhlIHBlb3BsZSB3aG8g ZGlkbid0IHJlYWQgdGhlIHNwZWM6IEkgcmVtb3ZlZCBhbnkgcmVmZXJlbmNlIHRvIHRoaXMgYWxy ZWFkeSBpbiBkcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDEuIEkgdGhpbmsgdGhp cyBpcyBhbiBpbXBvcnRhbnQgYW5kIHVzZWZ1bCBpbmZvIGFuZCBzdGFuZGFyZGl6aW5nIGl0IHdv dWxkIGJlIGJlbmVmaWNpYWwgZm9yIG1pZGRsZXdhcmUgYW5kIFNESyBjcmVhdG9ycywgYnV0IHVs dGltYXRlbHkgdGhpcyBpcyBhbiBpbnRlcm9wIHByb2ZpbGUgaGVuY2UgaWYgdGhlcmUncyBubyBz dHJvbmcgZGVzaXJlIHRvIHJlYWNoIGFuIGFncmVlbWVudCBoZXJlLCBJIGFtIGFsc28gT0sgd2l0 aCBkcm9wcGluZyB0aGUgbWF0dGVyIGFuZCBub3QgYWRkcmVzcyB0aGlzIGZ1bmN0aW9uIGluIHRo ZSBzcGVjLg0KVG8gc3VtbWFyaXplLCBJIGhhdmUgdHdvIHF1ZXN0aW9ucyBoZXJlOg0KQS4gRG8g d2UgYmVsaWV2ZSBpdCdzIHdvcnRoIGl0IHRvIGZvcm1hbGl6ZSBpbiB0aGUgcHJvZmlsZSBhIG1l Y2hhbmlzbSB0byBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBjbGllbnQgdGggb2J0YWluZWQgdGhlIEFU IGF1dGhlbnRpY2F0ZWQgaXRzZWxmIHdpdGggdGhlIEFTPw0KQi4gSWYgeWVzLCBhcmUgeW91IE9L IHdpaHQgYW4gb3B0aW9uYWwgYm9vbCBjbGFpbSBoZXJlPw0KDQoyLiBDbGFpbXMgaW5kaWNhdGlu ZyBzZXNzaW9uIHByb3BlcnRpZXMNCg0KVGhpcyBpcyBvbmUgYXJlYSB3aGVyZSBJIGFtIGZhciBt b3JlIHBhc3Npb25hdGUgYWJvdXQsIGFzIGl0IHJlcHJlc2VudHMgYSBmdW5kYW1lbnRhbCBhc3Bl Y3QgdGhhdCBwcm9kdWN0aW9uIHN5c3RlbXMgKGFuZCBpbiBwYXJ0aWN1bGFyIDFzdCBwYXJ0eSBz b2x1dGlvbnMpIGFscmVhZHkgcmVseSBvbiBpbiB0aGUgY3VycmVudCBwcm9wcmlldGFyeSBKVFcg QVRzLg0KVGhlIHByb2ZpbGUgY3VycmVudGx5IGluY2x1ZGVzIHRoZSBjbGFpbXMgYXV0aF90aW1l LCBhY3IgYW5kIGFtciAtIGNhcHR1cmluZyB0aGUgdmFsdWVzIG9mIHRob3NlIHByb3BlcnRpZXMg YXQgdGhlIHRpbWUgb2YgdGhlIGxhdGVzdCBhdXRoZW50aWNhdGlvbiB0aGUgdXNlciBwZXJmb3Jt ZWQgaW4gdGhlIHNlc3Npb24gdXNlZCB0byBpc3N1ZSB0aGUgY3VycmVudCBBVDogYXQgc2Vzc2lv biBjcmVhdGlvbiwgYXQgYXV0aCBzdGVwIHVwIHRpbWUgYW5kIHNvIG9uLg0KVGhvc2UgYXJlIHZh bHVlcyB0aGF0IEFQSSBuZWVkIGluIG9yZGVyIHRvIG1ha2UgYXV0aG9yaXphdGlvbiBkZWNpc2lv bnM7IGluIHRoZSBjYXNlIG9mIDFzdCBwYXJ0eSBBUElzLCB0aGUgQVQgaXMgdGhlIG9ubHkgYXJ0 aWZhY3QgdGhleSBldmVyIHJlY2VpdmUgaGVuY2UgdGhlcmUgaXMgbm8gb3RoZXIgd2F5IGZvciBh biBBUEkgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIGNhbGxlciBwZXJmb3JtZWQgc2F5IE1GQSBp biBvcmRlciB0byBvYnRhaW4gdGhlIGN1cnJlbnQgQVQuDQpTaW5jZSB0aGUgZmlyc3QgZHJhZnQs IHNvbWUgcGVvcGxlIHNpZ25hbGVkIGNvbmNlcm5zIGFib3V0IHRoZSBjdXJyZW50IG1lY2hhbmlz bXMgdGhydSB3aGljaCB0aG9zZSBjbGFpbXMgZ2V0IHRoZWlyIHZhbHVlLiBGb3IgZXhhbXBsZSwg aXQgaGFzIGJlZW4gcHJvcG9zZWQgdG8gbWFpbnRhaW4gdGhlIG9yaWdpbmFsIHZhbHVlcyBvZiBh dXRoX3RpbWUsIGFjciAmIGFtciBhbmQgaW50cm9kdWNlIGFkZGl0aW9uYWwgY2xhaW1zIHRvIGlu ZGljYXRlIGNoYW5nZXMgKGxpa2Ugc3RlcHVwKS4NCkkgYW0gbm90IGNsZWFyIG9uIHdoYXQgY29s ZCBnbyB3cm9uZyB3aXRoIHRoZSBjdXJyZW50IGFwcHJvYWNoLCBoZW5jZSBJIGRvbid0IGhhdmUg YW4gaW1tZWRpYXRlIGdyYXNwIG9mIGhvdyBjaGFuZ2VzIGxpa2UgdGhlIGFib3ZlIHdvdWxkIGhl bHAuDQpJZiB0aGUgcGVvcGxlIHVuY29tZm9ydGFibGUgd2l0aCB0aGUgY3VycmVudCBwcm9wb3Nh bCBjb3VsZCBkZXRhaWwgdGhlaXIgY29uY2Vybiwgd2UgY2FuIGJyYWluc3Rvcm0gd2F5cyB0byBt YWtlIHRoYXQgaW5mbyBhdmFpbGFibGUgdG8gQVBJIGluIGEgc2FmZXIgd2F5LiBUbyBzdW1tYXJp emU6DQpBLiBEbyB5b3UgaGF2ZSBjb25jZXJucyB3aXRoIHRoZSBjdXJyZW50IGF1dGhfdGltZSwg YXJtLCBhY3IgcHJvcG9zYWw/IENhbiB5b3Ugc3BlbGwgdGhlbSBvdXQ/IChwbGVhc2UgcmVhZCB0 aGUgcmVsZXZhbnQgcGFydHMgb2YgdGhlIHNwZWMgYmVmb3JlIGNoaW1pbmcgaW4gOikpDQpCLiBJ ZiB5ZXMsIHdoYXQgY2FuIHdlIGRvIHRvIG1ha2UgdGhhdCBpbmZvIGF2YWlsYWJsZSB0byBSU3Mg aW4gYSB3YXkgdGhhdCBtYWtlcyB5b3UgY29tZm9ydGFibGU/DQoNCg0KVGhhbmtzDQoNClYuDQoN Ck9uIE1vbiwgRGVjIDE2LCAyMDE5IGF0IDI6NDkgUE0gPGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4gd3JvdGU6DQoNCkEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBk aXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFdlYiBBdXRob3Jp emF0aW9uIFByb3RvY29sIFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAgICAgICAg ICA6IEpTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9r ZW5zDQogICAgICAgIEF1dGhvciAgICAgICAgICA6IFZpdHRvcmlvIEJlcnRvY2NpDQogICAgICAg IEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMy50 eHQNCiAgICAgICAgUGFnZXMgICAgICAgICAgIDogMTYNCiAgICAgICAgRGF0ZSAgICAgICAgICAg IDogMjAxOS0xMi0xNg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVz IGEgcHJvZmlsZSBmb3IgaXNzdWluZyBPQXV0aCAyLjAgYWNjZXNzDQogICB0b2tlbnMgaW4gSlNP TiB3ZWIgdG9rZW4gKEpXVCkgZm9ybWF0LiAgQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGFuZA0KICAg cmVzb3VyY2Ugc2VydmVycyBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzIGNhbiBsZXZlcmFnZSB0aGlz IHByb2ZpbGUgdG8NCiAgIGlzc3VlIGFuZCBjb25zdW1lIGFjY2VzcyB0b2tlbnMgaW4gaW50ZXJv cGVyYWJsZSBtYW5uZXIuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZl cnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzDQoNCkEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3Qt MDMNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRm Lm9yZz4uDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3Vz IEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_AE9BAC2950B04DADB27D02EC803537A9amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <43D9A6EAB7C46A43A96277196CA490DD@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjIgMCA1IDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIg NiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAy IDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2Ut MToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnBy ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixzZXJpZjt9DQpwLk1zb0xp c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJ e21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2Vy aWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBSZWdhcmRpbmcgQXV0aGVudGljYXRlZENsaWVu dDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgYSBtb2JpbGUgYXBw IHRoYXQgdXNlcyBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gdG8gZXN0YWJsaXNoIGEgY2xp ZW50IHNlY3JldCBjb3VudCBhcyBhbiDigJxhdXRoZW50aWNhdGVkIGNsaWVudOKAnT8gV2hhdCBp ZiB0aGF0IHJlZ2lzdHJhdGlvbiBpbmNsdWRlZCBhbiBhc3NlcnRpb24gc2lnbmVkIGJ5IGEgdHJ1 c3RlZCBlbnRpdHkgKGUuZy4sIGRldmljZSBtYW5hZ2VtZW50IHNvZnR3YXJlKSB1c2luZw0KIGEg Y2VydGlmaWNhdGUgdGhhdCBoYWQgYmVlbiBwdXNoZWQgdG8gdGhlIGRldmljZT8gV2l0aG91dCBz b21lIGtpbmQgb2YgTklTVCBMb0Etc3R5bGUgZGVmaW5pdGlvbiBvZiDigJxhdXRoZW50aWNhdGVk 4oCdLCBhIHNpbmdsZSBCb29sZWFuIOKAnEF1dGhlbnRpY2F0ZWRDbGllbnTigJ0gdmFsdWUgaXMg dG9vIGFtYmlndW91cyB0byBiZSB1c2VmdWwuIEhvd2V2ZXIsIEnigJltIHNrZXB0aWNhbCB0aGF0 IHdlIGNvdWxkIGZpbmQgY29uc2Vuc3VzIG9uIHdoYXQgdGhhdA0KIGRlZmluaXRpb24gc2hvdWxk IGJlLCBhbmQgaXQgbWF5IGJlIGJldHRlciB0byBkZWZpbmUgY2xpZW50IGFuYWxvZ3MgdG8gYGFj cmAgYW5kIGBhbXJgIHRoYXQgcHJvdmlkZSBzdGFuZGFyZCB3YXlzIG9mIGV4cHJlc3NpbmcgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIGRldGFpbHMgd2l0aG91dCBnZXR0aW5nIHByZXNjcmlwdGl2ZSBh Ym91dCB3aGF0IGtpbmQgb2YgYXV0aGVudGljYXRpb24gaXMg4oCcZ29vZCBlbm91Z2gu4oCdPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIFJlZ2FyZGluZyBhdXRoZW50aWNhdGlvbiBzZXNzaW9u IHByb3BlcnRpZXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBj b25mdXNlZCBieSB0aGUgZGVmaW5pdGlvbnMgZ2l2ZW4gZm9yIGBhdXRoX3RpbWVgLCBgYWNyYCwg YW5kIGBhbXJgLiBGb3IgYGF1dGhfdGltZWAsIGl0IHNheXM6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj7igJzigKZpdHMgdmFsdWUgd2lsbCBlaXRoZXIg cmVtYWluIHRoZSBzYW1lIGZvciBhbGwgdGhlIEpXVCBhY2Nlc3MgdG9rZW5zIGlzc3VlZCB3aXRo aW4gdGhhdCBzZXNzaW9uIG9yIGJlIHVwZGF0ZWQgdG8gdGhlIHRpbWUgb2YgbGF0ZXN0IGF1dGhl bnRpY2F0aW9uIGlmIHJlYXV0aGVudGljYXRpb24gb2NjdXJyZWQgbWlkLXNlc3Npb27igKbigJ08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IHRoZSDigJxGb3IgZXhhbXBsZeKAnSBhdCB0aGUg ZW5kIG9mIHRoYXQgZGVmaW5pdGlvbiBpbXBsaWVzIHRoYXQgYGF1dGhfdGltZWAgd2lsbCBub3Qg YmUgdXBkYXRlZC4gVGhlIGRlZmluaXRpb25zIGZvciBgYWNyYCBhbmQgYGFtcmAgc2F5IHRoZSBz YW1lLCBidXQgYWxzbyBzYXkgdGhhdCB0aGUg4oCc4oCmc2FtZSBjb25zaWRlcmF0aW9ucyBwcmVz ZW50ZWQgZm9yIGF1dGhfdGltZSBhcHBseeKApuKAnSBXaGF04oCZcyB0aGUgaW50ZW50aW9uDQog aGVyZTogYXJlIHRoZXkgZml4ZWQsIHVwZGF0ZWQsIG9yIGlzIGl0IHVwIHRvIHRoZSBkZXBsb3lt ZW50IHRvIGRlY2lkZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmWQgbGlrZSB0byBiZXR0 ZXIgdW5kZXJzdGFuZCB0aGUgdXNlIGNhc2UgZm9yIHB1dHRpbmcgdGhlc2UgaW4gdGhlIGFjY2Vz cyB0b2tlbi4gSWYgdGhlIFJTIGlzIG1ha2luZyBhdXRob3JpemF0aW9uIGRlY2lzaW9ucyBiYXNl ZCBvbiB0aGVzZSBjbGFpbXMsIHRoYXQgaW1wbGllcyB0aGF0IHRoZSBSUyBjYW5ub3QgcmVseSBv biB0aGUgQVMgdG8gZGV0ZXJtaW5lIChlLmcuLCBmcm9tIHRoZSByZXF1ZXN0ZWQgc2NvcGUpDQog dGhlIHJlcXVpcmVkIGF1dGhlbnRpY2F0aW9uIG1ldGhvZChzKSwgZnJlc2huZXNzLCBldGMuIElm IHRoZSBBUyBjb3VsZCBiZSByZWxpZWQgdXBvbiBmb3IgdGhpcywgdGhlbiBwcmVzdW1hYmx5IGl0 IHdvdWxkIG5vdCBpc3N1ZSBSVHMgYW5kIEFUcyBmb3IgYSBzY29wZSB3aXRob3V0IHJlcXVpcmlu ZyB0aGUgZW5kIHVzZXIgdG8gbWVldCB0aGUgYXBwcm9wcmlhdGUgYXV0aGVudGljYXRpb24gcmVx dWlyZW1lbnRzLiBJZiB0aGlzIGlzIHRoZSBjYXNlLA0KIHRoZW4gdGhlIFJTIG11c3QgaGF2ZSBh IHdheSB0byBzaWduYWwgdG8gdGhlIGNsaWVudCAoYW5kIHRoZW4gdGhlIEFTKSB0aGF0IGEgc3Rl cC11cCBhdXRoZW50aWNhdGlvbiBpcyByZXF1aXJlZC4gSXMgdGhlcmUgYW4gZXhpc3RpbmcgbWVj aGFuaXNtIHRocm91Z2ggd2hpY2ggdGhleSBjb3VsZCBkbyB0aGlzPyBBbGwgSSBjYW4gY29tZSB1 cCB3aXRoIGlzIGNyYW1taW5nIHRoZSBpbmZvcm1hdGlvbiBpbnRvIHRoZSBzY29wZSBhdHRyaWJ1 dGUgb2YNCiBhIFdXVy1BdXRoZW50aWNhdGUgY2hhbGxlbmdlLCBidXQgdGhhdCBoYXMgdGhlIHNh bWUgc2NvcGUgb3BhY2l0eSB2aW9sYXRpb24gcHJvYmxlbSBhcyBkZXNjcmliZWQgaW4gdGhpcyBk cmFmdOKAmXMgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuIFdpdGhvdXQgYSBjbGVhciB3YXkgdG8g ZXhwcmVzcyB0aGUgc3RlcC11cCByZXF1aXJlbWVudHMsIHRoaXMgZmVlbHMgaW5jb21wbGV0ZS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gUmVnYXJkaW5nIGFjY2VzcyB0b2tlbnMgdGhhdCBh cmUgdXNlZCB0byBhY2Nlc3MgZGlmZmVyZW50IHJlc291cmNlIHNlcnZlcnM6PGJyPg0KUmVhZGlu ZyBiZXR3ZWVuIHRoZSBsaW5lcywgSSAqPGI+dGhpbms8L2I+KiB0aGUgaW50ZW50aW9uIGlzIHRo YXQgYSBKV1QgYWNjZXNzIHRva2VuIHRoYXQgaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCB0byBhY2Nl c3MgdHdvIGRpZmZlcmVudCByZXNvdXJjZXMgYXQgdHdvIGRpZmZlcmVudCBSU2VzIHNob3VsZCBs b29rIHNvbWV0aGluZyBsaWtlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q291cmllciI+ezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDo1LjI1cHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDb3VyaWVyIj4mcXVvdDthdWQmcXVvdDs6ICZxdW90O2h0dHBzOi8vZ2VuZXJpYy1yZXNv dXJjZS1pbmRpY2F0b3IuZXhhbXBsZS5jb20vJnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDo1LjI1cHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mcXVvdDtzY29wZSZxdW90OzogJnF1b3Q7cmVzb3Vy Y2VfZm9vIHJlc291cmNlX2JhciZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q291cmllciI+Li4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPn08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpBbmQgdGhlIGV4cGVjdGF0aW9u IGlzIHRoYXQgZWFjaCBSUyBzaG91bGQgcmVjb2duaXplIHRoYXQgZ2VuZXJpYyBhdWRpZW5jZS4g SXMgdGhpcyBjb3JyZWN0PyBJZiBzbyBpdCBzZWVtcyB0byBnbyBhZ2FpbnN0IHRoZSBzcGlyaXQg b2YgcmVzb3VyY2UgaW5kaWNhdG9ycyBhcyBpbmRpY2F0aW5nIHRoZSB0YXJnZXQgb3IgbG9jYXRp b24gb2YgYSByZXNvdXJjZS4gSXTigJlzIHN0cmV0Y2hpbmcgdGhhdCBkZWZpbml0aW9uLCBhdCB0 aGUgdmVyeSBsZWFzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IGFzIEkgc2FpZCwgSeKA mW0gcmVhZGluZyBiZXR3ZWVuIHRoZSBsaW5lcyBoZXJlLiBJZiB0aGlzIGlzIHRoZSBpbnRlbnRp b24sIGl0IHNob3VsZCBiZSBjbGVhcmx5IHN0YXRlZC4gQWx0ZXJuYXRpdmVseSwgcmVtb3ZlIChv ciBjaGFuZ2UgdG8gYSBTSE9VTEQpIHRoZSByZXF1aXJlbWVudCB0aGF0IG11bHRpLXZhbHVlIGBh dWRgIGNsYWltcyBtdXN0IG9ubHkgY29udGFpbiBhbGlhc2VzIGZvciB0aGUgc2FtZQ0KIHJlc291 cmNlIGluZGljYXRvci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJlbGxl IFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0O29hdXRoLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7Vml0dG9y aW89NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRh eSwgRGVjZW1iZXIgMTYsIDIwMTkgYXQgMjo1MSBQTTxicj4NCjxiPlRvOiA8L2I+SUVURiBvYXV0 aCBXRyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtpLWQtYW5u b3VuY2VAaWV0Zi5vcmcmcXVvdDsgJmx0O2ktZC1hbm5vdW5jZUBpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vYXV0 aC1hY2Nlc3MtdG9rZW4tand0LTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5EZWFyIGFsbCw8YnI+DQpJIGZpbmFsbHkgZm91bmQgdGhlIHRpbWUgdG8gcHVzaCBhIG5ldyBk cmFmdCBvZiB0aGUgSldUIHByb2ZpbGUgZm9yIEFUcy4gVGhpcyB2ZXJzaW9uIGluY29ycG9yYXRl cyB0aGUgZmVlZGJhY2sga2luZGx5IHByb3ZpZGVkIGJ5IEJyaWFuIGFuZCBBYXJvbiBhdCBJRVRG MTA1Ljxicj4NClVuZm9ydHVuYXRlbHkgSSBkaWRuJ3QgaGF2ZSBhIGNoYW5jZSB0byBwYXJ0aWNp cGF0ZSB0byBJRVRGMTA2LCBoZW5jZSB3ZSBkaWRuJ3QgZG8gbXVjaCBwcm9ncmVzcyBzaW5jZSB0 aGVuLjxicj4NClRoZXJlIGFyZSBzdGlsbCB0d28gYXJlYXMgd2UgZGlkbid0IG1hbmFnZSB0byBy ZWFjaCBjb25zZW5zdXMgb246PGJyPg0KPGJyPg0KMS4gTWVjaGFuaXNtcyBmb3Igc2lnbmFsaW5n IHdoZXRoZXIgdGhlIEFUIHdhcyBvYnRhaW5lZCBieSBhIHVzZXIgb3IgYW4gYXBwbGljYXRpb248 YnI+DQo8YnI+DQpUaGlzIHBvaW50IHdhcyB0aGUgc3ViamVjdCBvZiBpbnRlbnNlIGRlYmF0ZSBv biB0aGUgbGlzdCBsZWFkaW5nIHRvIElFVEYxMDUuPGJyPg0KT25lIGluc2lnaHQgdGhhdCBlbWVy Z2VkIGZyb20gdGhlIElFVEYxMDUgZGlzY3Vzc2lvbiB3YXMgdGhhdCB0aGUgdXNlIGNhc2UgaGVy ZSBpcyBtb3JlIGFib3V0IHdoZXRoZXIgdGhlIEFUIGhhcyBiZWVuIG9idGFpbmVkIHZpYSBhIGdy YW50IHRoYXQgYXV0aGVudGljYXRlZCB0aGUgY2xpZW50IChyZWdhcmRsZXNzIG9mIHdoYXQgc3Bl Y2lmaWMgZ3JhbnQgd2FzIHVzZWQpIHZzIGEgcHVibGljIGNsaWVudCBncmFudC0gdGhhdCBpbmZv cm1hdGlvbg0KIGNhbiBiZSByZWxldmFudCB0byBhIHJlc291cmNlIGFzIGl0IGRldGVybWluZXMg d2hldGhlciB0aGUgaWRlbnRpdHkgb2YgdGhlIGNsaWVudCBjYW4gYmUgdXNlZCBpbiBhdXRob3Jp emF0aW9uIGRlY2lzaW9ucyAoaW4gdGhlIGZvcm1lciBjYXNlKSBvciBub3QgKGluIHRoZSBwdWJs aWMgY2xpZW50IGNhc2UpLiBJZiB0aGF0J3MgdGhlIHNjZW5hcmlvIHdlIGFyZSB0cnVseSBhZnRl ciwgYSBzaW1wbGUsIHBvc3NpYmx5IG9wdGlvbmFsIGJvb2xlYW4NCiBjbGFpbSAoc2F5IEF1dGhl bnRpY2F0ZWRDbGllbnQpIHdvdWxkIHN1ZmZpY2UuPGJyPg0KTm90ZSBmb3IgdGhlIHBlb3BsZSB3 aG8gZGlkbid0IHJlYWQgdGhlIHNwZWM6IEkgcmVtb3ZlZCBhbnkgcmVmZXJlbmNlIHRvIHRoaXMg YWxyZWFkeSBpbiBkcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDEuIEkgdGhpbmsg dGhpcyBpcyBhbiBpbXBvcnRhbnQgYW5kIHVzZWZ1bCBpbmZvIGFuZCBzdGFuZGFyZGl6aW5nIGl0 IHdvdWxkIGJlIGJlbmVmaWNpYWwgZm9yIG1pZGRsZXdhcmUgYW5kIFNESyBjcmVhdG9ycywgYnV0 IHVsdGltYXRlbHkNCiB0aGlzIGlzIGFuIGludGVyb3AgcHJvZmlsZSBoZW5jZSBpZiB0aGVyZSdz IG5vIHN0cm9uZyBkZXNpcmUgdG8gcmVhY2ggYW4gYWdyZWVtZW50IGhlcmUsIEkgYW0gYWxzbyBP SyB3aXRoIGRyb3BwaW5nIHRoZSBtYXR0ZXIgYW5kIG5vdCBhZGRyZXNzIHRoaXMgZnVuY3Rpb24g aW4gdGhlIHNwZWMuPGJyPg0KVG8gc3VtbWFyaXplLCBJIGhhdmUgdHdvIHF1ZXN0aW9ucyBoZXJl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEuIERvIHdlIGJlbGlldmUg aXQncyB3b3J0aCBpdCB0byBmb3JtYWxpemUgaW4gdGhlIHByb2ZpbGUgYSBtZWNoYW5pc20gdG8g aW5kaWNhdGUgd2hldGhlciB0aGUgY2xpZW50IHRoIG9idGFpbmVkIHRoZSBBVCBhdXRoZW50aWNh dGVkIGl0c2VsZiB3aXRoIHRoZSBBUz88YnI+DQpCLiBJZiB5ZXMsIGFyZSB5b3UgT0sgd2lodCBh biBvcHRpb25hbCBib29sIGNsYWltIGhlcmU/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N CjIuIENsYWltcyBpbmRpY2F0aW5nIHNlc3Npb24gcHJvcGVydGllczxicj4NCjxicj4NClRoaXMg aXMgb25lIGFyZWEgd2hlcmUgSSBhbSBmYXIgbW9yZSBwYXNzaW9uYXRlIGFib3V0LCBhcyBpdCBy ZXByZXNlbnRzIGEgZnVuZGFtZW50YWwgYXNwZWN0IHRoYXQgcHJvZHVjdGlvbiBzeXN0ZW1zIChh bmQgaW4gcGFydGljdWxhciAxc3QgcGFydHkgc29sdXRpb25zKSBhbHJlYWR5IHJlbHkgb24gaW4g dGhlIGN1cnJlbnQgcHJvcHJpZXRhcnkgSlRXIEFUcy48YnI+DQpUaGUgcHJvZmlsZSBjdXJyZW50 bHkgaW5jbHVkZXMgdGhlIGNsYWltcyBhdXRoX3RpbWUsIGFjciBhbmQgYW1yIC0gY2FwdHVyaW5n IHRoZSB2YWx1ZXMgb2YgdGhvc2UgcHJvcGVydGllcyBhdCB0aGUgdGltZSBvZiB0aGUgbGF0ZXN0 IGF1dGhlbnRpY2F0aW9uIHRoZSB1c2VyIHBlcmZvcm1lZCBpbiB0aGUgc2Vzc2lvbiB1c2VkIHRv IGlzc3VlIHRoZSBjdXJyZW50IEFUOiBhdCBzZXNzaW9uIGNyZWF0aW9uLCBhdCBhdXRoIHN0ZXAg dXAgdGltZSBhbmQNCiBzbyBvbi48YnI+DQpUaG9zZSBhcmUgdmFsdWVzIHRoYXQgQVBJIG5lZWQg aW4gb3JkZXIgdG8gbWFrZSBhdXRob3JpemF0aW9uIGRlY2lzaW9uczsgaW4gdGhlIGNhc2Ugb2Yg MXN0IHBhcnR5IEFQSXMsIHRoZSBBVCBpcyB0aGUgb25seSBhcnRpZmFjdCB0aGV5IGV2ZXIgcmVj ZWl2ZSBoZW5jZSB0aGVyZSBpcyBubyBvdGhlciB3YXkgZm9yIGFuIEFQSSB0byBkZXRlcm1pbmUg d2hldGhlciB0aGUgY2FsbGVyIHBlcmZvcm1lZCBzYXkgTUZBIGluIG9yZGVyIHRvIG9idGFpbg0K IHRoZSBjdXJyZW50IEFULjxicj4NClNpbmNlIHRoZSBmaXJzdCBkcmFmdCwgc29tZSBwZW9wbGUg c2lnbmFsZWQgY29uY2VybnMgYWJvdXQgdGhlIGN1cnJlbnQgbWVjaGFuaXNtcyB0aHJ1IHdoaWNo IHRob3NlIGNsYWltcyBnZXQgdGhlaXIgdmFsdWUuIEZvciBleGFtcGxlLCBpdCBoYXMgYmVlbiBw cm9wb3NlZCB0byBtYWludGFpbiB0aGUgb3JpZ2luYWwgdmFsdWVzIG9mIGF1dGhfdGltZSwgYWNy ICZhbXA7IGFtciBhbmQgaW50cm9kdWNlIGFkZGl0aW9uYWwgY2xhaW1zIHRvIGluZGljYXRlDQog Y2hhbmdlcyAobGlrZSBzdGVwdXApLjxicj4NCkkgYW0gbm90IGNsZWFyIG9uIHdoYXQgY29sZCBn byB3cm9uZyB3aXRoIHRoZSBjdXJyZW50IGFwcHJvYWNoLCBoZW5jZSBJIGRvbid0IGhhdmUgYW4g aW1tZWRpYXRlIGdyYXNwIG9mIGhvdyBjaGFuZ2VzIGxpa2UgdGhlIGFib3ZlIHdvdWxkIGhlbHAu PGJyPg0KSWYgdGhlIHBlb3BsZSB1bmNvbWZvcnRhYmxlIHdpdGggdGhlIGN1cnJlbnQgcHJvcG9z YWwgY291bGQgZGV0YWlsIHRoZWlyIGNvbmNlcm4sIHdlIGNhbiBicmFpbnN0b3JtIHdheXMgdG8g bWFrZSB0aGF0IGluZm8gYXZhaWxhYmxlIHRvIEFQSSBpbiBhIHNhZmVyIHdheS4gVG8gc3VtbWFy aXplOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEuIERvIHlvdSBoYXZl IGNvbmNlcm5zIHdpdGggdGhlIGN1cnJlbnQgYXV0aF90aW1lLCBhcm0sIGFjciBwcm9wb3NhbD8g Q2FuIHlvdSBzcGVsbCB0aGVtIG91dD8gKHBsZWFzZSByZWFkIHRoZSByZWxldmFudCBwYXJ0cyBv ZiB0aGUgc3BlYyBiZWZvcmUgY2hpbWluZyBpbiA6KSk8YnI+DQpCLiBJZiB5ZXMsIHdoYXQgY2Fu IHdlIGRvIHRvIG1ha2UgdGhhdCBpbmZvIGF2YWlsYWJsZSB0byBSU3MgaW4gYSB3YXkgdGhhdCBt YWtlcyB5b3UgY29tZm9ydGFibGU/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpUaGFua3M8YnI+DQo8YnI+DQpWLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBEZWMgMTYsIDIw MTkgYXQgMjo0OSBQTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgV2Vi IEF1dGhvcml6YXRpb24gUHJvdG9jb2wgV0cgb2YgdGhlIElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs6IEpTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBB Y2Nlc3MgVG9rZW5zPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvciZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBWaXR0b3JpbyBCZXJ0b2NjaTxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyA6IGRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMy50eHQ8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzogMTY8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0ZSZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjAxOS0xMi0xNjxicj4N Cjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIHNwZWNpZmljYXRpb24gZGVm aW5lcyBhIHByb2ZpbGUgZm9yIGlzc3VpbmcgT0F1dGggMi4wIGFjY2Vzczxicj4NCiZuYnNwOyAm bmJzcDt0b2tlbnMgaW4gSlNPTiB3ZWIgdG9rZW4gKEpXVCkgZm9ybWF0LiZuYnNwOyBBdXRob3Jp emF0aW9uIHNlcnZlcnMgYW5kPGJyPg0KJm5ic3A7ICZuYnNwO3Jlc291cmNlIHNlcnZlcnMgZnJv bSBkaWZmZXJlbnQgdmVuZG9ycyBjYW4gbGV2ZXJhZ2UgdGhpcyBwcm9maWxlIHRvPGJyPg0KJm5i c3A7ICZuYnNwO2lzc3VlIGFuZCBjb25zdW1lIGFjY2VzcyB0b2tlbnMgaW4gaW50ZXJvcGVyYWJs ZSBtYW5uZXIuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBh Z2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgt YWNjZXNzLXRva2VuLWp3dC88L2E+PGJyPg0KPGJyPg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQg dmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3Mt dG9rZW4tand0LTAzPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDM8L2E+PGJyPg0KPGJyPg0KQSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1q d3QtMDMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzPC9hPjxicj4NCjxicj4NCjxicj4N ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NCkludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQo8YSBocmVm PSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AE9BAC2950B04DADB27D02EC803537A9amazoncom_-- From nobody Mon Dec 16 20:19:56 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9BB12011B for ; Mon, 16 Dec 2019 20:19:53 -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, 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=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0C0-voZOM-hM for ; Mon, 16 Dec 2019 20:19:49 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBC01200B6 for ; Mon, 16 Dec 2019 20:19:49 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id z193so5960861iof.1 for ; Mon, 16 Dec 2019 20:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/Eb0liIpsrbCacJTMAEOix5q7yoBpngAgahUHH3yz0k=; b=aTttNURr7Sl97FLL/VLGrBkfb6QXiWc72NWuROIjPRgJEDGu3PNM5GrRMwiaubbiw8 ItKvHORY52i8A5lUaQ87pp2A+NErlsWjWPwbNxLe06lrahLZSRhRtS8AiXgbHVpDU7vX Q6bgWuf7ONvLAGGqPR674MKSl1T+4fYqfm4ffwe/QE1JR5AcdXqoO6qc0fj+TwnuMmSa VzBNKHWCbxS3TiqQ1By6Rh/hOeAqc7VeXlXZHoGjJQ2xn1DCTbkuomBor//M3zuE1npW fJuzft7gQOHg8joLW+XCTxc9HgB+l3zKnL5+pYZ00YmQu87EpQz4eBaH9eDT8QwCxHoW uYCg== 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=/Eb0liIpsrbCacJTMAEOix5q7yoBpngAgahUHH3yz0k=; b=uDQ9GAlxe+qUo33i+zmq3clGNSRdb/1H11RMlUPy059yE210c/lzIj7Kq8NRBQgkRd K3MrgST5MLEkpMet/K37GbzmXSSd+fGWfNeQIGhliHfY7UEvOpsnEOgPRL40Y9wMuYvu E30utvGbi83sqYSs2UyVbtED50v4T4Fi8kTjJSjsV4bmc/rZbE+PyE+YNmD4DjzaBeLo 7MKtD1+p4/+NsY+VWpq4WQ+50STPsZZ5kk3iofFhRM+kXBXu41KdefL0ASNoz2YLrhfl GYNJ6xniAZVQBxU98/giHNGqgthf1x+q5Qz9PW+dlskiw+BDpXUJV4GyybTL4QTzir+8 Br1Q== X-Gm-Message-State: APjAAAUf0NgsuKRpQnj3+jqA2GjtsCxrw/eeqYyMzaG2LQ/dmdmmotMs UycqG1GgSzyxtk9v5T6k94mmhunuzQ8oWDCCyARg4A== X-Google-Smtp-Source: APXvYqyzmdZki2wBYwqDOt6PgI9HYSfY6Yn42S4FSiOclItV4gLmjeOz8oFKPe/hoMqCowg0sMdkU2A/nnucQHKmJis= X-Received: by 2002:a5d:8cd6:: with SMTP id k22mr2129156iot.283.1576556388503; Mon, 16 Dec 2019 20:19:48 -0800 (PST) MIME-Version: 1.0 References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> In-Reply-To: From: Vittorio Bertocci Date: Mon, 16 Dec 2019 20:19:37 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: Vittorio Bertocci , IETF oauth WG , "i-d-announce@ietf.org" Content-Type: multipart/alternative; boundary="00000000000081675f0599dea3e3" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 04:19:53 -0000 --00000000000081675f0599dea3e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Annabelle. Does a mobile app that uses Dynamic Client Registration to establish a > client secret count as an =E2=80=9Cauthenticated client=E2=80=9D? I think it should count, tho I am not sure what the RS would do with it. Dynamic client registration would likely not have much use for this. In the cases I have seen, the idea is that a client (whose clientID is already known to the RS) can obtain tokens thru different grants, some of them confidential and others public; and the resource wants to know whether this particular token was obtained proving the identity of the client so that it can decide whether to grant extra privileges for that particular client in the current call. This scenario does not require the extra details about authentication method/strength you mention that, I agree, would be pretty hard to reach consensus on. TL;DR: there is at least one scenario that is satisfied by the simple bool, as the previous knowledge of the client solves the issues you mention out of band. authentication session properties: Let me try another angle. Say that I perform an authz code grant asking for AT, ID_T and RT- obtaining AT', ID_T' and RT'. The values of auth_time, acr and amr in AT' will be the same as the corresponding claims in ID_T'. When the client uses RT' to obtain AT`N, AT'N+1 etc etc, the values of those claims will remain the same for every AT'n obtained by RT'. Now, imagine that something happens (ignore what for the time being) that causes the client to perform a step up auth, which requires the user to perform interactive auth hence results in a new authz grant. The client will obtain a new tuple AT", ID_T" and RT". The exact same rules described for the ' tuple apply, with the new values determined by the new authentication: AT" auth_time/acr/amr will be the same as ID_T", and those values will remain unchanged for every AT"n derived by RT". If we want this to apply to the implicit flow as well, you can substitute the RT with the session artifact. Does that help clarifying the intent? If yes, do you feel that the current language does not describe this? use case for putting these in the access token I am not trying to create a complete framework for handling step up and the like, I am trying to create an interoperable representation of those values no matter how they were obtained. Consider the case in which an API allows certain operations only if a given amr value is present in the token. Whether that amr is required upfront on first authentication, as step up or any other reason is out of scope for this profile IMO: the AS might have all sorts of heuristics that determine that (user membership to a given group or role; geofencing; risk scoring; etc) that have nothing to do with scopes requested, and are not statically determined by RS-AS communications. Now, I agree that formalizing how a RS communicates to the AS via the client the need to step up and in what terms would be super useful; however I think that's well beyond the scope of this profile. Various vendors already have their own mechanisms for handling step up signaling from RS to AS (I am very familiar with the Microsoft one) and all I am looking for is a way of standardizing how to represent the outcomes, so that API gateways and SDK providers can provide tools that work across vendors; and possibly reuse some of the reasoning that was already done for id_tokens. TL;DR: I think we are doing something useful in formalizing how to embed that info an ATs even if we don't force vendors to give up their current mechanisms to populate those values. Regarding access tokens that are used to access different resource servers The intent is to explicitly disallow the use of an AT with multiple resource servers. If a client wants to talk with 2 different RSes, the client should ask for 2 different ATs. The spec is unambiguous on this IMO, here's the language I use in 03. If it receives a request for an access token containing more than one resource parameter, an authorization server issuing JWT access tokens MUST reject the request and fail with "invalid_request" as described in section 4.1.2.1 of [RFC6749] or with "invalid_target" as defined in section 2 of [ResourceIndicators ]. See Section 2.2 and Section 5 for more details on how this measure ensures there's no confusion on to what resource the access token granted scopes apply. Is it possible you are referring to an older draft? On Mon, Dec 16, 2019 at 5:28 PM Richard Backman, Annabelle wrote: > 1. Regarding AuthenticatedClient: > > Does a mobile app that uses Dynamic Client Registration to establish a > client secret count as an =E2=80=9Cauthenticated client=E2=80=9D? What if= that registration > included an assertion signed by a trusted entity (e.g., device management > software) using a certificate that had been pushed to the device? Without > some kind of NIST LoA-style definition of =E2=80=9Cauthenticated=E2=80=9D= , a single Boolean > =E2=80=9CAuthenticatedClient=E2=80=9D value is too ambiguous to be useful= . However, I=E2=80=99m > skeptical that we could find consensus on what that definition should be, > and it may be better to define client analogs to `acr` and `amr` that > provide standard ways of expressing client authentication details without > getting prescriptive about what kind of authentication is =E2=80=9Cgood e= nough.=E2=80=9D > > > > 2. Regarding authentication session properties: > > I=E2=80=99m confused by the definitions given for `auth_time`, `acr`, and= `amr`. > For `auth_time`, it says: > > > > =E2=80=9C=E2=80=A6its value will either remain the same for all the JWT a= ccess tokens > issued within that session or be updated to the time of latest > authentication if reauthentication occurred mid-session=E2=80=A6=E2=80=9D > > > > But the =E2=80=9CFor example=E2=80=9D at the end of that definition impli= es that > `auth_time` will not be updated. The definitions for `acr` and `amr` say > the same, but also say that the =E2=80=9C=E2=80=A6same considerations pre= sented for > auth_time apply=E2=80=A6=E2=80=9D What=E2=80=99s the intention here: are = they fixed, updated, or is > it up to the deployment to decide? > > > > I=E2=80=99d like to better understand the use case for putting these in t= he access > token. If the RS is making authorization decisions based on these claims, > that implies that the RS cannot rely on the AS to determine (e.g., from t= he > requested scope) the required authentication method(s), freshness, etc. I= f > the AS could be relied upon for this, then presumably it would not issue > RTs and ATs for a scope without requiring the end user to meet the > appropriate authentication requirements. If this is the case, then the RS > must have a way to signal to the client (and then the AS) that a step-up > authentication is required. Is there an existing mechanism through which > they could do this? All I can come up with is cramming the information in= to > the scope attribute of a WWW-Authenticate challenge, but that has the sam= e > scope opacity violation problem as described in this draft=E2=80=99s Secu= rity > Considerations. Without a clear way to express the step-up requirements, > this feels incomplete. > > > > 3. Regarding access tokens that are used to access different resource > servers: > Reading between the lines, I **think** the intention is that a JWT access > token that is intended to be used to access two different resources at tw= o > different RSes should look something like: > > > > { > > "aud": "https://generic-resource-indicator.example.com/", > > "scope": "resource_foo resource_bar", > > ... > > } > > > And the expectation is that each RS should recognize that generic > audience. Is this correct? If so it seems to go against the spirit of > resource indicators as indicating the target or location of a resource. > It=E2=80=99s stretching that definition, at the very least. > > > > But as I said, I=E2=80=99m reading between the lines here. If this is the > intention, it should be clearly stated. Alternatively, remove (or change = to > a SHOULD) the requirement that multi-value `aud` claims must only contain > aliases for the same resource indicator. > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Vittorio Bertocci > > *Date: *Monday, December 16, 2019 at 2:51 PM > *To: *IETF oauth WG > *Cc: *"i-d-announce@ietf.org" > *Subject: *Re: [OAUTH-WG] I-D Action: > draft-ietf-oauth-access-token-jwt-03.txt > > > > Dear all, > I finally found the time to push a new draft of the JWT profile for ATs. > This version incorporates the feedback kindly provided by Brian and Aaron > at IETF105. > Unfortunately I didn't have a chance to participate to IETF106, hence we > didn't do much progress since then. > There are still two areas we didn't manage to reach consensus on: > > 1. Mechanisms for signaling whether the AT was obtained by a user or an > application > > This point was the subject of intense debate on the list leading to > IETF105. > One insight that emerged from the IETF105 discussion was that the use cas= e > here is more about whether the AT has been obtained via a grant that > authenticated the client (regardless of what specific grant was used) vs = a > public client grant- that information can be relevant to a resource as it > determines whether the identity of the client can be used in authorizatio= n > decisions (in the former case) or not (in the public client case). If > that's the scenario we are truly after, a simple, possibly optional boole= an > claim (say AuthenticatedClient) would suffice. > Note for the people who didn't read the spec: I removed any reference to > this already in draft-ietf-oauth-access-token-jwt-01. I think this is an > important and useful info and standardizing it would be beneficial for > middleware and SDK creators, but ultimately this is an interop profile > hence if there's no strong desire to reach an agreement here, I am also O= K > with dropping the matter and not address this function in the spec. > To summarize, I have two questions here: > > A. Do we believe it's worth it to formalize in the profile a mechanism to > indicate whether the client th obtained the AT authenticated itself with > the AS? > B. If yes, are you OK wiht an optional bool claim here? > > > 2. Claims indicating session properties > > This is one area where I am far more passionate about, as it represents a > fundamental aspect that production systems (and in particular 1st party > solutions) already rely on in the current proprietary JTW ATs. > The profile currently includes the claims auth_time, acr and amr - > capturing the values of those properties at the time of the latest > authentication the user performed in the session used to issue the curren= t > AT: at session creation, at auth step up time and so on. > Those are values that API need in order to make authorization decisions; > in the case of 1st party APIs, the AT is the only artifact they ever > receive hence there is no other way for an API to determine whether the > caller performed say MFA in order to obtain the current AT. > Since the first draft, some people signaled concerns about the current > mechanisms thru which those claims get their value. For example, it has > been proposed to maintain the original values of auth_time, acr & amr and > introduce additional claims to indicate changes (like stepup). > I am not clear on what cold go wrong with the current approach, hence I > don't have an immediate grasp of how changes like the above would help. > If the people uncomfortable with the current proposal could detail their > concern, we can brainstorm ways to make that info available to API in a > safer way. To summarize: > > A. Do you have concerns with the current auth_time, arm, acr proposal? Ca= n > you spell them out? (please read the relevant parts of the spec before > chiming in :)) > B. If yes, what can we do to make that info available to RSs in a way tha= t > makes you comfortable? > > > > Thanks > > V. > > > > On Mon, Dec 16, 2019 at 2:49 PM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IET= F. > > Title : JSON Web Token (JWT) Profile for OAuth 2.0 > Access Tokens > Author : Vittorio Bertocci > Filename : draft-ietf-oauth-access-token-jwt-03.txt > Pages : 16 > Date : 2019-12-16 > > Abstract: > This specification defines a profile for issuing OAuth 2.0 access > tokens in JSON web token (JWT) format. Authorization servers and > resource servers from different vendors can leverage this profile to > issue and consume access tokens in interoperable manner. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-03 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-0= 3 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000081675f0599dea3e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Annabelle.

Does a mobile app that uses Dynamic Client Registration t= o establish a client secret count as an =E2=80=9Cauthenticated client=E2=80= =9D?=C2=A0=C2=A0
I think it should count, tho I am not sur= e what the RS would do with it. Dynamic client registration would likely no= t have much use for this.
In the cases I have seen, the idea is t= hat a client (whose clientID is already known to the RS) can obtain tokens = thru different grants, some of them confidential and others public; and the= resource wants to know whether this particular token was obtained proving = the identity of the client so that it can decide whether to grant extra pri= vileges for that particular=C2=A0client in the current call. This scenario = does not require the extra details about authentication method/strength you= mention that, I agree, would be pretty hard to reach consensus on.
TL;DR: there is at least one scenario that is satisfied by the simple bo= ol, as the previous knowledge of the client solves the issues you mention o= ut of band.=C2=A0

authentication session properties:=C2=A0
=C2= =A0Let me try another angle. Say that I perform an authz code grant asking = for AT, ID_T and RT- obtaining AT', ID_T' and RT'.=C2=A0
<= div>The values of auth_time, acr and amr in AT' will be the same as the= corresponding claims in ID_T'. When the client uses RT' to obtain = AT`N, AT'N+1 etc etc, the values of those claims will remain the same f= or every AT'n obtained by RT'.
Now, imagine that somethin= g happens (ignore what for the time being) that causes the client to perfor= m a step up auth, which requires the user to perform interactive auth hence= results in a new authz grant. The client will obtain a new tuple=C2=A0 AT", ID_T" and RT". The exact same rules described for the &= #39; tuple apply, with the new values determined by the new authentication:= AT" auth_time/acr/amr will be the same as ID_T", and those value= s will remain unchanged for every AT"n derived by RT".
If we w= ant this to apply to the implicit flow as well, you can substitute the RT w= ith the session artifact.=C2=A0
Does that help clarifying the int= ent? If yes, do you feel that the current language does not describe this?<= /div>

use c= ase for putting these in the access token=C2=A0
I am not t= rying to create a complete framework for handling step up and the like, I a= m trying to create an interoperable representation of those values no matte= r how they were obtained.=C2=A0
Consider the case in which an API= allows certain operations only if a given amr value is present in the toke= n. Whether that amr is required upfront on first authentication, as step up= or any other reason is out of scope for this profile IMO: the AS might hav= e all sorts of heuristics that determine that (user membership to a given g= roup or role; geofencing; risk scoring; etc) that have nothing to do with s= copes requested, and are not statically determined by RS-AS communications.= =C2=A0
Now, I agree that formalizing how a RS communicates to the= AS via the client the need to step up and in what terms would be super=C2= =A0useful; however I think that's well beyond the scope of this profile= . Various vendors already have their own mechanisms for handling step up si= gnaling from RS to AS (I am very familiar with the Microsoft=C2=A0one) and = all I am looking for is a way of standardizing how to represent the outcome= s, so that API gateways and SDK providers can provide tools that work acros= s vendors; and possibly reuse some of the reasoning that was already done f= or id_tokens.
TL;DR: I think we are doing something useful in for= malizing how to embed that info an ATs even if we don't force vendors t= o give up their current mechanisms to populate those values.

=
Regarding access to= kens that are used to access different resource servers
Th= e intent is to explicitly disallow the use of an AT with multiple resource = servers. If a client wants to talk with 2 different RSes, the client should= ask for 2 different ATs.
The spec is unambiguous on this IMO, he= re's the language I use in 03. 

If it receives a request for an acce=
ss token containing more than one
   resource parameter, an authorization server issuing JWT access tokens
   MUST reject the request and fail with "invalid_request" as des=
cribed
   in section=C2=A04.1.2.1 of [RFC6749] or with "invalid_tar=
get" as defined
   in section 2 of [ResourceIndic=
ators].  See Section 2.2 and Section 5
   for more details on how this measure ensures there's no confusion on
   to what resource the access token granted scopes apply.
= =C2=A0 Is it possible you are referring to an older draft?=C2=A0=C2=A0
<= /div>
=C2=A0

On Mon, Dec 16, 2019 at 5:28 PM Richard Backm= an, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

1. Regarding AuthenticatedClient:

Does a mobile app that uses Dynamic Client Registrat= ion to establish a client secret count as an =E2=80=9Cauthenticated client= =E2=80=9D? What if that registration included an assertion signed by a trus= ted entity (e.g., device management software) using a certificate that had been pushed to the device? Without some kind of NIS= T LoA-style definition of =E2=80=9Cauthenticated=E2=80=9D, a single Boolean= =E2=80=9CAuthenticatedClient=E2=80=9D value is too ambiguous to be useful.= However, I=E2=80=99m skeptical that we could find consensus on what that definition should be, and it may be better to define client analogs to `ac= r` and `amr` that provide standard ways of expressing client authentication= details without getting prescriptive about what kind of authentication is = =E2=80=9Cgood enough.=E2=80=9D

=C2=A0

2. Regarding authentication session properties:

I=E2=80=99m confused by the definitions given for `a= uth_time`, `acr`, and `amr`. For `auth_time`, it says:

=C2=A0

=E2=80=9C=E2=80=A6its va= lue will either remain the same for all the JWT access tokens issued within= that session or be updated to the time of latest authentication if reauthe= ntication occurred mid-session=E2=80=A6=E2=80=9D

=C2=A0

But the =E2=80=9CFor example=E2=80=9D at the end of = that definition implies that `auth_time` will not be updated. The definitio= ns for `acr` and `amr` say the same, but also say that the =E2=80=9C=E2=80= =A6same considerations presented for auth_time apply=E2=80=A6=E2=80=9D What= =E2=80=99s the intention here: are they fixed, updated, or is it up to the deployment to decide?=

=C2=A0

I=E2=80=99d like to better understand the use case f= or putting these in the access token. If the RS is making authorization dec= isions based on these claims, that implies that the RS cannot rely on the A= S to determine (e.g., from the requested scope) the required authentication method(s), freshness, etc. If the AS could be = relied upon for this, then presumably it would not issue RTs and ATs for a = scope without requiring the end user to meet the appropriate authentication= requirements. If this is the case, then the RS must have a way to signal to the client (and then the AS) that= a step-up authentication is required. Is there an existing mechanism throu= gh which they could do this? All I can come up with is cramming the informa= tion into the scope attribute of a WWW-Authenticate challenge, but that has the same scope opacity violatio= n problem as described in this draft=E2=80=99s Security Considerations. Wit= hout a clear way to express the step-up requirements, this feels incomplete= .

=C2=A0

3. Regarding access tokens that are used to access d= ifferent resource servers:
Reading between the lines, I *think* the intention is that a JWT acc= ess token that is intended to be used to access two different resources at = two different RSes should look something like:

=C2=A0

{<= /span>

"aud": "https://generic-resource-indicator.e= xample.com/",

"scope": "resource_foo resource_bar",

...

}<= /span>


And the expectation is that each RS should recognize that generic audience.= Is this correct? If so it seems to go against the spirit of resource indic= ators as indicating the target or location of a resource. It=E2=80=99s stre= tching that definition, at the very least.

=C2=A0

But as I said, I=E2=80=99m reading between the lines= here. If this is the intention, it should be clearly stated. Alternatively= , remove (or change to a SHOULD) the requirement that multi-value `aud` cla= ims must only contain aliases for the same resource indicator.

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Bac= kman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org><= br> Date: Monday, December 16, 2019 at 2:51 PM
To: IETF oauth WG <oauth@ietf.org>
Cc: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jw= t-03.txt

=C2=A0

Dear all,
I finally found the time to push a new draft of the JWT profile for ATs. Th= is version incorporates the feedback kindly provided by Brian and Aaron at = IETF105.
Unfortunately I didn't have a chance to participate to IETF106, hence w= e didn't do much progress since then.
There are still two areas we didn't manage to reach consensus on:

1. Mechanisms for signaling whether the AT was obtained by a user or an app= lication

This point was the subject of intense debate on the list leading to IETF105= .
One insight that emerged from the IETF105 discussion was that the use case = here is more about whether the AT has been obtained via a grant that authen= ticated the client (regardless of what specific grant was used) vs a public= client grant- that information can be relevant to a resource as it determines whether the identity of the= client can be used in authorization decisions (in the former case) or not = (in the public client case). If that's the scenario we are truly after,= a simple, possibly optional boolean claim (say AuthenticatedClient) would suffice.
Note for the people who didn't read the spec: I removed any reference t= o this already in draft-ietf-oauth-access-token-jwt-01. I think this is an = important and useful info and standardizing it would be beneficial for midd= leware and SDK creators, but ultimately this is an interop profile hence if there's no strong desire to reach = an agreement here, I am also OK with dropping the matter and not address th= is function in the spec.
To summarize, I have two questions here:

A. Do we believe it's worth it to formalize in t= he profile a mechanism to indicate whether the client th obtained the AT au= thenticated itself with the AS?
B. If yes, are you OK wiht an optional bool claim here?


2. Claims indicating session properties

This is one area where I am far more passionate about, as it represents a f= undamental aspect that production systems (and in particular 1st party solu= tions) already rely on in the current proprietary JTW ATs.
The profile currently includes the claims auth_time, acr and amr - capturin= g the values of those properties at the time of the latest authentication t= he user performed in the session used to issue the current AT: at session c= reation, at auth step up time and so on.
Those are values that API need in order to make authorization decisions; in= the case of 1st party APIs, the AT is the only artifact they ever receive = hence there is no other way for an API to determine whether the caller perf= ormed say MFA in order to obtain the current AT.
Since the first draft, some people signaled concerns about the current mech= anisms thru which those claims get their value. For example, it has been pr= oposed to maintain the original values of auth_time, acr & amr and intr= oduce additional claims to indicate changes (like stepup).
I am not clear on what cold go wrong with the current approach, hence I don= 't have an immediate grasp of how changes like the above would help. If the people uncomfortable with the current proposal could detail their co= ncern, we can brainstorm ways to make that info available to API in a safer= way. To summarize:

A. Do you have concerns with the current auth_time, = arm, acr proposal? Can you spell them out? (please read the relevant parts = of the spec before chiming in :))
B. If yes, what can we do to make that info available to RSs in a way that = makes you comfortable?



Thanks

V.

=C2=A0

On Mon, Dec 16, 2019 at 2:49 PM <internet-drafts@ietf.org&= gt; wrote:


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Vitt= orio Bertocci
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-access-token-jwt-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-12-16

Abstract:
=C2=A0 =C2=A0This specification defines a profile for issuing OAuth 2.0 acc= ess
=C2=A0 =C2=A0tokens in JSON web token (JWT) format.=C2=A0 Authorization ser= vers and
=C2=A0 =C2=A0resource servers from different vendors can leverage this prof= ile to
=C2=A0 =C2=A0issue and consume access tokens in interoperable manner.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-ac= cess-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-tok= en-jwt-03
https://datatracker.ietf.org/doc/html/draft-i= etf-oauth-access-token-jwt-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-= oauth-access-token-jwt-03


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

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

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000081675f0599dea3e3-- From nobody Mon Dec 16 21:31:28 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC671200B4 for ; Mon, 16 Dec 2019 21:31:26 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5zUALxczH0B for ; Mon, 16 Dec 2019 21:31:23 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0382812006B for ; Mon, 16 Dec 2019 21:31:23 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id k24so7978947ioc.4 for ; Mon, 16 Dec 2019 21:31:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jctZeJYGuAyASfMQIhOtjsZvY51zWIdFMpXnmBdzKgc=; b=rGqjVg/DLDWb/LZKETTls6gK8rVKVKjNkh/lqI6vLDotEB+MU4Q95A0HlDC/T/Ja3w XhWE9KfLo37Xjbxfqt8jupE8yScqUlcZCLk4CIGRNVw4u8BB8cDMubGiWv+Gi9B4FnCF d3LfgouByOTOg/sul3hmdhSPO9swyuVdrbp2WLE5ha3NoA8XNUQt0r3aqdarzn+K1Jzd xpwm0uWiR28Pn0QNL2JKmZB0Jywbzl4J6ZLJb2lt5CzRkbArEcAauhFKeUEuBbi0QzzZ 10q8/7i+AnQW/ts6gzhrlWsISeRJZZyv72/NYSO91qXtu/FU74rgGZz0mK6JaXErks2X D5kw== 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=jctZeJYGuAyASfMQIhOtjsZvY51zWIdFMpXnmBdzKgc=; b=TBo3JKNNg6jBQGQqrzkbrg3a17Yv51k8XMl62sKGF4jnFfJ62djgTbSgeBLRz8uytg UJ9r89N3y5iGM1VSwvAXo2LhZvzQEl/T0hXlS4mPDJNk+gOvcrUD5rGF4Vsl9FhcEkih gca7m22PAf34nep6+u/iYNbooK5o4lhEwdtqc7F7Afa9R24Y5ZSlk6CCZVGSKqxYAZM2 W0HW0ZvSxwehJUPUzIGUobu2us9SNIK0rH7KMPfER+R5j+yhudE3arr5ylYSrbOqWD48 Ev/XjOu8MOPlyGS3V1ZMG3uf2hWJpL5wlGzVjTee8MtfxKt+ZQ8FAeejrlHYz2XmqleW 8qjQ== X-Gm-Message-State: APjAAAVeqElvUlz8d6veyC6fx/+PO36FR8hAtnG9WQYRGt9IXbp8+dqs yEfvwS20SAYHrrnVnVRj+sUzLnq7nOuy7F4vgkvIeQ== X-Google-Smtp-Source: APXvYqxc8XAsKEZNNJy7rGcgBxP+hd7ACECn0+zbaobphJYp8kx6bpqopERRrvOAbK+BvVIYEoBW8cRHC1+pwmqLPyQ= X-Received: by 2002:a05:6638:72c:: with SMTP id j12mr15669404jad.136.1576560681910; Mon, 16 Dec 2019 21:31:21 -0800 (PST) MIME-Version: 1.0 References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> In-Reply-To: From: Vittorio Bertocci Date: Mon, 16 Dec 2019 20:35:39 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: IETF oauth WG , Vittorio Bertocci , "i-d-announce@ietf.org" Content-Type: multipart/alternative; boundary="00000000000069ca9a0599dfa302" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 05:31:26 -0000 --00000000000069ca9a0599dfa302 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Re: aliases, I see where the confusion is coming from! I updated the request section, but the session 2.2 data structure still mentions the aliases. That should be cleaned up as well. In any case the intent was always to only allow a singe resource per AT, the alias list was only for helping in cases where an AS identifies the same resource thru multiple IDs and the actual aud value depends on what ID the client requested. However we discussed this with Brian and he convinced me that it was just too ambiguous- your remark reinforces that impression. I=E2=80=99ll clean up 2.2 and eliminate references to aliases from there as= well. Thanks! On Mon, Dec 16, 2019 at 20:19 Vittorio Bertocci wrote: > Thanks Annabelle. > > Does a mobile app that uses Dynamic Client Registration to establish a >> client secret count as an =E2=80=9Cauthenticated client=E2=80=9D? > > I think it should count, tho I am not sure what the RS would do with it. > Dynamic client registration would likely not have much use for this. > In the cases I have seen, the idea is that a client (whose clientID is > already known to the RS) can obtain tokens thru different grants, some of > them confidential and others public; and the resource wants to know wheth= er > this particular token was obtained proving the identity of the client so > that it can decide whether to grant extra privileges for that > particular client in the current call. This scenario does not require the > extra details about authentication method/strength you mention that, I > agree, would be pretty hard to reach consensus on. > TL;DR: there is at least one scenario that is satisfied by the simple > bool, as the previous knowledge of the client solves the issues you menti= on > out of band. > > authentication session properties: > > Let me try another angle. Say that I perform an authz code grant asking > for AT, ID_T and RT- obtaining AT', ID_T' and RT'. > The values of auth_time, acr and amr in AT' will be the same as the > corresponding claims in ID_T'. When the client uses RT' to obtain AT`N, > AT'N+1 etc etc, the values of those claims will remain the same for every > AT'n obtained by RT'. > Now, imagine that something happens (ignore what for the time being) that > causes the client to perform a step up auth, which requires the user to > perform interactive auth hence results in a new authz grant. The client > will obtain a new tuple AT", ID_T" and RT". The exact same rules describ= ed > for the ' tuple apply, with the new values determined by the new > authentication: AT" auth_time/acr/amr will be the same as ID_T", and thos= e > values will remain unchanged for every AT"n derived by RT". > If we want this to apply to the implicit flow as well, you can substitute > the RT with the session artifact. > Does that help clarifying the intent? If yes, do you feel that the curren= t > language does not describe this? > > use case for putting these in the access token > > I am not trying to create a complete framework for handling step up and > the like, I am trying to create an interoperable representation of those > values no matter how they were obtained. > Consider the case in which an API allows certain operations only if a > given amr value is present in the token. Whether that amr is required > upfront on first authentication, as step up or any other reason is out of > scope for this profile IMO: the AS might have all sorts of heuristics tha= t > determine that (user membership to a given group or role; geofencing; ris= k > scoring; etc) that have nothing to do with scopes requested, and are not > statically determined by RS-AS communications. > Now, I agree that formalizing how a RS communicates to the AS via the > client the need to step up and in what terms would be super useful; howev= er > I think that's well beyond the scope of this profile. Various vendors > already have their own mechanisms for handling step up signaling from RS = to > AS (I am very familiar with the Microsoft one) and all I am looking for i= s > a way of standardizing how to represent the outcomes, so that API gateway= s > and SDK providers can provide tools that work across vendors; and possibl= y > reuse some of the reasoning that was already done for id_tokens. > TL;DR: I think we are doing something useful in formalizing how to embed > that info an ATs even if we don't force vendors to give up their current > mechanisms to populate those values. > > Regarding access tokens that are used to access different resource server= s > > The intent is to explicitly disallow the use of an AT with multiple > resource servers. If a client wants to talk with 2 different RSes, the > client should ask for 2 different ATs. > The spec is unambiguous on this IMO, here's the language I use in 03. > > If it receives a request for an access token containing more than one > resource parameter, an authorization server issuing JWT access tokens > MUST reject the request and fail with "invalid_request" as described > in section 4.1.2.1 of [RFC6749] or with "invalid_target" as defined > in section 2 of [ResourceIndicators ]. See Se= ction 2.2 and Section 5 > for more details on how this measure ensures there's no confusion on > to what resource the access token granted scopes apply. > > Is it possible you are referring to an older draft? > > > On Mon, Dec 16, 2019 at 5:28 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > >> 1. Regarding AuthenticatedClient: >> >> Does a mobile app that uses Dynamic Client Registration to establish a >> client secret count as an =E2=80=9Cauthenticated client=E2=80=9D? What i= f that registration >> included an assertion signed by a trusted entity (e.g., device managemen= t >> software) using a certificate that had been pushed to the device? Withou= t >> some kind of NIST LoA-style definition of =E2=80=9Cauthenticated=E2=80= =9D, a single Boolean >> =E2=80=9CAuthenticatedClient=E2=80=9D value is too ambiguous to be usefu= l. However, I=E2=80=99m >> skeptical that we could find consensus on what that definition should be= , >> and it may be better to define client analogs to `acr` and `amr` that >> provide standard ways of expressing client authentication details withou= t >> getting prescriptive about what kind of authentication is =E2=80=9Cgood = enough.=E2=80=9D >> >> >> >> 2. Regarding authentication session properties: >> >> I=E2=80=99m confused by the definitions given for `auth_time`, `acr`, an= d `amr`. >> For `auth_time`, it says: >> >> >> >> =E2=80=9C=E2=80=A6its value will either remain the same for all the JWT = access tokens >> issued within that session or be updated to the time of latest >> authentication if reauthentication occurred mid-session=E2=80=A6=E2=80= =9D >> >> >> >> But the =E2=80=9CFor example=E2=80=9D at the end of that definition impl= ies that >> `auth_time` will not be updated. The definitions for `acr` and `amr` say >> the same, but also say that the =E2=80=9C=E2=80=A6same considerations pr= esented for >> auth_time apply=E2=80=A6=E2=80=9D What=E2=80=99s the intention here: are= they fixed, updated, or is >> it up to the deployment to decide? >> >> >> >> I=E2=80=99d like to better understand the use case for putting these in = the >> access token. If the RS is making authorization decisions based on these >> claims, that implies that the RS cannot rely on the AS to determine (e.g= ., >> from the requested scope) the required authentication method(s), freshne= ss, >> etc. If the AS could be relied upon for this, then presumably it would n= ot >> issue RTs and ATs for a scope without requiring the end user to meet the >> appropriate authentication requirements. If this is the case, then the R= S >> must have a way to signal to the client (and then the AS) that a step-up >> authentication is required. Is there an existing mechanism through which >> they could do this? All I can come up with is cramming the information i= nto >> the scope attribute of a WWW-Authenticate challenge, but that has the sa= me >> scope opacity violation problem as described in this draft=E2=80=99s Sec= urity >> Considerations. Without a clear way to express the step-up requirements, >> this feels incomplete. >> >> >> >> 3. Regarding access tokens that are used to access different resource >> servers: >> Reading between the lines, I **think** the intention is that a JWT >> access token that is intended to be used to access two different resourc= es >> at two different RSes should look something like: >> >> >> >> { >> >> "aud": "https://generic-resource-indicator.example.com/", >> >> "scope": "resource_foo resource_bar", >> >> ... >> >> } >> >> >> And the expectation is that each RS should recognize that generic >> audience. Is this correct? If so it seems to go against the spirit of >> resource indicators as indicating the target or location of a resource. >> It=E2=80=99s stretching that definition, at the very least. >> >> >> >> But as I said, I=E2=80=99m reading between the lines here. If this is th= e >> intention, it should be clearly stated. Alternatively, remove (or change= to >> a SHOULD) the requirement that multi-value `aud` claims must only contai= n >> aliases for the same resource indicator. >> >> >> >> =E2=80=93 >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From: *OAuth on behalf of Vittorio Bertocci >> >> *Date: *Monday, December 16, 2019 at 2:51 PM >> *To: *IETF oauth WG >> *Cc: *"i-d-announce@ietf.org" >> *Subject: *Re: [OAUTH-WG] I-D Action: >> draft-ietf-oauth-access-token-jwt-03.txt >> >> >> >> Dear all, >> I finally found the time to push a new draft of the JWT profile for ATs. >> This version incorporates the feedback kindly provided by Brian and Aaro= n >> at IETF105. >> Unfortunately I didn't have a chance to participate to IETF106, hence we >> didn't do much progress since then. >> There are still two areas we didn't manage to reach consensus on: >> >> 1. Mechanisms for signaling whether the AT was obtained by a user or an >> application >> >> This point was the subject of intense debate on the list leading to >> IETF105. >> One insight that emerged from the IETF105 discussion was that the use >> case here is more about whether the AT has been obtained via a grant tha= t >> authenticated the client (regardless of what specific grant was used) vs= a >> public client grant- that information can be relevant to a resource as i= t >> determines whether the identity of the client can be used in authorizati= on >> decisions (in the former case) or not (in the public client case). If >> that's the scenario we are truly after, a simple, possibly optional bool= ean >> claim (say AuthenticatedClient) would suffice. >> Note for the people who didn't read the spec: I removed any reference to >> this already in draft-ietf-oauth-access-token-jwt-01. I think this is an >> important and useful info and standardizing it would be beneficial for >> middleware and SDK creators, but ultimately this is an interop profile >> hence if there's no strong desire to reach an agreement here, I am also = OK >> with dropping the matter and not address this function in the spec. >> To summarize, I have two questions here: >> >> A. Do we believe it's worth it to formalize in the profile a mechanism t= o >> indicate whether the client th obtained the AT authenticated itself with >> the AS? >> B. If yes, are you OK wiht an optional bool claim here? >> >> >> 2. Claims indicating session properties >> >> This is one area where I am far more passionate about, as it represents = a >> fundamental aspect that production systems (and in particular 1st party >> solutions) already rely on in the current proprietary JTW ATs. >> The profile currently includes the claims auth_time, acr and amr - >> capturing the values of those properties at the time of the latest >> authentication the user performed in the session used to issue the curre= nt >> AT: at session creation, at auth step up time and so on. >> Those are values that API need in order to make authorization decisions; >> in the case of 1st party APIs, the AT is the only artifact they ever >> receive hence there is no other way for an API to determine whether the >> caller performed say MFA in order to obtain the current AT. >> Since the first draft, some people signaled concerns about the current >> mechanisms thru which those claims get their value. For example, it has >> been proposed to maintain the original values of auth_time, acr & amr an= d >> introduce additional claims to indicate changes (like stepup). >> I am not clear on what cold go wrong with the current approach, hence I >> don't have an immediate grasp of how changes like the above would help. >> If the people uncomfortable with the current proposal could detail their >> concern, we can brainstorm ways to make that info available to API in a >> safer way. To summarize: >> >> A. Do you have concerns with the current auth_time, arm, acr proposal? >> Can you spell them out? (please read the relevant parts of the spec befo= re >> chiming in :)) >> B. If yes, what can we do to make that info available to RSs in a way >> that makes you comfortable? >> >> >> >> Thanks >> >> V. >> >> >> >> On Mon, Dec 16, 2019 at 2:49 PM wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol WG of the >> IETF. >> >> Title : JSON Web Token (JWT) Profile for OAuth 2.0 >> Access Tokens >> Author : Vittorio Bertocci >> Filename : draft-ietf-oauth-access-token-jwt-03.txt >> Pages : 16 >> Date : 2019-12-16 >> >> Abstract: >> This specification defines a profile for issuing OAuth 2.0 access >> tokens in JSON web token (JWT) format. Authorization servers and >> resource servers from different vendors can leverage this profile to >> issue and consume access tokens in interoperable manner. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-= 03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-03 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --00000000000069ca9a0599dfa302 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Re: aliases, I see where the confusion is coming fro= m!
I updated the request section, but the sess= ion 2.2 data structure still mentions the aliases. That should be cleaned u= p as well.=C2=A0
In any case the intent was always t= o only allow a singe resource per AT, the alias list was only for helping i= n cases where an AS identifies the same resource thru multiple IDs and the = actual aud value depends on what ID the client requested. However we discus= sed this with Brian and he convinced me that it was just too ambiguous- you= r remark reinforces that impression. I=E2=80=99ll clean up 2.2 and eliminat= e references to aliases from there as well.
Thanks!<= /div>


On Mon, Dec 16, 2019 at 20:19 Vittorio Bert= occi <Vittorio@auth0.com> w= rote:
Thanks Annab= elle.

Does a mobi= le app that uses Dynamic Client Registration to establish a client secret c= ount as an =E2=80=9Cauthenticated client=E2=80=9D?=C2=A0=C2=A0
=
I think it should count, tho I am not sure what the RS would do with i= t. Dynamic client registration would likely not have much use for this.
In the cases I have seen, the idea is that a client (whose clientID = is already known to the RS) can obtain tokens thru different grants, some o= f them confidential and others public; and the resource wants to know wheth= er this particular token was obtained proving the identity of the client so= that it can decide whether to grant extra privileges for that particular= =C2=A0client in the current call. This scenario does not require the extra = details about authentication method/strength you mention that, I agree, wou= ld be pretty hard to reach consensus on.
TL;DR: there is at least= one scenario that is satisfied by the simple bool, as the previous knowled= ge of the client solves the issues you mention out of band.=C2=A0

authentication= session properties:=C2=A0
=C2=A0Let me try another angle.= Say that I perform an authz code grant asking for AT, ID_T and RT- obtaini= ng AT', ID_T' and RT'.=C2=A0
The values of auth_time,= acr and amr in AT' will be the same as the corresponding claims in ID_= T'. When the client uses RT' to obtain AT`N, AT'N+1 etc etc, th= e values of those claims will remain the same for every AT'n obtained b= y RT'.
Now, imagine that something happens (ignore what for t= he time being) that causes the client to perform a step up auth, which requ= ires the user to perform interactive auth hence results in a new authz gran= t. The client will obtain a new tuple=C2=A0 AT", ID_T" and RT". The exact same rules described for the &= #39; tuple apply, with the new values determined by the new authentication:= AT" auth_time/acr/amr will be the same as ID_T", and those value= s will remain unchanged for every AT"n derived by RT".
If we w= ant this to apply to the implicit flow as well, you can substitute the RT w= ith the session artifact.=C2=A0
Does that help clarifying the int= ent? If yes, do you feel that the current language does not describe this?<= /div>

use c= ase for putting these in the access token=C2=A0
I am not t= rying to create a complete framework for handling step up and the like, I a= m trying to create an interoperable representation of those values no matte= r how they were obtained.=C2=A0
Consider the case in which an API= allows certain operations only if a given amr value is present in the toke= n. Whether that amr is required upfront on first authentication, as step up= or any other reason is out of scope for this profile IMO: the AS might hav= e all sorts of heuristics that determine that (user membership to a given g= roup or role; geofencing; risk scoring; etc) that have nothing to do with s= copes requested, and are not statically determined by RS-AS communications.= =C2=A0
Now, I agree that formalizing how a RS communicates to the= AS via the client the need to step up and in what terms would be super=C2= =A0useful; however I think that's well beyond the scope of this profile= . Various vendors already have their own mechanisms for handling step up si= gnaling from RS to AS (I am very familiar with the Microsoft=C2=A0one) and = all I am looking for is a way of standardizing how to represent the outcome= s, so that API gateways and SDK providers can provide tools that work acros= s vendors; and possibly reuse some of the reasoning that was already done f= or id_tokens.
TL;DR: I think we are doing something useful in for= malizing how to embed that info an ATs even if we don't force vendors t= o give up their current mechanisms to populate those values.

=
Regarding access to= kens that are used to access different resource servers
Th= e intent is to explicitly disallow the use of an AT with multiple resource = servers. If a client wants to talk with 2 different RSes, the client should= ask for 2 different ATs.
The spec is unambiguous on this IMO, he= re's the language I use in 03. 

If it receives a request for an access token containing more=
 than one
   resource parameter, an authorization server issuing JWT access tokens
   MUST reject the request and fail with "invalid_request" as des=
cribed
   in section=C2=A04.1.2.1 of [RFC6749] or with=
 "invalid_target" as defined
   in section 2 of [ResourceIndicators].  See Section 2.2 and Section 5
   for more details on how this measure ensures there's no confusion on
   to what resource the access token granted scopes apply.
= =C2=A0 Is it possible you are referring to an older draft?=C2=A0=C2=A0
<= /div>
=C2=A0

On Mon, Dec 16, 2019 at 5:28 PM Richard Backm= an, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

1. Regarding AuthenticatedClient:

Does a mobile app that uses Dynamic Client Registrat= ion to establish a client secret count as an =E2=80=9Cauthenticated client= =E2=80=9D? What if that registration included an assertion signed by a trus= ted entity (e.g., device management software) using a certificate that had been pushed to the device? Without some kind of NIS= T LoA-style definition of =E2=80=9Cauthenticated=E2=80=9D, a single Boolean= =E2=80=9CAuthenticatedClient=E2=80=9D value is too ambiguous to be useful.= However, I=E2=80=99m skeptical that we could find consensus on what that definition should be, and it may be better to define client analogs to `ac= r` and `amr` that provide standard ways of expressing client authentication= details without getting prescriptive about what kind of authentication is = =E2=80=9Cgood enough.=E2=80=9D

=C2=A0

2. Regarding authentication session properties:

I=E2=80=99m confused by the definitions given for `a= uth_time`, `acr`, and `amr`. For `auth_time`, it says:

=C2=A0

=E2=80=9C=E2=80=A6its va= lue will either remain the same for all the JWT access tokens issued within= that session or be updated to the time of latest authentication if reauthe= ntication occurred mid-session=E2=80=A6=E2=80=9D

=C2=A0

But the =E2=80=9CFor example=E2=80=9D at the end of = that definition implies that `auth_time` will not be updated. The definitio= ns for `acr` and `amr` say the same, but also say that the =E2=80=9C=E2=80= =A6same considerations presented for auth_time apply=E2=80=A6=E2=80=9D What= =E2=80=99s the intention here: are they fixed, updated, or is it up to the deployment to decide?=

=C2=A0

I=E2=80=99d like to better understand the use case f= or putting these in the access token. If the RS is making authorization dec= isions based on these claims, that implies that the RS cannot rely on the A= S to determine (e.g., from the requested scope) the required authentication method(s), freshness, etc. If the AS could be = relied upon for this, then presumably it would not issue RTs and ATs for a = scope without requiring the end user to meet the appropriate authentication= requirements. If this is the case, then the RS must have a way to signal to the client (and then the AS) that= a step-up authentication is required. Is there an existing mechanism throu= gh which they could do this? All I can come up with is cramming the informa= tion into the scope attribute of a WWW-Authenticate challenge, but that has the same scope opacity violatio= n problem as described in this draft=E2=80=99s Security Considerations. Wit= hout a clear way to express the step-up requirements, this feels incomplete= .

=C2=A0

3. Regarding access tokens that are used to access d= ifferent resource servers:
Reading between the lines, I *think* the intention is that a JWT acc= ess token that is intended to be used to access two different resources at = two different RSes should look something like:

=C2=A0

{<= /span>

"aud": "https://generic-resource-indicator.e= xample.com/",

"scope": "resource_foo resource_bar",

...

}<= /span>


And the expectation is that each RS should recognize that generic audience.= Is this correct? If so it seems to go against the spirit of resource indic= ators as indicating the target or location of a resource. It=E2=80=99s stre= tching that definition, at the very least.

=C2=A0

But as I said, I=E2=80=99m reading between the lines= here. If this is the intention, it should be clearly stated. Alternatively= , remove (or change to a SHOULD) the requirement that multi-value `aud` cla= ims must only contain aliases for the same resource indicator.

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Bac= kman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org><= br> Date: Monday, December 16, 2019 at 2:51 PM
To: IETF oauth WG <oauth@ietf.org>
Cc: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jw= t-03.txt

=C2=A0

Dear all,
I finally found the time to push a new draft of the JWT profile for ATs. Th= is version incorporates the feedback kindly provided by Brian and Aaron at = IETF105.
Unfortunately I didn't have a chance to participate to IETF106, hence w= e didn't do much progress since then.
There are still two areas we didn't manage to reach consensus on:

1. Mechanisms for signaling whether the AT was obtained by a user or an app= lication

This point was the subject of intense debate on the list leading to IETF105= .
One insight that emerged from the IETF105 discussion was that the use case = here is more about whether the AT has been obtained via a grant that authen= ticated the client (regardless of what specific grant was used) vs a public= client grant- that information can be relevant to a resource as it determines whether the identity of the= client can be used in authorization decisions (in the former case) or not = (in the public client case). If that's the scenario we are truly after,= a simple, possibly optional boolean claim (say AuthenticatedClient) would suffice.
Note for the people who didn't read the spec: I removed any reference t= o this already in draft-ietf-oauth-access-token-jwt-01. I think this is an = important and useful info and standardizing it would be beneficial for midd= leware and SDK creators, but ultimately this is an interop profile hence if there's no strong desire to reach = an agreement here, I am also OK with dropping the matter and not address th= is function in the spec.
To summarize, I have two questions here:

A. Do we believe it's worth it to formalize in t= he profile a mechanism to indicate whether the client th obtained the AT au= thenticated itself with the AS?
B. If yes, are you OK wiht an optional bool claim here?


2. Claims indicating session properties

This is one area where I am far more passionate about, as it represents a f= undamental aspect that production systems (and in particular 1st party solu= tions) already rely on in the current proprietary JTW ATs.
The profile currently includes the claims auth_time, acr and amr - capturin= g the values of those properties at the time of the latest authentication t= he user performed in the session used to issue the current AT: at session c= reation, at auth step up time and so on.
Those are values that API need in order to make authorization decisions; in= the case of 1st party APIs, the AT is the only artifact they ever receive = hence there is no other way for an API to determine whether the caller perf= ormed say MFA in order to obtain the current AT.
Since the first draft, some people signaled concerns about the current mech= anisms thru which those claims get their value. For example, it has been pr= oposed to maintain the original values of auth_time, acr & amr and intr= oduce additional claims to indicate changes (like stepup).
I am not clear on what cold go wrong with the current approach, hence I don= 't have an immediate grasp of how changes like the above would help. If the people uncomfortable with the current proposal could detail their co= ncern, we can brainstorm ways to make that info available to API in a safer= way. To summarize:

A. Do you have concerns with the current auth_time, = arm, acr proposal? Can you spell them out? (please read the relevant parts = of the spec before chiming in :))
B. If yes, what can we do to make that info available to RSs in a way that = makes you comfortable?



Thanks

V.

=C2=A0

On Mon, Dec 16, 2019 at 2:49 PM <internet-drafts@ietf.org&= gt; wrote:


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Vitt= orio Bertocci
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-access-token-jwt-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-12-16

Abstract:
=C2=A0 =C2=A0This specification defines a profile for issuing OAuth 2.0 acc= ess
=C2=A0 =C2=A0tokens in JSON web token (JWT) format.=C2=A0 Authorization ser= vers and
=C2=A0 =C2=A0resource servers from different vendors can leverage this prof= ile to
=C2=A0 =C2=A0issue and consume access tokens in interoperable manner.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-ac= cess-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-tok= en-jwt-03
https://datatracker.ietf.org/doc/html/draft-i= etf-oauth-access-token-jwt-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-= oauth-access-token-jwt-03


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

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

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000069ca9a0599dfa302-- From nobody Mon Dec 16 23:28:22 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F04112096F for ; Mon, 16 Dec 2019 23:28:21 -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 pjRDQQfiiDQP for ; Mon, 16 Dec 2019 23:28:19 -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 1B0291200CC for ; Mon, 16 Dec 2019 23:28:18 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id b6so10137252wrq.0 for ; Mon, 16 Dec 2019 23:28:18 -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=R4GrO1L2siBQUvKXqasYiznW1bRO+OaBL3+/kN/FVIA=; b=qODZPp5JYdFe8QQ4VZSYfoj8LaapofmjkymPefVvr3n1CQSfhShaSEriKBJzeDpp8a y+ap/8+pFzT1Gc92wlKQNVtc/lD8BLOS4I2cZQAFKw5NOEqYFMR45jrFzAkzACTs0Tor Iid8yukcN2fzG6qrA4xi7Rsv7BVNco7ZVHDIUMPa5tZXSaEkVG3Y2xxJCobiOY8D2AfR 5m6sZwcAgpglGP2g/mSqdFAGo7eY3cIf9GxBCl3ITq+SItkFb58/lo4P8tm45vYeU5vJ O3ZfUSIveuziPl9/hEoBX8UAOJ00olESaU2RAIuxcmQxjSJZOAMmf3w7vNaUN4mwan+H uDWw== 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=R4GrO1L2siBQUvKXqasYiznW1bRO+OaBL3+/kN/FVIA=; b=d46mjJ8+PjTd9sGXOYGgmoMJSMzJlLrqba+ldqEwRu/gb+MlaWNm26FZTpKx+NebDg ZLE1uTXrV77s9oPZqHSDC0HwZzfdGt1/80eccS8fTSeG0x7V3/aB2gA9D2zyjbaPbT7/ JaCM5hyzxD4Bzy06sXeJa9LdB6LaRXqb6DtecIzNhkUwIY3BhsK7LRCkXI5wj1tEKY9Z 32KQDXXI7WEQ1XFtdnGoKR3MRRWe7AicYJi7MT4NEa9+E7Vsq8tfZ15vgLqhys095uMT C8V6kTnc1nGU+fVwtajxmFsJYtcz6Zj/+cnVqCti1LOHhxwHJg4mNaG0Ciet7E9GsZzX BRYQ== X-Gm-Message-State: APjAAAVqwBcDR7nUWajWl1xOg+vCePVsXMKo8EaeodHtIKF6Cxau9SxW vdKwuCPHKaGw8aEmqK6IejZm0sxv/7PImw== X-Google-Smtp-Source: APXvYqzLowVqfVGxho8ypK0Fy6sw2MBr2fbL2FLflC1rdxxBjSV8j18s4kb8oq/1VtkQawwoSan+9g== X-Received: by 2002:adf:f606:: with SMTP id t6mr33938062wrp.85.1576567697392; Mon, 16 Dec 2019 23:28:17 -0800 (PST) Received: from [172.18.236.111] ([46.183.103.8]) by smtp.gmail.com with ESMTPSA id f17sm1975657wmc.8.2019.12.16.23.28.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Dec 2019 23:28:16 -0800 (PST) From: Torsten Lodderstedt Message-Id: <1A9A1162-E392-47C3-BC41-7DCDC1913A84@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_6D38E4BA-01B1-49B0-A99B-AD138D046782"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Tue, 17 Dec 2019 08:27:40 +0100 In-Reply-To: Cc: "Richard Backman, Annabelle" , IETF oauth WG To: Vittorio Bertocci References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 07:28:21 -0000 --Apple-Mail=_6D38E4BA-01B1-49B0-A99B-AD138D046782 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Vittorio, > On 17. Dec 2019, at 05:19, Vittorio Bertocci = wrote: >=20 > In the cases I have seen, the idea is that a client (whose clientID is = already known to the RS) can obtain tokens thru different grants, some = of them confidential and others public; just to make sure I understood correctly. Are you saying the client has = credentials but is not authenticated using those in all potential = scenarios? Can you pls. explain the rationale? best, Torsten.=20 --Apple-Mail=_6D38E4BA-01B1-49B0-A99B-AD138D046782 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 Fw0xOTEyMTcwNzI3NDBaMC8GCSqGSIb3DQEJBDEiBCBbJvF6NC/oFFFt/5OA6ypvfWEIIdaicqNg R2aCv5jZ8DCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAIeP3Pfo1Ni3gRdOKXIXrDgQw5RsdUY2QpKSASdDJyEKQzXQ6sAOG4ARPjHU KsP6eSkdsJLrVx8vbBssr05ZzXSx4r+YiRs5X/2FVvWCKp/KFEu2fAJrCSknijZ/KGrKD3pOTnkf dOth57Q4RG4HWOgXVVUdCA3nV7X5aA4GQZw2c4x6BbzaQkkL6Pkk35Te84jQoCIFzfVw2bK/ycHW 6Qtqijem2J5LGvLdTIOraqWBvOcfPFQWVwQRRfuTmNqIsQITMfgaIqElX7OOlun+Ay6lIXr5oZW1 2+va9Lqsbeydwpx4IrEin+Z1WZs+1OmNh3kMFOpwvDNV5gEueJQf1qAAAAAAAAA= --Apple-Mail=_6D38E4BA-01B1-49B0-A99B-AD138D046782-- From nobody Mon Dec 16 23:43:13 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5D3120972 for ; Mon, 16 Dec 2019 23:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y34_tDuVFfma for ; Mon, 16 Dec 2019 23:43:08 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A6E1200CC for ; Mon, 16 Dec 2019 23:43:08 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id t129so1292190qke.10 for ; Mon, 16 Dec 2019 23:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=aDqFpFlN9zdj6ElALcvD3i0natrAWo0rGRNMX+W9BkM=; b=QBcJy332XVg4XhrrqpE45tsw22676Q3ufn64/H6PHvD2VlaYqMkJHoj6t84pSAb1Yz QTOq1HBLEY8e/MFd7Mpo6iIjk4+js//sSSmC77Ee0tq3MECErBQOvGtoDm5MO8dY96n0 jwqY/QK7Pf644qwLZgp/8B36jr8r3H3dt7yHZQnkEJZ4hVyB6WY4DkJtrONT+EhKeQJA kEGgXarzv6QNVyLG63BT1fGSIhCb6Gyh/1ycaxMqAIzIQAZYLIsXTikEozW+X/XQp8E4 6JgLnB7HtmYqDoMFB0Z6EqRsgZFDmIO1pc+BU7VvY7FB9GQCVVu6bNxsabbp1q+JD7UG dx4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=aDqFpFlN9zdj6ElALcvD3i0natrAWo0rGRNMX+W9BkM=; b=nG3lxMbImUwY1ypwf/Vof9CJFjF2mBVflEMyBs4rh2tbMX8QmUEx7iU6r9GZvIHh7c 2MUv0k7RG8h9ASDLwcq5O97Y4oWuJKNSP9py5JpHiRKfASAdi9kJ4Q+iw6Yuc76jbvDa tUqTmK/OhZtKCbxASFil8KN0BYgZtVq8iTHXSVWV9aHQectAWzZXx9+NiQGHIEyWij69 daRc209mtsSkQ0T6q05Rr0te8uhA8Bifbi1NbSYziyemWdZ2LLHsEiRHiCtc85QdWQEa TTPUqdWGYCrQbc487BGrs8oednadYYoBWffY3H7Bznwii5y+m9yAy2sJiiKvyOANtKVo PP5g== X-Gm-Message-State: APjAAAVpHYWciouamaPrzU6zy+mRm8oc1coyLx2ydtRUYZcXbPX74qFT SYTGMWyVkIVVHanOVu0SYY2o/aevsyACOGYQvQTGljMgiA== X-Google-Smtp-Source: APXvYqxykTQDl/m/VcGjYAco432Tc4XduKh4IaQ/IrfkxaBDPhfY2xc5MG1CUWB212whH13n4Ixrx6TGzGpwfNaDdB8= X-Received: by 2002:a05:620a:48e:: with SMTP id 14mr3581592qkr.292.1576568587146; Mon, 16 Dec 2019 23:43:07 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 17 Dec 2019 02:43:06 -0500 From: Dominick Baier In-Reply-To: References: <4FD03604-C0A3-4A0A-9598-8ECD8137581F@mit.edu> MIME-Version: 1.0 Date: Tue, 17 Dec 2019 02:43:06 -0500 Message-ID: To: Rob Otto , "Richard Backman, Annabelle" Cc: Brian Campbell , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000099eebb0599e17a84" Archived-At: Subject: Re: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 07:43:12 -0000 --00000000000099eebb0599e17a84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99d support adoption of both PAR and RAR. =E2=80=94=E2=80=94=E2=80=94 Dominick Baier On 16. December 2019 at 23:02:58, Rob Otto ( robotto=3D40pingidentity.com@dmarc.ietf.org) wrote: I=E2=80=99d support adoption of both PAR and RAR. On Mon, 16 Dec 2019 at 21:57, Richard Backman, Annabelle wrote: > +1 for a call for adoption on PAR. > > > > I=E2=80=99d also like to see one for RAR; while there are questions that = need to > be resolved, there seems to be strong interest in this work and adoption > means we can have those discussions within the WG where they belong. > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Justin Richer < > jricher@mit.edu> > *Date:* Monday, December 16, 2019 at 12:36 PM > *To:* Brian Campbell > *Cc:* "oauth@ietf.org" > *Subject:* Re: [OAUTH-WG] Meeting Minutes > > > > +1 to this. My take away was that PAR was pretty clear for adoption right > now, RAR had interest but more question/debate. > > > > FWIW I=E2=80=99m in favor of both of them. > > > > =E2=80=94 Justin > > > > On Dec 16, 2019, at 11:26 AM, Brian Campbell < > bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote: > > > > With respect to the Pushed Authorization Requests (PAR) draft the minutes > do capture an individual comment that it's a "no brainer to adopt this > work" but as I recall there was also a hum to gauge the room's interest i= n > adoption, which was largely in favor of such. Of course, one hum in > Singapore isn't the final word but, following from that, I was > hoping/expecting to see a call for adoption go out to the mailing list? > > > > On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Here are the meeting minutes from the Singapore IETF meeting: > > https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03 > > > > Tony was our scribe. Thanks! > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Rob Otto EMEA Field CTO - Ping Identity +44 777 135 6092 * CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --00000000000099eebb0599e17a84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I=E2=80=99d support adoption of both PAR and RAR.

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

On 16. December 2019 at 23:02:58, R= ob Otto (rob= otto=3D40pingidentity.com@dmarc.ietf.org) wrote:

I=E2=80=99d support adoption of both PAR and RAR.=C2=A0

On Mon, 16 Dec 2019 at 21:57, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

+1 for a call for adoption on PAR.

=C2=A0

I=E2=80=99d also like to see one for RAR; while ther= e are questions that need to be resolved, there seems to be strong interest in this work and adoption means we can have those discussions within the WG where they belong.

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

=C2=A0

+1 to this. My take away was that PAR was pretty clear for adoption right now, RAR had interest but more question/debate.=C2=A0

=C2=A0

FWIW I=E2=80=99m in favor of both of them.

=C2=A0

=C2=A0=E2=80=94 Justin



On Dec 16, 2019, at 11:26 AM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:

=C2=A0

With respect to the Pushed Authorization Requests (PAR) draft the minutes do capture an individual comment that it's a "no brainer to adopt this work" but as I recall t= here was also a hum to gauge the room's interest in adoption, which was largely in favor of such. Of course, one hum in Singapore isn't the final word but, following from that, I was hoping/expecting to see a call for adoption go out to the mailing list?

=C2=A0

On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Here are the meeting minutes from the Singapore IETF meeting:

https://datatracker.ietf.= org/meeting/106/materials/minutes-106-oauth-03

=C2=A0

Tony was our scribe. Thanks!

=C2=A0

=C2=A0

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

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


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=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 attachments from your computer. Thank you._______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Rob Otto
EMEA Field CTO - Ping Identity
+44 777 135 6092

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=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 attachments from your computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
--00000000000099eebb0599e17a84-- From nobody Mon Dec 16 23:53:36 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06303120970 for ; Mon, 16 Dec 2019 23:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.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 xQOUQSuWZ8Tq for ; Mon, 16 Dec 2019 23:53:33 -0800 (PST) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF0912097D for ; Mon, 16 Dec 2019 23:53:32 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id h20so12665253otn.5 for ; Mon, 16 Dec 2019 23:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kBNvrtFEQnk02V6Xc4ocRcN8Yn4MUUfyNhwUrcgGc2w=; b=HpkckcKzhrS9rmvXsciejtdOuHHvqGF2eFIeTH87OJIxoNlCxYsDmlNC+yIZ+tdaVQ RktmQO8rYbaTejHQh1rfMvZHN3xvNiPxZ40LIE3pbeWKCPi8NdB6cRr46zQJtHN3uXcI +aZQ+wkI8jxNzCpyMwZC3SDDX3rCig1m369ftW6LbHqQNtgSQs2PJl6no6yDzegOC6bg w4rDdILFDib1qM7sErgwlVxsAye84SueCzfxHMMzeUmRjqqSMBAvDVv5iiq8gyEzZxbP z/Mo4bHHxgopQMmG88MXIIKY9SV68e1k1hEnGAflYXsE86q3Ixso2TNAoBysYhUN3JM2 KHKw== 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=kBNvrtFEQnk02V6Xc4ocRcN8Yn4MUUfyNhwUrcgGc2w=; b=JJBNNyra7XgU6zB/Tmq4q7kwvswq1Z4mZAMC3z/+qSLAcsBD35Nc5ZV1SkRTX7cMCS KLjIeByRaudUwxSAmz5M52UuLgq4j3e1m54cAKHII39krDPDqd8g5ylSyYxZlNlbHDv6 7OV/YMlys4RYk2sdZS2vUl5+VYdXZmn5bBM3+1cKOoOGCMWB7bpHrPyiaVzhqhdC+9NC QUEZYHry9U2qxejAFmVe9CA3METYwxgbJnJriOXuO0cABfNobPWhXfPGznka+n8heoqq euaHuP/DsSMlQsE6X2ncTUbkYcBg0gbyLwMtDymQsBsE4AzYatyzOsj/NL0XYyEHGEAV 8YpA== X-Gm-Message-State: APjAAAUCp/ByJURNOpI+wpBCj/bKKQAmCVN0MZ9NPuEpebdT50KldKeu qIzHaFK3P2v9iGCOaM5n6NvfVA5Snj6RB4/a4phuBQ== X-Google-Smtp-Source: APXvYqxLz4fOcywagf13cSrzbHeH9NhAwl5AY+QZwiufu8AcsRSd+wUjq4A8iJdb98WiVo58VXrwYIGMYLaOjQ2vK5c= X-Received: by 2002:a9d:7394:: with SMTP id j20mr36908150otk.273.1576569211379; Mon, 16 Dec 2019 23:53:31 -0800 (PST) MIME-Version: 1.0 References: <4FD03604-C0A3-4A0A-9598-8ECD8137581F@mit.edu> In-Reply-To: From: Steinar Noem Date: Tue, 17 Dec 2019 08:53:20 +0100 Message-ID: To: Dominick Baier Cc: Rob Otto , "Richard Backman, Annabelle" , Brian Campbell , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cef4e00599e19f6f" Archived-At: Subject: Re: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 07:53:35 -0000 --000000000000cef4e00599e19f6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd also like to see adoption for both PAR and RAR. We will actually start to use the "authorization_details" parameter early next year. tir. 17. des. 2019 kl. 08:43 skrev Dominick Baier : > I=E2=80=99d support adoption of both PAR and RAR. > > =E2=80=94=E2=80=94=E2=80=94 > Dominick Baier > > On 16. December 2019 at 23:02:58, Rob Otto ( > robotto=3D40pingidentity.com@dmarc.ietf.org) wrote: > > I=E2=80=99d support adoption of both PAR and RAR. > > On Mon, 16 Dec 2019 at 21:57, Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > >> +1 for a call for adoption on PAR. >> >> >> >> I=E2=80=99d also like to see one for RAR; while there are questions that= need to >> be resolved, there seems to be strong interest in this work and adoption >> means we can have those discussions within the WG where they belong. >> >> >> >> =E2=80=93 >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* OAuth on behalf of Justin Richer < >> jricher@mit.edu> >> *Date:* Monday, December 16, 2019 at 12:36 PM >> *To:* Brian Campbell >> *Cc:* "oauth@ietf.org" >> *Subject:* Re: [OAUTH-WG] Meeting Minutes >> >> >> >> +1 to this. My take away was that PAR was pretty clear for adoption righ= t >> now, RAR had interest but more question/debate. >> >> >> >> FWIW I=E2=80=99m in favor of both of them. >> >> >> >> =E2=80=94 Justin >> >> >> >> On Dec 16, 2019, at 11:26 AM, Brian Campbell < >> bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote: >> >> >> >> With respect to the Pushed Authorization Requests (PAR) draft the minute= s >> do capture an individual comment that it's a "no brainer to adopt this >> work" but as I recall there was also a hum to gauge the room's interest = in >> adoption, which was largely in favor of such. Of course, one hum in >> Singapore isn't the final word but, following from that, I was >> hoping/expecting to see a call for adoption go out to the mailing list? >> >> >> >> On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig < >> Hannes.Tschofenig@arm.com> wrote: >> >> Here are the meeting minutes from the Singapore IETF meeting: >> >> https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03 >> >> >> >> Tony was our scribe. Thanks! >> >> >> >> >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy t= he >> information in any medium. Thank you. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> * CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.*______________________________________________= _ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- > Rob Otto > EMEA Field CTO - Ping Identity > +44 777 135 6092 > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | --000000000000cef4e00599e19f6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd also like to see adoption for both PAR and RAR. We= will actually start to use the "authorization_details" parameter= early next year.

tir. 17. des. 2019 kl. 08:43 skrev Dominick Baier <dbaier@leastprivilege.com>:=
I=E2=80=99= d support adoption of both PAR and RAR.

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

On 16. December 2019 at 23:02:= 58, Rob Otto (robotto=3D40pingidentity.com@dmarc.ietf.org) wrote:=

I=E2=80=99d support adoption of both PAR and RAR.=C2=A0

On Mon, 16 Dec 2019 at 21:57, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

+1 for a call for adoption on PAR.

=C2=A0

I=E2=80=99d also like to see one for RAR; while ther= e are questions that need to be resolved, there seems to be strong interest in this work and adoption means we can have those discussions within the WG where they belong.

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

=C2=A0

+1 to this. My take away was that PAR was pretty clear for adoption right now, RAR had interest but more question/debate.=C2=A0

=C2=A0

FWIW I=E2=80=99m in favor of both of them.

=C2=A0

=C2=A0=E2=80=94 Justin



On Dec 16, 2019, at 11:26 AM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:

=C2=A0

With respect to the Pushed Authorization Requests (PAR) draft the minutes do capture an individual comment that it's a "no brainer to adopt this work" but as I recall t= here was also a hum to gauge the room's interest in adoption, which was largely in favor of such. Of course, one hum in Singapore isn't the final word but, following from that, I was hoping/expecting to see a call for adoption go out to the mailing list?

=C2=A0

On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Here are the meeting minutes from the Singapore IETF meeting:

https://datatracker.ietf.= org/meeting/106/materials/minutes-106-oauth-03

=C2=A0

Tony was our scribe. Thanks!

=C2=A0

=C2=A0

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

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


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=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 attachments from your computer. Thank you._______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Rob Otto
EMEA Field CTO - Ping Identity
+44 777 135 6092

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=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 attachments from your computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Vennlig hilsen=

Steinar Noem
Partner Udelt AS
Systemutvikler<= /div>
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@udelt.n= o=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.= no=C2=A0|=C2=A0
--000000000000cef4e00599e19f6f-- From nobody Tue Dec 17 00:28:27 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35241200DE for ; Tue, 17 Dec 2019 00:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C64rRljgl9Y for ; Tue, 17 Dec 2019 00:28:23 -0800 (PST) Received: from alkaline-solutions.com (unknown [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7535C120025 for ; Tue, 17 Dec 2019 00:28:23 -0800 (PST) Received: from [IPv6:2601:282:202:b210:b092:f754:6264:326] (unknown [IPv6:2601:282:202:b210:b092:f754:6264:326]) by alkaline-solutions.com (Postfix) with ESMTPSA id E543C3155C; Tue, 17 Dec 2019 08:29:25 +0000 (UTC) From: David Waite Message-Id: <528F7BBC-54DC-4EEF-8AE9-4074C0CB071F@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0ACEA500-C77F-451B-999E-0C83FD2DFEE9" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Tue, 17 Dec 2019 01:28:21 -0700 In-Reply-To: Cc: Hannes Tschofenig , Brian Campbell To: "oauth@ietf.org" References: X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 08:28:26 -0000 --Apple-Mail=_0ACEA500-C77F-451B-999E-0C83FD2DFEE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 to adopting PAR. For RAR I have a number of questions myself with the approach and with = some of the ramifications. I=E2=80=99m most concerned with the coupling = of business-specific presentation, process validation and workflow = within the AS, but also with the mixing of single transactional approval = into accesses token that is normally meant for longer-lived, coarser = client authorizations. To stick with the primary payment example - there are payment cases = which model well for single resource authorization, such as a = PayPal-style transaction where the client is also the recipient of = funds. For other types of transactions, I would worry this may become = primarily an AS-executed action rather than a client authorization. Before the device flow and before CIBA, I=E2=80=99d probably try and = make a case for not adopting it. The decoupling of the client from any = user-agent that could ask for user authorization outside of OAuth has = made an increase in scope (of scopes) a higher need - the current = communication pipe between the client and user-agent is only defined in = the scope of the actual OAuth grant processes. -DW > On Dec 16, 2019, at 9:26 AM, Brian Campbell = wrote: >=20 > With respect to the Pushed Authorization Requests (PAR) draft the = minutes do capture an individual comment that it's a "no brainer to = adopt this work" but as I recall there was also a hum to gauge the = room's interest in adoption, which was largely in favor of such. Of = course, one hum in Singapore isn't the final word but, following from = that, I was hoping/expecting to see a call for adoption go out to the = mailing list?=20 >=20 > On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig = > wrote: > Here are the meeting minutes from the Singapore IETF meeting: >=20 > = https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03 = > =20 >=20 > Tony was our scribe. Thanks! >=20 > =20 >=20 > =20 >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_0ACEA500-C77F-451B-999E-0C83FD2DFEE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 = to adopting PAR.

For = RAR I have a number of questions myself with the approach and with some = of the ramifications. I=E2=80=99m most concerned with the coupling of = business-specific presentation, process validation and workflow within = the AS, but also with the mixing of single transactional approval into = accesses token that is normally meant for longer-lived, coarser client = authorizations.

To stick with the primary payment example - there are payment = cases which model well for single resource authorization, such as a = PayPal-style transaction where the client is also the recipient of = funds. For other types of transactions, I would worry this may become = primarily an AS-executed action rather than a client = authorization.

Before the device flow and before CIBA, I=E2=80=99d probably = try and make a case for not adopting it. The decoupling of the client = from any user-agent that could ask for user authorization outside of = OAuth has made an increase in scope (of scopes) a higher need - the = current communication pipe between the client and user-agent is only = defined in the scope of the actual OAuth grant processes.

-DW


On Dec 16, 2019, at 9:26 AM, Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

With respect to the Pushed Authorization Requests = (PAR) draft the minutes do capture an individual comment that it's a "no = brainer to adopt this work" but as I recall there was also a hum to = gauge the room's interest in adoption, which was largely in favor of = such. Of course, one hum in Singapore isn't the final word but, = following from that, I was hoping/expecting to see a call for adoption = go out to the mailing list?

On Tue, Dec = 3, 2019 at 1:26 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Here are the meeting minutes from = the Singapore IETF meeting:

https://datatracker.ietf.org/meeting/106/materials/minutes-106-= oauth-03

 

Tony was our scribe. Thanks!

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited..  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_0ACEA500-C77F-451B-999E-0C83FD2DFEE9-- From nobody Tue Dec 17 04:59:39 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E2120236 for ; Tue, 17 Dec 2019 04:59: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 fgxGR6FLt6MQ for ; Tue, 17 Dec 2019 04:59:36 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A2951200E5 for ; Tue, 17 Dec 2019 04:59:36 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id f10so8298460ils.8 for ; Tue, 17 Dec 2019 04:59:36 -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=lV2PvjnsLCNKYA99fN1fnC0kKtD0zTzeA7OFHJT30bs=; b=GlOveoGNbOG9YP1QAVkThbMx2LBGEnZQkrQoq/uiRNSTpgTNojiKqWyiH8OJG7j/wB Otgm6EfkNEGp/dkS002WNTTIRhMG18hi2bNybToJ19TrLClZ/LD0lWO8gV1XtVw3j0JG 9vJ+0PFNy5279XhtpRqTpcUz7zhQghurpRJYuGTFcZ/oGWhUXgV4xJzxUNG3tuOzIKO8 rLAMDFVUAmTHoVELyEwWFllXzPEw0HzXOhJQ1i3OwYPTD5KUmFxViTYKq+uXsaLaGKTW 3WVQOvyphVZUREg6bdW3h/GqKzhJAXOsx9fp/lW5leBNpNeCdg176sZLaM/xsTbbcDqx kwYA== 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=lV2PvjnsLCNKYA99fN1fnC0kKtD0zTzeA7OFHJT30bs=; b=YypgzaInjG1PrsGLRAf4DHvgF2Y3iv6NQ2bVvOZi0j6yIjr/Fk7VBxArgRlVGBrj1E 5Lzy3NmZelQNNC+emv8D+z7li7V3Y+E9SJxEsNy1WAIBJfV7Dhr4Q1vOKJHIcke8PGnA uLyKB/P/A5dLt6Ay5Y0o5NBlx/VMFZqbfYKQ8IDDC0ygjm+MdSb1YrRh1Eux5JwmlRA7 NSTfvECHzwyL59fNG5IS8NSOnB7czkbPK0GpxLbUY4VatT+ODWTMgmV4X1xYwVW1EUuW F/b1UqIMWAuLIkX9qL+P7V+0n/TAt3Wq1bmhEHLwGGvaa6zMSWK4D4+bP6toKWfBwQv/ hxqw== X-Gm-Message-State: APjAAAU4h34Uwk/ZFZcv46M0kt8SVz/4kJbH1Zr7yTb/qZdfGaYiNDBO AovLXrLGg1CQI7MkB621bpqSBd/70FlrYZSGt2SBSB1cZDk= X-Google-Smtp-Source: APXvYqwys3dSt1XDbfHO3gvXTR70FWmBNWOhGdmjHjIAZkPrpu6uyTnrHe85B/w/KNvnxt9K5DNSFe06P93z8XTryNE= X-Received: by 2002:a92:3a8e:: with SMTP id i14mr17658500ilf.255.1576587575155; Tue, 17 Dec 2019 04:59:35 -0800 (PST) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Tue, 17 Dec 2019 07:59:23 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000005fe21f0599e5e696" Archived-At: Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 12:59:38 -0000 --0000000000005fe21f0599e5e696 Content-Type: text/plain; charset="UTF-8" All, This is a call for adoption of for the OAuth 2.0 Pushed Authorization Requests document. https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ There was a good support for this document during the Singapore meeting, and on the mailing list in the Meeting Minutes thread. Please, let us know if you support or object to adopting this document as a working group document by Dec 27th. If you have already indicated your support on the Meeting Minutes thread, you do not need to do it again on this thread. Regards, Rifaat & Hannes --0000000000005fe21f0599e5e696 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

This is a call for adoption of for= the=C2=A0OAuth 2.0 Pushed Authorization Requests document.

There was a good support for this document during the Singa= pore meeting, and on the mailing list in the Meeting Minutes thread.
<= div>
Please, let us know if you support or object to adopting= this document as a working group document by Dec 27th.

If you have already indicated your support on the Meeting Minutes thr= ead, you do not need to do it again on this thread.

Regards,
=C2=A0Rifaat & Hannes

=C2=A0
--0000000000005fe21f0599e5e696-- From nobody Tue Dec 17 05:00:42 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4344812008A for ; Tue, 17 Dec 2019 05:00:41 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLvakcFNeR7X for ; Tue, 17 Dec 2019 05:00:39 -0800 (PST) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1356120A76 for ; Tue, 17 Dec 2019 05:00:31 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id A509CB7DF for ; Tue, 17 Dec 2019 13:00:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1576587630; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aAFA/gCoMXUI54DUOcV7Il89EoYiWwIxRO3sV9FqbVc=; b=rlnMcIkZvgqhRxKTZ3ozvytXLoYeV+ZjtHeItm1MHIhEN8nCQRacPqUooejeuxKYPAGLvM j8O/38SYhisbEeC/ggD6Kxsxr/6+wHfe26QKhrrT8sgIGma5NrjrHF9UF/18IooqIM7kN9 FmGwsg5sV9AXc6CoIUsu0marPklHtVU= To: oauth@ietf.org References: From: Daniel Fett Message-ID: <6b419edd-e5d8-e767-20d5-e8c014ed9ff8@danielfett.de> Date: Tue, 17 Dec 2019 14:00:29 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4252EB88A40476C8E3441324" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1576587630; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aAFA/gCoMXUI54DUOcV7Il89EoYiWwIxRO3sV9FqbVc=; b=Y2byhej8NHN2fZt+oeH34iSW/+zlf0VI47QYtx2gcChW8bP4XJ36YcMN1A5A7izhR8ObxR bLZPCKYpdm2J53t3jgsC2u3D745L5Up9PnqU/oa6nrkEEhzYS0eppPLlrl/cqRUIhlZn+V Rf10ZtTbYFQC+O3F6H9r8MV0pYr0l7o= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1576587630; a=rsa-sha256; cv=none; b=gi0uZv+eKZpEM+F76g9NWNEpzvZFiC8cBuFkBbvm+TsbQDsVwZcgDdlpqmXyEYKr1XbAKvN5ogckSVMoLjeZrSsDsGk1Ckd372z1og3pBAMT2trCwa2TtNbxludztkH2e/F0sLnmcYOiur0P5OHt4z8hN2VriNGmj9Ak5VlXr5k= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 13:00:41 -0000 This is a multi-part message in MIME format. --------------4252EB88A40476C8E3441324 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I support the adoption of PAR. -Daniel Am 17.12.19 um 13:59 schrieb Rifaat Shekh-Yusef: > All, > > This is a call for adoption of for the OAuth 2.0 Pushed Authorization > Requests document. > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/  > > There was a good support for this document during the Singapore > meeting, and on the mailing list in the Meeting Minutes thread. > > Please, let us know if you support or object to adopting this document > as a working group document by Dec 27th. > > If you have already indicated your support on the Meeting Minutes > thread, you do not need to do it again on this thread. > > Regards, >  Rifaat & Hannes > > >   > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------4252EB88A40476C8E3441324 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I support the adoption of PAR.

-Daniel

Am 17.12.19 um 13:59 schrieb Rifaat Shekh-Yusef:
All,

This is a call for adoption of for the OAuth 2.0 Pushed Authorization Requests document.

There was a good support for this document during the Singapore meeting, and on the mailing list in the Meeting Minutes thread.

Please, let us know if you support or object to adopting this document as a working group document by Dec 27th.

If you have already indicated your support on the Meeting Minutes thread, you do not need to do it again on this thread.

Regards,
 Rifaat & Hannes


 

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


--------------4252EB88A40476C8E3441324-- From nobody Tue Dec 17 05:09:01 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B476D12022D for ; Tue, 17 Dec 2019 05:09:00 -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 nZS5deID37mr for ; Tue, 17 Dec 2019 05:08:58 -0800 (PST) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1DA912008A for ; Tue, 17 Dec 2019 05:08:58 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id 77so13701398oty.6 for ; Tue, 17 Dec 2019 05:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JEQHvL3rovzoBJvk0gCZ5njUeKa3iKoxToU6OkYHy8k=; b=tqYH+mzg1wgl6rNqU8lRBXjZ/6aGIByUYUWDPDr520yk7HyTZcf3vSOwgYIpDukI3B +yZcbEHi8R9n2cY6va4ZuyfsUYjJQBQc5hwIlwcQhzfya86ZWG87U7ZOA0HyADge89d/ JGn5okogjTG7KXGH8a/cVgc/9ebN8m24lQIlfi8sNs5oLV+xy/unKqbnd1n1hi+tTq63 na+BtxvrfIFHIei860s1rSIqHBaip+idW+10HVGEWiSypd/uffir/ui+ZwmyOpF3jZX5 QpR31hqaWKcQbMAUTZqYuUMAg/wQliAQ4Anwen+8z8Kfy9gXRCc72hhcsqpuNUTwIJdE 7nwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JEQHvL3rovzoBJvk0gCZ5njUeKa3iKoxToU6OkYHy8k=; b=VnUHR1Nh4+g8UPbLnnU8IYzE3AW9amRNpdD8tSjfp0ElCDZbySDs/EiUPTeJzpvlNS zAYdziV86AqdR8nTRybyf5gb6uPn0Aw2HOGlY4lNwUjga3J8meJiUS4zbtgNnpZcffG9 Msoa9tMxU3IJXimfkLr9J1g8f/6/3EbzZzzSe+nfhcyULcMtpw+SA0OtMd7fhHB3f3bY /f0BQU865mpxapyJsAUoLecnyb5SGoYO7XB6H+2nA3wmqphEOjfzLT6qVXuiH3SF9i/7 OPx4CaRInHuAC49FCdH6YdqzG2UHU3hE6BdpoR1GqRIvtqyO2I3hmCrjTszJpCIL+BRI 53kA== X-Gm-Message-State: APjAAAWMZMDQKZRI0hacnrn30dmL9JGxOKxMb+46SxM+Vw36EheuC1+F aCztnTMbN13yaZZI3vTjAfwkrESnESlpk+ydyTa0teM= X-Google-Smtp-Source: APXvYqw1IS1wm8Lt2GoHFZqC8k9WG+tZZApkvMchOaC2Ak2FBF2jPPXlg9FVz8hbJ0o6ok9pCwQOuq9jSaOR5sL/q7M= X-Received: by 2002:a05:6830:2087:: with SMTP id y7mr35627379otq.96.1576588137649; Tue, 17 Dec 2019 05:08:57 -0800 (PST) MIME-Version: 1.0 References: <6b419edd-e5d8-e767-20d5-e8c014ed9ff8@danielfett.de> In-Reply-To: <6b419edd-e5d8-e767-20d5-e8c014ed9ff8@danielfett.de> From: Filip Skokan Date: Tue, 17 Dec 2019 14:08:46 +0100 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000e6dc4e0599e6073f" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 13:09:01 -0000 --000000000000e6dc4e0599e6073f Content-Type: text/plain; charset="UTF-8" I support the WG adoption of PAR. Best, Filip On Tue, 17 Dec 2019 at 14:01, Daniel Fett wrote: > I support the adoption of PAR. > > -Daniel > > Am 17.12.19 um 13:59 schrieb Rifaat Shekh-Yusef: > > All, > > This is a call for adoption of for the OAuth 2.0 Pushed Authorization > Requests document. > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ > > There was a good support for this document during the Singapore meeting, > and on the mailing list in the Meeting Minutes thread. > > Please, let us know if you support or object to adopting this document as > a working group document by Dec 27th. > > If you have already indicated your support on the Meeting Minutes thread, > you do not need to do it again on this thread. > > Regards, > Rifaat & Hannes > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000e6dc4e0599e6073f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the WG adoption of PAR.

Best, Filip


On Tue, 17 Dec 2019 at 14:01, Daniel= Fett <fett@danielfett.de> = wrote:
=20 =20 =20
I support the adoption of PAR.

-Daniel

Am 17.12.19 um 13:59 schrieb Rifaat Shekh-Yusef:
=20
All,

This is a call for adoption of for the=C2=A0OAuth 2.0 Pushed Authorization Requests document.

There was a good support for this document during the Singapore meeting, and on the mailing list in the Meeting Minutes thread.

Please, let us know if you support or object to adopting this document as a working group document by Dec 27th.

If you have already indicated your support on the Meeting Minutes thread, you do not need to do it again on this thread.

Regards,
=C2=A0Rifaat & Hannes


=C2=A0

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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000e6dc4e0599e6073f-- From nobody Tue Dec 17 06:01:52 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB5B120112 for ; Tue, 17 Dec 2019 06:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 n5msejs5aCpX for ; Tue, 17 Dec 2019 06:01:47 -0800 (PST) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DFC1200B3 for ; Tue, 17 Dec 2019 06:01:47 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id g12so8462322ild.2 for ; Tue, 17 Dec 2019 06:01:47 -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; bh=wJ7MPuyzlzhUO0t+7tXnXbZ7KFoHtypRNHwOB1kxj9s=; b=sOZcsqO53wcYgwoxXpFO4hWxkgPshC8K9GqXYT+xgKT7KYWHb9apbQdLMhOOORTg/F Ku4gTdioI7nUqicdJFI6AhBKJOnVB93qjsh7pvTuh2JeRG1mlpFWkLK25uyz4gw/JTeT oe/T0bO/Mac6LdxdSg4T/BBmi/wvTtQX+j2qpjlGZ37P9MRJQcC5MJ/Q7g+aykDQ899L HdaILlym4LqU7ucuNt2OsEo6ncOsdsn8fx00AXsG3AD6BCTe9PnA3h3GQhWBOiG2q6Yp gd2RcJJ3+cEQNET+vxHzUFtqWX2J3P7KS69HFCSL5hr3KnCsgjvcUjMJh4t6aHh8wWcJ mTnA== 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=wJ7MPuyzlzhUO0t+7tXnXbZ7KFoHtypRNHwOB1kxj9s=; b=FIxwBgoBEg3gEMoNLPRYGBXeOuovW0aDWrqmo9ZMfJ3wp2p1+oURNiNO6Fr5/IX1nR WeTSpzoROWtX4d4vbWmPlf/B5CnVHUdYEKoeZuPDapD3T38jjDxjJCdFIwI93Ry6ffse lBbyhKUoVdvFzDth92Qvp6yi/LDv2cUIZeJdjEUja7wZ+pm+oFKwvQG2rAH4liByzaRI RPWmqEKpAR2XizvNipNY+OARNECvplkuBuQFxzDszvvh/q/IiSO1ks+m1rMfmCpVkINY y0THHfohM4zNhrimPzG8LgzHb5ZOv/FWH7NUmczyq7aCpBO+bTTJXzvn1F+eiKx4vbHc UMgQ== X-Gm-Message-State: APjAAAXPJ0dAWaEni+iyjmFMIPuL0JGEqKFMhSzNQYNbU9gn/C+m51LR dfSqY+uDUX870gQQH3D7d7VM6l/JOpA= X-Google-Smtp-Source: APXvYqwytO6Q4/6/ARatdmeqyjxt4CCyryjEcPgJb2I0qOVgwM3/iwf80ZwMiUYECeFIY8dcpnOFrg== X-Received: by 2002:a92:dc91:: with SMTP id c17mr14996543iln.78.1576591305809; Tue, 17 Dec 2019 06:01:45 -0800 (PST) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com. [209.85.166.44]) by smtp.gmail.com with ESMTPSA id s5sm3946106ilc.73.2019.12.17.06.01.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Dec 2019 06:01:45 -0800 (PST) Received: by mail-io1-f44.google.com with SMTP id b10so11061119iof.11 for ; Tue, 17 Dec 2019 06:01:44 -0800 (PST) X-Received: by 2002:a05:6638:3b6:: with SMTP id z22mr16742975jap.35.1576591304713; Tue, 17 Dec 2019 06:01:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Tue, 17 Dec 2019 06:01:33 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="000000000000ac6bc30599e6c476" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 14:01:50 -0000 --000000000000ac6bc30599e6c476 Content-Type: text/plain; charset="UTF-8" I support the adoption of PAR. Aaron Parecki On Tue, Dec 17, 2019 at 4:59 AM Rifaat Shekh-Yusef wrote: > All, > > This is a call for adoption of for the OAuth 2.0 Pushed Authorization > Requests document. > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ > > There was a good support for this document during the Singapore meeting, > and on the mailing list in the Meeting Minutes thread. > > Please, let us know if you support or object to adopting this document as > a working group document by Dec 27th. > > If you have already indicated your support on the Meeting Minutes thread, > you do not need to do it again on this thread. > > Regards, > Rifaat & Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- ---- Aaron Parecki aaronparecki.com @aaronpk --000000000000ac6bc30599e6c476 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the adoption of PAR.

Aaron Parecki
=

On Tue, Dec 17, 2019 at 4:59 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

Th= is is a call for adoption of for the=C2=A0OAuth 2.0 Pushed Authorization Re= quests document.

There was= a good support for this document during the Singapore meeting, and on the = mailing list in the Meeting Minutes thread.

Please= , let us know if you support or object to adopting this document as a worki= ng group document by Dec 27th.

If you have already= indicated your support on the Meeting Minutes thread, you do not need to d= o it again on this thread.

Regards,
=C2= =A0Rifaat & Hannes


=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
<= div>aaronparecki.com<= /a>

--000000000000ac6bc30599e6c476-- From nobody Tue Dec 17 06:14:56 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4229F120842 for ; Tue, 17 Dec 2019 06:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=ve7jtb-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 ctwGcaktVtPF for ; Tue, 17 Dec 2019 06:14:51 -0800 (PST) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8517E1201E3 for ; Tue, 17 Dec 2019 06:14:51 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id p9so1932410plk.9 for ; Tue, 17 Dec 2019 06:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=5x8LXPpt/SKLYpkL7HGkhZayljzji3c6zEsxRHdxpEM=; b=YSnmiUvp7CmFloGHgUt1FxglXu0rCCT4GICPw2LJPgMXBWC4VpGIhgqglOoXxrZkO3 MwH3CYUHqiQbYgAylQ7G2fW6BAUO1PFBJTi1nvES9ol61bWekZr+QSg5Nrercww5ZZLQ ePPMGuVhLkek+IUlK+/jRfzltsXBVGCbOf4v1r0PnE7UyPWF9Njagq3SAu9kJmAaV3Z9 OSHWbLvGXvA2CD5qj5epUow9afr+8jNSLIXO1ewKyOXFB29SyQxodkPkDWyt0NeT4mu5 ivyFMFdimcHdcTfHPc4cAJy3fRLZOykquy54uHorayR5XMF3Ky8faMXMcwbDmcvkvSu+ ixCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=5x8LXPpt/SKLYpkL7HGkhZayljzji3c6zEsxRHdxpEM=; b=TU3/Aiz3evkkDeHf/mEV2s2Xi2ubFhqRUZA4Apx6SmelxkMU9DItM1WUAwDH0K+ZBE hc5E6LsI7N1JkyR3EF5r9GshhX7U5rYEyLHcHSUqdPaLveqyLRwqiDrppKnllV26FRmU Df5LIZ/kGJyaDew/poUvCOriTS0QByYx8qS7VoxEYpQx7U/An3PSISJb3fsj27K7Jv4u q6oN2kgFCt3Eha4z4Tt5eGGZREsr3hq4Y7ICfsY8zdNlmYnfhsNk7RiKzaqme2Joboi2 ELriOgGQnrpxuFOLVbhs+gElGbK+O2zqmZzuQNnf+UCHfaouXEa4iCeYUAjznayrpNSu D/vQ== X-Gm-Message-State: APjAAAV3yNGaqqw16l4wzn67+wLYMk1y15IhGEWuIq5QEh0VqPvQnwbM 96wWOSicJRZV5Qg74DHX2dQo7nhoMaP7WQ== X-Google-Smtp-Source: APXvYqxB2sPhld3Ut44qFJdhi1vs7JSsQkQjyv0yxGfDbzmmBl1NNIrjEZToRCf2zkh+7+kFv5mrYg== X-Received: by 2002:a17:902:34d:: with SMTP id 71mr22449459pld.140.1576592089704; Tue, 17 Dec 2019 06:14:49 -0800 (PST) Received: from [192.168.8.101] ([191.126.136.27]) by smtp.gmail.com with ESMTPSA id z26sm26145784pgu.80.2019.12.17.06.14.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Dec 2019 06:14:48 -0800 (PST) To: oauth@ietf.org References: From: John Bradley Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE= Message-ID: <7cd6d76d-3734-532e-06a2-12adc9600d63@ve7jtb.com> Date: Tue, 17 Dec 2019 11:14:34 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7227BD75D72A1DA5414F4B75" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 14:14:54 -0000 This is a multi-part message in MIME format. --------------7227BD75D72A1DA5414F4B75 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I support addoption On 12/17/2019 11:01 AM, Aaron Parecki wrote: > I support the adoption of PAR. > > Aaron Parecki > > > On Tue, Dec 17, 2019 at 4:59 AM Rifaat Shekh-Yusef > > wrote: > > All, > > This is a call for adoption of for the OAuth 2.0 Pushed > Authorization Requests document. > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/  > > There was a good support for this document during the Singapore > meeting, and on the mailing list in the Meeting Minutes thread. > > Please, let us know if you support or object to adopting this > document as a working group document by Dec 27th. > > If you have already indicated your support on the Meeting Minutes > thread, you do not need to do it again on this thread. > > Regards, >  Rifaat & Hannes > > >   > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------7227BD75D72A1DA5414F4B75 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I support addoption

On 12/17/2019 11:01 AM, Aaron Parecki wrote:
I support the adoption of PAR.

Aaron Parecki


On Tue, Dec 17, 2019 at 4:59 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

This is a call for adoption of for the OAuth 2.0 Pushed Authorization Requests document.

There was a good support for this document during the Singapore meeting, and on the mailing list in the Meeting Minutes thread.

Please, let us know if you support or object to adopting this document as a working group document by Dec 27th.

If you have already indicated your support on the Meeting Minutes thread, you do not need to do it again on this thread.

Regards,
 Rifaat & Hannes


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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------7227BD75D72A1DA5414F4B75-- From nobody Tue Dec 17 06:41:17 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC2F12084F for ; Tue, 17 Dec 2019 06:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfpiVk2FkaJM for ; Tue, 17 Dec 2019 06:41:12 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC14120848 for ; Tue, 17 Dec 2019 06:41:12 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id x1so8393322qkl.12 for ; Tue, 17 Dec 2019 06:41:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8vUUhcKJIi5OwyKSNuXmSbYb/DwkIQDkOs58SEu0iv8=; b=QjVD8royx/2XG5guAifM6wRfOICswJpNKSowdCZPWhudPxqk3GHnHzJgITZo4GmmK6 k2Pohn24wp7Ccvmvr0tgZ28wR4POjg2bOSIb0La/lQrdq0+tSupq9LlcZyA/52KGCQ58 0JMnOX+hHeQY2IoxyQWsOLfhvxverad03TKc+E8jQPUlHeSKbxyGvkHmoNzNbD8PWXU2 161TN0WjfDt4Gp8r0YNpjNg9pLRtYRy5dtx1pPOG6qKA7pBzSeD6SB88ssxM+udweUR/ JzW59rQQrExxWD/hXDdB3jgwjG9+95i6+jpvAScMEwadjNKQX6BaTJo8o9k+hCSp28iY 7hkA== 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=8vUUhcKJIi5OwyKSNuXmSbYb/DwkIQDkOs58SEu0iv8=; b=uLp7u+GJ2CPCGzltHxpCX8wnmlm2LZKhS3ti0J5TmjUIjYlBtYQ5Za84tt7zX1mmT9 52J7blYsS9ogWoheQGK43f1rFPmhHcsjET5g+hJ7+keASRfk43/QOuWw+Il3sTtHY8lh N1+zDmuJcZM9ygFXSpYkHqUJlKvBTuq8W+tf1AUoSPGqYIvZWr8oA1xW8QqCQDZ1mJBx yd6aR+cis4BO402/8QBRPfLUjYLpJtbMPJ3akuSJNruSdWPV1dF1DbFIiuYG647NA10d t95mZk/zuMYu6V0hu+j0gqfh6j82LOHCcH32kMhDjJJph0HQynLyR4E2dm+//Q0ZBH9Y XlNQ== X-Gm-Message-State: APjAAAXgDTGAowc+KeN/oTIq+RCN1TvM3aoiiR7Hl38Eri+c0lo5fmY1 OOgkXIxK/gEdnMJJquoed1cNsZ7ZJX9Beni1N2r0jfv7ZWE= X-Google-Smtp-Source: APXvYqw1xSEvsV987Nk2qzqoLGzvfLkuZVvNxiHd9ZlPumE9CPzITBWEL65RWi28CTtj7t9ykzziY84vOgBA42BQBAA= X-Received: by 2002:a37:a30a:: with SMTP id m10mr5172743qke.56.1576593671257; Tue, 17 Dec 2019 06:41:11 -0800 (PST) MIME-Version: 1.0 References: <7cd6d76d-3734-532e-06a2-12adc9600d63@ve7jtb.com> In-Reply-To: <7cd6d76d-3734-532e-06a2-12adc9600d63@ve7jtb.com> From: Hans Zandbelt Date: Tue, 17 Dec 2019 22:40:58 +0800 Message-ID: To: John Bradley Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000bb160e0599e7517d" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 14:41:16 -0000 --000000000000bb160e0599e7517d Content-Type: text/plain; charset="UTF-8" I support the adoption of PAR Hans. On Tue, Dec 17, 2019, 22:15 John Bradley wrote: > I support addoption > On 12/17/2019 11:01 AM, Aaron Parecki wrote: > > I support the adoption of PAR. > > Aaron Parecki > > > On Tue, Dec 17, 2019 at 4:59 AM Rifaat Shekh-Yusef > wrote: > >> All, >> >> This is a call for adoption of for the OAuth 2.0 Pushed Authorization >> Requests document. >> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ >> >> There was a good support for this document during the Singapore meeting, >> and on the mailing list in the Meeting Minutes thread. >> >> Please, let us know if you support or object to adopting this document as >> a working group document by Dec 27th. >> >> If you have already indicated your support on the Meeting Minutes thread, >> you do not need to do it again on this thread. >> >> Regards, >> Rifaat & Hannes >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000bb160e0599e7517d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the adoption of PAR

=
Hans.

On Tue, Dec 17, 2019, 22:15 John Bradley <= ve7jtb@ve7jtb.com> wrote:
=20 =20 =20

I support addoption

On 12/17/2019 11:01 AM, Aaron Parecki wrote:
=20
I support the adoption of PAR.

Aaron Parecki


On Tue, Dec 17, 2019 at 4:5= 9 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

This is a call for adoption of for the=C2=A0OAuth 2.0 Pushed Authorization Requests document.

There was a good support for this document during the Singapore meeting, and on the mailing list in the Meeting Minutes thread.

Please, let us know if you support or object to adopting this document as a working group document by Dec 27th.

If you have already indicated your support on the Meeting Minutes thread, you do not need to do it again on this thread.

Regards,
=C2=A0Rifaat & Hannes


=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth
--
----
Aaron Parecki


_______________________________________________
OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000bb160e0599e7517d-- From nobody Tue Dec 17 09:52:55 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D48612085F for ; Tue, 17 Dec 2019 09:52:54 -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, 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=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 zimmGcgc5ZFJ for ; Tue, 17 Dec 2019 09:52:51 -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 3C4EF12085E for ; Tue, 17 Dec 2019 09:52:51 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id 203so7584302lfa.12 for ; Tue, 17 Dec 2019 09:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HljFXLFCmC8flQUY1DC9kyNcMv76SFI7EWDh0c9xG38=; b=ISsrt0C/LgLvmCGIHKflN8jmQ0ghqb/D3zW6cxafgTKmr4S0a5mk/YoIsDnP1Dp1EC NKWO9yXIlUgS9aWCCrkiP+TRvpBzGqPhxQ4sWnuunoTCTE69p+uCqQRCSrN8tDfDEBHB Mtp7VS86N9IN1miS5jLyVY1mB1q3exUcoVwdR3A7YncRkL34wjjmiAIwj9RmLdDfa3C0 cwGNhUyt/472BnXlvShR7eY3wl5glHYMVmrb+RJIwA2Lq/mIfhq0s/+CTd8gzQHhq1WF soFt5vBe+11FiAXL8x9sU986If0/IrG8+B02yH688l5rcUqBtsm7yPHQpWkxXBUxxGhm N9WA== 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=HljFXLFCmC8flQUY1DC9kyNcMv76SFI7EWDh0c9xG38=; b=ujLMIXyusjazDg9+AvUthCEz3BsbT6HQYv+rfB1SlrTpFRB3asi5jIWRLcobWTOMze ru0AI0mSxylvaMeVnhRtJ1YVI2x5PNY4twz31/umLcWgr+LXcT82AKPpfH1STnwk5F8i GDZ1lzG5PRNxoa1Vju35NE5b65FI7PvXyMXa1rDSGzJ+86v4VeOZcf+TWG3jX65Q4JLh 3ScGRv/qzdmcrGLuMM0po+cKaXXSCCZbMZQAs5XAbMG7mPkHSGTD2mug6npD+MjDpUqO O/4rGjPJkyU+joGZemF0j0SmxqaLmF6WeBYNPNiRXqrplD/kCwlOc6L+y2LHczwp0A+E +Lag== X-Gm-Message-State: APjAAAX2JaJ99JYPwN9Qx4I2vl6RPDvPPXBabBOuF1XlDHlRPqZ+eHDZ jvmPqkV07a2ejMsvSVO6GnJKENYOnVvME4rnlYRu3eR/2T9TjziqPLmde/jEsgnhSkuRMBNKpgt 1oevVH5Z8OwA5sg== X-Google-Smtp-Source: APXvYqw0iph4abZGJvoVQBXkUSNgxZpoudY/8/PGjnXPW12lrSBeLGMk0wKwEVEEFED1/g/pSd63p3oPILZ3sW8Bf1I= X-Received: by 2002:a19:5057:: with SMTP id z23mr3447276lfj.132.1576605169469; Tue, 17 Dec 2019 09:52:49 -0800 (PST) MIME-Version: 1.0 References: <7cd6d76d-3734-532e-06a2-12adc9600d63@ve7jtb.com> In-Reply-To: From: Brian Campbell Date: Tue, 17 Dec 2019 10:52:22 -0700 Message-ID: To: Hans Zandbelt Cc: John Bradley , oauth Content-Type: multipart/alternative; boundary="00000000000013f0d10599e9fff2" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 17:52:54 -0000 --00000000000013f0d10599e9fff2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption of PAR On Tue, Dec 17, 2019 at 7:41 AM Hans Zandbelt wrote: > I support the adoption of PAR > > Hans. > > On Tue, Dec 17, 2019, 22:15 John Bradley wrote: > >> I support addoption >> On 12/17/2019 11:01 AM, Aaron Parecki wrote: >> >> I support the adoption of PAR. >> >> Aaron Parecki >> >> >> On Tue, Dec 17, 2019 at 4:59 AM Rifaat Shekh-Yusef >> wrote: >> >>> All, >>> >>> This is a call for adoption of for the OAuth 2.0 Pushed Authorization >>> Requests document. >>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ >>> >>> There was a good support for this document during the Singapore meeting= , >>> and on the mailing list in the Meeting Minutes thread. >>> >>> Please, let us know if you support or object to adopting this document >>> as a working group document by Dec 27th. >>> >>> If you have already indicated your support on the Meeting Minutes >>> thread, you do not need to do it again on this thread. >>> >>> Regards, >>> Rifaat & Hannes >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> -- >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _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._ --00000000000013f0d10599e9fff2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption of PAR

On Tue, Dec 17, 2019 at 7:41= AM Hans Zandbelt <hans.za= ndbelt@zmartzone.eu> wrote:
I support the adoption of PAR

Hans.

On Tue, Dec 17, 2019, 22:1= 5 John Bradley <v= e7jtb@ve7jtb.com> wrote:
=20 =20 =20

I support addoption

On 12/17/2019 11:01 AM, Aaron Parecki wrote:
=20
I support the adoption of PAR.

Aaron Parecki


On Tue, Dec 17, 2019 at 4:5= 9 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

This is a call for adoption of for the=C2=A0OAuth 2.0 Pushed Authorization Requests document.

There was a good support for this document during the Singapore meeting, and on the mailing list in the Meeting Minutes thread.

Please, let us know if you support or object to adopting this document as a working group document by Dec 27th.

If you have already indicated your support on the Meeting Minutes thread, you do not need to do it again on this thread.

Regards,
=C2=A0Rifaat & Hannes


=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth
--
----
Aaron Parecki


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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000013f0d10599e9fff2-- From nobody Tue Dec 17 10:35:17 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C767120D14 for ; Tue, 17 Dec 2019 10:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9vcr0oalIBP for ; Tue, 17 Dec 2019 10:35:13 -0800 (PST) Received: from p3plsmtpa12-09.prod.phx3.secureserver.net (p3plsmtpa12-09.prod.phx3.secureserver.net [68.178.252.238]) (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 7C89B120D11 for ; Tue, 17 Dec 2019 10:35:13 -0800 (PST) Received: from [192.168.0.105] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id hHgciWkgaDFSlhHgdi1bLu; Tue, 17 Dec 2019 11:35:12 -0700 To: oauth@ietf.org References: From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <39ac39eb-a655-b10c-e52f-7a4671ad6039@connect2id.com> Date: Tue, 17 Dec 2019 20:35:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-CMAE-Envelope: MS4wfEX0jvIX4Fzhb/D0vGLR0EfUnTAAVXSRbHWJ6gTXvcU5l8rHKXIm/3UfpTvswZ5KkZHeaTfEhAuVldFIxAsPXGKHWGIPjim5A+7MERS9HUDIuQBXvwZp qgPM8j4f5rkS/kmpA+/QMrpiu5ahjK/PrLGyKVwjtkAUnL3YrwVEVEVl Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 18:35:15 -0000 +1 for the PAR spec adoption. We were in fact so pleased with PAR that next week we'll be making it available for production use, based on draft-lodderstedt-oauth-par-01. If we had any questions during the implementation, they were addressed in -01. The spec is feature complete IMHO. Vladimir On 17/12/2019 14:59, Rifaat Shekh-Yusef wrote: > All, > > This is a call for adoption of for the OAuth 2.0 Pushed Authorization > Requests document. > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/  > > There was a good support for this document during the Singapore > meeting, and on the mailing list in the Meeting Minutes thread. > > Please, let us know if you support or object to adopting this document > as a working group document by Dec 27th. > > If you have already indicated your support on the Meeting Minutes > thread, you do not need to do it again on this thread. > > Regards, >  Rifaat & Hannes From nobody Tue Dec 17 10:47:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397D7120874 for ; Tue, 17 Dec 2019 10:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=CZ9kFIiS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RzwAyzG+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVDXlZMriW24 for ; Tue, 17 Dec 2019 10:47:04 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A55120D1B for ; Tue, 17 Dec 2019 10:46:59 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id DA5785B1 for ; Tue, 17 Dec 2019 13:46:58 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 17 Dec 2019 13:46:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= to:from:subject:message-id:date:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=FcNjn26JMj0Ir3Wf3UZrEmD cMGcohjYDJBpMTKRxf8I=; b=CZ9kFIiSwTaXkqGQEeYLBoKEqSdG8LUdCXBHrqL hKCntZC2E0bWGk0RyZvW+17X8vPTxjAddEdN7paC+CBx7KJKKByDUIDjEugjyXOu yeCH60ftOT6sAbXxQWwz9RUQRwdeoyx5clml3hGdK3jcZxXwm0JK7rXiiN8ErQPd LYnY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=FcNjn2 6JMj0Ir3Wf3UZrEmDcMGcohjYDJBpMTKRxf8I=; b=RzwAyzG+bDVeZaOJQIwDKl kzJ8cekvEbB02HcRUATz88J+Uukml+Z2LMxW0V77dRHA/JY4tOudlI8PQzJVzHpR SmzqqSCDE3B2/mh/MUBDUOu4sYE+n4Jo0Od+kXy3NkEsyMYzVijRsRUkUryB3jGw izhc+RkqjWWl2tPDz344VGK7mbkR1OziSxRtDAprpVeExISolfvuVD/IJN5MihwW oijE4A+yj9FNUH9w+ChJWhQn1en4D3T3O31J0n+Y9SjNOrLiVeeWKPbMJMdMA6XB JTmCLugAtiXl/HF+K3kZsymPFVAXKpR6LbrCxs9ho2nGsgLFhtvIguIDO/LyWUsA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddtjedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepvffhuffkffgfgggtgfesthhqre dttdefjeenucfhrhhomhepgfhvvghrthcurfhothcuoehmvgesvghvvghrthhpohhtrdgt ohhmqeenucffohhmrghinhephhhtthhprhgvqhhuvghsthhsrghnuggruggushhthhhish hhvggruggvrhdrrghtnecukfhppeelledrvdeftddrvdehfedrheejnecurfgrrhgrmhep mhgrihhlfhhrohhmpehmvgesvghvvghrthhpohhtrdgtohhmnecuvehluhhsthgvrhfuih iivgeptd X-ME-Proxy: Received: from [192.168.0.27] (cpe9050ca212883-cm9050ca212880.cpe.net.cable.rogers.com [99.230.253.57]) by mail.messagingengine.com (Postfix) with ESMTPA id 1A5028005C for ; Tue, 17 Dec 2019 13:46:58 -0500 (EST) To: oauth From: Evert Pot Autocrypt: addr=me@evertpot.com; keydata= mQINBFzZpTYBEACt3GNTWOSosId2/7G1EHYWfva4gF4kgOL+/pew0+I2wTCyFeDXti+CRE1o 5LoCpTSGHDWZokSELeA2PwNX1ls7c2sZ7AVKWKhBLBhPEVo6YzlTli/B747ryGfMikiWYCRa e/yBJtyRuWuS8ArxCpEROzcUqCGZu7Rqs9RzUfYS7WZ85ne3DeRxPCCBIIlhlRu2lasjByPs IpSI0YSIpq4M5fLqbVdTjfqbTBGw82pDwQwlxO3J0T07dnvpEEheYspkMj/EGXqVTrLuoRw0 D7yObXgr0bcjuf+km8cdfZktclqCg1YajiseBBObw9IQpWiIE0oIxA7mAti1wus3JLxAfqCI tgzBtwEPeg6tcfzeDI9gnSl904g2+ozS0uFI61YHA/j70IxgIwyzp8QDsj0nS83aqaZV8k2U FNCnbriMftMCD/+iudRxfzq4VThkhIgfR9ZsaTvdWGIsAxCZyjaUHFMOBafjCMNjePCg74yA JSwdHhi6mzIuIfVGqsKXmO4Khzgm+c2qVq7cym93yp6kqNXOge9ZjQ2q96HHa64wXoYlNYZU 0fkvjkANj9V7ZC4PnavRMQHeFsW+vqU38pIFSppsqpeBggvV4U2WRHt2NyrE3ta9h1XTs9w3 SWSTujpJ/XGqPm7YYnNPrKXn5uvjEJ+OKt4+trpP1juUc3LJ8wARAQABtBtFdmVydCBQb3Qg PG1lQGV2ZXJ0cG90LmNvbT6JAk4EEwEIADgWIQTLR9Vo8uufCXNz2gLxiYR6BK2dDwUCXNml NgIbIwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRDxiYR6BK2dDyHmD/0bufc/UhM76R8S NSpYAds83HKt3XgIGPl8CEMaz35bkvlNypVUvd0iLy1MFgDDyqdXuM840HWL0grCC+g1LA8K eeHSYBDYm+ATlEu09FCN6+TdDbWBA19vmLlJ98mEgCDrIo/B+pskap4Qxq20vuxssL0nIXyM 1FoPlrTu8SuZrkViUSWmEICSB6UfZntIJDPxv9NSEjLKSkTCwIXna744W4zQQ/tHohohw2qc epCudGv1AhJBJS+UE8W+Lpt3e1fsMZQl/UIFpF3EQ3+6DkIHqk+nVe7zstcGbB/RUkHqwUCb km9Iv2B9YURrDW6XIF2jp+vAVuI78kLjXCTEBd8bzlBjt2BOTVaj4JZcdilKfNNr57H8Go+A IyVqsjjJ0LqkCdmG96lgJLUCcMztiJnTxxzLFSF4rQHKV14G8EQ+xMkx5We3QOWKGFHkf4JF zPCFD8O1978FbPEZ6JjnSR8Goeb5RKpGe3AfjHR7brS6jpxQaC8pGnjVBQzY3bXc1LSKWJ8N LHEOnKN5xBnwWpQv7pygxslnrNCzWCUijsqSQOFcihUEcZwNr6IwHBXBoR56pEiGk1u9Y8cZ VcJbQkj9Ok/0fNF1wYDlJS7gl20pD3YwZ2GIBPHH8FI+COOQmSTqpkN655H1qL4nfakXwu27 giSFbm0HupM7IuGm7fjigrkCDQRc2aU2ARAAysa169s6wds+2mg9oJTz0kDusRXca3pRiMKV 9YfpztMX9KK8F799gRtvjz8ZHVQlhr6NYHJmtsH5Y0iGYOL/6kUE56laB/C3cSJ0FOZN5Ov2 fROUWmEJod7oyHJW0mcGKGfHiuGo0Xs7bAcspxF5s8iysFr50nLGEqJJ7G6/jzcMuFwqhQ5z B3/hctD09nI5YPzJJrJiPxtJ3OV4wEziIW7Ff9rOwSDvMLbSfX/iJA7QRM81IuTVWBBljlG9 YkbPcyczINtqYAXFaKGaUM+TE3YnUDFsHgvpEm2MFC4NCcKFDgsAy8IOEYRCDXtkS2eopQvd rafP5jJ9aLXP/zbXlslY7dQ+QxQjus1W+V0eR09NDp83uaJ/EdtnveETyQqjrF+z4svdlRYF Xd3kyV91OC2r3fXX2uKHDuAQVI2jbAS2apnCJbCQJMQfULyAYXKf8iCGk7nC1y0tGGpQ7HxQ GW0KC86GQP8hrXYNVvhkFGuxGjp814U7eFfZUZICq3Lqk8rxi830+9noFCHU4egkRynULhCN M1R/A/itwBZsrZ4+I6vYejKizDvzm3e9sb+5CMQeX4Y1uLkYKT163hshJCGsJEIobmvLlqUh qkY3UFI293h8xv/b0bEbeILUWJn2c6GNWR3flbb4wYW968DZg3uvKnFkomA6XECwsAKDegUA EQEAAYkCNgQYAQgAIBYhBMtH1Wjy658Jc3PaAvGJhHoErZ0PBQJc2aU2AhsMAAoJEPGJhHoE rZ0PYdEP/0K9Nc7khSfCqvuyLnoV6ONkaGHfbjgNcjGj7n46nx9FQJpp36fVBYItJdFXEfbt riY7OnqS5voTDlpmS922xfk9gfG1TKGQrsHCKSj63LyIPweYdCFGvy5F/Ijn0eNeVuxJU48D gE3nfAygrDdjfgDy3E+iFNEbb1YJLXCTavA4ciX5IZ7W7uzWLC4m2u/3N2/phuPtRcRdszB+ kwHPnmPNX1Jqw84jLD+Nn8ideM4G6H3fqFS55GktB0wfMOgsnVDSyrFKnXMF/077W8ZUU9k/ TveBbBtYLxcwJyrVnARh97xUi9PUABK/K8djp+z/kBQCU+Umwii4vFoubh/vTE/09BRaY8jg tvTetzzeMoqsnRiEgFHO+RCUFVFrzG8X48zji44+Vs/Ocq4Rz1auHPGpVT7ksB7/1C3wWOIg D+rOfkLt+zr1QG2V/BT1O0qrAaxOOm3pj76OyYks/tcdERkXWIQhCamn2Wc4h7tWuGnCJHny AGRF93EEPoMXoa5YxE7ai6WIUJBnR892vEVL+tOMDc0uaOAxk9xfMTM9FICqLVzfxo4GUDhJ tVV72OP0MkjyR1JTKZ6zAS7e5CviHutd8m/ILFDCKxgl46mERGW87eolJEO2aAjR8LycuwD2 PApJHMoXVaQKApGJYYaUeJrYDbqVYBNRMoVllUFOGRE6 Message-ID: <073c968e-627e-6927-6d9f-cad2e9fe3e89@evertpot.com> Date: Tue, 17 Dec 2019 13:46:57 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: [OAUTH-WG] Recommendations for OAuth in browsers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 18:47:06 -0000 At our company we're developing REST apis. One of the things that are pretty important to us, is developers being able to access the REST apis directly, via their browsers.Our systems typically have a middleware that converts generated hal+JSON to a HTML interface for easily browsable. When using something like Digest or Basic authentication for the API, this is pretty easy. Browsers present a pop-up, allowing the developer to log in. With OAuth2 this is less easy. Being able to log in via a browser means that at least an Authorization header needs to be injected. Ideally, browsers would just support OAuth2, are able to discover the the OAuth2 token authorization and possibly use the dynamic client registration protocol, but alas... we don't live in that world, and I'm not aware of any browser extension that does this. In fact, I don't think it's possible today to write a browser extension that intercepts HTTP requests and adds this header. At least not in Chrome. So I'm looking at alternatives. One idea we had was to modify the resource service to detect browsers, send them through the authorization_code flow and set a session cookie. Initially our idea was to just set the actual access_token in the cookie. Another idea was to use a JWS token that encrypts both the access token and refresh token. I also don't love the idea for a resource server to support authentication via cookies. It feels risky, but I can't put my finger on why exactly. My question to this list is, are there any recommendations for this? It's a shame that many APIs can only be accessed by purpose-built clients, the nice thing of hypermedia-style APIs is that humans can actually browse them. Evert From nobody Tue Dec 17 10:48:56 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62A2120D25 for ; Tue, 17 Dec 2019 10:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.572 X-Spam-Level: X-Spam-Status: No, score=0.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, EMPTY_MESSAGE=2.32, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 xa1wxtqoSgC6 for ; Tue, 17 Dec 2019 10:48:52 -0800 (PST) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF74E120874 for ; Tue, 17 Dec 2019 10:47:57 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id x14so831579ybr.4 for ; Tue, 17 Dec 2019 10:47:57 -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=zQTxGind/awt+CfvSuUUanut/fn3qysJE4WL9HdDyak=; b=t3cqGwPXbeZpQTDlMAOTFNDyP3tpuHBqq69Pj90PTONbtFMAfJ+JAyiZLODqj8Q6YO 2/e1OG4Wohs/LKjYXdIrac1YZHb0jIrVHgvpCNN47u9ASN5G8hAeh5FpvfPZgWhkFxSz KUbVPQ+RSC2DOrE6ERS57ja3dZ5GU0T3cCmZU9ubJqMj7w4rTGVPMA2owHCDA7G1VXJL l6cOzccMlZqkenwZdA7pv48tzfV7IwcCL43/GAT3lV9M63zqwEvbj4kuXvKJIzOM5loA RRTukOIFxWEqBzTGxstqELSHz3r9yaHs+cxa0D0wj2LNFQ5LRr1TK/ePP8fWZ3CeKAoG fd+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zQTxGind/awt+CfvSuUUanut/fn3qysJE4WL9HdDyak=; b=ri3t7ptZoNDL/a2t18M5GM/o77c0yKdS6C8BMSxxb2TaxUVEHDBg0KatVGh5iVvGvo jQjV5cczJkI7OX+KGmvdg5EfxYwmB+k5HqUGG/QnSCappe031gdOxlsLrEHAY6WqNlWa D4BoyMOqBLVETe1sg4Jfn50r6pAeRROPOUFpoc41/5gKPkbEYqKp/6GmoFHyJxU125Zs u5WLRdim5FxhlNt9azemOnavRRujUApOoDFUkVrStaY5ga2K32e0DFi5UW9RrCfa1RcQ ldeGFqu5ZI6LaNx4xzLk9CDFkPAdaqOgJKnrI8XJ77938k95mWudct8YlGKdvrKiygVj sCfQ== X-Gm-Message-State: APjAAAXZVhl9dQmf7dEehlT/YA+ITnqnOxY+n/A1+F5wW0pUYNxcjpvV HmBvrPckjnzEXuHO7VklwJ4vrU0i/JmZsYFCfDJoneOPYR0= X-Google-Smtp-Source: APXvYqzAUNXt7j6HL52tvDGas8QjwQr0xp90yb1VA4vceq5KklozN6VoRraoYyrC8X3dVjHQAIWt4aPYo8APDeZrLWg= X-Received: by 2002:a25:db8d:: with SMTP id g135mr24927128ybf.157.1576608475960; Tue, 17 Dec 2019 10:47:55 -0800 (PST) MIME-Version: 1.0 From: Schlampa Schlampa Date: Tue, 17 Dec 2019 19:47:44 +0100 Message-ID: To: OAuth@ietf.org Content-Type: multipart/alternative; boundary="00000000000028db340599eac4ca" Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 18:48:54 -0000 --00000000000028db340599eac4ca Content-Type: text/plain; charset="UTF-8" --00000000000028db340599eac4ca Content-Type: text/html; charset="UTF-8"
--00000000000028db340599eac4ca-- From nobody Tue Dec 17 11:13:14 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644A3120CC4 for ; Tue, 17 Dec 2019 11:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv7h2gKkxVlu for ; Tue, 17 Dec 2019 11:13:09 -0800 (PST) Received: from alkaline-solutions.com (unknown [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id CD0161208CC for ; Tue, 17 Dec 2019 11:12:58 -0800 (PST) Received: from [IPv6:2601:282:202:b210:b092:f754:6264:326] (unknown [IPv6:2601:282:202:b210:b092:f754:6264:326]) by alkaline-solutions.com (Postfix) with ESMTPSA id 655013155C; Tue, 17 Dec 2019 19:14:02 +0000 (UTC) From: David Waite Message-Id: <97BDE284-1A1C-4299-8847-289F555D9FF7@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_ED056612-4118-4ED4-BD21-BA7BA3B6AE0D" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Tue, 17 Dec 2019 12:12:57 -0700 In-Reply-To: Cc: oauth To: Rifaat Shekh-Yusef References: X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 19:13:11 -0000 --Apple-Mail=_ED056612-4118-4ED4-BD21-BA7BA3B6AE0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support the adoption of PAR > On Dec 17, 2019, at 5:59 AM, Rifaat Shekh-Yusef = wrote: >=20 > All, >=20 > This is a call for adoption of for the OAuth 2.0 Pushed Authorization = Requests document. > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ = =20 >=20 > There was a good support for this document during the Singapore = meeting, and on the mailing list in the Meeting Minutes thread. >=20 > Please, let us know if you support or object to adopting this document = as a working group document by Dec 27th. >=20 > If you have already indicated your support on the Meeting Minutes = thread, you do not need to do it again on this thread. >=20 > Regards, > Rifaat & Hannes >=20 >=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_ED056612-4118-4ED4-BD21-BA7BA3B6AE0D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = support the adoption of PAR

= --Apple-Mail=_ED056612-4118-4ED4-BD21-BA7BA3B6AE0D-- From nobody Tue Dec 17 11:15:23 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E22120CD2 for ; Tue, 17 Dec 2019 11:15:20 -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 5byxOeLfS4ih for ; Tue, 17 Dec 2019 11:15:17 -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 04970120D23 for ; Tue, 17 Dec 2019 11:15:13 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id y19so7759135lfl.9 for ; Tue, 17 Dec 2019 11:15:12 -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=oes0KyOOCBsnA3v/04YkBr14rrCqLVdPQ342mLkf+P0=; b=IfghV8IY8dS5lNcz785ar64VtCUGKsL7Uc8BhxoqR1AQe48ucOYbRuq38Sl+oZJIhJ VA2fgbSLg7mYH/6e+yltmIFFzr82mnbBSVCtjy4byvz9nIVJerpKborIxGDGrCQUMJpS eGf4w3cSJrHJ5hJN+aVFgHAFPGiDC0d6GHeBq2mlmwKKhbiSpvuZL79Pk4amrSVa+GCF NrFdkVppjAFw7e18I5G79A5qUiJpJOlyiYUenWxMpDN36wTh78DBwaBqSOPiRS+kRzFo 6lQIjZUkNvKlKE+MUSDJO/APbIbjl2X+MkTQUWt4gBkIX8wqfsma748iQ4MrHIcY7chW n9Eg== 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=oes0KyOOCBsnA3v/04YkBr14rrCqLVdPQ342mLkf+P0=; b=MFQ7CNS15hQj4dYItRpnDE19pA0aT0WGT/bWe0pFMVMEMlFIDPv6iwzJX6QIFji6eW +ABq4gBCnmuY0vF7AV5Q2kNB1zJ8VISO1XmaN9t6P4GELmq1/zy5xlsvFTpK/Umw57aP cKg0KkBG4hEYh9qPgxZMkmQCpkUh7n0dr1w7g7/B8Gs6mUbW31gcViu9AWn4cs4873PJ /HToMz2+zYd6V2YMZQ+Ws0D4HAy0PBZuAyObNipyhuL6rGk9vdbsFrUCGCfXcNrR8Wka 7rm+5TJe4PUIoQqG2wVlDUH58wejvcHPvI13LwneCGA0DnkGRwV5A+9QrsdZ0lc2JlA6 JLnw== X-Gm-Message-State: APjAAAWClF8DvWKfH/0WzinjytwimVMuRwWDbA7ugpU6BcVIUrzNPUNM 4oNOhL+nUcWPpef1oZa+P/D3lPG4H5iotoA4sow= X-Google-Smtp-Source: APXvYqySfQDvsWut3p1iG3WodrAnV9JQHb8GeU2+BzIqZCUadWWb26AjWj5r/xBiwiwX7pBnaydh4hmYLZjmiMW0lRU= X-Received: by 2002:ac2:5337:: with SMTP id f23mr3658068lfh.192.1576610109280; Tue, 17 Dec 2019 11:15:09 -0800 (PST) MIME-Version: 1.0 References: <97BDE284-1A1C-4299-8847-289F555D9FF7@alkaline-solutions.com> In-Reply-To: <97BDE284-1A1C-4299-8847-289F555D9FF7@alkaline-solutions.com> From: Dick Hardt Date: Tue, 17 Dec 2019 11:14:58 -0800 Message-ID: To: David Waite Cc: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="00000000000083595e0599eb2542" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 19:15:20 -0000 --00000000000083595e0599eb2542 Content-Type: text/plain; charset="UTF-8" +1 On Tue, Dec 17, 2019 at 11:13 AM David Waite wrote: > I support the adoption of PAR > > On Dec 17, 2019, at 5:59 AM, Rifaat Shekh-Yusef > wrote: > > All, > > This is a call for adoption of for the OAuth 2.0 Pushed Authorization > Requests document. > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ > > There was a good support for this document during the Singapore meeting, > and on the mailing list in the Meeting Minutes thread. > > Please, let us know if you support or object to adopting this document as > a working group document by Dec 27th. > > If you have already indicated your support on the Meeting Minutes thread, > you do not need to do it again on this thread. > > Regards, > Rifaat & Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000083595e0599eb2542 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Tue, Dec 17, 2019 at 11:13 AM David Waite <david@alkaline-solutions.com> wrote:
I support the adoption of PAR


All,
This is a call for adoption of for the=C2=A0OAuth 2.0 Pushe= d Authorization Requests document.

There was a good support for this document during the Singapore me= eting, and on the mailing list in the Meeting Minutes thread.
Please, let us know if you support or object to adopting this d= ocument as a working group document by Dec 27th.

I= f you have already indicated your support on the Meeting Minutes thread, yo= u do not need to do it again on this thread.

Regar= ds,
=C2=A0Rifaat & Hannes


=
=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000083595e0599eb2542-- From nobody Tue Dec 17 11:37:56 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF87120891 for ; Tue, 17 Dec 2019 11:37:54 -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, 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=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk-r4hF_ozOA for ; Tue, 17 Dec 2019 11:37:52 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7A60120874 for ; Tue, 17 Dec 2019 11:37:30 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id b10so12357865iof.11 for ; Tue, 17 Dec 2019 11:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8874y8Dlvs7Ey4k+qn3PbJ2hXhicJE9WUeXnS01Ltzo=; b=MbjwdJj2yqqZyTMryK+4Gw3bkc1JQmNIBBiL3uv41Es1nFwWaR6maET9UMfbquiHPz 8SsE6b+OSOUqU2krViFEa9etETev5m8PkRAKrPptjPXQalwqEXKGh2TjxqDngKoGEkPl f/wd2yLy7fdniTeN0ER/911cvORZEBMwxJqp+kV52Hkkebhn4JPvqmL02NTenKTlrSNl 5y9MS0/EQEcsFunwrpY6yIS96r+SuZYW+lvYT4SmZ4WQ8E3aerQ+tJka7Q/bTdrbkrKd GaVn+KwlSKiijHG/obC87j9QXiJUakqajgOCUhFPCE9j2Dslbc/FDErvVJAljYWmdvtL oCEw== 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=8874y8Dlvs7Ey4k+qn3PbJ2hXhicJE9WUeXnS01Ltzo=; b=q4fwLSP55gW1G1leKpyi/eeTMBhEuM4urzzlIdHsnvKwandMuuzYYFUsL4cigFAznm 0yJw+TAme6kBOrSdKEX0ukZsIl0v1XjaV/YndUf/5ReTsDdqSolldEcMwXh5Ekd4fiGt tw/NirQkdug6utFkqaUqL+o0dpbhG+i/L73ZdEvNfs5XHAsK7e8d2K5BBoNYdYiTqNcs UmWP3mGICJswRErBLBX/HDkoF09hoYdY1xC4jf96WzU2zAgOvbzILHiG5DyDmqlKIZJM edSDSkUEDqKwpUQguv0h0TOZsPpHnZC4+9zFPx8vau+Gfuqpojd2PqdZOLGqljVolfuY VeXA== X-Gm-Message-State: APjAAAUes/fsuLSAPEu7n+yH2Jp1KwSR1/BdWj4AoPkIt4pv7Uv8xzfI wlYAJLENraTfrl29RXXLmTYwVMH7/1q1W41UPsENlA== X-Google-Smtp-Source: APXvYqxo52jW7UUU8UJW6EOdnhTtElS/+PZH0FPpax7DLiRbMDasmONoMH5Rp7T+hg2TIlSiAue2iJRBNnvM96fe6QI= X-Received: by 2002:a5d:8a1a:: with SMTP id w26mr415625iod.277.1576611449054; Tue, 17 Dec 2019 11:37:29 -0800 (PST) MIME-Version: 1.0 References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> <1A9A1162-E392-47C3-BC41-7DCDC1913A84@lodderstedt.net> In-Reply-To: <1A9A1162-E392-47C3-BC41-7DCDC1913A84@lodderstedt.net> From: Vittorio Bertocci Date: Tue, 17 Dec 2019 11:37:18 -0800 Message-ID: To: Torsten Lodderstedt Cc: "Richard Backman, Annabelle" , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000005ebe260599eb7529" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 19:37:55 -0000 --0000000000005ebe260599eb7529 Content-Type: text/plain; charset="UTF-8" Hi Torsten! > > just to make sure I understood correctly. Are you saying the client has > credentials but is not authenticated using those in all potential > scenarios? Can you pls. explain the rationale? Yes, that's the scenario. In Azure AD you create an app registration that generates a clientID you can then use for web apps (confidential), native clients (public) and the like. I believe you can do the same in google if you create a clientID using "other" as app type, but I am not sure. I am not 100% certain about the rationale, but I suspect it could be a way of say optimizing consent (if I consent for scope X for the iOS version of app1, I will not be prompted again when I access the web version of app1), provisioning across tenants or grouping app policy options. Even before that multi-type app registration option was introduced, AD has ways of making confidential cleitns behave like public ones: web apps that do have credentials, but whose clientID can be used in implicit hence getting tokens without using app credentials. Whether that's a good idea or not, the features have been there for a while and there are large numbers of apps in the wild alowing for this. Let me stress that I consider this area a nice to have and I am happy to drop it if it's too problematic (in fact it's not in the current spec language). On Mon, Dec 16, 2019 at 11:28 PM Torsten Lodderstedt wrote: > Hi Vittorio, > > > On 17. Dec 2019, at 05:19, Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > > > In the cases I have seen, the idea is that a client (whose clientID is > already known to the RS) can obtain tokens thru different grants, some of > them confidential and others public; > > just to make sure I understood correctly. Are you saying the client has > credentials but is not authenticated using those in all potential > scenarios? Can you pls. explain the rationale? > > best, > Torsten. > > --0000000000005ebe260599eb7529 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Torsten!
just to make sure I understood correctly. Are you saying the client has = credentials but is not authenticated using those in all potential scenarios= ? Can you pls. explain the rationale?=C2=A0=C2=A0

Yes, that's the scenario. In Azure AD you create an app registra= tion that generates a clientID you can then use for web apps (confidential)= , native clients (public) and the like. I believe you can do the same in go= ogle if you create a clientID using "other" as app type, but I am= not sure. I am not 100% certain about the rationale, but I suspect it coul= d be a way of say optimizing consent (if I consent for scope X for the iOS = version of app1, I will not be prompted again when I access the web version= of app1), provisioning across tenants or grouping app policy options.
Even before that multi-type app registration option was introduced, A= D has ways of making confidential cleitns behave like public ones: web apps= that do have credentials, but whose clientID can be used in implicit=C2=A0= hence getting tokens without using app credentials.
Whether that&= #39;s a good idea or not, the features have been there for a while and ther= e are large numbers of apps in the wild alowing for this. Let me stress tha= t I consider this area a nice to have and I am happy to drop it if it's= too problematic (in fact it's not in the current spec language).
=


On Mon, Dec 16, 2019 at 11:28 PM Torsten Lodderstedt <to= rsten=3D40lodderstedt.n= et@dmarc.ietf.org> wrote:
Hi Vittorio,

> On 17. Dec 2019, at 05:19, Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.iet= f.org> wrote:
>
> In the cases I have seen, the idea is that a client (whose clientID is= already known to the RS) can obtain tokens thru different grants, some of = them confidential and others public;

just to make sure I understood correctly. Are you saying the client has cre= dentials but is not authenticated using those in all potential scenarios? C= an you pls. explain the rationale?

best,
Torsten.

--0000000000005ebe260599eb7529-- From nobody Tue Dec 17 11:39:33 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CFF12086E; Tue, 17 Dec 2019 11:39:29 -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=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 ev0CWq3ceT2x; Tue, 17 Dec 2019 11:39:23 -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 1020E120125; Tue, 17 Dec 2019 11:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1576611563; x=1608147563; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UH7iaG7RW2hOYyxAvq2wLnBIvT0RZEUd93zIaU/Sx+A=; b=iSgsxgBl9/EMQZVJbmytnAUv8NYywA4d/oY5sghMNfIrCretNXbVvIUt DZtI/bdEAj6MwUlP/U6R0UkcM7IDSXQLtscSiGBPU/swLr59/ZnNeP/A3 C/i+8f7hQNi964k5vg0GO1RCa0nBfPcs5NQnQh1uEtdQKD+Q2k/bfOmVy 8=; IronPort-SDR: CuM1dTRSg5FR2tKqqy0pddRb2TnEE7PHI6M48ujwvv1R5ZLzxsQzsxqwe9MKnpS5NPSe8u2ar5 CDtF+WfL8o6w== X-IronPort-AV: E=Sophos; i="5.69,326,1571702400"; d="scan'208,217"; a="15468585" 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-33001.sea14.amazon.com with ESMTP; 17 Dec 2019 19:39:12 +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 42F97A2788; Tue, 17 Dec 2019 19:39:09 +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, 17 Dec 2019 19:39:09 +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, 17 Dec 2019 19:39:09 +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, 17 Dec 2019 19:39:09 +0000 From: "Richard Backman, Annabelle" To: Vittorio Bertocci CC: IETF oauth WG , Vittorio Bertocci , "i-d-announce@ietf.org" Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt Thread-Index: AQHVtGMkx0ZM11MJ9UuFnmHDKBqGmae9XaMA///YXwCAAIOagIAABHuAgAConoA= Date: Tue, 17 Dec 2019 19:39:09 +0000 Message-ID: <2518B18A-AD93-44E4-88D1-E5F6AAE7B1BB@amazon.com> References: <157653653318.24509.15075582637514649078@ietfa.amsl.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.205] Content-Type: multipart/alternative; boundary="_000_2518B18AAD9344E488D1E5F6AAE7B1BBamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 19:39:30 -0000 --_000_2518B18AAD9344E488D1E5F6AAE7B1BBamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJbiBhbnkgY2FzZSB0aGUgaW50ZW50IHdhcyBhbHdheXMgdG8gb25seSBhbGxvdyBhIHNpbmdl IHJlc291cmNlIHBlciBBVOKApg0KDQpNeSBjb25mdXNpb24gYWN0dWFsbHkgY29tZXMgZnJvbSB0 aGUgbGFzdCBwYXJhZ3JhcGggb2YgwqczLCB3aGVyZSBpdCBzYXlzIOKAnElmIGEgc2NvcGUgcGFy YW1ldGVyIGlzIHByZXNlbnQgaW4gdGhlIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBTSE9VTEQgdXNlIGl0IHRvIGluZmVyIHRoZSB2YWx1ZSBvZiB0aGUgZGVmYXVsdCByZXNvdXJj ZSBpbmRpY2F0b3IgdG8gYmUgdXNlZCBpbiB0aGUgYXVkIGNsYWltLuKAnSBJIGludGVycHJldGVk IHRoYXQgdG8gbGVhdmUgcm9vbSBmb3IgYW4gQVMgaW5mZXJyaW5nIHRoZSBzYW1lIOKAnGdlbmVy aWPigJ0gcmVzb3VyY2UgaW5kaWNhdG9yIGZvciByZXNvdXJjZXMgc2VydmVkIGJ5IGRpZmZlcmVu dCBSU2VzLiBUaGUgb25lLVJTLXBlci1BVCBtb2RlbCBpcyBhbiBpZGVhbCB0aGF0IHNpbXBseSBk b2VzbuKAmXQgbWF0Y2ggcmVhbGl0eS4gQ2xpZW50cyBkb27igJl0IHdhbnQgdG8gaGF2ZSB0byBq dWdnbGUgYSBidW5jaCBvZiBkaWZmZXJlbnQgdG9rZW5zLCBub3Igc2hvdWxkIHRoZXkgbmVlZCB0 by4gSeKAmW0gY29taW5nIHRvIHRoaW5rIHRoYXQgd2Ugc2hvdWxkbuKAmXQgYWN0dWFsbHkgdXNl IGBhdWRgIGFuZCBgc2NvcGVgIGluIEpXVCBBVHMgYXQgYWxsLCBhbmQgaW5zdGVhZCBhZG9wdCB0 aGUgc3RydWN0dXJlIFJBUiBkZWZpbmVzIHVzZWQgZm9yIHRoZSBgYXV0aG9yaXphdGlvbl9kZXRh aWxzYCBwYXJhbWV0ZXIgKEkgdGhpbmsgc29tZSBpdGVyYXRpb24gaXMgcmVxdWlyZWQsIGJ1dCBp dCBzZWVtcyBuYXR1cmFsIGZvciB0aGVzZSB0d28gdG8gZGVzY3JpYmUgYXV0aG9yaXphdGlvbnMg aW4gdGhlIHNhbWUgb3IgY29tcGF0aWJsZSB3YXlzKS4NCg0KDQo+IOKApnRoZSByZXNvdXJjZSB3 YW50cyB0byBrbm93IHdoZXRoZXIgdGhpcyBwYXJ0aWN1bGFyIHRva2VuIHdhcyBvYnRhaW5lZCBw cm92aW5nIHRoZSBpZGVudGl0eSBvZiB0aGUgY2xpZW504oCmDQoNCknigJltIHNrZXB0aWNhbCBv ZiB0aGUgaWRlYSB0aGF0IHRoZXJlIGlzIGp1c3Qgb25lIGxldmVsIG9mIGNsaWVudCBpZGVudGl0 eSBwcm9vZmluZyB0aGF0IFJTZXMgbWlnaHQgY2FyZSBhYm91dC4gVGhlcmUgbWlnaHQgYmUgc29t ZSBjbGVhciBsaW5lcyB0aGF0IGNhbiBiZSBkcmF3biwgYnV0IHdlIHNob3VsZCBiZSBleHBsaWNp dCBhYm91dCB3aGF0IHRob3NlIGxpbmVzIHJlcHJlc2VudCwgZS5nLiwg4oCcY2xpZW50IGF1dGhl bnRpY2F0ZWQgdXNpbmcgcHJlLWVzdGFibGlzaGVkIGNyZWRlbnRpYWzigJ0sIOKAnGNsaWVudCBp cyBydW5uaW5nIG9uIGVuZCB1c2VyLWNvbnRyb2xsZWQgZGV2aWNl4oCdLCBldGMuDQoNCg0KPiBJ IGFtIG5vdCB0cnlpbmcgdG8gY3JlYXRlIGEgY29tcGxldGUgZnJhbWV3b3JrIGZvciBoYW5kbGlu ZyBzdGVwIHVwIGFuZCB0aGUgbGlrZSwgSSBhbSB0cnlpbmcgdG8gY3JlYXRlIGFuIGludGVyb3Bl cmFibGUgcmVwcmVzZW50YXRpb24gb2YgdGhvc2UgdmFsdWVzIG5vIG1hdHRlciBob3cgdGhleSB3 ZXJlIG9idGFpbmVkLg0KDQpXaXRob3V0IHRha2luZyB0aGUgd2hvbGUgcGljdHVyZSBpbnRvIGFj Y291bnQsIHRoZXJlIGlzIHNpZ25pZmljYW50IHJpc2sgdGhhdCB3ZSB3aWxsIGRlZmluZSBzb21l dGhpbmcgdGhhdCB0dXJucyBvdXQgdG8gYmUgd29lZnVsbHkgaW5zdWZmaWNpZW50IChvciB3b3Jz ZSwgZXN0YWJsaXNoZXMgYW4gYW50aS1wYXR0ZXJuKS4gVGhhdCBzYWlkLCBJIGFncmVlIHRoYXQg aXTigJlzIHByb2JhYmx5IG5vdCBhcHByb3ByaWF0ZSBmb3IgdGhpcyBkcmFmdCwgYW5kIHJlY29t bWVuZCBkcm9wcGluZyB0aGVzZSBjbGFpbXMuIFRoZXkgY2FuIGFsd2F5cyBiZSBkZWZpbmVkIGlu IGEgc2VwYXJhdGUgZHJhZnQsIGFsb25nIHdpdGggdGhlIG90aGVyIGVsZW1lbnRzIG5lY2Vzc2Fy eSB0byBjb21tdW5pY2F0ZSBzdGVwLXVwIHJlcXVpcmVtZW50cy4NCg0K4oCTDQpBbm5hYmVsbGUg UmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBWaXR0b3JpbyBCZXJ0b2Nj aSA8Vml0dG9yaW89NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBNb25kYXksIERl Y2VtYmVyIDE2LCAyMDE5IGF0IDk6MzEgUE0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPg0KQ2M6IElFVEYgb2F1dGggV0cgPG9hdXRoQGlldGYu b3JnPiwgVml0dG9yaW8gQmVydG9jY2kgPFZpdHRvcmlvQGF1dGgwLmNvbT4sICJpLWQtYW5ub3Vu Y2VAaWV0Zi5vcmciIDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVU5WRVJJRklF RCBTRU5ERVJdIFJlOiBbT0FVVEgtV0ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb2F1dGgtYWNj ZXNzLXRva2VuLWp3dC0wMy50eHQNCg0KUmU6IGFsaWFzZXMsIEkgc2VlIHdoZXJlIHRoZSBjb25m dXNpb24gaXMgY29taW5nIGZyb20hDQpJIHVwZGF0ZWQgdGhlIHJlcXVlc3Qgc2VjdGlvbiwgYnV0 IHRoZSBzZXNzaW9uIDIuMiBkYXRhIHN0cnVjdHVyZSBzdGlsbCBtZW50aW9ucyB0aGUgYWxpYXNl cy4gVGhhdCBzaG91bGQgYmUgY2xlYW5lZCB1cCBhcyB3ZWxsLg0KSW4gYW55IGNhc2UgdGhlIGlu dGVudCB3YXMgYWx3YXlzIHRvIG9ubHkgYWxsb3cgYSBzaW5nZSByZXNvdXJjZSBwZXIgQVQsIHRo ZSBhbGlhcyBsaXN0IHdhcyBvbmx5IGZvciBoZWxwaW5nIGluIGNhc2VzIHdoZXJlIGFuIEFTIGlk ZW50aWZpZXMgdGhlIHNhbWUgcmVzb3VyY2UgdGhydSBtdWx0aXBsZSBJRHMgYW5kIHRoZSBhY3R1 YWwgYXVkIHZhbHVlIGRlcGVuZHMgb24gd2hhdCBJRCB0aGUgY2xpZW50IHJlcXVlc3RlZC4gSG93 ZXZlciB3ZSBkaXNjdXNzZWQgdGhpcyB3aXRoIEJyaWFuIGFuZCBoZSBjb252aW5jZWQgbWUgdGhh dCBpdCB3YXMganVzdCB0b28gYW1iaWd1b3VzLSB5b3VyIHJlbWFyayByZWluZm9yY2VzIHRoYXQg aW1wcmVzc2lvbi4gSeKAmWxsIGNsZWFuIHVwIDIuMiBhbmQgZWxpbWluYXRlIHJlZmVyZW5jZXMg dG8gYWxpYXNlcyBmcm9tIHRoZXJlIGFzIHdlbGwuDQpUaGFua3MhDQoNCg0KT24gTW9uLCBEZWMg MTYsIDIwMTkgYXQgMjA6MTkgVml0dG9yaW8gQmVydG9jY2kgPFZpdHRvcmlvQGF1dGgwLmNvbTxt YWlsdG86Vml0dG9yaW9AYXV0aDAuY29tPj4gd3JvdGU6DQpUaGFua3MgQW5uYWJlbGxlLg0KDQpE b2VzIGEgbW9iaWxlIGFwcCB0aGF0IHVzZXMgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIHRv IGVzdGFibGlzaCBhIGNsaWVudCBzZWNyZXQgY291bnQgYXMgYW4g4oCcYXV0aGVudGljYXRlZCBj bGllbnTigJ0/DQpJIHRoaW5rIGl0IHNob3VsZCBjb3VudCwgdGhvIEkgYW0gbm90IHN1cmUgd2hh dCB0aGUgUlMgd291bGQgZG8gd2l0aCBpdC4gRHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIHdv dWxkIGxpa2VseSBub3QgaGF2ZSBtdWNoIHVzZSBmb3IgdGhpcy4NCkluIHRoZSBjYXNlcyBJIGhh dmUgc2VlbiwgdGhlIGlkZWEgaXMgdGhhdCBhIGNsaWVudCAod2hvc2UgY2xpZW50SUQgaXMgYWxy ZWFkeSBrbm93biB0byB0aGUgUlMpIGNhbiBvYnRhaW4gdG9rZW5zIHRocnUgZGlmZmVyZW50IGdy YW50cywgc29tZSBvZiB0aGVtIGNvbmZpZGVudGlhbCBhbmQgb3RoZXJzIHB1YmxpYzsgYW5kIHRo ZSByZXNvdXJjZSB3YW50cyB0byBrbm93IHdoZXRoZXIgdGhpcyBwYXJ0aWN1bGFyIHRva2VuIHdh cyBvYnRhaW5lZCBwcm92aW5nIHRoZSBpZGVudGl0eSBvZiB0aGUgY2xpZW50IHNvIHRoYXQgaXQg Y2FuIGRlY2lkZSB3aGV0aGVyIHRvIGdyYW50IGV4dHJhIHByaXZpbGVnZXMgZm9yIHRoYXQgcGFy dGljdWxhciBjbGllbnQgaW4gdGhlIGN1cnJlbnQgY2FsbC4gVGhpcyBzY2VuYXJpbyBkb2VzIG5v dCByZXF1aXJlIHRoZSBleHRyYSBkZXRhaWxzIGFib3V0IGF1dGhlbnRpY2F0aW9uIG1ldGhvZC9z dHJlbmd0aCB5b3UgbWVudGlvbiB0aGF0LCBJIGFncmVlLCB3b3VsZCBiZSBwcmV0dHkgaGFyZCB0 byByZWFjaCBjb25zZW5zdXMgb24uDQpUTDtEUjogdGhlcmUgaXMgYXQgbGVhc3Qgb25lIHNjZW5h cmlvIHRoYXQgaXMgc2F0aXNmaWVkIGJ5IHRoZSBzaW1wbGUgYm9vbCwgYXMgdGhlIHByZXZpb3Vz IGtub3dsZWRnZSBvZiB0aGUgY2xpZW50IHNvbHZlcyB0aGUgaXNzdWVzIHlvdSBtZW50aW9uIG91 dCBvZiBiYW5kLg0KDQphdXRoZW50aWNhdGlvbiBzZXNzaW9uIHByb3BlcnRpZXM6DQogTGV0IG1l IHRyeSBhbm90aGVyIGFuZ2xlLiBTYXkgdGhhdCBJIHBlcmZvcm0gYW4gYXV0aHogY29kZSBncmFu dCBhc2tpbmcgZm9yIEFULCBJRF9UIGFuZCBSVC0gb2J0YWluaW5nIEFUJywgSURfVCcgYW5kIFJU Jy4NClRoZSB2YWx1ZXMgb2YgYXV0aF90aW1lLCBhY3IgYW5kIGFtciBpbiBBVCcgd2lsbCBiZSB0 aGUgc2FtZSBhcyB0aGUgY29ycmVzcG9uZGluZyBjbGFpbXMgaW4gSURfVCcuIFdoZW4gdGhlIGNs aWVudCB1c2VzIFJUJyB0byBvYnRhaW4gQVRgTiwgQVQnTisxIGV0YyBldGMsIHRoZSB2YWx1ZXMg b2YgdGhvc2UgY2xhaW1zIHdpbGwgcmVtYWluIHRoZSBzYW1lIGZvciBldmVyeSBBVCduIG9idGFp bmVkIGJ5IFJUJy4NCk5vdywgaW1hZ2luZSB0aGF0IHNvbWV0aGluZyBoYXBwZW5zIChpZ25vcmUg d2hhdCBmb3IgdGhlIHRpbWUgYmVpbmcpIHRoYXQgY2F1c2VzIHRoZSBjbGllbnQgdG8gcGVyZm9y bSBhIHN0ZXAgdXAgYXV0aCwgd2hpY2ggcmVxdWlyZXMgdGhlIHVzZXIgdG8gcGVyZm9ybSBpbnRl cmFjdGl2ZSBhdXRoIGhlbmNlIHJlc3VsdHMgaW4gYSBuZXcgYXV0aHogZ3JhbnQuIFRoZSBjbGll bnQgd2lsbCBvYnRhaW4gYSBuZXcgdHVwbGUgIEFUIiwgSURfVCIgYW5kIFJUIi4gVGhlIGV4YWN0 IHNhbWUgcnVsZXMgZGVzY3JpYmVkIGZvciB0aGUgJyB0dXBsZSBhcHBseSwgd2l0aCB0aGUgbmV3 IHZhbHVlcyBkZXRlcm1pbmVkIGJ5IHRoZSBuZXcgYXV0aGVudGljYXRpb246IEFUIiBhdXRoX3Rp bWUvYWNyL2FtciB3aWxsIGJlIHRoZSBzYW1lIGFzIElEX1QiLCBhbmQgdGhvc2UgdmFsdWVzIHdp bGwgcmVtYWluIHVuY2hhbmdlZCBmb3IgZXZlcnkgQVQibiBkZXJpdmVkIGJ5IFJUIi4NCklmIHdl IHdhbnQgdGhpcyB0byBhcHBseSB0byB0aGUgaW1wbGljaXQgZmxvdyBhcyB3ZWxsLCB5b3UgY2Fu IHN1YnN0aXR1dGUgdGhlIFJUIHdpdGggdGhlIHNlc3Npb24gYXJ0aWZhY3QuDQpEb2VzIHRoYXQg aGVscCBjbGFyaWZ5aW5nIHRoZSBpbnRlbnQ/IElmIHllcywgZG8geW91IGZlZWwgdGhhdCB0aGUg Y3VycmVudCBsYW5ndWFnZSBkb2VzIG5vdCBkZXNjcmliZSB0aGlzPw0KDQp1c2UgY2FzZSBmb3Ig cHV0dGluZyB0aGVzZSBpbiB0aGUgYWNjZXNzIHRva2VuDQpJIGFtIG5vdCB0cnlpbmcgdG8gY3Jl YXRlIGEgY29tcGxldGUgZnJhbWV3b3JrIGZvciBoYW5kbGluZyBzdGVwIHVwIGFuZCB0aGUgbGlr ZSwgSSBhbSB0cnlpbmcgdG8gY3JlYXRlIGFuIGludGVyb3BlcmFibGUgcmVwcmVzZW50YXRpb24g b2YgdGhvc2UgdmFsdWVzIG5vIG1hdHRlciBob3cgdGhleSB3ZXJlIG9idGFpbmVkLg0KQ29uc2lk ZXIgdGhlIGNhc2UgaW4gd2hpY2ggYW4gQVBJIGFsbG93cyBjZXJ0YWluIG9wZXJhdGlvbnMgb25s eSBpZiBhIGdpdmVuIGFtciB2YWx1ZSBpcyBwcmVzZW50IGluIHRoZSB0b2tlbi4gV2hldGhlciB0 aGF0IGFtciBpcyByZXF1aXJlZCB1cGZyb250IG9uIGZpcnN0IGF1dGhlbnRpY2F0aW9uLCBhcyBz dGVwIHVwIG9yIGFueSBvdGhlciByZWFzb24gaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIHByb2Zp bGUgSU1POiB0aGUgQVMgbWlnaHQgaGF2ZSBhbGwgc29ydHMgb2YgaGV1cmlzdGljcyB0aGF0IGRl dGVybWluZSB0aGF0ICh1c2VyIG1lbWJlcnNoaXAgdG8gYSBnaXZlbiBncm91cCBvciByb2xlOyBn ZW9mZW5jaW5nOyByaXNrIHNjb3Jpbmc7IGV0YykgdGhhdCBoYXZlIG5vdGhpbmcgdG8gZG8gd2l0 aCBzY29wZXMgcmVxdWVzdGVkLCBhbmQgYXJlIG5vdCBzdGF0aWNhbGx5IGRldGVybWluZWQgYnkg UlMtQVMgY29tbXVuaWNhdGlvbnMuDQpOb3csIEkgYWdyZWUgdGhhdCBmb3JtYWxpemluZyBob3cg YSBSUyBjb21tdW5pY2F0ZXMgdG8gdGhlIEFTIHZpYSB0aGUgY2xpZW50IHRoZSBuZWVkIHRvIHN0 ZXAgdXAgYW5kIGluIHdoYXQgdGVybXMgd291bGQgYmUgc3VwZXIgdXNlZnVsOyBob3dldmVyIEkg dGhpbmsgdGhhdCdzIHdlbGwgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHByb2ZpbGUuLiBWYXJp b3VzIHZlbmRvcnMgYWxyZWFkeSBoYXZlIHRoZWlyIG93biBtZWNoYW5pc21zIGZvciBoYW5kbGlu ZyBzdGVwIHVwIHNpZ25hbGluZyBmcm9tIFJTIHRvIEFTIChJIGFtIHZlcnkgZmFtaWxpYXIgd2l0 aCB0aGUgTWljcm9zb2Z0IG9uZSkgYW5kIGFsbCBJIGFtIGxvb2tpbmcgZm9yIGlzIGEgd2F5IG9m IHN0YW5kYXJkaXppbmcgaG93IHRvIHJlcHJlc2VudCB0aGUgb3V0Y29tZXMsIHNvIHRoYXQgQVBJ IGdhdGV3YXlzIGFuZCBTREsgcHJvdmlkZXJzIGNhbiBwcm92aWRlIHRvb2xzIHRoYXQgd29yayBh Y3Jvc3MgdmVuZG9yczsgYW5kIHBvc3NpYmx5IHJldXNlIHNvbWUgb2YgdGhlIHJlYXNvbmluZyB0 aGF0IHdhcyBhbHJlYWR5IGRvbmUgZm9yIGlkX3Rva2Vucy4NClRMO0RSOiBJIHRoaW5rIHdlIGFy ZSBkb2luZyBzb21ldGhpbmcgdXNlZnVsIGluIGZvcm1hbGl6aW5nIGhvdyB0byBlbWJlZCB0aGF0 IGluZm8gYW4gQVRzIGV2ZW4gaWYgd2UgZG9uJ3QgZm9yY2UgdmVuZG9ycyB0byBnaXZlIHVwIHRo ZWlyIGN1cnJlbnQgbWVjaGFuaXNtcyB0byBwb3B1bGF0ZSB0aG9zZSB2YWx1ZXMuDQoNClJlZ2Fy ZGluZyBhY2Nlc3MgdG9rZW5zIHRoYXQgYXJlIHVzZWQgdG8gYWNjZXNzIGRpZmZlcmVudCByZXNv dXJjZSBzZXJ2ZXJzDQpUaGUgaW50ZW50IGlzIHRvIGV4cGxpY2l0bHkgZGlzYWxsb3cgdGhlIHVz ZSBvZiBhbiBBVCB3aXRoIG11bHRpcGxlIHJlc291cmNlIHNlcnZlcnMuIElmIGEgY2xpZW50IHdh bnRzIHRvIHRhbGsgd2l0aCAyIGRpZmZlcmVudCBSU2VzLCB0aGUgY2xpZW50IHNob3VsZCBhc2sg Zm9yIDIgZGlmZmVyZW50IEFUcy4NClRoZSBzcGVjIGlzIHVuYW1iaWd1b3VzIG9uIHRoaXMgSU1P LCBoZXJlJ3MgdGhlIGxhbmd1YWdlIEkgdXNlIGluIDAzLg0KDQoNCklmIGl0IHJlY2VpdmVzIGEg cmVxdWVzdCBmb3IgYW4gYWNjZXNzIHRva2VuIGNvbnRhaW5pbmcgbW9yZSB0aGFuIG9uZQ0KDQog ICByZXNvdXJjZSBwYXJhbWV0ZXIsIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VpbmcgSldU IGFjY2VzcyB0b2tlbnMNCg0KICAgTVVTVCByZWplY3QgdGhlIHJlcXVlc3QgYW5kIGZhaWwgd2l0 aCAiaW52YWxpZF9yZXF1ZXN0IiBhcyBkZXNjcmliZWQNCg0KICAgaW4gc2VjdGlvbiA0LjEuMi4x IG9mIFtSRkM2NzQ5XTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzY3 NDkjc2VjdGlvbi00LjEuMi4xPiBvciB3aXRoICJpbnZhbGlkX3RhcmdldCIgYXMgZGVmaW5lZA0K DQogICBpbiBzZWN0aW9uIDIgb2YgW1Jlc291cmNlSW5kaWNhdG9yczxodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0w MyNyZWYtUmVzb3VyY2VJbmRpY2F0b3JzPl0uICBTZWUgU2VjdGlvbiAyLjI8aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1q d3QtMDMjc2VjdGlvbi0yLjI+IGFuZCBTZWN0aW9uIDU8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMjc2VjdGlv bi01Pg0KDQogICBmb3IgbW9yZSBkZXRhaWxzIG9uIGhvdyB0aGlzIG1lYXN1cmUgZW5zdXJlcyB0 aGVyZSdzIG5vIGNvbmZ1c2lvbiBvbg0KDQogICB0byB3aGF0IHJlc291cmNlIHRoZSBhY2Nlc3Mg dG9rZW4gZ3JhbnRlZCBzY29wZXMgYXBwbHkuDQogIElzIGl0IHBvc3NpYmxlIHlvdSBhcmUgcmVm ZXJyaW5nIHRvIGFuIG9sZGVyIGRyYWZ0Pw0KDQoNCk9uIE1vbiwgRGVjIDE2LCAyMDE5IGF0IDU6 MjggUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBk bWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6 DQoxLiBSZWdhcmRpbmcgQXV0aGVudGljYXRlZENsaWVudDoNCkRvZXMgYSBtb2JpbGUgYXBwIHRo YXQgdXNlcyBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gdG8gZXN0YWJsaXNoIGEgY2xpZW50 IHNlY3JldCBjb3VudCBhcyBhbiDigJxhdXRoZW50aWNhdGVkIGNsaWVudOKAnT8gV2hhdCBpZiB0 aGF0IHJlZ2lzdHJhdGlvbiBpbmNsdWRlZCBhbiBhc3NlcnRpb24gc2lnbmVkIGJ5IGEgdHJ1c3Rl ZCBlbnRpdHkgKGUuZy4sIGRldmljZSBtYW5hZ2VtZW50IHNvZnR3YXJlKSB1c2luZyBhIGNlcnRp ZmljYXRlIHRoYXQgaGFkIGJlZW4gcHVzaGVkIHRvIHRoZSBkZXZpY2U/IFdpdGhvdXQgc29tZSBr aW5kIG9mIE5JU1QgTG9BLXN0eWxlIGRlZmluaXRpb24gb2Yg4oCcYXV0aGVudGljYXRlZOKAnSwg YSBzaW5nbGUgQm9vbGVhbiDigJxBdXRoZW50aWNhdGVkQ2xpZW504oCdIHZhbHVlIGlzIHRvbyBh bWJpZ3VvdXMgdG8gYmUgdXNlZnVsLiBIb3dldmVyLCBJ4oCZbSBza2VwdGljYWwgdGhhdCB3ZSBj b3VsZCBmaW5kIGNvbnNlbnN1cyBvbiB3aGF0IHRoYXQgZGVmaW5pdGlvbiBzaG91bGQgYmUsIGFu ZCBpdCBtYXkgYmUgYmV0dGVyIHRvIGRlZmluZSBjbGllbnQgYW5hbG9ncyB0byBgYWNyYCBhbmQg YGFtcmAgdGhhdCBwcm92aWRlIHN0YW5kYXJkIHdheXMgb2YgZXhwcmVzc2luZyBjbGllbnQgYXV0 aGVudGljYXRpb24gZGV0YWlscyB3aXRob3V0IGdldHRpbmcgcHJlc2NyaXB0aXZlIGFib3V0IHdo YXQga2luZCBvZiBhdXRoZW50aWNhdGlvbiBpcyDigJxnb29kIGVub3VnaC7igJ0NCg0KMi4gUmVn YXJkaW5nIGF1dGhlbnRpY2F0aW9uIHNlc3Npb24gcHJvcGVydGllczoNCknigJltIGNvbmZ1c2Vk IGJ5IHRoZSBkZWZpbml0aW9ucyBnaXZlbiBmb3IgYGF1dGhfdGltZWAsIGBhY3JgLCBhbmQgYGFt cmAuIEZvciBgYXV0aF90aW1lYCwgaXQgc2F5czoNCg0K4oCc4oCmaXRzIHZhbHVlIHdpbGwgZWl0 aGVyIHJlbWFpbiB0aGUgc2FtZSBmb3IgYWxsIHRoZSBKV1QgYWNjZXNzIHRva2VucyBpc3N1ZWQg d2l0aGluIHRoYXQgc2Vzc2lvbiBvciBiZSB1cGRhdGVkIHRvIHRoZSB0aW1lIG9mIGxhdGVzdCBh dXRoZW50aWNhdGlvbiBpZiByZWF1dGhlbnRpY2F0aW9uIG9jY3VycmVkIG1pZC1zZXNzaW9u4oCm 4oCdDQoNCkJ1dCB0aGUg4oCcRm9yIGV4YW1wbGXigJ0gYXQgdGhlIGVuZCBvZiB0aGF0IGRlZmlu aXRpb24gaW1wbGllcyB0aGF0IGBhdXRoX3RpbWVgIHdpbGwgbm90IGJlIHVwZGF0ZWQuIFRoZSBk ZWZpbml0aW9ucyBmb3IgYGFjcmAgYW5kIGBhbXJgIHNheSB0aGUgc2FtZSwgYnV0IGFsc28gc2F5 IHRoYXQgdGhlIOKAnOKApnNhbWUgY29uc2lkZXJhdGlvbnMgcHJlc2VudGVkIGZvciBhdXRoX3Rp bWUgYXBwbHnigKbigJ0gV2hhdOKAmXMgdGhlIGludGVudGlvbiBoZXJlOiBhcmUgdGhleSBmaXhl ZCwgdXBkYXRlZCwgb3IgaXMgaXQgdXAgdG8gdGhlIGRlcGxveW1lbnQgdG8gZGVjaWRlPw0KDQpJ 4oCZZCBsaWtlIHRvIGJldHRlciB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZSBmb3IgcHV0dGluZyB0 aGVzZSBpbiB0aGUgYWNjZXNzIHRva2VuLiBJZiB0aGUgUlMgaXMgbWFraW5nIGF1dGhvcml6YXRp b24gZGVjaXNpb25zIGJhc2VkIG9uIHRoZXNlIGNsYWltcywgdGhhdCBpbXBsaWVzIHRoYXQgdGhl IFJTIGNhbm5vdCByZWx5IG9uIHRoZSBBUyB0byBkZXRlcm1pbmUgKGUuZy4sIGZyb20gdGhlIHJl cXVlc3RlZCBzY29wZSkgdGhlIHJlcXVpcmVkIGF1dGhlbnRpY2F0aW9uIG1ldGhvZChzKSwgZnJl c2huZXNzLCBldGMuIElmIHRoZSBBUyBjb3VsZCBiZSByZWxpZWQgdXBvbiBmb3IgdGhpcywgdGhl biBwcmVzdW1hYmx5IGl0IHdvdWxkIG5vdCBpc3N1ZSBSVHMgYW5kIEFUcyBmb3IgYSBzY29wZSB3 aXRob3V0IHJlcXVpcmluZyB0aGUgZW5kIHVzZXIgdG8gbWVldCB0aGUgYXBwcm9wcmlhdGUgYXV0 aGVudGljYXRpb24gcmVxdWlyZW1lbnRzLiBJZiB0aGlzIGlzIHRoZSBjYXNlLCB0aGVuIHRoZSBS UyBtdXN0IGhhdmUgYSB3YXkgdG8gc2lnbmFsIHRvIHRoZSBjbGllbnQgKGFuZCB0aGVuIHRoZSBB UykgdGhhdCBhIHN0ZXAtdXAgYXV0aGVudGljYXRpb24gaXMgcmVxdWlyZWQuIElzIHRoZXJlIGFu IGV4aXN0aW5nIG1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIHRoZXkgY291bGQgZG8gdGhpcz8gQWxs IEkgY2FuIGNvbWUgdXAgd2l0aCBpcyBjcmFtbWluZyB0aGUgaW5mb3JtYXRpb24gaW50byB0aGUg c2NvcGUgYXR0cmlidXRlIG9mIGEgV1dXLUF1dGhlbnRpY2F0ZSBjaGFsbGVuZ2UsIGJ1dCB0aGF0 IGhhcyB0aGUgc2FtZSBzY29wZSBvcGFjaXR5IHZpb2xhdGlvbiBwcm9ibGVtIGFzIGRlc2NyaWJl ZCBpbiB0aGlzIGRyYWZ04oCZcyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4gV2l0aG91dCBhIGNs ZWFyIHdheSB0byBleHByZXNzIHRoZSBzdGVwLXVwIHJlcXVpcmVtZW50cywgdGhpcyBmZWVscyBp bmNvbXBsZXRlLi4NCg0KMy4gUmVnYXJkaW5nIGFjY2VzcyB0b2tlbnMgdGhhdCBhcmUgdXNlZCB0 byBhY2Nlc3MgZGlmZmVyZW50IHJlc291cmNlIHNlcnZlcnM6DQpSZWFkaW5nIGJldHdlZW4gdGhl IGxpbmVzLCBJICp0aGluayogdGhlIGludGVudGlvbiBpcyB0aGF0IGEgSldUIGFjY2VzcyB0b2tl biB0aGF0IGlzIGludGVuZGVkIHRvIGJlIHVzZWQgdG8gYWNjZXNzIHR3byBkaWZmZXJlbnQgcmVz b3VyY2VzIGF0IHR3byBkaWZmZXJlbnQgUlNlcyBzaG91bGQgbG9vayBzb21ldGhpbmcgbGlrZToN Cg0Kew0KImF1ZCI6ICJodHRwczovL2dlbmVyaWMtcmVzb3VyY2UtaW5kaWNhdG9yLmV4YW1wbGUu Y29tLyIsDQoic2NvcGUiOiAicmVzb3VyY2VfZm9vIHJlc291cmNlX2JhciIsDQouLi4NCn0NCg0K QW5kIHRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IGVhY2ggUlMgc2hvdWxkIHJlY29nbml6ZSB0aGF0 IGdlbmVyaWMgYXVkaWVuY2UuIElzIHRoaXMgY29ycmVjdD8gSWYgc28gaXQgc2VlbXMgdG8gZ28g YWdhaW5zdCB0aGUgc3Bpcml0IG9mIHJlc291cmNlIGluZGljYXRvcnMgYXMgaW5kaWNhdGluZyB0 aGUgdGFyZ2V0IG9yIGxvY2F0aW9uIG9mIGEgcmVzb3VyY2UuIEl04oCZcyBzdHJldGNoaW5nIHRo YXQgZGVmaW5pdGlvbiwgYXQgdGhlIHZlcnkgbGVhc3QuDQoNCkJ1dCBhcyBJIHNhaWQsIEnigJlt IHJlYWRpbmcgYmV0d2VlbiB0aGUgbGluZXMgaGVyZS4gSWYgdGhpcyBpcyB0aGUgaW50ZW50aW9u LCBpdCBzaG91bGQgYmUgY2xlYXJseSBzdGF0ZWQuIEFsdGVybmF0aXZlbHksIHJlbW92ZSAob3Ig Y2hhbmdlIHRvIGEgU0hPVUxEKSB0aGUgcmVxdWlyZW1lbnQgdGhhdCBtdWx0aS12YWx1ZSBgYXVk YCBjbGFpbXMgbXVzdCBvbmx5IGNvbnRhaW4gYWxpYXNlcyBmb3IgdGhlIHNhbWUgcmVzb3VyY2Ug aW5kaWNhdG9yLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0 eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jp bz00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0 Zi5vcmc+Pg0KRGF0ZTogTW9uZGF5LCBEZWNlbWJlciAxNiwgMjAxOSBhdCAyOjUxIFBNDQpUbzog SUVURiBvYXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NCkNj OiAiaS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+IiA8 aS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3Mt dG9rZW4tand0LTAzLnR4dA0KDQpEZWFyIGFsbCwNCkkgZmluYWxseSBmb3VuZCB0aGUgdGltZSB0 byBwdXNoIGEgbmV3IGRyYWZ0IG9mIHRoZSBKV1QgcHJvZmlsZSBmb3IgQVRzLiBUaGlzIHZlcnNp b24gaW5jb3Jwb3JhdGVzIHRoZSBmZWVkYmFjayBraW5kbHkgcHJvdmlkZWQgYnkgQnJpYW4gYW5k IEFhcm9uIGF0IElFVEYxMDUuDQpVbmZvcnR1bmF0ZWx5IEkgZGlkbid0IGhhdmUgYSBjaGFuY2Ug dG8gcGFydGljaXBhdGUgdG8gSUVURjEwNiwgaGVuY2Ugd2UgZGlkbid0IGRvIG11Y2ggcHJvZ3Jl c3Mgc2luY2UgdGhlbi4NClRoZXJlIGFyZSBzdGlsbCB0d28gYXJlYXMgd2UgZGlkbid0IG1hbmFn ZSB0byByZWFjaCBjb25zZW5zdXMgb246DQoNCjEuIE1lY2hhbmlzbXMgZm9yIHNpZ25hbGluZyB3 aGV0aGVyIHRoZSBBVCB3YXMgb2J0YWluZWQgYnkgYSB1c2VyIG9yIGFuIGFwcGxpY2F0aW9uDQoN ClRoaXMgcG9pbnQgd2FzIHRoZSBzdWJqZWN0IG9mIGludGVuc2UgZGViYXRlIG9uIHRoZSBsaXN0 IGxlYWRpbmcgdG8gSUVURjEwNS4uDQpPbmUgaW5zaWdodCB0aGF0IGVtZXJnZWQgZnJvbSB0aGUg SUVURjEwNSBkaXNjdXNzaW9uIHdhcyB0aGF0IHRoZSB1c2UgY2FzZSBoZXJlIGlzIG1vcmUgYWJv dXQgd2hldGhlciB0aGUgQVQgaGFzIGJlZW4gb2J0YWluZWQgdmlhIGEgZ3JhbnQgdGhhdCBhdXRo ZW50aWNhdGVkIHRoZSBjbGllbnQgKHJlZ2FyZGxlc3Mgb2Ygd2hhdCBzcGVjaWZpYyBncmFudCB3 YXMgdXNlZCkgdnMgYSBwdWJsaWMgY2xpZW50IGdyYW50LSB0aGF0IGluZm9ybWF0aW9uIGNhbiBi ZSByZWxldmFudCB0byBhIHJlc291cmNlIGFzIGl0IGRldGVybWluZXMgd2hldGhlciB0aGUgaWRl bnRpdHkgb2YgdGhlIGNsaWVudCBjYW4gYmUgdXNlZCBpbiBhdXRob3JpemF0aW9uIGRlY2lzaW9u cyAoaW4gdGhlIGZvcm1lciBjYXNlKSBvciBub3QgKGluIHRoZSBwdWJsaWMgY2xpZW50IGNhc2Up LiBJZiB0aGF0J3MgdGhlIHNjZW5hcmlvIHdlIGFyZSB0cnVseSBhZnRlciwgYSBzaW1wbGUsIHBv c3NpYmx5IG9wdGlvbmFsIGJvb2xlYW4gY2xhaW0gKHNheSBBdXRoZW50aWNhdGVkQ2xpZW50KSB3 b3VsZCBzdWZmaWNlLg0KTm90ZSBmb3IgdGhlIHBlb3BsZSB3aG8gZGlkbid0IHJlYWQgdGhlIHNw ZWM6IEkgcmVtb3ZlZCBhbnkgcmVmZXJlbmNlIHRvIHRoaXMgYWxyZWFkeSBpbiBkcmFmdC1pZXRm LW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDEuIEkgdGhpbmsgdGhpcyBpcyBhbiBpbXBvcnRhbnQg YW5kIHVzZWZ1bCBpbmZvIGFuZCBzdGFuZGFyZGl6aW5nIGl0IHdvdWxkIGJlIGJlbmVmaWNpYWwg Zm9yIG1pZGRsZXdhcmUgYW5kIFNESyBjcmVhdG9ycywgYnV0IHVsdGltYXRlbHkgdGhpcyBpcyBh biBpbnRlcm9wIHByb2ZpbGUgaGVuY2UgaWYgdGhlcmUncyBubyBzdHJvbmcgZGVzaXJlIHRvIHJl YWNoIGFuIGFncmVlbWVudCBoZXJlLCBJIGFtIGFsc28gT0sgd2l0aCBkcm9wcGluZyB0aGUgbWF0 dGVyIGFuZCBub3QgYWRkcmVzcyB0aGlzIGZ1bmN0aW9uIGluIHRoZSBzcGVjLg0KVG8gc3VtbWFy aXplLCBJIGhhdmUgdHdvIHF1ZXN0aW9ucyBoZXJlOg0KQS4gRG8gd2UgYmVsaWV2ZSBpdCdzIHdv cnRoIGl0IHRvIGZvcm1hbGl6ZSBpbiB0aGUgcHJvZmlsZSBhIG1lY2hhbmlzbSB0byBpbmRpY2F0 ZSB3aGV0aGVyIHRoZSBjbGllbnQgdGggb2J0YWluZWQgdGhlIEFUIGF1dGhlbnRpY2F0ZWQgaXRz ZWxmIHdpdGggdGhlIEFTPw0KQi4gSWYgeWVzLCBhcmUgeW91IE9LIHdpaHQgYW4gb3B0aW9uYWwg Ym9vbCBjbGFpbSBoZXJlPw0KDQoyLiBDbGFpbXMgaW5kaWNhdGluZyBzZXNzaW9uIHByb3BlcnRp ZXMNCg0KVGhpcyBpcyBvbmUgYXJlYSB3aGVyZSBJIGFtIGZhciBtb3JlIHBhc3Npb25hdGUgYWJv dXQsIGFzIGl0IHJlcHJlc2VudHMgYSBmdW5kYW1lbnRhbCBhc3BlY3QgdGhhdCBwcm9kdWN0aW9u IHN5c3RlbXMgKGFuZCBpbiBwYXJ0aWN1bGFyIDFzdCBwYXJ0eSBzb2x1dGlvbnMpIGFscmVhZHkg cmVseSBvbiBpbiB0aGUgY3VycmVudCBwcm9wcmlldGFyeSBKVFcgQVRzLg0KVGhlIHByb2ZpbGUg Y3VycmVudGx5IGluY2x1ZGVzIHRoZSBjbGFpbXMgYXV0aF90aW1lLCBhY3IgYW5kIGFtciAtIGNh cHR1cmluZyB0aGUgdmFsdWVzIG9mIHRob3NlIHByb3BlcnRpZXMgYXQgdGhlIHRpbWUgb2YgdGhl IGxhdGVzdCBhdXRoZW50aWNhdGlvbiB0aGUgdXNlciBwZXJmb3JtZWQgaW4gdGhlIHNlc3Npb24g dXNlZCB0byBpc3N1ZSB0aGUgY3VycmVudCBBVDogYXQgc2Vzc2lvbiBjcmVhdGlvbiwgYXQgYXV0 aCBzdGVwIHVwIHRpbWUgYW5kIHNvIG9uLg0KVGhvc2UgYXJlIHZhbHVlcyB0aGF0IEFQSSBuZWVk IGluIG9yZGVyIHRvIG1ha2UgYXV0aG9yaXphdGlvbiBkZWNpc2lvbnM7IGluIHRoZSBjYXNlIG9m IDFzdCBwYXJ0eSBBUElzLCB0aGUgQVQgaXMgdGhlIG9ubHkgYXJ0aWZhY3QgdGhleSBldmVyIHJl Y2VpdmUgaGVuY2UgdGhlcmUgaXMgbm8gb3RoZXIgd2F5IGZvciBhbiBBUEkgdG8gZGV0ZXJtaW5l IHdoZXRoZXIgdGhlIGNhbGxlciBwZXJmb3JtZWQgc2F5IE1GQSBpbiBvcmRlciB0byBvYnRhaW4g dGhlIGN1cnJlbnQgQVQuDQpTaW5jZSB0aGUgZmlyc3QgZHJhZnQsIHNvbWUgcGVvcGxlIHNpZ25h bGVkIGNvbmNlcm5zIGFib3V0IHRoZSBjdXJyZW50IG1lY2hhbmlzbXMgdGhydSB3aGljaCB0aG9z ZSBjbGFpbXMgZ2V0IHRoZWlyIHZhbHVlLiBGb3IgZXhhbXBsZSwgaXQgaGFzIGJlZW4gcHJvcG9z ZWQgdG8gbWFpbnRhaW4gdGhlIG9yaWdpbmFsIHZhbHVlcyBvZiBhdXRoX3RpbWUsIGFjciAmIGFt ciBhbmQgaW50cm9kdWNlIGFkZGl0aW9uYWwgY2xhaW1zIHRvIGluZGljYXRlIGNoYW5nZXMgKGxp a2Ugc3RlcHVwKS4NCkkgYW0gbm90IGNsZWFyIG9uIHdoYXQgY29sZCBnbyB3cm9uZyB3aXRoIHRo ZSBjdXJyZW50IGFwcHJvYWNoLCBoZW5jZSBJIGRvbid0IGhhdmUgYW4gaW1tZWRpYXRlIGdyYXNw IG9mIGhvdyBjaGFuZ2VzIGxpa2UgdGhlIGFib3ZlIHdvdWxkIGhlbHAuDQpJZiB0aGUgcGVvcGxl IHVuY29tZm9ydGFibGUgd2l0aCB0aGUgY3VycmVudCBwcm9wb3NhbCBjb3VsZCBkZXRhaWwgdGhl aXIgY29uY2Vybiwgd2UgY2FuIGJyYWluc3Rvcm0gd2F5cyB0byBtYWtlIHRoYXQgaW5mbyBhdmFp bGFibGUgdG8gQVBJIGluIGEgc2FmZXIgd2F5LiBUbyBzdW1tYXJpemU6DQpBLiBEbyB5b3UgaGF2 ZSBjb25jZXJucyB3aXRoIHRoZSBjdXJyZW50IGF1dGhfdGltZSwgYXJtLCBhY3IgcHJvcG9zYWw/ IENhbiB5b3Ugc3BlbGwgdGhlbSBvdXQ/IChwbGVhc2UgcmVhZCB0aGUgcmVsZXZhbnQgcGFydHMg b2YgdGhlIHNwZWMgYmVmb3JlIGNoaW1pbmcgaW4gOikpDQpCLiBJZiB5ZXMsIHdoYXQgY2FuIHdl IGRvIHRvIG1ha2UgdGhhdCBpbmZvIGF2YWlsYWJsZSB0byBSU3MgaW4gYSB3YXkgdGhhdCBtYWtl cyB5b3UgY29tZm9ydGFibGU/DQoNCg0KVGhhbmtzDQoNClYuDQoNCk9uIE1vbiwgRGVjIDE2LCAy MDE5IGF0IDI6NDkgUE0gPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPj4gd3JvdGU6DQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29sIFdH IG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IEpTT04gV2ViIFRva2Vu IChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zDQogICAgICAgIEF1dGhv ciAgICAgICAgICA6IFZpdHRvcmlvIEJlcnRvY2NpDQogICAgICAgIEZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMy50eHQNCiAgICAgICAgUGFnZXMg ICAgICAgICAgIDogMTYNCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxOS0xMi0xNg0KDQpB YnN0cmFjdDoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgcHJvZmlsZSBmb3IgaXNz dWluZyBPQXV0aCAyLjAgYWNjZXNzDQogICB0b2tlbnMgaW4gSlNPTiB3ZWIgdG9rZW4gKEpXVCkg Zm9ybWF0LiAgQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGFuZA0KICAgcmVzb3VyY2Ugc2VydmVycyBm cm9tIGRpZmZlcmVudCB2ZW5kb3JzIGNhbiBsZXZlcmFnZSB0aGlzIHByb2ZpbGUgdG8NCiAgIGlz c3VlIGFuZCBjb25zdW1lIGFjY2VzcyB0b2tlbnMgaW4gaW50ZXJvcGVyYWJsZSBtYW5uZXIuDQoN Cg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10 b2tlbi1qd3QvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBh dDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10 b2tlbi1qd3QtMDMNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt aWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91 cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMNCg0KDQpQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNCkludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0 cC4uaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzxmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_2518B18AAD9344E488D1E5F6AAE7B1BBamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <42B1E9C0703C9440B14C46781C1D06C1@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjIgMCA1IDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIg NiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAy IDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2Ut MToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJQVCBN b25vIjsNCglwYW5vc2UtMToyIDYgNSA5IDIgMiA1IDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEluIGFueSBjYXNlIHRoZSBpbnRlbnQg d2FzIGFsd2F5cyB0byBvbmx5IGFsbG93IGEgc2luZ2UgcmVzb3VyY2UgcGVyIEFU4oCmPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk15IGNvbmZ1c2lvbiBhY3R1YWxseSBjb21lcyBmcm9tIHRoZSBs YXN0IHBhcmFncmFwaCBvZiDCpzMsIHdoZXJlIGl0IHNheXMg4oCcSWYgYSBzY29wZSBwYXJhbWV0 ZXIgaXMgcHJlc2VudCBpbiB0aGUgcmVxdWVzdCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNI T1VMRCB1c2UgaXQgdG8gaW5mZXIgdGhlIHZhbHVlIG9mIHRoZSBkZWZhdWx0IHJlc291cmNlIGlu ZGljYXRvciB0byBiZSB1c2VkIGluIHRoZSBhdWQNCiBjbGFpbS7igJ0gSSBpbnRlcnByZXRlZCB0 aGF0IHRvIGxlYXZlIHJvb20gZm9yIGFuIEFTIGluZmVycmluZyB0aGUgc2FtZSDigJxnZW5lcmlj 4oCdIHJlc291cmNlIGluZGljYXRvciBmb3IgcmVzb3VyY2VzIHNlcnZlZCBieSBkaWZmZXJlbnQg UlNlcy4gVGhlIG9uZS1SUy1wZXItQVQgbW9kZWwgaXMgYW4gaWRlYWwgdGhhdCBzaW1wbHkgZG9l c27igJl0IG1hdGNoIHJlYWxpdHkuIENsaWVudHMgZG9u4oCZdCB3YW50IHRvIGhhdmUgdG8ganVn Z2xlIGEgYnVuY2ggb2YNCiBkaWZmZXJlbnQgdG9rZW5zLCBub3Igc2hvdWxkIHRoZXkgbmVlZCB0 by4gSeKAmW0gY29taW5nIHRvIHRoaW5rIHRoYXQgd2Ugc2hvdWxkbuKAmXQgYWN0dWFsbHkgdXNl IGBhdWRgIGFuZCBgc2NvcGVgIGluIEpXVCBBVHMgYXQgYWxsLCBhbmQgaW5zdGVhZCBhZG9wdCB0 aGUgc3RydWN0dXJlIFJBUiBkZWZpbmVzIHVzZWQgZm9yIHRoZSBgYXV0aG9yaXphdGlvbl9kZXRh aWxzYCBwYXJhbWV0ZXIgKEkgdGhpbmsgc29tZSBpdGVyYXRpb24gaXMgcmVxdWlyZWQsDQogYnV0 IGl0IHNlZW1zIG5hdHVyYWwgZm9yIHRoZXNlIHR3byB0byBkZXNjcmliZSBhdXRob3JpemF0aW9u cyBpbiB0aGUgc2FtZSBvciBjb21wYXRpYmxlIHdheXMpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsg4oCmdGhl IHJlc291cmNlIHdhbnRzIHRvIGtub3cgd2hldGhlciB0aGlzIHBhcnRpY3VsYXIgdG9rZW4gd2Fz IG9idGFpbmVkIHByb3ZpbmcgdGhlIGlkZW50aXR5IG9mIHRoZSBjbGllbnTigKY8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SeKAmW0gc2tlcHRpY2FsIG9mIHRoZSBpZGVhIHRoYXQgdGhlcmUgaXMg anVzdCBvbmUgbGV2ZWwgb2YgY2xpZW50IGlkZW50aXR5IHByb29maW5nIHRoYXQgUlNlcyBtaWdo dCBjYXJlIGFib3V0LiBUaGVyZSBtaWdodCBiZSBzb21lIGNsZWFyIGxpbmVzIHRoYXQgY2FuIGJl IGRyYXduLCBidXQgd2Ugc2hvdWxkIGJlIGV4cGxpY2l0IGFib3V0IHdoYXQgdGhvc2UgbGluZXMg cmVwcmVzZW50LCBlLmcuLCDigJxjbGllbnQNCiBhdXRoZW50aWNhdGVkIHVzaW5nIHByZS1lc3Rh Ymxpc2hlZCBjcmVkZW50aWFs4oCdLCDigJxjbGllbnQgaXMgcnVubmluZyBvbiBlbmQgdXNlci1j b250cm9sbGVkIGRldmljZeKAnSwgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSSBhbSBub3QgdHJ5aW5n IHRvIGNyZWF0ZSBhIGNvbXBsZXRlIGZyYW1ld29yayBmb3IgaGFuZGxpbmcgc3RlcCB1cCBhbmQg dGhlIGxpa2UsIEkgYW0gdHJ5aW5nIHRvIGNyZWF0ZSBhbiBpbnRlcm9wZXJhYmxlIHJlcHJlc2Vu dGF0aW9uIG9mIHRob3NlIHZhbHVlcyBubyBtYXR0ZXIgaG93IHRoZXkgd2VyZSBvYnRhaW5lZC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0aG91dCB0YWtpbmcgdGhlIHdob2xlIHBpY3R1cmUg aW50byBhY2NvdW50LCB0aGVyZSBpcyBzaWduaWZpY2FudCByaXNrIHRoYXQgd2Ugd2lsbCBkZWZp bmUgc29tZXRoaW5nIHRoYXQgdHVybnMgb3V0IHRvIGJlIHdvZWZ1bGx5IGluc3VmZmljaWVudCAo b3Igd29yc2UsIGVzdGFibGlzaGVzIGFuIGFudGktcGF0dGVybikuIFRoYXQgc2FpZCwgSSBhZ3Jl ZSB0aGF0IGl04oCZcyBwcm9iYWJseSBub3QgYXBwcm9wcmlhdGUNCiBmb3IgdGhpcyBkcmFmdCwg YW5kIHJlY29tbWVuZCBkcm9wcGluZyB0aGVzZSBjbGFpbXMuIFRoZXkgY2FuIGFsd2F5cyBiZSBk ZWZpbmVkIGluIGEgc2VwYXJhdGUgZHJhZnQsIGFsb25nIHdpdGggdGhlIG90aGVyIGVsZW1lbnRz IG5lY2Vzc2FyeSB0byBjb21tdW5pY2F0ZSBzdGVwLXVwIHJlcXVpcmVtZW50cy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJMm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5WaXR0b3JpbyBCZXJ0b2NjaSAm bHQ7Vml0dG9yaW89NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPk1vbmRheSwgRGVjZW1iZXIgMTYsIDIwMTkgYXQgOTozMSBQTTxicj4NCjxiPlRvOiA8L2I+ JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hQGFtYXpv bi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5JRVRGIG9hdXRoIFdHICZsdDtvYXV0aEBpZXRmLm9y ZyZndDssIFZpdHRvcmlvIEJlcnRvY2NpICZsdDtWaXR0b3Jpb0BhdXRoMC5jb20mZ3Q7LCAmcXVv dDtpLWQtYW5ub3VuY2VAaWV0Zi5vcmcmcXVvdDsgJmx0O2ktZC1hbm5vdW5jZUBpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W1VOVkVSSUZJRUQgU0VOREVSXSBSZTogW09BVVRILVdH XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMudHh0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5SZTogYWxpYXNlcywgSSBzZWUgd2hlcmUgdGhlIGNvbmZ1c2lvbiBpcyBjb21pbmcgZnJvbSE8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgdXBkYXRlZCB0aGUgcmVxdWVzdCBzZWN0aW9u LCBidXQgdGhlIHNlc3Npb24gMi4yIGRhdGEgc3RydWN0dXJlIHN0aWxsIG1lbnRpb25zIHRoZSBh bGlhc2VzLiBUaGF0IHNob3VsZCBiZSBjbGVhbmVkIHVwIGFzIHdlbGwuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+SW4gYW55IGNhc2UgdGhlIGludGVudCB3YXMgYWx3YXlzIHRvIG9ubHkgYWxs b3cgYSBzaW5nZSByZXNvdXJjZSBwZXIgQVQsIHRoZSBhbGlhcyBsaXN0IHdhcyBvbmx5IGZvciBo ZWxwaW5nIGluIGNhc2VzIHdoZXJlIGFuIEFTIGlkZW50aWZpZXMgdGhlIHNhbWUgcmVzb3VyY2Ug dGhydSBtdWx0aXBsZSBJRHMgYW5kIHRoZSBhY3R1YWwgYXVkIHZhbHVlIGRlcGVuZHMgb24NCiB3 aGF0IElEIHRoZSBjbGllbnQgcmVxdWVzdGVkLiBIb3dldmVyIHdlIGRpc2N1c3NlZCB0aGlzIHdp dGggQnJpYW4gYW5kIGhlIGNvbnZpbmNlZCBtZSB0aGF0IGl0IHdhcyBqdXN0IHRvbyBhbWJpZ3Vv dXMtIHlvdXIgcmVtYXJrIHJlaW5mb3JjZXMgdGhhdCBpbXByZXNzaW9uLiBJ4oCZbGwgY2xlYW4g dXAgMi4yIGFuZCBlbGltaW5hdGUgcmVmZXJlbmNlcyB0byBhbGlhc2VzIGZyb20gdGhlcmUgYXMg d2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGFua3MhPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiBNb24s IERlYyAxNiwgMjAxOSBhdCAyMDoxOSBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7PGEgaHJlZj0ibWFp bHRvOlZpdHRvcmlvQGF1dGgwLmNvbSI+Vml0dG9yaW9AYXV0aDAuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoYW5rcyBBbm5hYmVsbGUuIDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+RG9lcyBhIG1vYmlsZSBhcHAgdGhhdCB1 c2VzIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiB0byBlc3RhYmxpc2ggYSBjbGllbnQgc2Vj cmV0IGNvdW50IGFzIGFuIOKAnGF1dGhlbnRpY2F0ZWQgY2xpZW504oCdPyZuYnNwOyZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIHRoaW5rIGl0IHNob3VsZCBjb3VudCwgdGhvIEkg YW0gbm90IHN1cmUgd2hhdCB0aGUgUlMgd291bGQgZG8gd2l0aCBpdC4gRHluYW1pYyBjbGllbnQg cmVnaXN0cmF0aW9uIHdvdWxkIGxpa2VseSBub3QgaGF2ZSBtdWNoIHVzZSBmb3IgdGhpcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5JbiB0aGUgY2FzZXMgSSBoYXZlIHNlZW4sIHRoZSBpZGVhIGlzIHRo YXQgYSBjbGllbnQgKHdob3NlIGNsaWVudElEIGlzIGFscmVhZHkga25vd24gdG8gdGhlIFJTKSBj YW4gb2J0YWluIHRva2VucyB0aHJ1IGRpZmZlcmVudCBncmFudHMsIHNvbWUgb2YgdGhlbSBjb25m aWRlbnRpYWwgYW5kIG90aGVycyBwdWJsaWM7IGFuZCB0aGUgcmVzb3VyY2Ugd2FudHMgdG8ga25v dw0KIHdoZXRoZXIgdGhpcyBwYXJ0aWN1bGFyIHRva2VuIHdhcyBvYnRhaW5lZCBwcm92aW5nIHRo ZSBpZGVudGl0eSBvZiB0aGUgY2xpZW50IHNvIHRoYXQgaXQgY2FuIGRlY2lkZSB3aGV0aGVyIHRv IGdyYW50IGV4dHJhIHByaXZpbGVnZXMgZm9yIHRoYXQgcGFydGljdWxhciZuYnNwO2NsaWVudCBp biB0aGUgY3VycmVudCBjYWxsLiBUaGlzIHNjZW5hcmlvIGRvZXMgbm90IHJlcXVpcmUgdGhlIGV4 dHJhIGRldGFpbHMgYWJvdXQgYXV0aGVudGljYXRpb24gbWV0aG9kL3N0cmVuZ3RoDQogeW91IG1l bnRpb24gdGhhdCwgSSBhZ3JlZSwgd291bGQgYmUgcHJldHR5IGhhcmQgdG8gcmVhY2ggY29uc2Vu c3VzIG9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRMO0RSOiB0aGVyZSBpcyBhdCBsZWFzdCBvbmUg c2NlbmFyaW8gdGhhdCBpcyBzYXRpc2ZpZWQgYnkgdGhlIHNpbXBsZSBib29sLCBhcyB0aGUgcHJl dmlvdXMga25vd2xlZGdlIG9mIHRoZSBjbGllbnQgc29sdmVzIHRoZSBpc3N1ZXMgeW91IG1lbnRp b24gb3V0IG9mIGJhbmQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+YXV0aGVudGljYXRpb24gc2Vzc2lvbiBwcm9wZXJ0aWVzOiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDtMZXQgbWUgdHJ5IGFub3RoZXIgYW5n bGUuIFNheSB0aGF0IEkgcGVyZm9ybSBhbiBhdXRoeiBjb2RlIGdyYW50IGFza2luZyBmb3IgQVQs IElEX1QgYW5kIFJULSBvYnRhaW5pbmcgQVQnLCBJRF9UJyBhbmQgUlQnLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPlRoZSB2YWx1ZXMgb2YgYXV0aF90aW1lLCBhY3IgYW5kIGFtciBpbiBBVCcg d2lsbCBiZSB0aGUgc2FtZSBhcyB0aGUgY29ycmVzcG9uZGluZyBjbGFpbXMgaW4gSURfVCcuIFdo ZW4gdGhlIGNsaWVudCB1c2VzIFJUJyB0byBvYnRhaW4gQVRgTiwgQVQnTiYjNDM7MSBldGMgZXRj LCB0aGUgdmFsdWVzIG9mIHRob3NlIGNsYWltcyB3aWxsIHJlbWFpbiB0aGUgc2FtZSBmb3IgZXZl cnkNCiBBVCduIG9idGFpbmVkIGJ5IFJUJy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Ob3csIGltYWdp bmUgdGhhdCBzb21ldGhpbmcgaGFwcGVucyAoaWdub3JlIHdoYXQgZm9yIHRoZSB0aW1lIGJlaW5n KSB0aGF0IGNhdXNlcyB0aGUgY2xpZW50IHRvIHBlcmZvcm0gYSBzdGVwIHVwIGF1dGgsIHdoaWNo IHJlcXVpcmVzIHRoZSB1c2VyIHRvIHBlcmZvcm0gaW50ZXJhY3RpdmUgYXV0aCBoZW5jZSByZXN1 bHRzIGluIGEgbmV3IGF1dGh6IGdyYW50LiBUaGUNCiBjbGllbnQgd2lsbCBvYnRhaW4gYSBuZXcg dHVwbGUmbmJzcDsgQVQmcXVvdDssIElEX1QmcXVvdDsgYW5kIFJUJnF1b3Q7LiBUaGUgZXhhY3Qg c2FtZSBydWxlcyBkZXNjcmliZWQgZm9yIHRoZSAnIHR1cGxlIGFwcGx5LCB3aXRoIHRoZSBuZXcg dmFsdWVzIGRldGVybWluZWQgYnkgdGhlIG5ldyBhdXRoZW50aWNhdGlvbjogQVQmcXVvdDsgYXV0 aF90aW1lL2Fjci9hbXIgd2lsbCBiZSB0aGUgc2FtZSBhcyBJRF9UJnF1b3Q7LCBhbmQgdGhvc2Ug dmFsdWVzIHdpbGwgcmVtYWluIHVuY2hhbmdlZCBmb3INCiBldmVyeSBBVCZxdW90O24gZGVyaXZl ZCBieSBSVCZxdW90Oy48YnI+DQpJZiB3ZSB3YW50IHRoaXMgdG8gYXBwbHkgdG8gdGhlIGltcGxp Y2l0IGZsb3cgYXMgd2VsbCwgeW91IGNhbiBzdWJzdGl0dXRlIHRoZSBSVCB3aXRoIHRoZSBzZXNz aW9uIGFydGlmYWN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkRvZXMgdGhhdCBoZWxwIGNs YXJpZnlpbmcgdGhlIGludGVudD8gSWYgeWVzLCBkbyB5b3UgZmVlbCB0aGF0IHRoZSBjdXJyZW50 IGxhbmd1YWdlIGRvZXMgbm90IGRlc2NyaWJlIHRoaXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+dXNlIGNhc2UgZm9yIHB1dHRpbmcgdGhlc2Ug aW4gdGhlIGFjY2VzcyB0b2tlbiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIGFt IG5vdCB0cnlpbmcgdG8gY3JlYXRlIGEgY29tcGxldGUgZnJhbWV3b3JrIGZvciBoYW5kbGluZyBz dGVwIHVwIGFuZCB0aGUgbGlrZSwgSSBhbSB0cnlpbmcgdG8gY3JlYXRlIGFuIGludGVyb3BlcmFi bGUgcmVwcmVzZW50YXRpb24gb2YgdGhvc2UgdmFsdWVzIG5vIG1hdHRlciBob3cgdGhleSB3ZXJl IG9idGFpbmVkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkNvbnNpZGVyIHRoZSBjYXNlIGlu IHdoaWNoIGFuIEFQSSBhbGxvd3MgY2VydGFpbiBvcGVyYXRpb25zIG9ubHkgaWYgYSBnaXZlbiBh bXIgdmFsdWUgaXMgcHJlc2VudCBpbiB0aGUgdG9rZW4uIFdoZXRoZXIgdGhhdCBhbXIgaXMgcmVx dWlyZWQgdXBmcm9udCBvbiBmaXJzdCBhdXRoZW50aWNhdGlvbiwgYXMgc3RlcCB1cCBvciBhbnkg b3RoZXIgcmVhc29uIGlzIG91dA0KIG9mIHNjb3BlIGZvciB0aGlzIHByb2ZpbGUgSU1POiB0aGUg QVMgbWlnaHQgaGF2ZSBhbGwgc29ydHMgb2YgaGV1cmlzdGljcyB0aGF0IGRldGVybWluZSB0aGF0 ICh1c2VyIG1lbWJlcnNoaXAgdG8gYSBnaXZlbiBncm91cCBvciByb2xlOyBnZW9mZW5jaW5nOyBy aXNrIHNjb3Jpbmc7IGV0YykgdGhhdCBoYXZlIG5vdGhpbmcgdG8gZG8gd2l0aCBzY29wZXMgcmVx dWVzdGVkLCBhbmQgYXJlIG5vdCBzdGF0aWNhbGx5IGRldGVybWluZWQgYnkgUlMtQVMNCiBjb21t dW5pY2F0aW9ucy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Ob3csIEkgYWdyZWUgdGhhdCBm b3JtYWxpemluZyBob3cgYSBSUyBjb21tdW5pY2F0ZXMgdG8gdGhlIEFTIHZpYSB0aGUgY2xpZW50 IHRoZSBuZWVkIHRvIHN0ZXAgdXAgYW5kIGluIHdoYXQgdGVybXMgd291bGQgYmUgc3VwZXImbmJz cDt1c2VmdWw7IGhvd2V2ZXIgSSB0aGluayB0aGF0J3Mgd2VsbCBiZXlvbmQgdGhlIHNjb3BlIG9m IHRoaXMgcHJvZmlsZS4uIFZhcmlvdXMgdmVuZG9ycw0KIGFscmVhZHkgaGF2ZSB0aGVpciBvd24g bWVjaGFuaXNtcyBmb3IgaGFuZGxpbmcgc3RlcCB1cCBzaWduYWxpbmcgZnJvbSBSUyB0byBBUyAo SSBhbSB2ZXJ5IGZhbWlsaWFyIHdpdGggdGhlIE1pY3Jvc29mdCZuYnNwO29uZSkgYW5kIGFsbCBJ IGFtIGxvb2tpbmcgZm9yIGlzIGEgd2F5IG9mIHN0YW5kYXJkaXppbmcgaG93IHRvIHJlcHJlc2Vu dCB0aGUgb3V0Y29tZXMsIHNvIHRoYXQgQVBJIGdhdGV3YXlzIGFuZCBTREsgcHJvdmlkZXJzIGNh biBwcm92aWRlDQogdG9vbHMgdGhhdCB3b3JrIGFjcm9zcyB2ZW5kb3JzOyBhbmQgcG9zc2libHkg cmV1c2Ugc29tZSBvZiB0aGUgcmVhc29uaW5nIHRoYXQgd2FzIGFscmVhZHkgZG9uZSBmb3IgaWRf dG9rZW5zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRMO0RSOiBJIHRoaW5rIHdlIGFyZSBkb2luZyBz b21ldGhpbmcgdXNlZnVsIGluIGZvcm1hbGl6aW5nIGhvdyB0byBlbWJlZCB0aGF0IGluZm8gYW4g QVRzIGV2ZW4gaWYgd2UgZG9uJ3QgZm9yY2UgdmVuZG9ycyB0byBnaXZlIHVwIHRoZWlyIGN1cnJl bnQgbWVjaGFuaXNtcyB0byBwb3B1bGF0ZSB0aG9zZSB2YWx1ZXMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+UmVnYXJkaW5nIGFjY2VzcyB0b2tl bnMgdGhhdCBhcmUgdXNlZCB0byBhY2Nlc3MgZGlmZmVyZW50IHJlc291cmNlIHNlcnZlcnM8bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGludGVudCBpcyB0byBleHBsaWNpdGx5IGRpc2Fs bG93IHRoZSB1c2Ugb2YgYW4gQVQgd2l0aCBtdWx0aXBsZSByZXNvdXJjZSBzZXJ2ZXJzLiBJZiBh IGNsaWVudCB3YW50cyB0byB0YWxrIHdpdGggMiBkaWZmZXJlbnQgUlNlcywgdGhlIGNsaWVudCBz aG91bGQgYXNrIGZvciAyIGRpZmZlcmVudCBBVHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIHNw ZWMgaXMgdW5hbWJpZ3VvdXMgb24gdGhpcyBJTU8sIGhlcmUncyB0aGUgbGFuZ3VhZ2UgSSB1c2Ug aW4gMDMuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47d29yZC1icmVhazpicmVhay1h bGw7Ym94LXNpemluZzpib3JkZXItYm94O2JvcmRlci1yYWRpdXM6NHB4O292ZXJmbG93OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8m cXVvdDs7Y29sb3I6YmxhY2siPklmIGl0IHJlY2VpdmVzIGEgcmVxdWVzdCBmb3IgYW4gYWNjZXNz IHRva2VuIGNvbnRhaW5pbmcgbW9yZSB0aGFuIG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHJlc291cmNlIHBhcmFtZXRlciwgYW4gYXV0aG9yaXph dGlvbiBzZXJ2ZXIgaXNzdWluZyBKV1QgYWNjZXNzIHRva2VuczxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IE1VU1QgcmVqZWN0IHRoZSByZXF1ZXN0IGFu ZCBmYWlsIHdpdGggJnF1b3Q7aW52YWxpZF9yZXF1ZXN0JnF1b3Q7IGFzIGRlc2NyaWJlZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt3b3JkLWJy ZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGluIDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTQu MS4yLjEiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzNEMjJCMyI+c2VjdGlv biZuYnNwOzQuMS4yLjEgb2YgW1JGQzY3NDldPC9zcGFuPjwvYT4gb3Igd2l0aCAmcXVvdDtpbnZh bGlkX3RhcmdldCZxdW90OyBhcyBkZWZpbmVkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgaW4gc2VjdGlvbiAyIG9mIFs8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2Vu LWp3dC0wMyNyZWYtUmVzb3VyY2VJbmRpY2F0b3JzIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMzRDIyQjMiPlJlc291cmNlSW5kaWNhdG9yczwvc3Bhbj48L2E+XS4mbmJzcDsg U2VlIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt aWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzI3NlY3Rpb24tMi4yIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzRDIyQjMiPlNlY3Rpb24gMi4yPC9zcGFuPjwvYT4gYW5k IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0 Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzI3NlY3Rpb24tNSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjojM0QyMkIzIj5TZWN0aW9uIDU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt3b3JkLWJyZWFrOmJy ZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGZvciBtb3JlIGRldGFpbHMg b24gaG93IHRoaXMgbWVhc3VyZSBlbnN1cmVzIHRoZXJlJ3Mgbm8gY29uZnVzaW9uIG9uPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3dvcmQtYnJl YWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdG8gd2hhdCByZXNv dXJjZSB0aGUgYWNjZXNzIHRva2VuIGdyYW50ZWQgc2NvcGVzIGFwcGx5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyBJcyBpdCBwb3NzaWJsZSB5b3UgYXJlIHJlZmVycmluZyB0 byBhbiBvbGRlciBkcmFmdD8mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9u IE1vbiwgRGVjIDE2LCAyMDE5IGF0IDU6MjggUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUg Jmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj40MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KMS4gUmVnYXJkaW5nIEF1dGhl bnRpY2F0ZWRDbGllbnQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6LjVpbiI+DQpEb2VzIGEgbW9iaWxlIGFwcCB0aGF0IHVzZXMgRHluYW1pYyBDbGll bnQgUmVnaXN0cmF0aW9uIHRvIGVzdGFibGlzaCBhIGNsaWVudCBzZWNyZXQgY291bnQgYXMgYW4g 4oCcYXV0aGVudGljYXRlZCBjbGllbnTigJ0/IFdoYXQgaWYgdGhhdCByZWdpc3RyYXRpb24gaW5j bHVkZWQgYW4gYXNzZXJ0aW9uIHNpZ25lZCBieSBhIHRydXN0ZWQgZW50aXR5IChlLmcuLCBkZXZp Y2UgbWFuYWdlbWVudCBzb2Z0d2FyZSkgdXNpbmcgYSBjZXJ0aWZpY2F0ZSB0aGF0IGhhZA0KIGJl ZW4gcHVzaGVkIHRvIHRoZSBkZXZpY2U/IFdpdGhvdXQgc29tZSBraW5kIG9mIE5JU1QgTG9BLXN0 eWxlIGRlZmluaXRpb24gb2Yg4oCcYXV0aGVudGljYXRlZOKAnSwgYSBzaW5nbGUgQm9vbGVhbiDi gJxBdXRoZW50aWNhdGVkQ2xpZW504oCdIHZhbHVlIGlzIHRvbyBhbWJpZ3VvdXMgdG8gYmUgdXNl ZnVsLiBIb3dldmVyLCBJ4oCZbSBza2VwdGljYWwgdGhhdCB3ZSBjb3VsZCBmaW5kIGNvbnNlbnN1 cyBvbiB3aGF0IHRoYXQgZGVmaW5pdGlvbiBzaG91bGQgYmUsDQogYW5kIGl0IG1heSBiZSBiZXR0 ZXIgdG8gZGVmaW5lIGNsaWVudCBhbmFsb2dzIHRvIGBhY3JgIGFuZCBgYW1yYCB0aGF0IHByb3Zp ZGUgc3RhbmRhcmQgd2F5cyBvZiBleHByZXNzaW5nIGNsaWVudCBhdXRoZW50aWNhdGlvbiBkZXRh aWxzIHdpdGhvdXQgZ2V0dGluZyBwcmVzY3JpcHRpdmUgYWJvdXQgd2hhdCBraW5kIG9mIGF1dGhl bnRpY2F0aW9uIGlzIOKAnGdvb2QgZW5vdWdoLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQoyLiBSZWdhcmRpbmcgYXV0 aGVudGljYXRpb24gc2Vzc2lvbiBwcm9wZXJ0aWVzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KSeKAmW0gY29uZnVzZWQgYnkgdGhlIGRl ZmluaXRpb25zIGdpdmVuIGZvciBgYXV0aF90aW1lYCwgYGFjcmAsIGFuZCBgYW1yYC4gRm9yIGBh dXRoX3RpbWVgLCBpdCBzYXlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0K4oCc4oCmaXRzIHZhbHVlIHdpbGwgZWl0aGVy IHJlbWFpbiB0aGUgc2FtZSBmb3IgYWxsIHRoZSBKV1QgYWNjZXNzIHRva2VucyBpc3N1ZWQgd2l0 aGluIHRoYXQgc2Vzc2lvbiBvciBiZSB1cGRhdGVkIHRvIHRoZSB0aW1lIG9mIGxhdGVzdCBhdXRo ZW50aWNhdGlvbiBpZiByZWF1dGhlbnRpY2F0aW9uIG9jY3VycmVkIG1pZC1zZXNzaW9u4oCm4oCd PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+ DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluIj4NCkJ1dCB0aGUg4oCcRm9yIGV4YW1wbGXigJ0gYXQgdGhlIGVuZCBvZiB0aGF0IGRl ZmluaXRpb24gaW1wbGllcyB0aGF0IGBhdXRoX3RpbWVgIHdpbGwgbm90IGJlIHVwZGF0ZWQuIFRo ZSBkZWZpbml0aW9ucyBmb3IgYGFjcmAgYW5kIGBhbXJgIHNheSB0aGUgc2FtZSwgYnV0IGFsc28g c2F5IHRoYXQgdGhlIOKAnOKApnNhbWUgY29uc2lkZXJhdGlvbnMgcHJlc2VudGVkIGZvciBhdXRo X3RpbWUgYXBwbHnigKbigJ0gV2hhdOKAmXMgdGhlIGludGVudGlvbiBoZXJlOiBhcmUgdGhleQ0K IGZpeGVkLCB1cGRhdGVkLCBvciBpcyBpdCB1cCB0byB0aGUgZGVwbG95bWVudCB0byBkZWNpZGU/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+ DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluIj4NCknigJlkIGxpa2UgdG8gYmV0dGVyIHVuZGVyc3RhbmQgdGhlIHVzZSBjYXNlIGZv ciBwdXR0aW5nIHRoZXNlIGluIHRoZSBhY2Nlc3MgdG9rZW4uIElmIHRoZSBSUyBpcyBtYWtpbmcg YXV0aG9yaXphdGlvbiBkZWNpc2lvbnMgYmFzZWQgb24gdGhlc2UgY2xhaW1zLCB0aGF0IGltcGxp ZXMgdGhhdCB0aGUgUlMgY2Fubm90IHJlbHkgb24gdGhlIEFTIHRvIGRldGVybWluZSAoZS5nLiwg ZnJvbSB0aGUgcmVxdWVzdGVkIHNjb3BlKSB0aGUgcmVxdWlyZWQgYXV0aGVudGljYXRpb24NCiBt ZXRob2QocyksIGZyZXNobmVzcywgZXRjLiBJZiB0aGUgQVMgY291bGQgYmUgcmVsaWVkIHVwb24g Zm9yIHRoaXMsIHRoZW4gcHJlc3VtYWJseSBpdCB3b3VsZCBub3QgaXNzdWUgUlRzIGFuZCBBVHMg Zm9yIGEgc2NvcGUgd2l0aG91dCByZXF1aXJpbmcgdGhlIGVuZCB1c2VyIHRvIG1lZXQgdGhlIGFw cHJvcHJpYXRlIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cy4gSWYgdGhpcyBpcyB0aGUgY2Fz ZSwgdGhlbiB0aGUgUlMgbXVzdCBoYXZlIGENCiB3YXkgdG8gc2lnbmFsIHRvIHRoZSBjbGllbnQg KGFuZCB0aGVuIHRoZSBBUykgdGhhdCBhIHN0ZXAtdXAgYXV0aGVudGljYXRpb24gaXMgcmVxdWly ZWQuIElzIHRoZXJlIGFuIGV4aXN0aW5nIG1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIHRoZXkgY291 bGQgZG8gdGhpcz8gQWxsIEkgY2FuIGNvbWUgdXAgd2l0aCBpcyBjcmFtbWluZyB0aGUgaW5mb3Jt YXRpb24gaW50byB0aGUgc2NvcGUgYXR0cmlidXRlIG9mIGEgV1dXLUF1dGhlbnRpY2F0ZSBjaGFs bGVuZ2UsDQogYnV0IHRoYXQgaGFzIHRoZSBzYW1lIHNjb3BlIG9wYWNpdHkgdmlvbGF0aW9uIHBy b2JsZW0gYXMgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnTigJlzIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zLiBXaXRob3V0IGEgY2xlYXIgd2F5IHRvIGV4cHJlc3MgdGhlIHN0ZXAtdXAgcmVxdWlyZW1l bnRzLCB0aGlzIGZlZWxzIGluY29tcGxldGUuLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQozLiBSZWdhcmRpbmcgYWNjZXNz IHRva2VucyB0aGF0IGFyZSB1c2VkIHRvIGFjY2VzcyBkaWZmZXJlbnQgcmVzb3VyY2Ugc2VydmVy czo8YnI+DQpSZWFkaW5nIGJldHdlZW4gdGhlIGxpbmVzLCBJICo8Yj50aGluazwvYj4qIHRoZSBp bnRlbnRpb24gaXMgdGhhdCBhIEpXVCBhY2Nlc3MgdG9rZW4gdGhhdCBpcyBpbnRlbmRlZCB0byBi ZSB1c2VkIHRvIGFjY2VzcyB0d28gZGlmZmVyZW50IHJlc291cmNlcyBhdCB0d28gZGlmZmVyZW50 IFJTZXMgc2hvdWxkIGxvb2sgc29tZXRoaW5nIGxpa2U6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDb3VyaWVyIj57PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6NS4yNXB0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mcXVvdDthdWQmcXVvdDs6ICZxdW90OzxhIGhyZWY9 Imh0dHBzOi8vZ2VuZXJpYy1yZXNvdXJjZS1pbmRpY2F0b3IuZXhhbXBsZS5jb20vIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly9nZW5lcmljLXJlc291cmNlLWluZGljYXRvci5leGFtcGxlLmNvbS88 L2E+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50OjUuMjVwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q291cmllciI+JnF1b3Q7c2NvcGUmcXVvdDs6ICZxdW90O3Jlc291cmNlX2ZvbyByZXNv dXJjZV9iYXImcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6NS4yNXB0Ij4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDb3VyaWVyIj4uLi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q291cmllciI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluIj4NCjxicj4NCkFuZCB0aGUgZXhwZWN0YXRpb24gaXMgdGhhdCBlYWNo IFJTIHNob3VsZCByZWNvZ25pemUgdGhhdCBnZW5lcmljIGF1ZGllbmNlLiBJcyB0aGlzIGNvcnJl Y3Q/IElmIHNvIGl0IHNlZW1zIHRvIGdvIGFnYWluc3QgdGhlIHNwaXJpdCBvZiByZXNvdXJjZSBp bmRpY2F0b3JzIGFzIGluZGljYXRpbmcgdGhlIHRhcmdldCBvciBsb2NhdGlvbiBvZiBhIHJlc291 cmNlLiBJdOKAmXMgc3RyZXRjaGluZyB0aGF0IGRlZmluaXRpb24sIGF0IHRoZSB2ZXJ5IGxlYXN0 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4i Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQpCdXQgYXMgSSBzYWlkLCBJ4oCZbSByZWFkaW5nIGJldHdlZW4gdGhlIGxpbmVz IGhlcmUuIElmIHRoaXMgaXMgdGhlIGludGVudGlvbiwgaXQgc2hvdWxkIGJlIGNsZWFybHkgc3Rh dGVkLiBBbHRlcm5hdGl2ZWx5LCByZW1vdmUgKG9yIGNoYW5nZSB0byBhIFNIT1VMRCkgdGhlIHJl cXVpcmVtZW50IHRoYXQgbXVsdGktdmFsdWUgYGF1ZGAgY2xhaW1zIG11c3Qgb25seSBjb250YWlu IGFsaWFzZXMgZm9yIHRoZSBzYW1lIHJlc291cmNlIGluZGljYXRvci48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0OzxhIGhyZWY9 Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91 bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7 Vml0dG9yaW89PGEgaHJlZj0ibWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5Nb25kYXksIERlY2VtYmVyIDE2LCAyMDE5IGF0IDI6NTEgUE08YnI+DQo8Yj5Ubzog PC9iPklFVEYgb2F1dGggV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90 OzxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5p LWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aS1kLWFu bm91bmNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aS1kLWFubm91bmNlQGlldGYub3JnPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzLnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 O21hcmdpbi1sZWZ0Oi41aW4iPg0KRGVhciBhbGwsPGJyPg0KSSBmaW5hbGx5IGZvdW5kIHRoZSB0 aW1lIHRvIHB1c2ggYSBuZXcgZHJhZnQgb2YgdGhlIEpXVCBwcm9maWxlIGZvciBBVHMuIFRoaXMg dmVyc2lvbiBpbmNvcnBvcmF0ZXMgdGhlIGZlZWRiYWNrIGtpbmRseSBwcm92aWRlZCBieSBCcmlh biBhbmQgQWFyb24gYXQgSUVURjEwNS48YnI+DQpVbmZvcnR1bmF0ZWx5IEkgZGlkbid0IGhhdmUg YSBjaGFuY2UgdG8gcGFydGljaXBhdGUgdG8gSUVURjEwNiwgaGVuY2Ugd2UgZGlkbid0IGRvIG11 Y2ggcHJvZ3Jlc3Mgc2luY2UgdGhlbi48YnI+DQpUaGVyZSBhcmUgc3RpbGwgdHdvIGFyZWFzIHdl IGRpZG4ndCBtYW5hZ2UgdG8gcmVhY2ggY29uc2Vuc3VzIG9uOjxicj4NCjxicj4NCjEuIE1lY2hh bmlzbXMgZm9yIHNpZ25hbGluZyB3aGV0aGVyIHRoZSBBVCB3YXMgb2J0YWluZWQgYnkgYSB1c2Vy IG9yIGFuIGFwcGxpY2F0aW9uPGJyPg0KPGJyPg0KVGhpcyBwb2ludCB3YXMgdGhlIHN1YmplY3Qg b2YgaW50ZW5zZSBkZWJhdGUgb24gdGhlIGxpc3QgbGVhZGluZyB0byBJRVRGMTA1Li48YnI+DQpP bmUgaW5zaWdodCB0aGF0IGVtZXJnZWQgZnJvbSB0aGUgSUVURjEwNSBkaXNjdXNzaW9uIHdhcyB0 aGF0IHRoZSB1c2UgY2FzZSBoZXJlIGlzIG1vcmUgYWJvdXQgd2hldGhlciB0aGUgQVQgaGFzIGJl ZW4gb2J0YWluZWQgdmlhIGEgZ3JhbnQgdGhhdCBhdXRoZW50aWNhdGVkIHRoZSBjbGllbnQgKHJl Z2FyZGxlc3Mgb2Ygd2hhdCBzcGVjaWZpYyBncmFudCB3YXMgdXNlZCkgdnMgYSBwdWJsaWMgY2xp ZW50IGdyYW50LSB0aGF0IGluZm9ybWF0aW9uDQogY2FuIGJlIHJlbGV2YW50IHRvIGEgcmVzb3Vy Y2UgYXMgaXQgZGV0ZXJtaW5lcyB3aGV0aGVyIHRoZSBpZGVudGl0eSBvZiB0aGUgY2xpZW50IGNh biBiZSB1c2VkIGluIGF1dGhvcml6YXRpb24gZGVjaXNpb25zIChpbiB0aGUgZm9ybWVyIGNhc2Up IG9yIG5vdCAoaW4gdGhlIHB1YmxpYyBjbGllbnQgY2FzZSkuIElmIHRoYXQncyB0aGUgc2NlbmFy aW8gd2UgYXJlIHRydWx5IGFmdGVyLCBhIHNpbXBsZSwgcG9zc2libHkgb3B0aW9uYWwgYm9vbGVh bg0KIGNsYWltIChzYXkgQXV0aGVudGljYXRlZENsaWVudCkgd291bGQgc3VmZmljZS48YnI+DQpO b3RlIGZvciB0aGUgcGVvcGxlIHdobyBkaWRuJ3QgcmVhZCB0aGUgc3BlYzogSSByZW1vdmVkIGFu eSByZWZlcmVuY2UgdG8gdGhpcyBhbHJlYWR5IGluIGRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRv a2VuLWp3dC0wMS4gSSB0aGluayB0aGlzIGlzIGFuIGltcG9ydGFudCBhbmQgdXNlZnVsIGluZm8g YW5kIHN0YW5kYXJkaXppbmcgaXQgd291bGQgYmUgYmVuZWZpY2lhbCBmb3IgbWlkZGxld2FyZSBh bmQgU0RLIGNyZWF0b3JzLCBidXQgdWx0aW1hdGVseQ0KIHRoaXMgaXMgYW4gaW50ZXJvcCBwcm9m aWxlIGhlbmNlIGlmIHRoZXJlJ3Mgbm8gc3Ryb25nIGRlc2lyZSB0byByZWFjaCBhbiBhZ3JlZW1l bnQgaGVyZSwgSSBhbSBhbHNvIE9LIHdpdGggZHJvcHBpbmcgdGhlIG1hdHRlciBhbmQgbm90IGFk ZHJlc3MgdGhpcyBmdW5jdGlvbiBpbiB0aGUgc3BlYy48YnI+DQpUbyBzdW1tYXJpemUsIEkgaGF2 ZSB0d28gcXVlc3Rpb25zIGhlcmU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Ij4NCkEuIERvIHdlIGJlbGlldmUgaXQncyB3b3J0aCBpdCB0byBmb3JtYWxpemUgaW4gdGhlIHBy b2ZpbGUgYSBtZWNoYW5pc20gdG8gaW5kaWNhdGUgd2hldGhlciB0aGUgY2xpZW50IHRoIG9idGFp bmVkIHRoZSBBVCBhdXRoZW50aWNhdGVkIGl0c2VsZiB3aXRoIHRoZSBBUz88YnI+DQpCLiBJZiB5 ZXMsIGFyZSB5b3UgT0sgd2lodCBhbiBvcHRpb25hbCBib29sIGNsYWltIGhlcmU/PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+ DQo8YnI+DQoyLiBDbGFpbXMgaW5kaWNhdGluZyBzZXNzaW9uIHByb3BlcnRpZXM8YnI+DQo8YnI+ DQpUaGlzIGlzIG9uZSBhcmVhIHdoZXJlIEkgYW0gZmFyIG1vcmUgcGFzc2lvbmF0ZSBhYm91dCwg YXMgaXQgcmVwcmVzZW50cyBhIGZ1bmRhbWVudGFsIGFzcGVjdCB0aGF0IHByb2R1Y3Rpb24gc3lz dGVtcyAoYW5kIGluIHBhcnRpY3VsYXIgMXN0IHBhcnR5IHNvbHV0aW9ucykgYWxyZWFkeSByZWx5 IG9uIGluIHRoZSBjdXJyZW50IHByb3ByaWV0YXJ5IEpUVyBBVHMuPGJyPg0KVGhlIHByb2ZpbGUg Y3VycmVudGx5IGluY2x1ZGVzIHRoZSBjbGFpbXMgYXV0aF90aW1lLCBhY3IgYW5kIGFtciAtIGNh cHR1cmluZyB0aGUgdmFsdWVzIG9mIHRob3NlIHByb3BlcnRpZXMgYXQgdGhlIHRpbWUgb2YgdGhl IGxhdGVzdCBhdXRoZW50aWNhdGlvbiB0aGUgdXNlciBwZXJmb3JtZWQgaW4gdGhlIHNlc3Npb24g dXNlZCB0byBpc3N1ZSB0aGUgY3VycmVudCBBVDogYXQgc2Vzc2lvbiBjcmVhdGlvbiwgYXQgYXV0 aCBzdGVwIHVwIHRpbWUgYW5kDQogc28gb24uPGJyPg0KVGhvc2UgYXJlIHZhbHVlcyB0aGF0IEFQ SSBuZWVkIGluIG9yZGVyIHRvIG1ha2UgYXV0aG9yaXphdGlvbiBkZWNpc2lvbnM7IGluIHRoZSBj YXNlIG9mIDFzdCBwYXJ0eSBBUElzLCB0aGUgQVQgaXMgdGhlIG9ubHkgYXJ0aWZhY3QgdGhleSBl dmVyIHJlY2VpdmUgaGVuY2UgdGhlcmUgaXMgbm8gb3RoZXIgd2F5IGZvciBhbiBBUEkgdG8gZGV0 ZXJtaW5lIHdoZXRoZXIgdGhlIGNhbGxlciBwZXJmb3JtZWQgc2F5IE1GQSBpbiBvcmRlciB0byBv YnRhaW4NCiB0aGUgY3VycmVudCBBVC48YnI+DQpTaW5jZSB0aGUgZmlyc3QgZHJhZnQsIHNvbWUg cGVvcGxlIHNpZ25hbGVkIGNvbmNlcm5zIGFib3V0IHRoZSBjdXJyZW50IG1lY2hhbmlzbXMgdGhy dSB3aGljaCB0aG9zZSBjbGFpbXMgZ2V0IHRoZWlyIHZhbHVlLiBGb3IgZXhhbXBsZSwgaXQgaGFz IGJlZW4gcHJvcG9zZWQgdG8gbWFpbnRhaW4gdGhlIG9yaWdpbmFsIHZhbHVlcyBvZiBhdXRoX3Rp bWUsIGFjciAmYW1wOyBhbXIgYW5kIGludHJvZHVjZSBhZGRpdGlvbmFsIGNsYWltcyB0byBpbmRp Y2F0ZQ0KIGNoYW5nZXMgKGxpa2Ugc3RlcHVwKS48YnI+DQpJIGFtIG5vdCBjbGVhciBvbiB3aGF0 IGNvbGQgZ28gd3Jvbmcgd2l0aCB0aGUgY3VycmVudCBhcHByb2FjaCwgaGVuY2UgSSBkb24ndCBo YXZlIGFuIGltbWVkaWF0ZSBncmFzcCBvZiBob3cgY2hhbmdlcyBsaWtlIHRoZSBhYm92ZSB3b3Vs ZCBoZWxwLjxicj4NCklmIHRoZSBwZW9wbGUgdW5jb21mb3J0YWJsZSB3aXRoIHRoZSBjdXJyZW50 IHByb3Bvc2FsIGNvdWxkIGRldGFpbCB0aGVpciBjb25jZXJuLCB3ZSBjYW4gYnJhaW5zdG9ybSB3 YXlzIHRvIG1ha2UgdGhhdCBpbmZvIGF2YWlsYWJsZSB0byBBUEkgaW4gYSBzYWZlciB3YXkuIFRv IHN1bW1hcml6ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVm dDozMC4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KQS4gRG8g eW91IGhhdmUgY29uY2VybnMgd2l0aCB0aGUgY3VycmVudCBhdXRoX3RpbWUsIGFybSwgYWNyIHBy b3Bvc2FsPyBDYW4geW91IHNwZWxsIHRoZW0gb3V0PyAocGxlYXNlIHJlYWQgdGhlIHJlbGV2YW50 IHBhcnRzIG9mIHRoZSBzcGVjIGJlZm9yZSBjaGltaW5nIGluIDopKTxicj4NCkIuIElmIHllcywg d2hhdCBjYW4gd2UgZG8gdG8gbWFrZSB0aGF0IGluZm8gYXZhaWxhYmxlIHRvIFJTcyBpbiBhIHdh eSB0aGF0IG1ha2VzIHlvdSBjb21mb3J0YWJsZT88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxicj4NCjxicj4N ClRoYW5rczxicj4NCjxicj4NClYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpPbiBN b24sIERlYyAxNiwgMjAxOSBhdCAyOjQ5IFBNICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6NC4uOHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluIj4NCjxicj4NCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+DQpUaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBX RyBvZiB0aGUgSUVURi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0 bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogSlNPTiBXZWIgVG9r ZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnM8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9yJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyA6IFZpdHRvcmlvIEJlcnRvY2NpPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IEZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi1vYXV0aC1h Y2Nlc3MtdG9rZW4tand0LTAzLnR4dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQ YWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAxNjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgOiAyMDE5LTEyLTE2PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5i c3A7ICZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgcHJvZmlsZSBmb3IgaXNzdWlu ZyBPQXV0aCAyLjAgYWNjZXNzPGJyPg0KJm5ic3A7ICZuYnNwO3Rva2VucyBpbiBKU09OIHdlYiB0 b2tlbiAoSldUKSBmb3JtYXQuJm5ic3A7IEF1dGhvcml6YXRpb24gc2VydmVycyBhbmQ8YnI+DQom bmJzcDsgJm5ic3A7cmVzb3VyY2Ugc2VydmVycyBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzIGNhbiBs ZXZlcmFnZSB0aGlzIHByb2ZpbGUgdG88YnI+DQombmJzcDsgJm5ic3A7aXNzdWUgYW5kIGNvbnN1 bWUgYWNjZXNzIHRva2VucyBpbiBpbnRlcm9wZXJhYmxlIG1hbm5lci48YnI+DQo8YnI+DQo8YnI+ DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+ DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9h dXRoLWFjY2Vzcy10b2tlbi1qd3QvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LzwvYT48YnI+ DQo8YnI+DQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt YWNjZXNzLXRva2VuLWp3dC0wMyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDM8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9h dXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0w MzwvYT48YnI+DQo8YnI+DQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFp bGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10 b2tlbi1qd3QtMDM8L2E+PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4N CnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRm Lm9yZzwvYT4uPGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLi5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_2518B18AAD9344E488D1E5F6AAE7B1BBamazoncom_-- From nobody Tue Dec 17 12:04:30 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EAD120077 for ; Tue, 17 Dec 2019 12:03:46 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHg779inLZvZ for ; Tue, 17 Dec 2019 12:03:39 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E06B1208A5 for ; Tue, 17 Dec 2019 12:03:12 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id r13so2220238ioa.3 for ; Tue, 17 Dec 2019 12:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PibTpVgOhPcY+qHzOosAvgNF+idd10+HwaPAWRcSrrU=; b=WIr+Nn9rBQKq4rdu/vpD7dpCFn9NUC1F0xtcXQd2i0CJ+QGkueIVfuMNTuUfn+yq98 yo1cJKvUsSkFu51iRnO9Q60vyBcpHe0RqU5opETE/6MxvxcqSrmorR7rU9+NUSMIeZtk XAfB8E9DoV3FVVvM+EVmTCSofFkHZKCCcxaiGa5qxoPyv6y7JENhakJS5xfHa9ZaTrCv p9ctQbFv567oBHhjE5XKo6UHW6Vnb4fZZ+NDDEwcULi8aBScdIFNYdTZP3s/7E9zHgUH JOz6ZZ7MBOF+vrcwv12W9wiW83EmZFtEKgDCEnZfNbrGSVrcHp0PpSOs+FdSlniNCrjQ K3sg== 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=PibTpVgOhPcY+qHzOosAvgNF+idd10+HwaPAWRcSrrU=; b=QvEpABJzT5UQfHOTPaX3AbrXQ9w1ddMw7l6537AoizaNEbpoAP1xgygpZQ846c8ljg EgD1GFe+ZACPrpZl/BIdJYOZSfHzsGy4iIpDQONpK5TTfB2UYstx5cBtkU+/HUbV0kS1 Z4EH/8xoRVfzm5ZPpsS5ibV6KnaVVRF9RmItjdLAW4/g2izRG0xOAZK3vyyCGSLuvZM8 DbneRl6VaS7WUv7LpyeOrVt/L5ypJoQ07wxZYNA4JCLQ/oxsNwagrEedoJQtjT2eyFm0 5bt2hTOfC4oRO+BfZfMfadQctOJ/3mprGO7j9UiITKV3YQPWQ+PMoC9uON06Ie20KMQx mVEg== X-Gm-Message-State: APjAAAUa9bZ/SP13UqyY6ENUlpNiOed9UtleWUwheLIGVvon1ioautd9 3la2uOvpLLeYfc3eSnSQKtiSg28T7gYzdfN5uSflYg== X-Google-Smtp-Source: APXvYqwu7xPOJtS5q46SiKS01/6JGREgzIWuuPZ1938614ClFG9FgGrRD4dEWk4d76s3yxVXkL0J4wXq95ndI3jv7sI= X-Received: by 2002:a5d:8954:: with SMTP id b20mr4964535iot.281.1576612990477; Tue, 17 Dec 2019 12:03:10 -0800 (PST) MIME-Version: 1.0 References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> <2518B18A-AD93-44E4-88D1-E5F6AAE7B1BB@amazon.com> In-Reply-To: <2518B18A-AD93-44E4-88D1-E5F6AAE7B1BB@amazon.com> From: Vittorio Bertocci Date: Tue, 17 Dec 2019 12:02:59 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: Vittorio Bertocci , IETF oauth WG , "i-d-announce@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003f13450599ebd12b" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 20:03:47 -0000 --0000000000003f13450599ebd12b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > The one-RS-per-AT model is an ideal that simply doesn=E2=80=99t match rea= lity. That's a pretty strong statement :) I have worked with a very large number of developers, on a very large number of applications. I don't dispute that your experience might be different, but the one AT per RS is daily reality for hundreds of thousands of apps in production today. That's real by any measure of reality. The fact that AD offers RTs that behave like TGTs makes it possible. RAR is an interesting development, but it's in the inception phase. The aud and scopes claims are already in nearly all the proprietary JWT implementations in production today, as shown in the research I presented when the draft was adopted by the WG, hence it seems natural to include them in an interop profile. Nothing prevents us from developing it further as new approaches gain traction on the market, but for the time being I think the value of this would be to bring some order in existing implementations and contain abuses such as id_tokens used in lieu of access tokens today. I=E2=80=99m skeptical of the idea that there is just one level of client id= entity > proofing that RSes might care about. In the scenario that led me to include this item in the discussion, knowledge of that level isn't necessary. Again, I agree it would be useful to define those levels, but I don't think it would be in scope here. If inclusion of that info in the JWT AT would be conditional to do all that work, I'd much rather drop that aspect in favor of making faster progress. Without taking the whole picture into account, there is significant risk > that we will define something that turns out to be woefully insufficient > (or worse, establishes an anti-pattern). That said, I agree that it=E2=80= =99s > probably not appropriate for this draft, and recommend dropping these > claims. They can always be defined in a separate draft, along with the > other elements necessary to communicate step-up requirements. Could you expand on a concrete scenario that would lead to an antipattern because of the presence of those claims in the profile? There is already logic out there predicated on those claim values, precisely because ID_token defines them and vendors latch onto them. I am concerned that if we don't include those claims in the profile, people will simply keep using ID_tokens for calling APIs. On Tue, Dec 17, 2019 at 11:39 AM Richard Backman, Annabelle < richanna@amazon.com> wrote: > > In any case the intent was always to only allow a singe resource per AT= =E2=80=A6 > > > > My confusion actually comes from the last paragraph of =C2=A73, where it = says > =E2=80=9CIf a scope parameter is present in the request, the authorizatio= n server > SHOULD use it to infer the value of the default resource indicator to be > used in the aud claim.=E2=80=9D I interpreted that to leave room for an A= S > inferring the same =E2=80=9Cgeneric=E2=80=9D resource indicator for resou= rces served by > different RSes. The one-RS-per-AT model is an ideal that simply doesn=E2= =80=99t > match reality. Clients don=E2=80=99t want to have to juggle a bunch of di= fferent > tokens, nor should they need to. I=E2=80=99m coming to think that we shou= ldn=E2=80=99t > actually use `aud` and `scope` in JWT ATs at all, and instead adopt the > structure RAR defines used for the `authorization_details` parameter (I > think some iteration is required, but it seems natural for these two to > describe authorizations in the same or compatible ways). > > > > > > > =E2=80=A6the resource wants to know whether this particular token was o= btained > proving the identity of the client=E2=80=A6 > > > > I=E2=80=99m skeptical of the idea that there is just one level of client = identity > proofing that RSes might care about. There might be some clear lines that > can be drawn, but we should be explicit about what those lines represent, > e.g., =E2=80=9Cclient authenticated using pre-established credential=E2= =80=9D, =E2=80=9Cclient is > running on end user-controlled device=E2=80=9D, etc. > > > > > > > I am not trying to create a complete framework for handling step up and > the like, I am trying to create an interoperable representation of those > values no matter how they were obtained. > > > > Without taking the whole picture into account, there is significant risk > that we will define something that turns out to be woefully insufficient > (or worse, establishes an anti-pattern). That said, I agree that it=E2=80= =99s > probably not appropriate for this draft, and recommend dropping these > claims. They can always be defined in a separate draft, along with the > other elements necessary to communicate step-up requirements. > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Vittorio Bertocci > *Date: *Monday, December 16, 2019 at 9:31 PM > *To: *"Richard Backman, Annabelle" > *Cc: *IETF oauth WG , Vittorio Bertocci < > Vittorio@auth0.com>, "i-d-announce@ietf.org" > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: > draft-ietf-oauth-access-token-jwt-03.txt > > > > Re: aliases, I see where the confusion is coming from! > > I updated the request section, but the session 2.2 data structure still > mentions the aliases. That should be cleaned up as well. > > In any case the intent was always to only allow a singe resource per AT, > the alias list was only for helping in cases where an AS identifies the > same resource thru multiple IDs and the actual aud value depends on what = ID > the client requested. However we discussed this with Brian and he convinc= ed > me that it was just too ambiguous- your remark reinforces that impression= . > I=E2=80=99ll clean up 2.2 and eliminate references to aliases from there = as well. > > Thanks! > > > > > > On Mon, Dec 16, 2019 at 20:19 Vittorio Bertocci > wrote: > > Thanks Annabelle. > > > > Does a mobile app that uses Dynamic Client Registration to establish a > client secret count as an =E2=80=9Cauthenticated client=E2=80=9D? > > I think it should count, tho I am not sure what the RS would do with it. > Dynamic client registration would likely not have much use for this. > > In the cases I have seen, the idea is that a client (whose clientID is > already known to the RS) can obtain tokens thru different grants, some of > them confidential and others public; and the resource wants to know wheth= er > this particular token was obtained proving the identity of the client so > that it can decide whether to grant extra privileges for that > particular client in the current call. This scenario does not require the > extra details about authentication method/strength you mention that, I > agree, would be pretty hard to reach consensus on. > > TL;DR: there is at least one scenario that is satisfied by the simple > bool, as the previous knowledge of the client solves the issues you menti= on > out of band. > > > > authentication session properties: > > Let me try another angle. Say that I perform an authz code grant asking > for AT, ID_T and RT- obtaining AT', ID_T' and RT'. > > The values of auth_time, acr and amr in AT' will be the same as the > corresponding claims in ID_T'. When the client uses RT' to obtain AT`N, > AT'N+1 etc etc, the values of those claims will remain the same for every > AT'n obtained by RT'. > > Now, imagine that something happens (ignore what for the time being) that > causes the client to perform a step up auth, which requires the user to > perform interactive auth hence results in a new authz grant. The client > will obtain a new tuple AT", ID_T" and RT". The exact same rules describ= ed > for the ' tuple apply, with the new values determined by the new > authentication: AT" auth_time/acr/amr will be the same as ID_T", and thos= e > values will remain unchanged for every AT"n derived by RT". > If we want this to apply to the implicit flow as well, you can substitute > the RT with the session artifact. > > Does that help clarifying the intent? If yes, do you feel that the curren= t > language does not describe this? > > > > use case for putting these in the access token > > I am not trying to create a complete framework for handling step up and > the like, I am trying to create an interoperable representation of those > values no matter how they were obtained. > > Consider the case in which an API allows certain operations only if a > given amr value is present in the token. Whether that amr is required > upfront on first authentication, as step up or any other reason is out of > scope for this profile IMO: the AS might have all sorts of heuristics tha= t > determine that (user membership to a given group or role; geofencing; ris= k > scoring; etc) that have nothing to do with scopes requested, and are not > statically determined by RS-AS communications. > > Now, I agree that formalizing how a RS communicates to the AS via the > client the need to step up and in what terms would be super useful; howev= er > I think that's well beyond the scope of this profile.. Various vendors > already have their own mechanisms for handling step up signaling from RS = to > AS (I am very familiar with the Microsoft one) and all I am looking for i= s > a way of standardizing how to represent the outcomes, so that API gateway= s > and SDK providers can provide tools that work across vendors; and possibl= y > reuse some of the reasoning that was already done for id_tokens. > > TL;DR: I think we are doing something useful in formalizing how to embed > that info an ATs even if we don't force vendors to give up their current > mechanisms to populate those values. > > > > Regarding access tokens that are used to access different resource server= s > > The intent is to explicitly disallow the use of an AT with multiple > resource servers. If a client wants to talk with 2 different RSes, the > client should ask for 2 different ATs. > > The spec is unambiguous on this IMO, here's the language I use in 03. > > > > If it receives a request for an access token containing more than one > > resource parameter, an authorization server issuing JWT access tokens > > MUST reject the request and fail with "invalid_request" as described > > in section 4.1.2.1 of [RFC6749] or with "invalid_target" as defined > > in section 2 of [ResourceIndicators ]. See Se= ction 2.2 and Section 5 > > for more details on how this measure ensures there's no confusion on > > to what resource the access token granted scopes apply. > > Is it possible you are referring to an older draft? > > > > > > On Mon, Dec 16, 2019 at 5:28 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > 1. Regarding AuthenticatedClient: > > Does a mobile app that uses Dynamic Client Registration to establish a > client secret count as an =E2=80=9Cauthenticated client=E2=80=9D? What if= that registration > included an assertion signed by a trusted entity (e.g., device management > software) using a certificate that had been pushed to the device? Without > some kind of NIST LoA-style definition of =E2=80=9Cauthenticated=E2=80=9D= , a single Boolean > =E2=80=9CAuthenticatedClient=E2=80=9D value is too ambiguous to be useful= . However, I=E2=80=99m > skeptical that we could find consensus on what that definition should be, > and it may be better to define client analogs to `acr` and `amr` that > provide standard ways of expressing client authentication details without > getting prescriptive about what kind of authentication is =E2=80=9Cgood e= nough.=E2=80=9D > > > > 2. Regarding authentication session properties: > > I=E2=80=99m confused by the definitions given for `auth_time`, `acr`, and= `amr`. > For `auth_time`, it says: > > > > =E2=80=9C=E2=80=A6its value will either remain the same for all the JWT a= ccess tokens > issued within that session or be updated to the time of latest > authentication if reauthentication occurred mid-session=E2=80=A6=E2=80=9D > > > > But the =E2=80=9CFor example=E2=80=9D at the end of that definition impli= es that > `auth_time` will not be updated. The definitions for `acr` and `amr` say > the same, but also say that the =E2=80=9C=E2=80=A6same considerations pre= sented for > auth_time apply=E2=80=A6=E2=80=9D What=E2=80=99s the intention here: are = they fixed, updated, or is > it up to the deployment to decide? > > > > I=E2=80=99d like to better understand the use case for putting these in t= he access > token. If the RS is making authorization decisions based on these claims, > that implies that the RS cannot rely on the AS to determine (e.g., from t= he > requested scope) the required authentication method(s), freshness, etc. I= f > the AS could be relied upon for this, then presumably it would not issue > RTs and ATs for a scope without requiring the end user to meet the > appropriate authentication requirements. If this is the case, then the RS > must have a way to signal to the client (and then the AS) that a step-up > authentication is required. Is there an existing mechanism through which > they could do this? All I can come up with is cramming the information in= to > the scope attribute of a WWW-Authenticate challenge, but that has the sam= e > scope opacity violation problem as described in this draft=E2=80=99s Secu= rity > Considerations. Without a clear way to express the step-up requirements, > this feels incomplete.. > > > > 3. Regarding access tokens that are used to access different resource > servers: > Reading between the lines, I **think** the intention is that a JWT access > token that is intended to be used to access two different resources at tw= o > different RSes should look something like: > > > > { > > "aud": "https://generic-resource-indicator.example.com/", > > "scope": "resource_foo resource_bar", > > ... > > } > > > And the expectation is that each RS should recognize that generic > audience. Is this correct? If so it seems to go against the spirit of > resource indicators as indicating the target or location of a resource. > It=E2=80=99s stretching that definition, at the very least. > > > > But as I said, I=E2=80=99m reading between the lines here. If this is the > intention, it should be clearly stated. Alternatively, remove (or change = to > a SHOULD) the requirement that multi-value `aud` claims must only contain > aliases for the same resource indicator. > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Vittorio Bertocci > > *Date: *Monday, December 16, 2019 at 2:51 PM > *To: *IETF oauth WG > *Cc: *"i-d-announce@ietf.org" > *Subject: *Re: [OAUTH-WG] I-D Action: > draft-ietf-oauth-access-token-jwt-03.txt > > > > Dear all, > I finally found the time to push a new draft of the JWT profile for ATs. > This version incorporates the feedback kindly provided by Brian and Aaron > at IETF105. > Unfortunately I didn't have a chance to participate to IETF106, hence we > didn't do much progress since then. > There are still two areas we didn't manage to reach consensus on: > > 1. Mechanisms for signaling whether the AT was obtained by a user or an > application > > This point was the subject of intense debate on the list leading to > IETF105.. > One insight that emerged from the IETF105 discussion was that the use cas= e > here is more about whether the AT has been obtained via a grant that > authenticated the client (regardless of what specific grant was used) vs = a > public client grant- that information can be relevant to a resource as it > determines whether the identity of the client can be used in authorizatio= n > decisions (in the former case) or not (in the public client case). If > that's the scenario we are truly after, a simple, possibly optional boole= an > claim (say AuthenticatedClient) would suffice. > Note for the people who didn't read the spec: I removed any reference to > this already in draft-ietf-oauth-access-token-jwt-01. I think this is an > important and useful info and standardizing it would be beneficial for > middleware and SDK creators, but ultimately this is an interop profile > hence if there's no strong desire to reach an agreement here, I am also O= K > with dropping the matter and not address this function in the spec. > To summarize, I have two questions here: > > A. Do we believe it's worth it to formalize in the profile a mechanism to > indicate whether the client th obtained the AT authenticated itself with > the AS? > B. If yes, are you OK wiht an optional bool claim here? > > > 2. Claims indicating session properties > > This is one area where I am far more passionate about, as it represents a > fundamental aspect that production systems (and in particular 1st party > solutions) already rely on in the current proprietary JTW ATs. > The profile currently includes the claims auth_time, acr and amr - > capturing the values of those properties at the time of the latest > authentication the user performed in the session used to issue the curren= t > AT: at session creation, at auth step up time and so on. > Those are values that API need in order to make authorization decisions; > in the case of 1st party APIs, the AT is the only artifact they ever > receive hence there is no other way for an API to determine whether the > caller performed say MFA in order to obtain the current AT. > Since the first draft, some people signaled concerns about the current > mechanisms thru which those claims get their value. For example, it has > been proposed to maintain the original values of auth_time, acr & amr and > introduce additional claims to indicate changes (like stepup). > I am not clear on what cold go wrong with the current approach, hence I > don't have an immediate grasp of how changes like the above would help. > If the people uncomfortable with the current proposal could detail their > concern, we can brainstorm ways to make that info available to API in a > safer way. To summarize: > > A. Do you have concerns with the current auth_time, arm, acr proposal? Ca= n > you spell them out? (please read the relevant parts of the spec before > chiming in :)) > B. If yes, what can we do to make that info available to RSs in a way tha= t > makes you comfortable? > > > > Thanks > > V. > > > > On Mon, Dec 16, 2019 at 2:49 PM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IET= F. > > Title : JSON Web Token (JWT) Profile for OAuth 2.0 > Access Tokens > Author : Vittorio Bertocci > Filename : draft-ietf-oauth-access-token-jwt-03.txt > Pages : 16 > Date : 2019-12-16 > > Abstract: > This specification defines a profile for issuing OAuth 2.0 access > tokens in JSON web token (JWT) format. Authorization servers and > resource servers from different vendors can leverage this profile to > issue and consume access tokens in interoperable manner. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-03 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-0= 3 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp..ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0000000000003f13450599ebd12b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The one-= RS-per-AT model is an ideal that simply doesn=E2=80=99t match reality.=C2= =A0=C2=A0
That's a pretty strong statement :) I have w= orked with a very large number of developers, on a very large number of app= lications. I don't dispute that your experience might be different, but= the one AT per RS is daily reality for hundreds of thousands of apps in pr= oduction today. That's real by any measure of reality. The fact that AD= offers RTs that behave like TGTs makes it possible.=C2=A0
RAR is= an interesting development, but it's in the inception phase. The aud a= nd scopes claims are already in nearly all the proprietary JWT implementati= ons in production today, as shown in the research I presented when the draf= t was adopted by the WG, hence it seems natural to include them in an inter= op profile.
Nothing prevents us from developing it further as new= approaches=C2=A0gain traction on the market, but for the time being I thin= k the value of this would be to bring some order in existing implementation= s=C2=A0and contain abuses such as id_tokens used in lieu of access tokens t= oday.

I=E2=80=99m skeptical of the idea that there is just one level of client i= dentity proofing that RSes might care about.=C2=A0
In the = scenario that led me to include this item in the discussion, knowledge of t= hat level isn't necessary. Again, I agree it would be useful to define = those levels, but I don't think it would be in scope here. If inclusion= of that info in the JWT AT would be conditional to do all that work, I'= ;d much rather drop that aspect in favor of making faster progress.

Without taki= ng the whole picture into account, there is significant risk that we will d= efine something that turns out to be woefully insufficient (or worse, estab= lishes an anti-pattern). That said, I agree that it=E2=80=99s probably not = appropriate for this draft, and recommend dropping these claims. They can a= lways be defined in a separate draft, along with the other elements necessa= ry to communicate step-up requirements.=C2=A0
Could you ex= pand on a concrete scenario that would lead to an antipattern because of th= e presence of those claims in the profile?
There is already l= ogic out there predicated on those claim values, precisely because ID_token= defines them and vendors latch onto them. I am concerned that if we don= 9;t include those claims in the profile, people will simply keep using ID_t= okens for calling APIs.
=C2=A0

On Tue, Dec 17, 2019 at 1= 1:39 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

> In any case the intent was always to only allow= a singe resource per AT=E2=80=A6

=C2=A0

My confusion actually comes from the last paragraph = of =C2=A73, where it says =E2=80=9CIf a scope parameter is present in the r= equest, the authorization server SHOULD use it to infer the value of the de= fault resource indicator to be used in the aud claim.=E2=80=9D I interpreted that to leave room for an AS inferring the s= ame =E2=80=9Cgeneric=E2=80=9D resource indicator for resources served by di= fferent RSes. The one-RS-per-AT model is an ideal that simply doesn=E2=80= =99t match reality. Clients don=E2=80=99t want to have to juggle a bunch of different tokens, nor should they need to. I=E2=80=99m coming to think tha= t we shouldn=E2=80=99t actually use `aud` and `scope` in JWT ATs at all, an= d instead adopt the structure RAR defines used for the `authorization_detai= ls` parameter (I think some iteration is required, but it seems natural for these two to describe authorizations in the same = or compatible ways).

=C2=A0

=C2=A0

> =E2=80=A6the resource wants to know whether thi= s particular token was obtained proving the identity of the client=E2=80=A6=

=C2=A0

I=E2=80=99m skeptical of the idea that there is just= one level of client identity proofing that RSes might care about. There mi= ght be some clear lines that can be drawn, but we should be explicit about = what those lines represent, e.g., =E2=80=9Cclient authenticated using pre-established credential=E2=80=9D, =E2=80=9Cclient i= s running on end user-controlled device=E2=80=9D, etc.

=C2=A0

=C2=A0

> I am not trying to create a complete framework = for handling step up and the like, I am trying to create an interoperable r= epresentation of those values no matter how they were obtained.

=C2=A0

Without taking the whole picture into account, there= is significant risk that we will define something that turns out to be woe= fully insufficient (or worse, establishes an anti-pattern). That said, I ag= ree that it=E2=80=99s probably not appropriate for this draft, and recommend dropping these claims. They can always be de= fined in a separate draft, along with the other elements necessary to commu= nicate step-up requirements.

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Bac= kman

AWS Identity

=C2=A0

=C2=A0

From: Vittorio Bertocci <= ;Vittorio=3D40auth0.com@dmarc.ietf.org>
Date: Monday, December 16, 2019 at 9:31 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: IETF oauth WG <oauth@ietf.org>, Vittorio Bertocci <Vittorio@auth0.com>, "i-d-announce@ietf.org" <i-d= -announce@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-o= auth-access-token-jwt-03.txt

=C2=A0

Re: aliases, I see where= the confusion is coming from!

I updated the request se= ction, but the session 2.2 data structure still mentions the aliases. That = should be cleaned up as well.=C2=A0

In any case the intent w= as always to only allow a singe resource per AT, the alias list was only fo= r helping in cases where an AS identifies the same resource thru multiple I= Ds and the actual aud value depends on what ID the client requested. However we discussed this with Brian and he = convinced me that it was just too ambiguous- your remark reinforces that im= pression. I=E2=80=99ll clean up 2.2 and eliminate references to aliases fro= m there as well.

Thanks!

=C2=A0

=C2=A0

On Mon, Dec 16, 2019 at = 20:19 Vittorio Bertocci <Vittorio@auth0.com> wrote:

Thanks Annabelle.

=C2=A0

Does a mobile app that u= ses Dynamic Client Registration to establish a client secret count as an = =E2=80=9Cauthenticated client=E2=80=9D?=C2=A0=C2=A0

I think it should count,= tho I am not sure what the RS would do with it. Dynamic client registratio= n would likely not have much use for this.

In the cases I have seen= , the idea is that a client (whose clientID is already known to the RS) can= obtain tokens thru different grants, some of them confidential and others = public; and the resource wants to know whether this particular token was obtained proving the identity of the cli= ent so that it can decide whether to grant extra privileges for that partic= ular=C2=A0client in the current call. This scenario does not require the ex= tra details about authentication method/strength you mention that, I agree, would be pretty hard to reach consensus on.<= /u>

TL;DR: there is at least= one scenario that is satisfied by the simple bool, as the previous knowled= ge of the client solves the issues you mention out of band.=C2=A0=

=C2=A0

authentication session p= roperties:=C2=A0

=C2=A0Let me try another= angle. Say that I perform an authz code grant asking for AT, ID_T and RT- = obtaining AT', ID_T' and RT'.=C2=A0

The values of auth_time,= acr and amr in AT' will be the same as the corresponding claims in ID_= T'. When the client uses RT' to obtain AT`N, AT'N+1 etc etc, th= e values of those claims will remain the same for every AT'n obtained by RT'.

Now, imagine that someth= ing happens (ignore what for the time being) that causes the client to perf= orm a step up auth, which requires the user to perform interactive auth hen= ce results in a new authz grant. The client will obtain a new tuple=C2=A0 AT", ID_T" and RT". Th= e exact same rules described for the ' tuple apply, with the new values= determined by the new authentication: AT" auth_time/acr/amr will be t= he same as ID_T", and those values will remain unchanged for every AT"n derived by RT".
If we want this to apply to the implicit flow as well, you can substitute t= he RT with the session artifact.=C2=A0

Does that help clarifyin= g the intent? If yes, do you feel that the current language does not descri= be this?

=C2=A0

use case for putting the= se in the access token=C2=A0

I am not trying to creat= e a complete framework for handling step up and the like, I am trying to cr= eate an interoperable representation of those values no matter how they wer= e obtained.=C2=A0

Consider the case in whi= ch an API allows certain operations only if a given amr value is present in= the token. Whether that amr is required upfront on first authentication, a= s step up or any other reason is out of scope for this profile IMO: the AS might have all sorts of heuristics t= hat determine that (user membership to a given group or role; geofencing; r= isk scoring; etc) that have nothing to do with scopes requested, and are no= t statically determined by RS-AS communications.=C2=A0

Now, I agree that formal= izing how a RS communicates to the AS via the client the need to step up an= d in what terms would be super=C2=A0useful; however I think that's well= beyond the scope of this profile.. Various vendors already have their own mechanisms for handling step up signaling from RS t= o AS (I am very familiar with the Microsoft=C2=A0one) and all I am looking = for is a way of standardizing how to represent the outcomes, so that API ga= teways and SDK providers can provide tools that work across vendors; and possibly reuse some of the reasoning t= hat was already done for id_tokens.

TL;DR: I think we are do= ing something useful in formalizing how to embed that info an ATs even if w= e don't force vendors to give up their current mechanisms to populate t= hose values.

=C2=A0

Regarding access tokens = that are used to access different resource servers

The intent is to explici= tly disallow the use of an AT with multiple resource servers. If a client w= ants to talk with 2 different RSes, the client should ask for 2 different A= Ts.

The spec is unambiguous = on this IMO, here's the language I use in 03.

=C2=A0

If it receives a request for an access t=
oken containing more than one
=C2=A0=C2=A0 resour=
ce parameter, an authorization server issuing JWT access tokens
=C2=A0=C2=A0 MUST r=
eject the request and fail with "invalid_request" as described=

=C2=A0=C2=A0 in section=C2=A04.1.2.1 of =
[RFC6749] or with "invalid_target" as defined
=C2=A0=C2=A0 in sec=
tion 2 of [ResourceIndicators].=C2=A0 See Sec=
tion 2.2 and Section 5
=C2=A0=C2=A0 for mo=
re details on how this measure ensures there's no confusion on
=C2=A0=C2=A0 to wha=
t resource the access token granted scopes apply.

=C2=A0 Is it possible yo= u are referring to an older draft?=C2=A0=C2=A0

=C2=A0

=C2=A0

On Mon, Dec 16, 2019 at = 5:28 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>= wrote:

1. Regarding AuthenticatedClient:

Does a mobile app that uses Dynamic Client Registration to establish a clie= nt secret count as an =E2=80=9Cauthenticated client=E2=80=9D? What if that = registration included an assertion signed by a trusted entity (e.g., device= management software) using a certificate that had been pushed to the device? Without some kind of NIST LoA-style definition = of =E2=80=9Cauthenticated=E2=80=9D, a single Boolean =E2=80=9CAuthenticated= Client=E2=80=9D value is too ambiguous to be useful. However, I=E2=80=99m s= keptical that we could find consensus on what that definition should be, and it may be better to define client analogs to `acr` and `amr` that prov= ide standard ways of expressing client authentication details without getti= ng prescriptive about what kind of authentication is =E2=80=9Cgood enough.= =E2=80=9D

=C2=A0

2. Regarding authentication session properties:

I=E2=80=99m confused by the definitions given for `auth_time`, `acr`, and `= amr`. For `auth_time`, it says:

=C2=A0

=E2=80=9C=E2=80=A6its value will either remain the same for all the JWT acc= ess tokens issued within that session or be updated to the time of latest a= uthentication if reauthentication occurred mid-session=E2=80=A6=E2=80=9D=

=C2=A0

But the =E2=80=9CFor example=E2=80=9D at the end of that definition implies= that `auth_time` will not be updated. The definitions for `acr` and `amr` = say the same, but also say that the =E2=80=9C=E2=80=A6same considerations p= resented for auth_time apply=E2=80=A6=E2=80=9D What=E2=80=99s the intention= here: are they fixed, updated, or is it up to the deployment to decide?

=C2=A0

I=E2=80=99d like to better understand the use case for putting these in the= access token. If the RS is making authorization decisions based on these c= laims, that implies that the RS cannot rely on the AS to determine (e.g., f= rom the requested scope) the required authentication method(s), freshness, etc. If the AS could be relied upon for this, then p= resumably it would not issue RTs and ATs for a scope without requiring the = end user to meet the appropriate authentication requirements. If this is th= e case, then the RS must have a way to signal to the client (and then the AS) that a step-up authenticatio= n is required. Is there an existing mechanism through which they could do t= his? All I can come up with is cramming the information into the scope attr= ibute of a WWW-Authenticate challenge, but that has the same scope opacity violation problem as described in this= draft=E2=80=99s Security Considerations. Without a clear way to express th= e step-up requirements, this feels incomplete..

=C2=A0

3. Regarding access tokens that are used to access different resource serve= rs:
Reading between the lines, I *think* the intention is that a JWT acc= ess token that is intended to be used to access two different resources at = two different RSes should look something like:

=C2=A0

{

"aud": "https://gener= ic-resource-indicator.example.com/",

"scope": "resource_foo r= esource_bar",

...

}


And the expectation is that each RS should recognize that generic audience.= Is this correct? If so it seems to go against the spirit of resource indic= ators as indicating the target or location of a resource. It=E2=80=99s stre= tching that definition, at the very least.

=C2=A0

But as I said, I=E2=80=99m reading between the lines here. If this is the i= ntention, it should be clearly stated. Alternatively, remove (or change to = a SHOULD) the requirement that multi-value `aud` claims must only contain a= liases for the same resource indicator.

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org> on behalf of Vitt= orio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>
Date: Monday, December 16, 2019 at 2:51 PM
To: IETF oauth WG <oauth@ietf.org>
Cc: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jw= t-03.txt

=C2=A0

Dear all,
I finally found the time to push a new draft of the JWT profile for ATs. Th= is version incorporates the feedback kindly provided by Brian and Aaron at = IETF105.
Unfortunately I didn't have a chance to participate to IETF106, hence w= e didn't do much progress since then.
There are still two areas we didn't manage to reach consensus on:

1. Mechanisms for signaling whether the AT was obtained by a user or an app= lication

This point was the subject of intense debate on the list leading to IETF105= ..
One insight that emerged from the IETF105 discussion was that the use case = here is more about whether the AT has been obtained via a grant that authen= ticated the client (regardless of what specific grant was used) vs a public= client grant- that information can be relevant to a resource as it determines whether the identity of the= client can be used in authorization decisions (in the former case) or not = (in the public client case). If that's the scenario we are truly after,= a simple, possibly optional boolean claim (say AuthenticatedClient) would suffice.
Note for the people who didn't read the spec: I removed any reference t= o this already in draft-ietf-oauth-access-token-jwt-01. I think this is an = important and useful info and standardizing it would be beneficial for midd= leware and SDK creators, but ultimately this is an interop profile hence if there's no strong desire to reach = an agreement here, I am also OK with dropping the matter and not address th= is function in the spec.
To summarize, I have two questions here:

A. Do we believe it's worth it to formalize in the profile a mechanism = to indicate whether the client th obtained the AT authenticated itself with= the AS?
B. If yes, are you OK wiht an optional bool claim here?


2. Claims indicating session properties

This is one area where I am far more passionate about, as it represents a f= undamental aspect that production systems (and in particular 1st party solu= tions) already rely on in the current proprietary JTW ATs.
The profile currently includes the claims auth_time, acr and amr - capturin= g the values of those properties at the time of the latest authentication t= he user performed in the session used to issue the current AT: at session c= reation, at auth step up time and so on.
Those are values that API need in order to make authorization decisions; in= the case of 1st party APIs, the AT is the only artifact they ever receive = hence there is no other way for an API to determine whether the caller perf= ormed say MFA in order to obtain the current AT.
Since the first draft, some people signaled concerns about the current mech= anisms thru which those claims get their value. For example, it has been pr= oposed to maintain the original values of auth_time, acr & amr and intr= oduce additional claims to indicate changes (like stepup).
I am not clear on what cold go wrong with the current approach, hence I don= 't have an immediate grasp of how changes like the above would help. If the people uncomfortable with the current proposal could detail their co= ncern, we can brainstorm ways to make that info available to API in a safer= way. To summarize:

A. Do you have concerns with the current auth_time, arm, acr proposal? Can = you spell them out? (please read the relevant parts of the spec before chim= ing in :))
B. If yes, what can we do to make that info available to RSs in a way that = makes you comfortable?



Thanks

V.

=C2=A0

On Mon, Dec 16, 2019 at 2:49 PM <internet-drafts@ietf.org> wrote:


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Vitt= orio Bertocci
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-access-token-jwt-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-12-16

Abstract:
=C2=A0 =C2=A0This specification defines a profile for issuing OAuth 2.0 acc= ess
=C2=A0 =C2=A0tokens in JSON web token (JWT) format.=C2=A0 Authorization ser= vers and
=C2=A0 =C2=A0resource servers from different vendors can leverage this prof= ile to
=C2=A0 =C2=A0issue and consume access tokens in interoperable manner.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-ac= cess-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-tok= en-jwt-03
https://datatracker.ietf.org/doc/html/draft-i= etf-oauth-access-token-jwt-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-= oauth-access-token-jwt-03


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

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

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

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

--0000000000003f13450599ebd12b-- From nobody Tue Dec 17 12:38:19 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFF812087A for ; Tue, 17 Dec 2019 12:38: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, 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 EbV494zXfGp2 for ; Tue, 17 Dec 2019 12:38:10 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20702120125 for ; Tue, 17 Dec 2019 12:38:10 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id m24so4272790wmc.3 for ; Tue, 17 Dec 2019 12:38:10 -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=7BteLxekh2u6P8mLq8oD5rxHnO6w2da+Tq9t7oua0WA=; b=hr22rOKEoktP5qhAauwGfP1/LxFB3Uq1sr0lxqNafRMSN2mm46Pc4xX1xXIDXUaxP0 I+DaK9TDhaFf+kLKK2owwu5M/l22lbuuQOegB1HH3mwMGE8DuOtFQa/M+hTLIxqEvQDU YFhMzt7LofFG0YMI8LLkRf723gMiAAff0917hcViIa7AgAuN5huvedG62JQxsVSs5N73 XxdpNfC4aDWz279JMX1drE/iRM658SQZ4hIO5Rc6zYP6u49C1cXhPAvVtHZ/fXncOfIQ G2RwBqzPzzMpSzwnlgO0fJiY0TeT5j+L1O9WxYrGGSXP1tgy1yhH1sCYmbnNRqzRTGva NXYw== 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=7BteLxekh2u6P8mLq8oD5rxHnO6w2da+Tq9t7oua0WA=; b=P1eQSG5ZyNthKtlFlvWdxjqQYmZF4lrrFJ+S4s4ATs+UbnErOYPumvLxu1oZoqWoE4 V+Mtu8r5u1NlcDdm1RRNLNWaYU9PiQH5hFRfHeY5dFCFQ+y6nB3ZQaUdMlB9d0k9Eefq UFRnPUD+p/2S3tzqdOlYurYkpMw/9ebftdYIeJPfPGMECdNgCf2TwR8YZn9pauGaIN8H Vv6OzMuuH1Ua2CB5woxEqHQWffL2uCrXbualCvCw0lD2NO+ghwGVUzxCDkR/pVijIgxw b1kGvLrQGQPsA48VOfYzG8S//ZRDyvTNYLKFsHoKbS2YhWR4nq1cqPr8gEGe6oBmKCnJ yP9A== X-Gm-Message-State: APjAAAW1RJhn2Suhd/uKtiZ5Yfb/C8Tum9O11b53aS8sNs552MZmRtRf oZYYZpKCq9yV6b4HcXgtZdsaXWUXzvt2/g== X-Google-Smtp-Source: APXvYqz7UC4MquMGGKIaPRzvKqp1qvQ0yLWnRWLF8MYMBXPjKSxLhNOLIjlyaV8BqlR/uwamRKaGpQ== X-Received: by 2002:a1c:49c2:: with SMTP id w185mr7360645wma.138.1576615087866; Tue, 17 Dec 2019 12:38:07 -0800 (PST) Received: from ?IPv6:2003:eb:8f1a:5080:e843:207f:e439:b840? (p200300EB8F1A5080E843207FE439B840.dip0.t-ipconnect.de. [2003:eb:8f1a:5080:e843:207f:e439:b840]) by smtp.gmail.com with ESMTPSA id o15sm27311574wra.83.2019.12.17.12.38.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Dec 2019 12:38:06 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-5DA92538-0B7E-4876-8826-20283E991846 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Tue, 17 Dec 2019 21:38:02 +0100 Message-Id: <48909509-A322-44EB-A8F6-01BB2992E670@lodderstedt.net> References: Cc: "Richard Backman, Annabelle" , IETF oauth WG , "i-d-announce@ietf.org" In-Reply-To: To: Vittorio Bertocci X-Mailer: iPad Mail (17A860) Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 20:38:17 -0000 --Apple-Mail-5DA92538-0B7E-4876-8826-20283E991846 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 17.12.2019 um 21:03 schrieb Vittorio Bertocci : >=20 > =EF=BB=BF >> The one-RS-per-AT model is an ideal that simply doesn=E2=80=99t match rea= lity. =20 > That's a pretty strong statement :) I have worked with a very large number= of developers, on a very large number of applications. I don't dispute that= your experience might be different, but the one AT per RS is daily reality f= or hundreds of thousands of apps in production today. That's real by any mea= sure of reality. I second this statement. I have worked in a large deployment that strictly u= ses per RS ATs. > The fact that AD offers RTs that behave like TGTs makes it possible.=20 Funny, I assume any solution based on or inspired by Kerberos (like ours) wo= rks that way ;-) > RAR is an interesting development, but it's in the inception phase. The au= d and scopes claims are already in nearly all the proprietary JWT implementa= tions in production today, as shown in the research I presented when the dra= ft was adopted by the WG, hence it seems natural to include them in an inter= op profile. Scopes can be used to identify RSs in the authorization request (and turned i= nto aud in a token), but that=E2=80=99s not interoperable. Resource indicato= rs is the first step towards interoperable means to obtain RS-specific token= s, RAR is the next evolution. > Nothing prevents us from developing it further as new approaches gain trac= tion on the market, but for the time being I think the value of this would b= e to bring some order in existing implementations and contain abuses such as= id_tokens used in lieu of access tokens today. I think including scope and aud in the JWT profile is ok but it=E2=80=99s no= t sufficient for true interoperability. >=20 >> I=E2=80=99m skeptical of the idea that there is just one level of client i= dentity proofing that RSes might care about.=20 > In the scenario that led me to include this item in the discussion, knowle= dge of that level isn't necessary. Again, I agree it would be useful to defi= ne those levels, but I don't think it would be in scope here. If inclusion o= f that info in the JWT AT would be conditional to do all that work, I'd much= rather drop that aspect in favor of making faster progress. >=20 >> Without taking the whole picture into account, there is significant risk t= hat we will define something that turns out to be woefully insufficient (or w= orse, establishes an anti-pattern). That said, I agree that it=E2=80=99s pro= bably not appropriate for this draft, and recommend dropping these claims. T= hey can always be defined in a separate draft, along with the other elements= necessary to communicate step-up requirements.=20 > Could you expand on a concrete scenario that would lead to an antipattern b= ecause of the presence of those claims in the profile? > There is already logic out there predicated on those claim values, precise= ly because ID_token defines them and vendors latch onto them. I am concerned= that if we don't include those claims in the profile, people will simply ke= ep using ID_tokens for calling APIs. > =20 >=20 >> On Tue, Dec 17, 2019 at 11:39 AM Richard Backman, Annabelle wrote: >> > In any case the intent was always to only allow a singe resource per AT= =E2=80=A6 >>=20 >> =20 >>=20 >> My confusion actually comes from the last paragraph of =C2=A73, where it s= ays =E2=80=9CIf a scope parameter is present in the request, the authorizati= on server SHOULD use it to infer the value of the default resource indicator= to be used in the aud claim.=E2=80=9D I interpreted that to leave room for a= n AS inferring the same =E2=80=9Cgeneric=E2=80=9D resource indicator for res= ources served by different RSes. The one-RS-per-AT model is an ideal that si= mply doesn=E2=80=99t match reality. Clients don=E2=80=99t want to have to ju= ggle a bunch of different tokens, nor should they need to. I=E2=80=99m comin= g to think that we shouldn=E2=80=99t actually use `aud` and `scope` in JWT A= Ts at all, and instead adopt the structure RAR defines used for the `authori= zation_details` parameter (I think some iteration is required, but it seems n= atural for these two to describe authorizations in the same or compatible wa= ys). >>=20 >> =20 >>=20 >> =20 >>=20 >> > =E2=80=A6the resource wants to know whether this particular token was o= btained proving the identity of the client=E2=80=A6 >>=20 >> =20 >>=20 >> I=E2=80=99m skeptical of the idea that there is just one level of client i= dentity proofing that RSes might care about. There might be some clear lines= that can be drawn, but we should be explicit about what those lines represe= nt, e.g., =E2=80=9Cclient authenticated using pre-established credential=E2=80= =9D, =E2=80=9Cclient is running on end user-controlled device=E2=80=9D, etc.= >>=20 >> =20 >>=20 >> =20 >>=20 >> > I am not trying to create a complete framework for handling step up and= the like, I am trying to create an interoperable representation of those va= lues no matter how they were obtained. >>=20 >> =20 >>=20 >> Without taking the whole picture into account, there is significant risk t= hat we will define something that turns out to be woefully insufficient (or w= orse, establishes an anti-pattern). That said, I agree that it=E2=80=99s pro= bably not appropriate for this draft, and recommend dropping these claims. T= hey can always be defined in a separate draft, along with the other elements= necessary to communicate step-up requirements. >>=20 >> =20 >>=20 >> =E2=80=93=20 >>=20 >> Annabelle Richard Backman >>=20 >> AWS Identity >>=20 >> =20 >>=20 >> =20 >>=20 >> From: Vittorio Bertocci >> Date: Monday, December 16, 2019 at 9:31 PM >> To: "Richard Backman, Annabelle" >> Cc: IETF oauth WG , Vittorio Bertocci , "i-d-announce@ietf.org" >> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-= access-token-jwt-03.txt >>=20 >> =20 >>=20 >> Re: aliases, I see where the confusion is coming from! >>=20 >> I updated the request section, but the session 2.2 data structure still m= entions the aliases. That should be cleaned up as well.=20 >>=20 >> In any case the intent was always to only allow a singe resource per AT, t= he alias list was only for helping in cases where an AS identifies the same r= esource thru multiple IDs and the actual aud value depends on what ID the cl= ient requested. However we discussed this with Brian and he convinced me tha= t it was just too ambiguous- your remark reinforces that impression. I=E2=80= =99ll clean up 2.2 and eliminate references to aliases from there as well. >>=20 >> Thanks! >>=20 >> =20 >>=20 >> =20 >>=20 >> On Mon, Dec 16, 2019 at 20:19 Vittorio Bertocci wrot= e: >>=20 >> Thanks Annabelle. >>=20 >> =20 >>=20 >> Does a mobile app that uses Dynamic Client Registration to establish a cl= ient secret count as an =E2=80=9Cauthenticated client=E2=80=9D? =20 >>=20 >> I think it should count, tho I am not sure what the RS would do with it. D= ynamic client registration would likely not have much use for this. >>=20 >> In the cases I have seen, the idea is that a client (whose clientID is al= ready known to the RS) can obtain tokens thru different grants, some of them= confidential and others public; and the resource wants to know whether this= particular token was obtained proving the identity of the client so that it= can decide whether to grant extra privileges for that particular client in t= he current call. This scenario does not require the extra details about auth= entication method/strength you mention that, I agree, would be pretty hard t= o reach consensus on. >>=20 >> TL;DR: there is at least one scenario that is satisfied by the simple boo= l, as the previous knowledge of the client solves the issues you mention out= of band.=20 >>=20 >> =20 >>=20 >> authentication session properties:=20 >>=20 >> Let me try another angle. Say that I perform an authz code grant asking f= or AT, ID_T and RT- obtaining AT', ID_T' and RT'.=20 >>=20 >> The values of auth_time, acr and amr in AT' will be the same as the corre= sponding claims in ID_T'. When the client uses RT' to obtain AT`N, AT'N+1 et= c etc, the values of those claims will remain the same for every AT'n obtain= ed by RT'. >>=20 >> Now, imagine that something happens (ignore what for the time being) that= causes the client to perform a step up auth, which requires the user to per= form interactive auth hence results in a new authz grant. The client will ob= tain a new tuple AT", ID_T" and RT". The exact same rules described for the= ' tuple apply, with the new values determined by the new authentication: AT= " auth_time/acr/amr will be the same as ID_T", and those values will remain u= nchanged for every AT"n derived by RT". >> If we want this to apply to the implicit flow as well, you can substitute= the RT with the session artifact.=20 >>=20 >> Does that help clarifying the intent? If yes, do you feel that the curren= t language does not describe this? >>=20 >> =20 >>=20 >> use case for putting these in the access token=20 >>=20 >> I am not trying to create a complete framework for handling step up and t= he like, I am trying to create an interoperable representation of those valu= es no matter how they were obtained.=20 >>=20 >> Consider the case in which an API allows certain operations only if a giv= en amr value is present in the token. Whether that amr is required upfront o= n first authentication, as step up or any other reason is out of scope for t= his profile IMO: the AS might have all sorts of heuristics that determine th= at (user membership to a given group or role; geofencing; risk scoring; etc)= that have nothing to do with scopes requested, and are not statically deter= mined by RS-AS communications.=20 >>=20 >> Now, I agree that formalizing how a RS communicates to the AS via the cli= ent the need to step up and in what terms would be super useful; however I t= hink that's well beyond the scope of this profile.. Various vendors already h= ave their own mechanisms for handling step up signaling from RS to AS (I am v= ery familiar with the Microsoft one) and all I am looking for is a way of st= andardizing how to represent the outcomes, so that API gateways and SDK prov= iders can provide tools that work across vendors; and possibly reuse some of= the reasoning that was already done for id_tokens. >>=20 >> TL;DR: I think we are doing something useful in formalizing how to embed t= hat info an ATs even if we don't force vendors to give up their current mech= anisms to populate those values. >>=20 >> =20 >>=20 >> Regarding access tokens that are used to access different resource server= s >>=20 >> The intent is to explicitly disallow the use of an AT with multiple resou= rce servers. If a client wants to talk with 2 different RSes, the client sho= uld ask for 2 different ATs. >>=20 >> The spec is unambiguous on this IMO, here's the language I use in 03. >>=20 >> =20 >>=20 >> If it receives a request for an access token containing more than one >> resource parameter, an authorization server issuing JWT access tokens >> MUST reject the request and fail with "invalid_request" as described >> in section 4.1.2.1 of [RFC6749] or with "invalid_target" as defined >> in section 2 of [ResourceIndicators]. See Section 2.2 and Section 5 >> for more details on how this measure ensures there's no confusion on >> to what resource the access token granted scopes apply. >> Is it possible you are referring to an older draft? =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Mon, Dec 16, 2019 at 5:28 PM Richard Backman, Annabelle wrote: >>=20 >> 1. Regarding AuthenticatedClient: >>=20 >> Does a mobile app that uses Dynamic Client Registration to establish a cl= ient secret count as an =E2=80=9Cauthenticated client=E2=80=9D? What if that= registration included an assertion signed by a trusted entity (e.g., device= management software) using a certificate that had been pushed to the device= ? Without some kind of NIST LoA-style definition of =E2=80=9Cauthenticated=E2= =80=9D, a single Boolean =E2=80=9CAuthenticatedClient=E2=80=9D value is too a= mbiguous to be useful. However, I=E2=80=99m skeptical that we could find con= sensus on what that definition should be, and it may be better to define cli= ent analogs to `acr` and `amr` that provide standard ways of expressing clie= nt authentication details without getting prescriptive about what kind of au= thentication is =E2=80=9Cgood enough.=E2=80=9D >>=20 >> =20 >>=20 >> 2. Regarding authentication session properties: >>=20 >> I=E2=80=99m confused by the definitions given for `auth_time`, `acr`, and= `amr`. For `auth_time`, it says: >>=20 >> =20 >>=20 >> =E2=80=9C=E2=80=A6its value will either remain the same for all the JWT a= ccess tokens issued within that session or be updated to the time of latest a= uthentication if reauthentication occurred mid-session=E2=80=A6=E2=80=9D >>=20 >> =20 >>=20 >> But the =E2=80=9CFor example=E2=80=9D at the end of that definition impli= es that `auth_time` will not be updated. The definitions for `acr` and `amr`= say the same, but also say that the =E2=80=9C=E2=80=A6same considerations p= resented for auth_time apply=E2=80=A6=E2=80=9D What=E2=80=99s the intention h= ere: are they fixed, updated, or is it up to the deployment to decide? >>=20 >> =20 >>=20 >> I=E2=80=99d like to better understand the use case for putting these in t= he access token. If the RS is making authorization decisions based on these c= laims, that implies that the RS cannot rely on the AS to determine (e.g., fr= om the requested scope) the required authentication method(s), freshness, et= c. If the AS could be relied upon for this, then presumably it would not iss= ue RTs and ATs for a scope without requiring the end user to meet the approp= riate authentication requirements. If this is the case, then the RS must hav= e a way to signal to the client (and then the AS) that a step-up authenticat= ion is required. Is there an existing mechanism through which they could do t= his? All I can come up with is cramming the information into the scope attri= bute of a WWW-Authenticate challenge, but that has the same scope opacity vi= olation problem as described in this draft=E2=80=99s Security Considerations= . Without a clear way to express the step-up requirements, this feels incomp= lete.. >>=20 >> =20 >>=20 >> 3. Regarding access tokens that are used to access different resource ser= vers: >> Reading between the lines, I *think* the intention is that a JWT access t= oken that is intended to be used to access two different resources at two di= fferent RSes should look something like: >>=20 >> =20 >>=20 >> { >>=20 >> "aud": "https://generic-resource-indicator.example.com/", >>=20 >> "scope": "resource_foo resource_bar", >>=20 >> ... >>=20 >> } >>=20 >>=20 >> And the expectation is that each RS should recognize that generic audienc= e. Is this correct? If so it seems to go against the spirit of resource indi= cators as indicating the target or location of a resource. It=E2=80=99s stre= tching that definition, at the very least. >>=20 >> =20 >>=20 >> But as I said, I=E2=80=99m reading between the lines here. If this is the= intention, it should be clearly stated. Alternatively, remove (or change to= a SHOULD) the requirement that multi-value `aud` claims must only contain a= liases for the same resource indicator. >>=20 >> =20 >>=20 >> =E2=80=93=20 >>=20 >> Annabelle Richard Backman >>=20 >> AWS Identity >>=20 >> =20 >>=20 >> =20 >>=20 >> From: OAuth on behalf of Vittorio Bertocci >> Date: Monday, December 16, 2019 at 2:51 PM >> To: IETF oauth WG >> Cc: "i-d-announce@ietf.org" >> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.= txt >>=20 >> =20 >>=20 >> Dear all, >> I finally found the time to push a new draft of the JWT profile for ATs. T= his version incorporates the feedback kindly provided by Brian and Aaron at I= ETF105. >> Unfortunately I didn't have a chance to participate to IETF106, hence we d= idn't do much progress since then. >> There are still two areas we didn't manage to reach consensus on: >>=20 >> 1. Mechanisms for signaling whether the AT was obtained by a user or an a= pplication >>=20 >> This point was the subject of intense debate on the list leading to IETF1= 05... >> One insight that emerged from the IETF105 discussion was that the use cas= e here is more about whether the AT has been obtained via a grant that authe= nticated the client (regardless of what specific grant was used) vs a public= client grant- that information can be relevant to a resource as it determin= es whether the identity of the client can be used in authorization decisions= (in the former case) or not (in the public client case). If that's the scen= ario we are truly after, a simple, possibly optional boolean claim (say Auth= enticatedClient) would suffice. >> Note for the people who didn't read the spec: I removed any reference to t= his already in draft-ietf-oauth-access-token-jwt-01. I think this is an impo= rtant and useful info and standardizing it would be beneficial for middlewar= e and SDK creators, but ultimately this is an interop profile hence if there= 's no strong desire to reach an agreement here, I am also OK with dropping t= he matter and not address this function in the spec. >> To summarize, I have two questions here: >>=20 >> A. Do we believe it's worth it to formalize in the profile a mechanism to= indicate whether the client th obtained the AT authenticated itself with th= e AS? >> B. If yes, are you OK wiht an optional bool claim here? >>=20 >>=20 >> 2. Claims indicating session properties >>=20 >> This is one area where I am far more passionate about, as it represents a= fundamental aspect that production systems (and in particular 1st party sol= utions) already rely on in the current proprietary JTW ATs. >> The profile currently includes the claims auth_time, acr and amr - captur= ing the values of those properties at the time of the latest authentication t= he user performed in the session used to issue the current AT: at session cr= eation, at auth step up time and so on. >> Those are values that API need in order to make authorization decisions; i= n the case of 1st party APIs, the AT is the only artifact they ever receive h= ence there is no other way for an API to determine whether the caller perfor= med say MFA in order to obtain the current AT. >> Since the first draft, some people signaled concerns about the current me= chanisms thru which those claims get their value. For example, it has been p= roposed to maintain the original values of auth_time, acr & amr and introduc= e additional claims to indicate changes (like stepup). >> I am not clear on what cold go wrong with the current approach, hence I d= on't have an immediate grasp of how changes like the above would help. >> If the people uncomfortable with the current proposal could detail their c= oncern, we can brainstorm ways to make that info available to API in a safer= way. To summarize: >>=20 >> A. Do you have concerns with the current auth_time, arm, acr proposal? Ca= n you spell them out? (please read the relevant parts of the spec before chi= ming in :)) >> B. If yes, what can we do to make that info available to RSs in a way tha= t makes you comfortable? >>=20 >>=20 >>=20 >> Thanks >>=20 >> V. >>=20 >> =20 >>=20 >> On Mon, Dec 16, 2019 at 2:49 PM wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >> This draft is a work item of the Web Authorization Protocol WG of the IET= F. >>=20 >> Title : JSON Web Token (JWT) Profile for OAuth 2.0 Acce= ss Tokens >> Author : Vittorio Bertocci >> Filename : draft-ietf-oauth-access-token-jwt-03.txt >> Pages : 16 >> Date : 2019-12-16 >>=20 >> Abstract: >> This specification defines a profile for issuing OAuth 2.0 access >> tokens in JSON web token (JWT) format. Authorization servers and >> resource servers from different vendors can leverage this profile to >> issue and consume access tokens in interoperable manner. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-0= 3 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-03 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submiss= ion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp...ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-5DA92538-0B7E-4876-8826-20283E991846 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Am 17.12.2019 um 21:03 schrieb Vittorio Berto= cci <Vittorio=3D40auth0.com@dmarc.ietf.org>:

=EF=BB=BF
The one-RS-per-AT model is an ide= al that simply doesn=E2=80=99t match reality.  
T= hat's a pretty strong statement :) I have worked with a very large number of= developers, on a very large number of applications. I don't dispute that yo= ur experience might be different, but the one AT per RS is daily reality for= hundreds of thousands of apps in production today. That's real by any measu= re of reality.

I second this s= tatement. I have worked in a large deployment that strictly uses per RS ATs.=

Th= e fact that AD offers RTs that behave like TGTs makes it possible. 

Funny, I assume any solution based= on or inspired by Kerberos (like ours) works that way ;-)

RAR is an inte= resting development, but it's in the inception phase. The aud and scopes cla= ims are already in nearly all the proprietary JWT implementations in product= ion today, as shown in the research I presented when the draft was adopted b= y the WG, hence it seems natural to include them in an interop profile.

Scopes can be used to identify RSs i= n the authorization request (and turned into aud in a token), but that=E2=80= =99s not interoperable. Resource indicators is the first step towards intero= perable means to obtain RS-specific tokens, RAR is the next evolution.
=

Nothing prevents us from developing it further as new approaches&nb= sp;gain traction on the market, but for the time being I think the value of t= his would be to bring some order in existing implementations and contai= n abuses such as id_tokens used in lieu of access tokens today.
<= /div>

I think including scope and aud in the JWT p= rofile is ok but it=E2=80=99s not sufficient for true interoperability.

<= br>
I=E2=80=99m skepti= cal of the idea that there is just one level of client identity proofing tha= t RSes might care about. 
In the scenario that led me t= o include this item in the discussion, knowledge of that level isn't necessa= ry. Again, I agree it would be useful to define those levels, but I don't th= ink it would be in scope here. If inclusion of that info in the JWT AT would= be conditional to do all that work, I'd much rather drop that aspect in fav= or of making faster progress.

Without taking the whole picture into account, there i= s significant risk that we will define something that turns out to be woeful= ly insufficient (or worse, establishes an anti-pattern). That said, I agree t= hat it=E2=80=99s probably not appropriate for this draft, and recommend drop= ping these claims. They can always be defined in a separate draft, along wit= h the other elements necessary to communicate step-up requirements. 
Could you expand on a concrete scenario that would lead to an= antipattern because of the presence of those claims in the profile?
There is already logic out there predicated on those claim values, pr= ecisely because ID_token defines them and vendors latch onto them. I am conc= erned that if we don't include those claims in the profile, people will simp= ly keep using ID_tokens for calling APIs.
 
On Tue, D= ec 17, 2019 at 11:39 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

> In any case the intent was always to only allow a= singe resource per AT=E2=80=A6

 

My confusion actually comes from the last paragraph o= f =C2=A73, where it says =E2=80=9CIf a scope parameter is present in the req= uest, the authorization server SHOULD use it to infer the value of the defau= lt resource indicator to be used in the aud claim.=E2=80=9D I interpreted that to leave room for an AS inferring the sa= me =E2=80=9Cgeneric=E2=80=9D resource indicator for resources served by diff= erent RSes. The one-RS-per-AT model is an ideal that simply doesn=E2=80=99t m= atch reality. Clients don=E2=80=99t want to have to juggle a bunch of different tokens, nor should they need to. I=E2=80=99m coming to think that= we shouldn=E2=80=99t actually use `aud` and `scope` in JWT ATs at all, and i= nstead adopt the structure RAR defines used for the `authorization_details` p= arameter (I think some iteration is required, but it seems natural for these two to describe authorizations in the same o= r compatible ways).

 

 

> =E2=80=A6the resource wants to know whether this= particular token was obtained proving the identity of the client=E2=80=A6

 

I=E2=80=99m skeptical of the idea that there is just o= ne level of client identity proofing that RSes might care about. There might= be some clear lines that can be drawn, but we should be explicit about what= those lines represent, e.g., =E2=80=9Cclient authenticated using pre-established credential=E2=80=9D, =E2=80=9Cclient is= running on end user-controlled device=E2=80=9D, etc.

 

 

> I am not trying to create a complete framework f= or handling step up and the like, I am trying to create an interoperable rep= resentation of those values no matter how they were obtained.<= /p>

 

Without taking the whole picture into account, there i= s significant risk that we will define something that turns out to be woeful= ly insufficient (or worse, establishes an anti-pattern). That said, I agree t= hat it=E2=80=99s probably not appropriate for this draft, and recommend dropping these claims. They can always be def= ined in a separate draft, along with the other elements necessary to communi= cate step-up requirements.

 

=E2=80=93 =

Annabelle Richard Back= man

AWS Identity=

 

 

From: Vittorio Bertocci <= Vittorio=3D4= 0auth0.com@dmarc.ietf.org>
Date: Monday, December 16, 2019 at 9:31 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: IETF oauth WG <oauth@ietf.org>, Vittorio Bertocci <Vittorio@auth0.com>, "i-d-announce@ietf.org" <i-d-announce@ietf.o= rg>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-oa= uth-access-token-jwt-03.txt

 

Re: aliases, I see where t= he confusion is coming from!

I updated the request sec= tion, but the session 2.2 data structure still mentions the aliases. That sh= ould be cleaned up as well. 

In any case the intent wa= s always to only allow a singe resource per AT, the alias list was only for h= elping in cases where an AS identifies the same resource thru multiple IDs a= nd the actual aud value depends on what ID the client requested. However we discussed this with Brian and he c= onvinced me that it was just too ambiguous- your remark reinforces that impr= ession. I=E2=80=99ll clean up 2.2 and eliminate references to aliases from t= here as well.

Thanks!

=

 

 

On Mon, Dec 16, 2019 at 2= 0:19 Vittorio Bertocci <Vittorio@auth0.com> wrote:

Thanks Annabelle. =

 

Does a mobile app that us= es Dynamic Client Registration to establish a client secret count as an =E2=80= =9Cauthenticated client=E2=80=9D?  

I think it should count, t= ho I am not sure what the RS would do with it. Dynamic client registration w= ould likely not have much use for this.

In the cases I have seen,= the idea is that a client (whose clientID is already known to the RS) can o= btain tokens thru different grants, some of them confidential and others pub= lic; and the resource wants to know whether this particular token was obtained proving the identity of the clie= nt so that it can decide whether to grant extra privileges for that particul= ar client in the current call. This scenario does not require the extra= details about authentication method/strength you mention that, I agree, would be pretty hard to reach consensus on.

TL;DR: there is at least o= ne scenario that is satisfied by the simple bool, as the previous knowledge o= f the client solves the issues you mention out of band. <= /p>

 

authentication session pr= operties: 

 Let me try another a= ngle. Say that I perform an authz code grant asking for AT, ID_T and RT- obt= aining AT', ID_T' and RT'. 

The values of auth_time, a= cr and amr in AT' will be the same as the corresponding claims in ID_T'. Whe= n the client uses RT' to obtain AT`N, AT'N+1 etc etc, the values of those cl= aims will remain the same for every AT'n obtained by RT'.

Now, imagine that somethi= ng happens (ignore what for the time being) that causes the client to perfor= m a step up auth, which requires the user to perform interactive auth hence r= esults in a new authz grant. The client will obtain a new tuple  AT", ID_T" and RT". The exact same rul= es described for the ' tuple apply, with the new values determined by the ne= w authentication: AT" auth_time/acr/amr will be the same as ID_T", and those= values will remain unchanged for every AT"n derived by RT".
If we want this to apply to the implicit flow as well, you can substitute th= e RT with the session artifact. 

Does that help clarifying= the intent? If yes, do you feel that the current language does not describe= this?

 

use case for putting thes= e in the access token 

I am not trying to create= a complete framework for handling step up and the like, I am trying to crea= te an interoperable representation of those values no matter how they were o= btained. 

Consider the case in whic= h an API allows certain operations only if a given amr value is present in t= he token. Whether that amr is required upfront on first authentication, as s= tep up or any other reason is out of scope for this profile IMO: the AS might have all sorts of heuristics th= at determine that (user membership to a given group or role; geofencing; ris= k scoring; etc) that have nothing to do with scopes requested, and are not s= tatically determined by RS-AS communications. 

Now, I agree that formali= zing how a RS communicates to the AS via the client the need to step up and i= n what terms would be super useful; however I think that's well beyond t= he scope of this profile.. Various vendors already have their own mechanisms for handling step up signaling from RS to= AS (I am very familiar with the Microsoft one) and all I am looking fo= r is a way of standardizing how to represent the outcomes, so that API gatew= ays and SDK providers can provide tools that work across vendors; and possibly reuse some of the reasoning th= at was already done for id_tokens.

TL;DR: I think we are doi= ng something useful in formalizing how to embed that info an ATs even if we d= on't force vendors to give up their current mechanisms to populate those val= ues.

 

Regarding access tokens t= hat are used to access different resource servers

The intent is to explicit= ly disallow the use of an AT with multiple resource servers. If a client wan= ts to talk with 2 different RSes, the client should ask for 2 different ATs.=

The spec is unambiguous o= n this IMO, here's the language I use in 03.

 

If it receives a request for an access toke=
n containing more than one
   resource=
 parameter, an authorization server issuing JWT access tokens<=
/span>
   MUST rej=
ect the request and fail with "invalid_request" as described
   in section 4.1.2.1 of [RFC67=
49] or with "invalid_target" as defined

   in secti=
on 2 of [ResourceIndicators].  See Section 2.=
2 and Section 5


   for more=
 details on how this measure ensures there's no confusion on


   to what r=
esource the access token granted scopes apply.

  Is it possible you= are referring to an older draft?  

 

 

On Mon, Dec 16, 2019 at 5= :28 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wr= ote:

1. Regarding AuthenticatedClient:

Does a mobile app that uses Dynamic Client Registration to establish a clien= t secret count as an =E2=80=9Cauthenticated client=E2=80=9D? What if that re= gistration included an assertion signed by a trusted entity (e.g., device ma= nagement software) using a certificate that had been pushed to the device? Without some kind of NIST LoA-style definition o= f =E2=80=9Cauthenticated=E2=80=9D, a single Boolean =E2=80=9CAuthenticatedCl= ient=E2=80=9D value is too ambiguous to be useful. However, I=E2=80=99m skep= tical that we could find consensus on what that definition should be, and it may be better to define client analogs to `acr` and `amr` that provi= de standard ways of expressing client authentication details without getting= prescriptive about what kind of authentication is =E2=80=9Cgood enough.=E2=80= =9D

 

2. Regarding authentication session properties:

I=E2=80=99m confused by the definitions given for `auth_time`, `acr`, and `a= mr`. For `auth_time`, it says:

 

=E2=80=9C=E2=80=A6its value will either remain the same for all the JWT acce= ss tokens issued within that session or be updated to the time of latest aut= hentication if reauthentication occurred mid-session=E2=80=A6=E2=80=9D

 

But the =E2=80=9CFor example=E2=80=9D at the end of that definition implies t= hat `auth_time` will not be updated. The definitions for `acr` and `amr` say= the same, but also say that the =E2=80=9C=E2=80=A6same considerations prese= nted for auth_time apply=E2=80=A6=E2=80=9D What=E2=80=99s the intention here= : are they fixed, updated, or is it up to the deployment to decide?

 

I=E2=80=99d like to better understand the use case for putting these in the a= ccess token. If the RS is making authorization decisions based on these clai= ms, that implies that the RS cannot rely on the AS to determine (e.g., from t= he requested scope) the required authentication method(s), freshness, etc. If the AS could be relied upon for this, then pr= esumably it would not issue RTs and ATs for a scope without requiring the en= d user to meet the appropriate authentication requirements. If this is the c= ase, then the RS must have a way to signal to the client (and then the AS) that a step-up authentication= is required. Is there an existing mechanism through which they could do thi= s? All I can come up with is cramming the information into the scope attribu= te of a WWW-Authenticate challenge, but that has the same scope opacity violation problem as described in this d= raft=E2=80=99s Security Considerations. Without a clear way to express the s= tep-up requirements, this feels incomplete..

 

3. Regarding access tokens that are used to access different resource server= s:
Reading between the lines, I *think* the intention is that a JWT acce= ss token that is intended to be used to access two different resources at tw= o different RSes should look something like:

 

{

"aud": "https://generic-resource-indic= ator.example.com/",

"scope": "resource_foo resource_bar",

...

}


And the expectation is that each RS should recognize that generic audience. I= s this correct? If so it seems to go against the spirit of resource indicato= rs as indicating the target or location of a resource. It=E2=80=99s stretchi= ng that definition, at the very least.

 

But as I said, I=E2=80=99m reading between the lines here. If this is the in= tention, it should be clearly stated. Alternatively, remove (or change to a S= HOULD) the requirement that multi-value `aud` claims must only contain alias= es for the same resource indicator.

 

=E2=80=93 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio B= ertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>
Date: Monday, December 16, 2019 at 2:51 PM
To: IETF oauth WG <oauth@ietf.org>
Cc: "i-d-a= nnounce@ietf.org" <i-d-announce@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt= -03.txt

 

Dear all,
I finally found the time to push a new draft of the JWT profile for ATs. Thi= s version incorporates the feedback kindly provided by Brian and Aaron at IE= TF105.
Unfortunately I didn't have a chance to participate to IETF106, hence we did= n't do much progress since then.
There are still two areas we didn't manage to reach consensus on:

1. Mechanisms for signaling whether the AT was obtained by a user or an appl= ication

This point was the subject of intense debate on the list leading to IETF105.= ..
One insight that emerged from the IETF105 discussion was that the use case h= ere is more about whether the AT has been obtained via a grant that authenti= cated the client (regardless of what specific grant was used) vs a public cl= ient grant- that information can be relevant to a resource as it determines whether the identity of the c= lient can be used in authorization decisions (in the former case) or not (in= the public client case). If that's the scenario we are truly after, a simpl= e, possibly optional boolean claim (say AuthenticatedClient) would suffice.
Note for the people who didn't read the spec: I removed any reference to thi= s already in draft-ietf-oauth-access-token-jwt-01. I think this is an import= ant and useful info and standardizing it would be beneficial for middleware a= nd SDK creators, but ultimately this is an interop profile hence if there's no strong desire to reach an ag= reement here, I am also OK with dropping the matter and not address this fun= ction in the spec.
To summarize, I have two questions here:

A. Do we believe it's worth it to formalize in the profile a mechanism to in= dicate whether the client th obtained the AT authenticated itself with the A= S?
B. If yes, are you OK wiht an optional bool claim here?


2. Claims indicating session properties

This is one area where I am far more passionate about, as it represents a fu= ndamental aspect that production systems (and in particular 1st party soluti= ons) already rely on in the current proprietary JTW ATs.
The profile currently includes the claims auth_time, acr and amr - capturing= the values of those properties at the time of the latest authentication the= user performed in the session used to issue the current AT: at session crea= tion, at auth step up time and so on.
Those are values that API need in order to make authorization decisions; in t= he case of 1st party APIs, the AT is the only artifact they ever receive hen= ce there is no other way for an API to determine whether the caller performe= d say MFA in order to obtain the current AT.
Since the first draft, some people signaled concerns about the current mecha= nisms thru which those claims get their value. For example, it has been prop= osed to maintain the original values of auth_time, acr & amr and introdu= ce additional claims to indicate changes (like stepup).
I am not clear on what cold go wrong with the current approach, hence I don'= t have an immediate grasp of how changes like the above would help.
If the people uncomfortable with the current proposal could detail their con= cern, we can brainstorm ways to make that info available to API in a safer w= ay. To summarize:

A. Do you have concerns with the current auth_time, arm, acr proposal? Can y= ou spell them out? (please read the relevant parts of the spec before chimin= g in :))
B. If yes, what can we do to make that info available to RSs in a way that m= akes you comfortable?



Thanks

V.

 

On Mon, Dec 16, 2019 at 2:49 PM <internet-drafts@ietf.org> wrote:<= /p>


A New Internet-Draft is available from the on-line Internet-Drafts directori= es.
This draft is a work item of the Web Authorization Protocol WG of the IETF.<= br>
        Title           : J= SON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
        Author          : Vitto= rio Bertocci
        Filename        : draft-ietf= -oauth-access-token-jwt-03.txt
        Pages           : 1= 6
        Date            : 2= 019-12-16

Abstract:
   This specification defines a profile for issuing OAuth 2.0 acce= ss
   tokens in JSON web token (JWT) format.  Authorization serv= ers and
   resource servers from different vendors can leverage this profi= le to
   issue and consume access tokens in interoperable manner.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-acce= ss-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-token= -jwt-03
https://datatracker.ietf.org/doc/html/draft-iet= f-oauth-access-token-jwt-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oa= uth-access-token-jwt-03


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

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

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

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

_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
= --Apple-Mail-5DA92538-0B7E-4876-8826-20283E991846-- From nobody Tue Dec 17 13:12:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9E3120876; Tue, 17 Dec 2019 13:12:45 -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 G_yKCDuHfV7i; Tue, 17 Dec 2019 13:12:40 -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 D1E9A120077; Tue, 17 Dec 2019 13:12:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1576617160; x=1608153160; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UNeZMCTPMsPDTpnR5uYnnLFvBmekw+idM3j4ZQrTZIE=; b=ekmmYSq5J0+EI9Iq2v7rVTjbKGvEh5LEhuHGldFoQK8PRmR2n6rZlc1a wg77jYdYrvBJwKqcuBgb8nGQ5I3W+UEa+2IuEgPEvB9NjcE7vPgnSv5o+ 9LKp4bduVrotN/eZHZ82rITepgwGxC7JODhJggpCVa/PSEdFpT98EmX/Y M=; IronPort-SDR: Jm9ILDEkMFaktXk2F9pdLm+j4Kk4LVe66JjKYLkJoLuJkmttJhJMjwWBRQoXKsMiENYm82IqJo y052XJVGqEaQ== X-IronPort-AV: E=Sophos;i="5.69,326,1571702400"; d="scan'208,217";a="5704631" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-2225282c.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 17 Dec 2019 21:12:28 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2c-2225282c.us-west-2.amazon.com (Postfix) with ESMTPS id 0B19EA280B; Tue, 17 Dec 2019 21:12:27 +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, 17 Dec 2019 21:12: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; Tue, 17 Dec 2019 21:12: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; Tue, 17 Dec 2019 21:12:27 +0000 From: "Richard Backman, Annabelle" To: Vittorio Bertocci CC: Vittorio Bertocci , IETF oauth WG , "i-d-announce@ietf.org" Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt Thread-Index: AQHVtGMkx0ZM11MJ9UuFnmHDKBqGmae9XaMA///YXwCAAIOagIAABHuAgAConoCAAFp6gP//v5YA Date: Tue, 17 Dec 2019 21:12:26 +0000 Message-ID: <16EBA415-06A9-4190-B8C3-EE96771B70BD@amazon.com> References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> <2518B18A-AD93-44E4-88D1-E5F6AAE7B1BB@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.160.100] Content-Type: multipart/alternative; boundary="_000_16EBA41506A94190B8C3EE96771B70BDamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 21:12:46 -0000 --_000_16EBA41506A94190B8C3EE96771B70BDamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGF0J3MgYSBwcmV0dHkgc3Ryb25nIHN0YXRlbWVudCA6KQ0KDQpPbmUgSSBzaG91bGTigJl2 ZSBjbGFyaWZpZWQuIPCfmIMgSSBkb27igJl0IG1lYW4gdGhhdCB0aGUgb25lLVJTLXBlci1BVCBt b2RlbCBpcyBub3QgdXNlZCBhdCBhbGwsIGp1c3QgdGhhdCBpdCBpcyBub3QgdW5pdmVyc2FsIGFu ZCBjb21lcyB3aXRoIHJlYWwsIHByYWN0aWNhbCB0cmFkZW9mZnMgdGhhdCBtYXkgbm90IGJlIGFw cHJvcHJpYXRlIGZvciBhbGwgdXNlIGNhc2VzLiBDb25zZXF1ZW50bHksIHdlIHNob3VsZCBub3Qg ZGVzaWduIGZ1bmRhbWVudGFsIHNwZWNzIHRoYXQgbWFuZGF0ZSBpdHMgYWRvcHRpb24uDQoNCg0K PiDigKZrbm93bGVkZ2Ugb2YgdGhhdCBsZXZlbCBpc24ndCBuZWNlc3NhcnkuDQoNCkVpdGhlciB0 aGUgUlMgYW5kIEFTIGhhdmUgYSBzaGFyZWQgdW5kZXJzdGFuZGluZyBvZiB0aGF0IGxldmVsLCBv ciB0aGUgUlMgaXMgdHJ1c3RpbmcgdGhlIEFTIHRvIGRlY2lkZSB3aGF0IOKAnEF1dGhlbnRpY2F0 ZWRDbGllbnTigJ0gbWVhbnMsIGFuZCBzZXQgaXQgYWNjb3JkaW5nbHkuIFRoZSBsYXR0ZXIgcmVx dWlyZXMgdGhhdCB0aGUgUlMgb25seSBzdXBwb3J0cyBBU2VzIHRoYXQgaGF2ZSBhIHNoYXJlZCAo b3Igc3Vic3RhbnRpYWxseSBzaW1pbGFyKSB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgdGhhdCBsZXZl bCBpcywgd2hpY2ggaXMgdW5saWtlbHkgb3V0c2lkZSBvZiBhIGNsb3NlZCBzeXN0ZW0uIEluIHRo YXQgY2FzZSwgdGhlcmUgaXNu4oCZdCBhIGxvdCBvZiB2YWx1ZSBpbiBwcm92aWRpbmcgYSBzdGFu ZGFyZCBjbGFpbSwgYXMgdGhlIGNsb3NlZCBzeXN0ZW0gY291bGQganVzdCBhcyBlYXNpbHkgZGVm aW5lIGEgcHJvcHJpZXRhcnkgb25lLg0KDQoNCj4gQ291bGQgeW91IGV4cGFuZCBvbiBhIGNvbmNy ZXRlIHNjZW5hcmlvIHRoYXQgd291bGQgbGVhZCB0byBhbiBhbnRpcGF0dGVybiBiZWNhdXNlIG9m IHRoZSBwcmVzZW5jZSBvZiB0aG9zZSBjbGFpbXMgaW4gdGhlIHByb2ZpbGU/DQoNCklmIEkgY291 bGQsIHRoZW4gSSB3b3VsZG7igJl0IGJlIGNvbmNlcm5lZCBhYm91dCBkZWZpbmluZyB0aGlzIHBp ZWNlIG9mIHRoZSBwdXp6bGUgd2l0aG91dCB0aGUgcmVzdCBvZiBpdC4g8J+Ygw0KDQpJbiB5b3Vy IGV4cGVyaWVuY2UsIGFyZSB0aGUgZXhpc3Rpbmcgc3lzdGVtcyB0aGF0IHVzZSB0aGVzZSBjbGFp bXMgcmVhZGluZyB0aGVtIGZyb20gSUQgVG9rZW5zLCBvciBmcm9tIEpXVCBhY2Nlc3MgdG9rZW5z PyBBcmUgdGhlc2UgdHlwaWNhbGx5IGNsaWVudHMgdGhhdCBhcmUgYWNjZXNzaW5nIHRoZWlyIG93 biBSU2VzLCB1c2luZyB0b2tlbnMgdmVuZGVkIGJ5IGFuIElkUD8gKGUuZy4sIGEgU2FhUyBwcm9k dWN0IHRoYXQgZ2V0cyB0b2tlbnMgZnJvbSBhIGhvc3RlZCBJRGFhUyBwcm9kdWN0KSBJIGFzayBi ZWNhdXNlIE9JREMgY2xpZW50cyBjYW4gc3BlY2lmaXkgbWF4X2FnZSBhbmQgYWNyX3ZhbHVlcywg YW5kIGlmIGNsaWVudCBhbmQgUlMgYXJlIG93bmVkIGJ5IHRoZSBzYW1lIGVudGl0eSB0aGVuIHRo ZXkgY2FuIGRvIHdoYXRldmVyIHByb3ByaWV0YXJ5IHRoaW5nIHRoZXkgd2FudCB0byBpbmRpY2F0 ZSB0aGUgcmVhc29uIGZvciBhbiBhdXRob3JpemF0aW9uIGZhaWx1cmUuDQoNCuKAkw0KQW5uYWJl bGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogVml0dG9yaW8gQmVy dG9jY2kgPFZpdHRvcmlvQGF1dGgwLmNvbT4NCkRhdGU6IFR1ZXNkYXksIERlY2VtYmVyIDE3LCAy MDE5IGF0IDEyOjA0IFBNDQpUbzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFu bmFAYW1hem9uLmNvbT4NCkNjOiBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW89NDBhdXRoMC5j b21AZG1hcmMuaWV0Zi5vcmc+LCBJRVRGIG9hdXRoIFdHIDxvYXV0aEBpZXRmLm9yZz4sICJpLWQt YW5ub3VuY2VAaWV0Zi5vcmciIDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W1VOVkVSSUZJRUQgU0VOREVSXSBSZTogW09BVVRILVdHXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMudHh0DQoNClRoZSBvbmUtUlMtcGVyLUFUIG1vZGVs IGlzIGFuIGlkZWFsIHRoYXQgc2ltcGx5IGRvZXNu4oCZdCBtYXRjaCByZWFsaXR5Lg0KVGhhdCdz IGEgcHJldHR5IHN0cm9uZyBzdGF0ZW1lbnQgOikgSSBoYXZlIHdvcmtlZCB3aXRoIGEgdmVyeSBs YXJnZSBudW1iZXIgb2YgZGV2ZWxvcGVycywgb24gYSB2ZXJ5IGxhcmdlIG51bWJlciBvZiBhcHBs aWNhdGlvbnMuIEkgZG9uJ3QgZGlzcHV0ZSB0aGF0IHlvdXIgZXhwZXJpZW5jZSBtaWdodCBiZSBk aWZmZXJlbnQsIGJ1dCB0aGUgb25lIEFUIHBlciBSUyBpcyBkYWlseSByZWFsaXR5IGZvciBodW5k cmVkcyBvZiB0aG91c2FuZHMgb2YgYXBwcyBpbiBwcm9kdWN0aW9uIHRvZGF5LiBUaGF0J3MgcmVh bCBieSBhbnkgbWVhc3VyZSBvZiByZWFsaXR5LiBUaGUgZmFjdCB0aGF0IEFEIG9mZmVycyBSVHMg dGhhdCBiZWhhdmUgbGlrZSBUR1RzIG1ha2VzIGl0IHBvc3NpYmxlLg0KUkFSIGlzIGFuIGludGVy ZXN0aW5nIGRldmVsb3BtZW50LCBidXQgaXQncyBpbiB0aGUgaW5jZXB0aW9uIHBoYXNlLiBUaGUg YXVkIGFuZCBzY29wZXMgY2xhaW1zIGFyZSBhbHJlYWR5IGluIG5lYXJseSBhbGwgdGhlIHByb3By aWV0YXJ5IEpXVCBpbXBsZW1lbnRhdGlvbnMgaW4gcHJvZHVjdGlvbiB0b2RheSwgYXMgc2hvd24g aW4gdGhlIHJlc2VhcmNoIEkgcHJlc2VudGVkIHdoZW4gdGhlIGRyYWZ0IHdhcyBhZG9wdGVkIGJ5 IHRoZSBXRywgaGVuY2UgaXQgc2VlbXMgbmF0dXJhbCB0byBpbmNsdWRlIHRoZW0gaW4gYW4gaW50 ZXJvcCBwcm9maWxlLg0KTm90aGluZyBwcmV2ZW50cyB1cyBmcm9tIGRldmVsb3BpbmcgaXQgZnVy dGhlciBhcyBuZXcgYXBwcm9hY2hlcyBnYWluIHRyYWN0aW9uIG9uIHRoZSBtYXJrZXQsIGJ1dCBm b3IgdGhlIHRpbWUgYmVpbmcgSSB0aGluayB0aGUgdmFsdWUgb2YgdGhpcyB3b3VsZCBiZSB0byBi cmluZyBzb21lIG9yZGVyIGluIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBhbmQgY29udGFpbiBh YnVzZXMgc3VjaCBhcyBpZF90b2tlbnMgdXNlZCBpbiBsaWV1IG9mIGFjY2VzcyB0b2tlbnMgdG9k YXkuDQoNCknigJltIHNrZXB0aWNhbCBvZiB0aGUgaWRlYSB0aGF0IHRoZXJlIGlzIGp1c3Qgb25l IGxldmVsIG9mIGNsaWVudCBpZGVudGl0eSBwcm9vZmluZyB0aGF0IFJTZXMgbWlnaHQgY2FyZSBh Ym91dC4NCkluIHRoZSBzY2VuYXJpbyB0aGF0IGxlZCBtZSB0byBpbmNsdWRlIHRoaXMgaXRlbSBp biB0aGUgZGlzY3Vzc2lvbiwga25vd2xlZGdlIG9mIHRoYXQgbGV2ZWwgaXNuJ3QgbmVjZXNzYXJ5 LiBBZ2FpbiwgSSBhZ3JlZSBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gZGVmaW5lIHRob3NlIGxldmVs cywgYnV0IEkgZG9uJ3QgdGhpbmsgaXQgd291bGQgYmUgaW4gc2NvcGUgaGVyZS4gSWYgaW5jbHVz aW9uIG9mIHRoYXQgaW5mbyBpbiB0aGUgSldUIEFUIHdvdWxkIGJlIGNvbmRpdGlvbmFsIHRvIGRv IGFsbCB0aGF0IHdvcmssIEknZCBtdWNoIHJhdGhlciBkcm9wIHRoYXQgYXNwZWN0IGluIGZhdm9y IG9mIG1ha2luZyBmYXN0ZXIgcHJvZ3Jlc3MuDQoNCldpdGhvdXQgdGFraW5nIHRoZSB3aG9sZSBw aWN0dXJlIGludG8gYWNjb3VudCwgdGhlcmUgaXMgc2lnbmlmaWNhbnQgcmlzayB0aGF0IHdlIHdp bGwgZGVmaW5lIHNvbWV0aGluZyB0aGF0IHR1cm5zIG91dCB0byBiZSB3b2VmdWxseSBpbnN1ZmZp Y2llbnQgKG9yIHdvcnNlLCBlc3RhYmxpc2hlcyBhbiBhbnRpLXBhdHRlcm4pLiBUaGF0IHNhaWQs IEkgYWdyZWUgdGhhdCBpdOKAmXMgcHJvYmFibHkgbm90IGFwcHJvcHJpYXRlIGZvciB0aGlzIGRy YWZ0LCBhbmQgcmVjb21tZW5kIGRyb3BwaW5nIHRoZXNlIGNsYWltcy4gVGhleSBjYW4gYWx3YXlz IGJlIGRlZmluZWQgaW4gYSBzZXBhcmF0ZSBkcmFmdCwgYWxvbmcgd2l0aCB0aGUgb3RoZXIgZWxl bWVudHMgbmVjZXNzYXJ5IHRvIGNvbW11bmljYXRlIHN0ZXAtdXAgcmVxdWlyZW1lbnRzLg0KQ291 bGQgeW91IGV4cGFuZCBvbiBhIGNvbmNyZXRlIHNjZW5hcmlvIHRoYXQgd291bGQgbGVhZCB0byBh biBhbnRpcGF0dGVybiBiZWNhdXNlIG9mIHRoZSBwcmVzZW5jZSBvZiB0aG9zZSBjbGFpbXMgaW4g dGhlIHByb2ZpbGU/DQpUaGVyZSBpcyBhbHJlYWR5IGxvZ2ljIG91dCB0aGVyZSBwcmVkaWNhdGVk IG9uIHRob3NlIGNsYWltIHZhbHVlcywgcHJlY2lzZWx5IGJlY2F1c2UgSURfdG9rZW4gZGVmaW5l cyB0aGVtIGFuZCB2ZW5kb3JzIGxhdGNoIG9udG8gdGhlbS4gSSBhbSBjb25jZXJuZWQgdGhhdCBp ZiB3ZSBkb24ndCBpbmNsdWRlIHRob3NlIGNsYWltcyBpbiB0aGUgcHJvZmlsZSwgcGVvcGxlIHdp bGwgc2ltcGx5IGtlZXAgdXNpbmcgSURfdG9rZW5zIGZvciBjYWxsaW5nIEFQSXMuDQoNCg0KT24g VHVlLCBEZWMgMTcsIDIwMTkgYXQgMTE6MzkgQU0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUg PHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiB3cm90ZToN Cj4gSW4gYW55IGNhc2UgdGhlIGludGVudCB3YXMgYWx3YXlzIHRvIG9ubHkgYWxsb3cgYSBzaW5n ZSByZXNvdXJjZSBwZXIgQVTigKYNCg0KTXkgY29uZnVzaW9uIGFjdHVhbGx5IGNvbWVzIGZyb20g dGhlIGxhc3QgcGFyYWdyYXBoIG9mIMKnMywgd2hlcmUgaXQgc2F5cyDigJxJZiBhIHNjb3BlIHBh cmFtZXRlciBpcyBwcmVzZW50IGluIHRoZSByZXF1ZXN0LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgU0hPVUxEIHVzZSBpdCB0byBpbmZlciB0aGUgdmFsdWUgb2YgdGhlIGRlZmF1bHQgcmVzb3Vy Y2UgaW5kaWNhdG9yIHRvIGJlIHVzZWQgaW4gdGhlIGF1ZCBjbGFpbS7igJ0gSSBpbnRlcnByZXRl ZCB0aGF0IHRvIGxlYXZlIHJvb20gZm9yIGFuIEFTIGluZmVycmluZyB0aGUgc2FtZSDigJxnZW5l cmlj4oCdIHJlc291cmNlIGluZGljYXRvciBmb3IgcmVzb3VyY2VzIHNlcnZlZCBieSBkaWZmZXJl bnQgUlNlcy4gVGhlIG9uZS1SUy1wZXItQVQgbW9kZWwgaXMgYW4gaWRlYWwgdGhhdCBzaW1wbHkg ZG9lc27igJl0IG1hdGNoIHJlYWxpdHkuIENsaWVudHMgZG9u4oCZdCB3YW50IHRvIGhhdmUgdG8g anVnZ2xlIGEgYnVuY2ggb2YgZGlmZmVyZW50IHRva2Vucywgbm9yIHNob3VsZCB0aGV5IG5lZWQg dG8uIEnigJltIGNvbWluZyB0byB0aGluayB0aGF0IHdlIHNob3VsZG7igJl0IGFjdHVhbGx5IHVz ZSBgYXVkYCBhbmQgYHNjb3BlYCBpbiBKV1QgQVRzIGF0IGFsbCwgYW5kIGluc3RlYWQgYWRvcHQg dGhlIHN0cnVjdHVyZSBSQVIgZGVmaW5lcyB1c2VkIGZvciB0aGUgYGF1dGhvcml6YXRpb25fZGV0 YWlsc2AgcGFyYW1ldGVyIChJIHRoaW5rIHNvbWUgaXRlcmF0aW9uIGlzIHJlcXVpcmVkLCBidXQg aXQgc2VlbXMgbmF0dXJhbCBmb3IgdGhlc2UgdHdvIHRvIGRlc2NyaWJlIGF1dGhvcml6YXRpb25z IGluIHRoZSBzYW1lIG9yIGNvbXBhdGlibGUgd2F5cykuDQoNCg0KPiDigKZ0aGUgcmVzb3VyY2Ug d2FudHMgdG8ga25vdyB3aGV0aGVyIHRoaXMgcGFydGljdWxhciB0b2tlbiB3YXMgb2J0YWluZWQg cHJvdmluZyB0aGUgaWRlbnRpdHkgb2YgdGhlIGNsaWVudOKApg0KDQpJ4oCZbSBza2VwdGljYWwg b2YgdGhlIGlkZWEgdGhhdCB0aGVyZSBpcyBqdXN0IG9uZSBsZXZlbCBvZiBjbGllbnQgaWRlbnRp dHkgcHJvb2ZpbmcgdGhhdCBSU2VzIG1pZ2h0IGNhcmUgYWJvdXQuIFRoZXJlIG1pZ2h0IGJlIHNv bWUgY2xlYXIgbGluZXMgdGhhdCBjYW4gYmUgZHJhd24sIGJ1dCB3ZSBzaG91bGQgYmUgZXhwbGlj aXQgYWJvdXQgd2hhdCB0aG9zZSBsaW5lcyByZXByZXNlbnQsIGUuZy4sIOKAnGNsaWVudCBhdXRo ZW50aWNhdGVkIHVzaW5nIHByZS1lc3RhYmxpc2hlZCBjcmVkZW50aWFs4oCdLCDigJxjbGllbnQg aXMgcnVubmluZyBvbiBlbmQgdXNlci1jb250cm9sbGVkIGRldmljZeKAnSwgZXRjLg0KDQoNCj4g SSBhbSBub3QgdHJ5aW5nIHRvIGNyZWF0ZSBhIGNvbXBsZXRlIGZyYW1ld29yayBmb3IgaGFuZGxp bmcgc3RlcCB1cCBhbmQgdGhlIGxpa2UsIEkgYW0gdHJ5aW5nIHRvIGNyZWF0ZSBhbiBpbnRlcm9w ZXJhYmxlIHJlcHJlc2VudGF0aW9uIG9mIHRob3NlIHZhbHVlcyBubyBtYXR0ZXIgaG93IHRoZXkg d2VyZSBvYnRhaW5lZC4NCg0KV2l0aG91dCB0YWtpbmcgdGhlIHdob2xlIHBpY3R1cmUgaW50byBh Y2NvdW50LCB0aGVyZSBpcyBzaWduaWZpY2FudCByaXNrIHRoYXQgd2Ugd2lsbCBkZWZpbmUgc29t ZXRoaW5nIHRoYXQgdHVybnMgb3V0IHRvIGJlIHdvZWZ1bGx5IGluc3VmZmljaWVudCAob3Igd29y c2UsIGVzdGFibGlzaGVzIGFuIGFudGktcGF0dGVybikuIFRoYXQgc2FpZCwgSSBhZ3JlZSB0aGF0 IGl04oCZcyBwcm9iYWJseSBub3QgYXBwcm9wcmlhdGUgZm9yIHRoaXMgZHJhZnQsIGFuZCByZWNv bW1lbmQgZHJvcHBpbmcgdGhlc2UgY2xhaW1zLiBUaGV5IGNhbiBhbHdheXMgYmUgZGVmaW5lZCBp biBhIHNlcGFyYXRlIGRyYWZ0LCBhbG9uZyB3aXRoIHRoZSBvdGhlciBlbGVtZW50cyBuZWNlc3Nh cnkgdG8gY29tbXVuaWNhdGUgc3RlcC11cCByZXF1aXJlbWVudHMuDQoNCuKAkw0KQW5uYWJlbGxl IFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogVml0dG9yaW8gQmVydG9j Y2kgPFZpdHRvcmlvPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGF1dGgwLmNv bUBkbWFyYy5pZXRmLm9yZz4+DQpEYXRlOiBNb25kYXksIERlY2VtYmVyIDE2LCAyMDE5IGF0IDk6 MzEgUE0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24u Y29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4NCkNjOiBJRVRGIG9hdXRoIFdHIDxvYXV0 aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiwgVml0dG9yaW8gQmVydG9jY2kgPFZp dHRvcmlvQGF1dGgwLmNvbTxtYWlsdG86Vml0dG9yaW9AYXV0aDAuY29tPj4sICJpLWQtYW5ub3Vu Y2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4iIDxpLWQtYW5ub3VuY2VA aWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbVU5WRVJJ RklFRCBTRU5ERVJdIFJlOiBbT0FVVEgtV0ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb2F1dGgt YWNjZXNzLXRva2VuLWp3dC0wMy50eHQNCg0KUmU6IGFsaWFzZXMsIEkgc2VlIHdoZXJlIHRoZSBj b25mdXNpb24gaXMgY29taW5nIGZyb20hDQpJIHVwZGF0ZWQgdGhlIHJlcXVlc3Qgc2VjdGlvbiwg YnV0IHRoZSBzZXNzaW9uIDIuMiBkYXRhIHN0cnVjdHVyZSBzdGlsbCBtZW50aW9ucyB0aGUgYWxp YXNlcy4gVGhhdCBzaG91bGQgYmUgY2xlYW5lZCB1cCBhcyB3ZWxsLg0KSW4gYW55IGNhc2UgdGhl IGludGVudCB3YXMgYWx3YXlzIHRvIG9ubHkgYWxsb3cgYSBzaW5nZSByZXNvdXJjZSBwZXIgQVQs IHRoZSBhbGlhcyBsaXN0IHdhcyBvbmx5IGZvciBoZWxwaW5nIGluIGNhc2VzIHdoZXJlIGFuIEFT IGlkZW50aWZpZXMgdGhlIHNhbWUgcmVzb3VyY2UgdGhydSBtdWx0aXBsZSBJRHMgYW5kIHRoZSBh Y3R1YWwgYXVkIHZhbHVlIGRlcGVuZHMgb24gd2hhdCBJRCB0aGUgY2xpZW50IHJlcXVlc3RlZC4g SG93ZXZlciB3ZSBkaXNjdXNzZWQgdGhpcyB3aXRoIEJyaWFuIGFuZCBoZSBjb252aW5jZWQgbWUg dGhhdCBpdCB3YXMganVzdCB0b28gYW1iaWd1b3VzLSB5b3VyIHJlbWFyayByZWluZm9yY2VzIHRo YXQgaW1wcmVzc2lvbi4gSeKAmWxsIGNsZWFuIHVwIDIuMiBhbmQgZWxpbWluYXRlIHJlZmVyZW5j ZXMgdG8gYWxpYXNlcyBmcm9tIHRoZXJlIGFzIHdlbGwuDQpUaGFua3MhDQoNCg0KT24gTW9uLCBE ZWMgMTYsIDIwMTkgYXQgMjA6MTkgVml0dG9yaW8gQmVydG9jY2kgPFZpdHRvcmlvQGF1dGgwLmNv bTxtYWlsdG86Vml0dG9yaW9AYXV0aDAuY29tPj4gd3JvdGU6DQpUaGFua3MgQW5uYWJlbGxlLg0K DQpEb2VzIGEgbW9iaWxlIGFwcCB0aGF0IHVzZXMgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9u IHRvIGVzdGFibGlzaCBhIGNsaWVudCBzZWNyZXQgY291bnQgYXMgYW4g4oCcYXV0aGVudGljYXRl ZCBjbGllbnTigJ0/DQpJIHRoaW5rIGl0IHNob3VsZCBjb3VudCwgdGhvIEkgYW0gbm90IHN1cmUg d2hhdCB0aGUgUlMgd291bGQgZG8gd2l0aCBpdC4gRHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9u IHdvdWxkIGxpa2VseSBub3QgaGF2ZSBtdWNoIHVzZSBmb3IgdGhpcy4NCkluIHRoZSBjYXNlcyBJ IGhhdmUgc2VlbiwgdGhlIGlkZWEgaXMgdGhhdCBhIGNsaWVudCAod2hvc2UgY2xpZW50SUQgaXMg YWxyZWFkeSBrbm93biB0byB0aGUgUlMpIGNhbiBvYnRhaW4gdG9rZW5zIHRocnUgZGlmZmVyZW50 IGdyYW50cywgc29tZSBvZiB0aGVtIGNvbmZpZGVudGlhbCBhbmQgb3RoZXJzIHB1YmxpYzsgYW5k IHRoZSByZXNvdXJjZSB3YW50cyB0byBrbm93IHdoZXRoZXIgdGhpcyBwYXJ0aWN1bGFyIHRva2Vu IHdhcyBvYnRhaW5lZCBwcm92aW5nIHRoZSBpZGVudGl0eSBvZiB0aGUgY2xpZW50IHNvIHRoYXQg aXQgY2FuIGRlY2lkZSB3aGV0aGVyIHRvIGdyYW50IGV4dHJhIHByaXZpbGVnZXMgZm9yIHRoYXQg cGFydGljdWxhciBjbGllbnQgaW4gdGhlIGN1cnJlbnQgY2FsbC4gVGhpcyBzY2VuYXJpbyBkb2Vz IG5vdCByZXF1aXJlIHRoZSBleHRyYSBkZXRhaWxzIGFib3V0IGF1dGhlbnRpY2F0aW9uIG1ldGhv ZC9zdHJlbmd0aCB5b3UgbWVudGlvbiB0aGF0LCBJIGFncmVlLCB3b3VsZCBiZSBwcmV0dHkgaGFy ZCB0byByZWFjaCBjb25zZW5zdXMgb24uDQpUTDtEUjogdGhlcmUgaXMgYXQgbGVhc3Qgb25lIHNj ZW5hcmlvIHRoYXQgaXMgc2F0aXNmaWVkIGJ5IHRoZSBzaW1wbGUgYm9vbCwgYXMgdGhlIHByZXZp b3VzIGtub3dsZWRnZSBvZiB0aGUgY2xpZW50IHNvbHZlcyB0aGUgaXNzdWVzIHlvdSBtZW50aW9u IG91dCBvZiBiYW5kLg0KDQphdXRoZW50aWNhdGlvbiBzZXNzaW9uIHByb3BlcnRpZXM6DQogTGV0 IG1lIHRyeSBhbm90aGVyIGFuZ2xlLiBTYXkgdGhhdCBJIHBlcmZvcm0gYW4gYXV0aHogY29kZSBn cmFudCBhc2tpbmcgZm9yIEFULCBJRF9UIGFuZCBSVC0gb2J0YWluaW5nIEFUJywgSURfVCcgYW5k IFJUJy4NClRoZSB2YWx1ZXMgb2YgYXV0aF90aW1lLCBhY3IgYW5kIGFtciBpbiBBVCcgd2lsbCBi ZSB0aGUgc2FtZSBhcyB0aGUgY29ycmVzcG9uZGluZyBjbGFpbXMgaW4gSURfVCcuIFdoZW4gdGhl IGNsaWVudCB1c2VzIFJUJyB0byBvYnRhaW4gQVRgTiwgQVQnTisxIGV0YyBldGMsIHRoZSB2YWx1 ZXMgb2YgdGhvc2UgY2xhaW1zIHdpbGwgcmVtYWluIHRoZSBzYW1lIGZvciBldmVyeSBBVCduIG9i dGFpbmVkIGJ5IFJUJy4NCk5vdywgaW1hZ2luZSB0aGF0IHNvbWV0aGluZyBoYXBwZW5zIChpZ25v cmUgd2hhdCBmb3IgdGhlIHRpbWUgYmVpbmcpIHRoYXQgY2F1c2VzIHRoZSBjbGllbnQgdG8gcGVy Zm9ybSBhIHN0ZXAgdXAgYXV0aCwgd2hpY2ggcmVxdWlyZXMgdGhlIHVzZXIgdG8gcGVyZm9ybSBp bnRlcmFjdGl2ZSBhdXRoIGhlbmNlIHJlc3VsdHMgaW4gYSBuZXcgYXV0aHogZ3JhbnQuIFRoZSBj bGllbnQgd2lsbCBvYnRhaW4gYSBuZXcgdHVwbGUgIEFUIiwgSURfVCIgYW5kIFJUIi4gVGhlIGV4 YWN0IHNhbWUgcnVsZXMgZGVzY3JpYmVkIGZvciB0aGUgJyB0dXBsZSBhcHBseSwgd2l0aCB0aGUg bmV3IHZhbHVlcyBkZXRlcm1pbmVkIGJ5IHRoZSBuZXcgYXV0aGVudGljYXRpb246IEFUIiBhdXRo X3RpbWUvYWNyL2FtciB3aWxsIGJlIHRoZSBzYW1lIGFzIElEX1QiLCBhbmQgdGhvc2UgdmFsdWVz IHdpbGwgcmVtYWluIHVuY2hhbmdlZCBmb3IgZXZlcnkgQVQibiBkZXJpdmVkIGJ5IFJUIi4NCklm IHdlIHdhbnQgdGhpcyB0byBhcHBseSB0byB0aGUgaW1wbGljaXQgZmxvdyBhcyB3ZWxsLCB5b3Ug Y2FuIHN1YnN0aXR1dGUgdGhlIFJUIHdpdGggdGhlIHNlc3Npb24gYXJ0aWZhY3QuDQpEb2VzIHRo YXQgaGVscCBjbGFyaWZ5aW5nIHRoZSBpbnRlbnQ/IElmIHllcywgZG8geW91IGZlZWwgdGhhdCB0 aGUgY3VycmVudCBsYW5ndWFnZSBkb2VzIG5vdCBkZXNjcmliZSB0aGlzPw0KDQp1c2UgY2FzZSBm b3IgcHV0dGluZyB0aGVzZSBpbiB0aGUgYWNjZXNzIHRva2VuDQpJIGFtIG5vdCB0cnlpbmcgdG8g Y3JlYXRlIGEgY29tcGxldGUgZnJhbWV3b3JrIGZvciBoYW5kbGluZyBzdGVwIHVwIGFuZCB0aGUg bGlrZSwgSSBhbSB0cnlpbmcgdG8gY3JlYXRlIGFuIGludGVyb3BlcmFibGUgcmVwcmVzZW50YXRp b24gb2YgdGhvc2UgdmFsdWVzIG5vIG1hdHRlciBob3cgdGhleSB3ZXJlIG9idGFpbmVkLg0KQ29u c2lkZXIgdGhlIGNhc2UgaW4gd2hpY2ggYW4gQVBJIGFsbG93cyBjZXJ0YWluIG9wZXJhdGlvbnMg b25seSBpZiBhIGdpdmVuIGFtciB2YWx1ZSBpcyBwcmVzZW50IGluIHRoZSB0b2tlbi4gV2hldGhl ciB0aGF0IGFtciBpcyByZXF1aXJlZCB1cGZyb250IG9uIGZpcnN0IGF1dGhlbnRpY2F0aW9uLCBh cyBzdGVwIHVwIG9yIGFueSBvdGhlciByZWFzb24gaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIHBy b2ZpbGUgSU1POiB0aGUgQVMgbWlnaHQgaGF2ZSBhbGwgc29ydHMgb2YgaGV1cmlzdGljcyB0aGF0 IGRldGVybWluZSB0aGF0ICh1c2VyIG1lbWJlcnNoaXAgdG8gYSBnaXZlbiBncm91cCBvciByb2xl OyBnZW9mZW5jaW5nOyByaXNrIHNjb3Jpbmc7IGV0YykgdGhhdCBoYXZlIG5vdGhpbmcgdG8gZG8g d2l0aCBzY29wZXMgcmVxdWVzdGVkLCBhbmQgYXJlIG5vdCBzdGF0aWNhbGx5IGRldGVybWluZWQg YnkgUlMtQVMgY29tbXVuaWNhdGlvbnMuDQpOb3csIEkgYWdyZWUgdGhhdCBmb3JtYWxpemluZyBo b3cgYSBSUyBjb21tdW5pY2F0ZXMgdG8gdGhlIEFTIHZpYSB0aGUgY2xpZW50IHRoZSBuZWVkIHRv IHN0ZXAgdXAgYW5kIGluIHdoYXQgdGVybXMgd291bGQgYmUgc3VwZXIgdXNlZnVsOyBob3dldmVy IEkgdGhpbmsgdGhhdCdzIHdlbGwgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHByb2ZpbGUuLiBW YXJpb3VzIHZlbmRvcnMgYWxyZWFkeSBoYXZlIHRoZWlyIG93biBtZWNoYW5pc21zIGZvciBoYW5k bGluZyBzdGVwIHVwIHNpZ25hbGluZyBmcm9tIFJTIHRvIEFTIChJIGFtIHZlcnkgZmFtaWxpYXIg d2l0aCB0aGUgTWljcm9zb2Z0IG9uZSkgYW5kIGFsbCBJIGFtIGxvb2tpbmcgZm9yIGlzIGEgd2F5 IG9mIHN0YW5kYXJkaXppbmcgaG93IHRvIHJlcHJlc2VudCB0aGUgb3V0Y29tZXMsIHNvIHRoYXQg QVBJIGdhdGV3YXlzIGFuZCBTREsgcHJvdmlkZXJzIGNhbiBwcm92aWRlIHRvb2xzIHRoYXQgd29y ayBhY3Jvc3MgdmVuZG9yczsgYW5kIHBvc3NpYmx5IHJldXNlIHNvbWUgb2YgdGhlIHJlYXNvbmlu ZyB0aGF0IHdhcyBhbHJlYWR5IGRvbmUgZm9yIGlkX3Rva2Vucy4NClRMO0RSOiBJIHRoaW5rIHdl IGFyZSBkb2luZyBzb21ldGhpbmcgdXNlZnVsIGluIGZvcm1hbGl6aW5nIGhvdyB0byBlbWJlZCB0 aGF0IGluZm8gYW4gQVRzIGV2ZW4gaWYgd2UgZG9uJ3QgZm9yY2UgdmVuZG9ycyB0byBnaXZlIHVw IHRoZWlyIGN1cnJlbnQgbWVjaGFuaXNtcyB0byBwb3B1bGF0ZSB0aG9zZSB2YWx1ZXMuDQoNClJl Z2FyZGluZyBhY2Nlc3MgdG9rZW5zIHRoYXQgYXJlIHVzZWQgdG8gYWNjZXNzIGRpZmZlcmVudCBy ZXNvdXJjZSBzZXJ2ZXJzDQpUaGUgaW50ZW50IGlzIHRvIGV4cGxpY2l0bHkgZGlzYWxsb3cgdGhl IHVzZSBvZiBhbiBBVCB3aXRoIG11bHRpcGxlIHJlc291cmNlIHNlcnZlcnMuIElmIGEgY2xpZW50 IHdhbnRzIHRvIHRhbGsgd2l0aCAyIGRpZmZlcmVudCBSU2VzLCB0aGUgY2xpZW50IHNob3VsZCBh c2sgZm9yIDIgZGlmZmVyZW50IEFUcy4NClRoZSBzcGVjIGlzIHVuYW1iaWd1b3VzIG9uIHRoaXMg SU1PLCBoZXJlJ3MgdGhlIGxhbmd1YWdlIEkgdXNlIGluIDAzLg0KDQoNCklmIGl0IHJlY2VpdmVz IGEgcmVxdWVzdCBmb3IgYW4gYWNjZXNzIHRva2VuIGNvbnRhaW5pbmcgbW9yZSB0aGFuIG9uZQ0K DQogICByZXNvdXJjZSBwYXJhbWV0ZXIsIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3Vpbmcg SldUIGFjY2VzcyB0b2tlbnMNCg0KICAgTVVTVCByZWplY3QgdGhlIHJlcXVlc3QgYW5kIGZhaWwg d2l0aCAiaW52YWxpZF9yZXF1ZXN0IiBhcyBkZXNjcmliZWQNCg0KICAgaW4gc2VjdGlvbiA0LjEu Mi4xIG9mIFtSRkM2NzQ5XTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3Jm YzY3NDkjc2VjdGlvbi00LjEuMi4xPiBvciB3aXRoICJpbnZhbGlkX3RhcmdldCIgYXMgZGVmaW5l ZA0KDQogICBpbiBzZWN0aW9uIDIgb2YgW1Jlc291cmNlSW5kaWNhdG9yczxodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3 dC0wMyNyZWYtUmVzb3VyY2VJbmRpY2F0b3JzPl0uICBTZWUgU2VjdGlvbiAyLjI8aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tl bi1qd3QtMDMjc2VjdGlvbi0yLjI+IGFuZCBTZWN0aW9uIDU8aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMjc2Vj dGlvbi01Pg0KDQogICBmb3IgbW9yZSBkZXRhaWxzIG9uIGhvdyB0aGlzIG1lYXN1cmUgZW5zdXJl cyB0aGVyZSdzIG5vIGNvbmZ1c2lvbiBvbg0KDQogICB0byB3aGF0IHJlc291cmNlIHRoZSBhY2Nl c3MgdG9rZW4gZ3JhbnRlZCBzY29wZXMgYXBwbHkuDQogIElzIGl0IHBvc3NpYmxlIHlvdSBhcmUg cmVmZXJyaW5nIHRvIGFuIG9sZGVyIGRyYWZ0Pw0KDQoNCk9uIE1vbiwgRGVjIDE2LCAyMDE5IGF0 IDU6MjggUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNv bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPj4gd3Jv dGU6DQoxLiBSZWdhcmRpbmcgQXV0aGVudGljYXRlZENsaWVudDoNCkRvZXMgYSBtb2JpbGUgYXBw IHRoYXQgdXNlcyBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gdG8gZXN0YWJsaXNoIGEgY2xp ZW50IHNlY3JldCBjb3VudCBhcyBhbiDigJxhdXRoZW50aWNhdGVkIGNsaWVudOKAnT8gV2hhdCBp ZiB0aGF0IHJlZ2lzdHJhdGlvbiBpbmNsdWRlZCBhbiBhc3NlcnRpb24gc2lnbmVkIGJ5IGEgdHJ1 c3RlZCBlbnRpdHkgKGUuZy4sIGRldmljZSBtYW5hZ2VtZW50IHNvZnR3YXJlKSB1c2luZyBhIGNl cnRpZmljYXRlIHRoYXQgaGFkIGJlZW4gcHVzaGVkIHRvIHRoZSBkZXZpY2U/IFdpdGhvdXQgc29t ZSBraW5kIG9mIE5JU1QgTG9BLXN0eWxlIGRlZmluaXRpb24gb2Yg4oCcYXV0aGVudGljYXRlZOKA nSwgYSBzaW5nbGUgQm9vbGVhbiDigJxBdXRoZW50aWNhdGVkQ2xpZW504oCdIHZhbHVlIGlzIHRv byBhbWJpZ3VvdXMgdG8gYmUgdXNlZnVsLiBIb3dldmVyLCBJ4oCZbSBza2VwdGljYWwgdGhhdCB3 ZSBjb3VsZCBmaW5kIGNvbnNlbnN1cyBvbiB3aGF0IHRoYXQgZGVmaW5pdGlvbiBzaG91bGQgYmUs IGFuZCBpdCBtYXkgYmUgYmV0dGVyIHRvIGRlZmluZSBjbGllbnQgYW5hbG9ncyB0byBgYWNyYCBh bmQgYGFtcmAgdGhhdCBwcm92aWRlIHN0YW5kYXJkIHdheXMgb2YgZXhwcmVzc2luZyBjbGllbnQg YXV0aGVudGljYXRpb24gZGV0YWlscyB3aXRob3V0IGdldHRpbmcgcHJlc2NyaXB0aXZlIGFib3V0 IHdoYXQga2luZCBvZiBhdXRoZW50aWNhdGlvbiBpcyDigJxnb29kIGVub3VnaC7igJ0NCg0KMi4g UmVnYXJkaW5nIGF1dGhlbnRpY2F0aW9uIHNlc3Npb24gcHJvcGVydGllczoNCknigJltIGNvbmZ1 c2VkIGJ5IHRoZSBkZWZpbml0aW9ucyBnaXZlbiBmb3IgYGF1dGhfdGltZWAsIGBhY3JgLCBhbmQg YGFtcmAuIEZvciBgYXV0aF90aW1lYCwgaXQgc2F5czoNCg0K4oCc4oCmaXRzIHZhbHVlIHdpbGwg ZWl0aGVyIHJlbWFpbiB0aGUgc2FtZSBmb3IgYWxsIHRoZSBKV1QgYWNjZXNzIHRva2VucyBpc3N1 ZWQgd2l0aGluIHRoYXQgc2Vzc2lvbiBvciBiZSB1cGRhdGVkIHRvIHRoZSB0aW1lIG9mIGxhdGVz dCBhdXRoZW50aWNhdGlvbiBpZiByZWF1dGhlbnRpY2F0aW9uIG9jY3VycmVkIG1pZC1zZXNzaW9u 4oCm4oCdDQoNCkJ1dCB0aGUg4oCcRm9yIGV4YW1wbGXigJ0gYXQgdGhlIGVuZCBvZiB0aGF0IGRl ZmluaXRpb24gaW1wbGllcyB0aGF0IGBhdXRoX3RpbWVgIHdpbGwgbm90IGJlIHVwZGF0ZWQuIFRo ZSBkZWZpbml0aW9ucyBmb3IgYGFjcmAgYW5kIGBhbXJgIHNheSB0aGUgc2FtZSwgYnV0IGFsc28g c2F5IHRoYXQgdGhlIOKAnOKApnNhbWUgY29uc2lkZXJhdGlvbnMgcHJlc2VudGVkIGZvciBhdXRo X3RpbWUgYXBwbHnigKbigJ0gV2hhdOKAmXMgdGhlIGludGVudGlvbiBoZXJlOiBhcmUgdGhleSBm aXhlZCwgdXBkYXRlZCwgb3IgaXMgaXQgdXAgdG8gdGhlIGRlcGxveW1lbnQgdG8gZGVjaWRlPw0K DQpJ4oCZZCBsaWtlIHRvIGJldHRlciB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZSBmb3IgcHV0dGlu ZyB0aGVzZSBpbiB0aGUgYWNjZXNzIHRva2VuLiBJZiB0aGUgUlMgaXMgbWFraW5nIGF1dGhvcml6 YXRpb24gZGVjaXNpb25zIGJhc2VkIG9uIHRoZXNlIGNsYWltcywgdGhhdCBpbXBsaWVzIHRoYXQg dGhlIFJTIGNhbm5vdCByZWx5IG9uIHRoZSBBUyB0byBkZXRlcm1pbmUgKGUuZy4sIGZyb20gdGhl IHJlcXVlc3RlZCBzY29wZSkgdGhlIHJlcXVpcmVkIGF1dGhlbnRpY2F0aW9uIG1ldGhvZChzKSwg ZnJlc2huZXNzLCBldGMuIElmIHRoZSBBUyBjb3VsZCBiZSByZWxpZWQgdXBvbiBmb3IgdGhpcywg dGhlbiBwcmVzdW1hYmx5IGl0IHdvdWxkIG5vdCBpc3N1ZSBSVHMgYW5kIEFUcyBmb3IgYSBzY29w ZSB3aXRob3V0IHJlcXVpcmluZyB0aGUgZW5kIHVzZXIgdG8gbWVldCB0aGUgYXBwcm9wcmlhdGUg YXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnRzLiBJZiB0aGlzIGlzIHRoZSBjYXNlLCB0aGVuIHRo ZSBSUyBtdXN0IGhhdmUgYSB3YXkgdG8gc2lnbmFsIHRvIHRoZSBjbGllbnQgKGFuZCB0aGVuIHRo ZSBBUykgdGhhdCBhIHN0ZXAtdXAgYXV0aGVudGljYXRpb24gaXMgcmVxdWlyZWQuIElzIHRoZXJl IGFuIGV4aXN0aW5nIG1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIHRoZXkgY291bGQgZG8gdGhpcz8g QWxsIEkgY2FuIGNvbWUgdXAgd2l0aCBpcyBjcmFtbWluZyB0aGUgaW5mb3JtYXRpb24gaW50byB0 aGUgc2NvcGUgYXR0cmlidXRlIG9mIGEgV1dXLUF1dGhlbnRpY2F0ZSBjaGFsbGVuZ2UsIGJ1dCB0 aGF0IGhhcyB0aGUgc2FtZSBzY29wZSBvcGFjaXR5IHZpb2xhdGlvbiBwcm9ibGVtIGFzIGRlc2Ny aWJlZCBpbiB0aGlzIGRyYWZ04oCZcyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4gV2l0aG91dCBh IGNsZWFyIHdheSB0byBleHByZXNzIHRoZSBzdGVwLXVwIHJlcXVpcmVtZW50cywgdGhpcyBmZWVs cyBpbmNvbXBsZXRlLi4NCg0KMy4gUmVnYXJkaW5nIGFjY2VzcyB0b2tlbnMgdGhhdCBhcmUgdXNl ZCB0byBhY2Nlc3MgZGlmZmVyZW50IHJlc291cmNlIHNlcnZlcnM6DQpSZWFkaW5nIGJldHdlZW4g dGhlIGxpbmVzLCBJICp0aGluayogdGhlIGludGVudGlvbiBpcyB0aGF0IGEgSldUIGFjY2VzcyB0 b2tlbiB0aGF0IGlzIGludGVuZGVkIHRvIGJlIHVzZWQgdG8gYWNjZXNzIHR3byBkaWZmZXJlbnQg cmVzb3VyY2VzIGF0IHR3byBkaWZmZXJlbnQgUlNlcyBzaG91bGQgbG9vayBzb21ldGhpbmcgbGlr ZToNCg0Kew0KImF1ZCI6ICJodHRwczovL2dlbmVyaWMtcmVzb3VyY2UtaW5kaWNhdG9yLmV4YW1w bGUuY29tLyIsDQoic2NvcGUiOiAicmVzb3VyY2VfZm9vIHJlc291cmNlX2JhciIsDQouLi4NCn0N Cg0KQW5kIHRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IGVhY2ggUlMgc2hvdWxkIHJlY29nbml6ZSB0 aGF0IGdlbmVyaWMgYXVkaWVuY2UuIElzIHRoaXMgY29ycmVjdD8gSWYgc28gaXQgc2VlbXMgdG8g Z28gYWdhaW5zdCB0aGUgc3Bpcml0IG9mIHJlc291cmNlIGluZGljYXRvcnMgYXMgaW5kaWNhdGlu ZyB0aGUgdGFyZ2V0IG9yIGxvY2F0aW9uIG9mIGEgcmVzb3VyY2UuIEl04oCZcyBzdHJldGNoaW5n IHRoYXQgZGVmaW5pdGlvbiwgYXQgdGhlIHZlcnkgbGVhc3QuDQoNCkJ1dCBhcyBJIHNhaWQsIEni gJltIHJlYWRpbmcgYmV0d2VlbiB0aGUgbGluZXMgaGVyZS4gSWYgdGhpcyBpcyB0aGUgaW50ZW50 aW9uLCBpdCBzaG91bGQgYmUgY2xlYXJseSBzdGF0ZWQuIEFsdGVybmF0aXZlbHksIHJlbW92ZSAo b3IgY2hhbmdlIHRvIGEgU0hPVUxEKSB0aGUgcmVxdWlyZW1lbnQgdGhhdCBtdWx0aS12YWx1ZSBg YXVkYCBjbGFpbXMgbXVzdCBvbmx5IGNvbnRhaW4gYWxpYXNlcyBmb3IgdGhlIHNhbWUgcmVzb3Vy Y2UgaW5kaWNhdG9yLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVu dGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0 b3Jpbz00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMu aWV0Zi5vcmc+Pg0KRGF0ZTogTW9uZGF5LCBEZWNlbWJlciAxNiwgMjAxOSBhdCAyOjUxIFBNDQpU bzogSUVURiBvYXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4N CkNjOiAiaS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+ IiA8aS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0K U3ViamVjdDogUmU6IFtPQVVUSC1XR10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vYXV0aC1hY2Nl c3MtdG9rZW4tand0LTAzLnR4dA0KDQpEZWFyIGFsbCwNCkkgZmluYWxseSBmb3VuZCB0aGUgdGlt ZSB0byBwdXNoIGEgbmV3IGRyYWZ0IG9mIHRoZSBKV1QgcHJvZmlsZSBmb3IgQVRzLiBUaGlzIHZl cnNpb24gaW5jb3Jwb3JhdGVzIHRoZSBmZWVkYmFjayBraW5kbHkgcHJvdmlkZWQgYnkgQnJpYW4g YW5kIEFhcm9uIGF0IElFVEYxMDUuDQpVbmZvcnR1bmF0ZWx5IEkgZGlkbid0IGhhdmUgYSBjaGFu Y2UgdG8gcGFydGljaXBhdGUgdG8gSUVURjEwNiwgaGVuY2Ugd2UgZGlkbid0IGRvIG11Y2ggcHJv Z3Jlc3Mgc2luY2UgdGhlbi4NClRoZXJlIGFyZSBzdGlsbCB0d28gYXJlYXMgd2UgZGlkbid0IG1h bmFnZSB0byByZWFjaCBjb25zZW5zdXMgb246DQoNCjEuIE1lY2hhbmlzbXMgZm9yIHNpZ25hbGlu ZyB3aGV0aGVyIHRoZSBBVCB3YXMgb2J0YWluZWQgYnkgYSB1c2VyIG9yIGFuIGFwcGxpY2F0aW9u DQoNClRoaXMgcG9pbnQgd2FzIHRoZSBzdWJqZWN0IG9mIGludGVuc2UgZGViYXRlIG9uIHRoZSBs aXN0IGxlYWRpbmcgdG8gSUVURjEwNS4uDQpPbmUgaW5zaWdodCB0aGF0IGVtZXJnZWQgZnJvbSB0 aGUgSUVURjEwNSBkaXNjdXNzaW9uIHdhcyB0aGF0IHRoZSB1c2UgY2FzZSBoZXJlIGlzIG1vcmUg YWJvdXQgd2hldGhlciB0aGUgQVQgaGFzIGJlZW4gb2J0YWluZWQgdmlhIGEgZ3JhbnQgdGhhdCBh dXRoZW50aWNhdGVkIHRoZSBjbGllbnQgKHJlZ2FyZGxlc3Mgb2Ygd2hhdCBzcGVjaWZpYyBncmFu dCB3YXMgdXNlZCkgdnMgYSBwdWJsaWMgY2xpZW50IGdyYW50LSB0aGF0IGluZm9ybWF0aW9uIGNh biBiZSByZWxldmFudCB0byBhIHJlc291cmNlIGFzIGl0IGRldGVybWluZXMgd2hldGhlciB0aGUg aWRlbnRpdHkgb2YgdGhlIGNsaWVudCBjYW4gYmUgdXNlZCBpbiBhdXRob3JpemF0aW9uIGRlY2lz aW9ucyAoaW4gdGhlIGZvcm1lciBjYXNlKSBvciBub3QgKGluIHRoZSBwdWJsaWMgY2xpZW50IGNh c2UpLiBJZiB0aGF0J3MgdGhlIHNjZW5hcmlvIHdlIGFyZSB0cnVseSBhZnRlciwgYSBzaW1wbGUs IHBvc3NpYmx5IG9wdGlvbmFsIGJvb2xlYW4gY2xhaW0gKHNheSBBdXRoZW50aWNhdGVkQ2xpZW50 KSB3b3VsZCBzdWZmaWNlLg0KTm90ZSBmb3IgdGhlIHBlb3BsZSB3aG8gZGlkbid0IHJlYWQgdGhl IHNwZWM6IEkgcmVtb3ZlZCBhbnkgcmVmZXJlbmNlIHRvIHRoaXMgYWxyZWFkeSBpbiBkcmFmdC1p ZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDEuIEkgdGhpbmsgdGhpcyBpcyBhbiBpbXBvcnRh bnQgYW5kIHVzZWZ1bCBpbmZvIGFuZCBzdGFuZGFyZGl6aW5nIGl0IHdvdWxkIGJlIGJlbmVmaWNp YWwgZm9yIG1pZGRsZXdhcmUgYW5kIFNESyBjcmVhdG9ycywgYnV0IHVsdGltYXRlbHkgdGhpcyBp cyBhbiBpbnRlcm9wIHByb2ZpbGUgaGVuY2UgaWYgdGhlcmUncyBubyBzdHJvbmcgZGVzaXJlIHRv IHJlYWNoIGFuIGFncmVlbWVudCBoZXJlLCBJIGFtIGFsc28gT0sgd2l0aCBkcm9wcGluZyB0aGUg bWF0dGVyIGFuZCBub3QgYWRkcmVzcyB0aGlzIGZ1bmN0aW9uIGluIHRoZSBzcGVjLg0KVG8gc3Vt bWFyaXplLCBJIGhhdmUgdHdvIHF1ZXN0aW9ucyBoZXJlOg0KQS4gRG8gd2UgYmVsaWV2ZSBpdCdz IHdvcnRoIGl0IHRvIGZvcm1hbGl6ZSBpbiB0aGUgcHJvZmlsZSBhIG1lY2hhbmlzbSB0byBpbmRp Y2F0ZSB3aGV0aGVyIHRoZSBjbGllbnQgdGggb2J0YWluZWQgdGhlIEFUIGF1dGhlbnRpY2F0ZWQg aXRzZWxmIHdpdGggdGhlIEFTPw0KQi4gSWYgeWVzLCBhcmUgeW91IE9LIHdpaHQgYW4gb3B0aW9u YWwgYm9vbCBjbGFpbSBoZXJlPw0KDQoyLiBDbGFpbXMgaW5kaWNhdGluZyBzZXNzaW9uIHByb3Bl cnRpZXMNCg0KVGhpcyBpcyBvbmUgYXJlYSB3aGVyZSBJIGFtIGZhciBtb3JlIHBhc3Npb25hdGUg YWJvdXQsIGFzIGl0IHJlcHJlc2VudHMgYSBmdW5kYW1lbnRhbCBhc3BlY3QgdGhhdCBwcm9kdWN0 aW9uIHN5c3RlbXMgKGFuZCBpbiBwYXJ0aWN1bGFyIDFzdCBwYXJ0eSBzb2x1dGlvbnMpIGFscmVh ZHkgcmVseSBvbiBpbiB0aGUgY3VycmVudCBwcm9wcmlldGFyeSBKVFcgQVRzLg0KVGhlIHByb2Zp bGUgY3VycmVudGx5IGluY2x1ZGVzIHRoZSBjbGFpbXMgYXV0aF90aW1lLCBhY3IgYW5kIGFtciAt IGNhcHR1cmluZyB0aGUgdmFsdWVzIG9mIHRob3NlIHByb3BlcnRpZXMgYXQgdGhlIHRpbWUgb2Yg dGhlIGxhdGVzdCBhdXRoZW50aWNhdGlvbiB0aGUgdXNlciBwZXJmb3JtZWQgaW4gdGhlIHNlc3Np b24gdXNlZCB0byBpc3N1ZSB0aGUgY3VycmVudCBBVDogYXQgc2Vzc2lvbiBjcmVhdGlvbiwgYXQg YXV0aCBzdGVwIHVwIHRpbWUgYW5kIHNvIG9uLg0KVGhvc2UgYXJlIHZhbHVlcyB0aGF0IEFQSSBu ZWVkIGluIG9yZGVyIHRvIG1ha2UgYXV0aG9yaXphdGlvbiBkZWNpc2lvbnM7IGluIHRoZSBjYXNl IG9mIDFzdCBwYXJ0eSBBUElzLCB0aGUgQVQgaXMgdGhlIG9ubHkgYXJ0aWZhY3QgdGhleSBldmVy IHJlY2VpdmUgaGVuY2UgdGhlcmUgaXMgbm8gb3RoZXIgd2F5IGZvciBhbiBBUEkgdG8gZGV0ZXJt aW5lIHdoZXRoZXIgdGhlIGNhbGxlciBwZXJmb3JtZWQgc2F5IE1GQSBpbiBvcmRlciB0byBvYnRh aW4gdGhlIGN1cnJlbnQgQVQuDQpTaW5jZSB0aGUgZmlyc3QgZHJhZnQsIHNvbWUgcGVvcGxlIHNp Z25hbGVkIGNvbmNlcm5zIGFib3V0IHRoZSBjdXJyZW50IG1lY2hhbmlzbXMgdGhydSB3aGljaCB0 aG9zZSBjbGFpbXMgZ2V0IHRoZWlyIHZhbHVlLiBGb3IgZXhhbXBsZSwgaXQgaGFzIGJlZW4gcHJv cG9zZWQgdG8gbWFpbnRhaW4gdGhlIG9yaWdpbmFsIHZhbHVlcyBvZiBhdXRoX3RpbWUsIGFjciAm IGFtciBhbmQgaW50cm9kdWNlIGFkZGl0aW9uYWwgY2xhaW1zIHRvIGluZGljYXRlIGNoYW5nZXMg KGxpa2Ugc3RlcHVwKS4NCkkgYW0gbm90IGNsZWFyIG9uIHdoYXQgY29sZCBnbyB3cm9uZyB3aXRo IHRoZSBjdXJyZW50IGFwcHJvYWNoLCBoZW5jZSBJIGRvbid0IGhhdmUgYW4gaW1tZWRpYXRlIGdy YXNwIG9mIGhvdyBjaGFuZ2VzIGxpa2UgdGhlIGFib3ZlIHdvdWxkIGhlbHAuDQpJZiB0aGUgcGVv cGxlIHVuY29tZm9ydGFibGUgd2l0aCB0aGUgY3VycmVudCBwcm9wb3NhbCBjb3VsZCBkZXRhaWwg dGhlaXIgY29uY2Vybiwgd2UgY2FuIGJyYWluc3Rvcm0gd2F5cyB0byBtYWtlIHRoYXQgaW5mbyBh dmFpbGFibGUgdG8gQVBJIGluIGEgc2FmZXIgd2F5LiBUbyBzdW1tYXJpemU6DQpBLiBEbyB5b3Ug aGF2ZSBjb25jZXJucyB3aXRoIHRoZSBjdXJyZW50IGF1dGhfdGltZSwgYXJtLCBhY3IgcHJvcG9z YWw/IENhbiB5b3Ugc3BlbGwgdGhlbSBvdXQ/IChwbGVhc2UgcmVhZCB0aGUgcmVsZXZhbnQgcGFy dHMgb2YgdGhlIHNwZWMgYmVmb3JlIGNoaW1pbmcgaW4gOikpDQpCLiBJZiB5ZXMsIHdoYXQgY2Fu IHdlIGRvIHRvIG1ha2UgdGhhdCBpbmZvIGF2YWlsYWJsZSB0byBSU3MgaW4gYSB3YXkgdGhhdCBt YWtlcyB5b3UgY29tZm9ydGFibGU/DQoNCg0KVGhhbmtzDQoNClYuDQoNCk9uIE1vbiwgRGVjIDE2 LCAyMDE5IGF0IDI6NDkgUE0gPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPj4gd3JvdGU6DQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2 YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29s IFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IEpTT04gV2ViIFRv a2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zDQogICAgICAgIEF1 dGhvciAgICAgICAgICA6IFZpdHRvcmlvIEJlcnRvY2NpDQogICAgICAgIEZpbGVuYW1lICAgICAg ICA6IGRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMy50eHQNCiAgICAgICAgUGFn ZXMgICAgICAgICAgIDogMTYNCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxOS0xMi0xNg0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgcHJvZmlsZSBmb3Ig aXNzdWluZyBPQXV0aCAyLjAgYWNjZXNzDQogICB0b2tlbnMgaW4gSlNPTiB3ZWIgdG9rZW4gKEpX VCkgZm9ybWF0LiAgQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGFuZA0KICAgcmVzb3VyY2Ugc2VydmVy cyBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzIGNhbiBsZXZlcmFnZSB0aGlzIHByb2ZpbGUgdG8NCiAg IGlzc3VlIGFuZCBjb25zdW1lIGFjY2VzcyB0b2tlbnMgaW4gaW50ZXJvcGVyYWJsZSBtYW5uZXIu DQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vz cy10b2tlbi1qd3QvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJs ZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vz cy10b2tlbi1qd3QtMDMNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2 aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMNCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNCkludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDov L2Z0cC4uaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzxmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_16EBA41506A94190B8C3EE96771B70BDamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjIgMCA1IDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIg NiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAy IDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2Ut MToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJQVCBN b25vIjsNCglwYW5vc2UtMToyIDYgNSA5IDIgMiA1IDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFRoYXQncyBhIHByZXR0eSBzdHJvbmcg c3RhdGVtZW50IDopJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBJIHNob3VsZOKA mXZlIGNsYXJpZmllZC4gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FwcGxlIENvbG9y IEVtb2ppJnF1b3Q7Ij4NCiYjMTI4NTE1Ozwvc3Bhbj4gSSBkb27igJl0IG1lYW4gdGhhdCB0aGUg b25lLVJTLXBlci1BVCBtb2RlbCBpcyBub3QgdXNlZCBhdCBhbGwsIGp1c3QgdGhhdCBpdCBpcyBu b3QgdW5pdmVyc2FsIGFuZCBjb21lcyB3aXRoIHJlYWwsIHByYWN0aWNhbCB0cmFkZW9mZnMgdGhh dCBtYXkgbm90IGJlIGFwcHJvcHJpYXRlIGZvciBhbGwgdXNlIGNhc2VzLiBDb25zZXF1ZW50bHks IHdlIHNob3VsZCBub3QgZGVzaWduIGZ1bmRhbWVudGFsIHNwZWNzIHRoYXQgbWFuZGF0ZSBpdHMN CiBhZG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IOKApmtub3dsZWRnZSBvZiB0aGF0IGxldmVsIGlz bid0IG5lY2Vzc2FyeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RWl0aGVyIHRoZSBSUyBhbmQg QVMgaGF2ZSBhIHNoYXJlZCB1bmRlcnN0YW5kaW5nIG9mIHRoYXQgbGV2ZWwsIG9yIHRoZSBSUyBp cyB0cnVzdGluZyB0aGUgQVMgdG8gZGVjaWRlIHdoYXQg4oCcQXV0aGVudGljYXRlZENsaWVudOKA nSBtZWFucywgYW5kIHNldCBpdCBhY2NvcmRpbmdseS4gVGhlIGxhdHRlciByZXF1aXJlcyB0aGF0 IHRoZSBSUyBvbmx5IHN1cHBvcnRzIEFTZXMgdGhhdCBoYXZlIGEgc2hhcmVkIChvciBzdWJzdGFu dGlhbGx5DQogc2ltaWxhcikgdW5kZXJzdGFuZGluZyBvZiB3aGF0IHRoYXQgbGV2ZWwgaXMsIHdo aWNoIGlzIHVubGlrZWx5IG91dHNpZGUgb2YgYSBjbG9zZWQgc3lzdGVtLiBJbiB0aGF0IGNhc2Us IHRoZXJlIGlzbuKAmXQgYSBsb3Qgb2YgdmFsdWUgaW4gcHJvdmlkaW5nIGEgc3RhbmRhcmQgY2xh aW0sIGFzIHRoZSBjbG9zZWQgc3lzdGVtIGNvdWxkIGp1c3QgYXMgZWFzaWx5IGRlZmluZSBhIHBy b3ByaWV0YXJ5IG9uZS48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBD b3VsZCB5b3UgZXhwYW5kIG9uIGEgY29uY3JldGUgc2NlbmFyaW8gdGhhdCB3b3VsZCBsZWFkIHRv IGFuIGFudGlwYXR0ZXJuIGJlY2F1c2Ugb2YgdGhlIHByZXNlbmNlIG9mIHRob3NlIGNsYWltcyBp biB0aGUgcHJvZmlsZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgSSBjb3VsZCwgdGhlbiBJ IHdvdWxkbuKAmXQgYmUgY29uY2VybmVkIGFib3V0IGRlZmluaW5nIHRoaXMgcGllY2Ugb2YgdGhl IHB1enpsZSB3aXRob3V0IHRoZSByZXN0IG9mIGl0Lg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FwcGxlIENvbG9yIEVtb2ppJnF1b3Q7Ij4mIzEyODUxNTs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkluIHlvdXIgZXhwZXJpZW5jZSwgYXJlIHRoZSBleGlzdGluZyBzeXN0 ZW1zIHRoYXQgdXNlIHRoZXNlIGNsYWltcyByZWFkaW5nIHRoZW0gZnJvbSBJRCBUb2tlbnMsIG9y IGZyb20gSldUIGFjY2VzcyB0b2tlbnM/IEFyZSB0aGVzZSB0eXBpY2FsbHkgY2xpZW50cyB0aGF0 IGFyZSBhY2Nlc3NpbmcgdGhlaXIgb3duIFJTZXMsIHVzaW5nIHRva2VucyB2ZW5kZWQgYnkgYW4g SWRQPyAoZS5nLiwgYSBTYWFTIHByb2R1Y3QNCiB0aGF0IGdldHMgdG9rZW5zIGZyb20gYSBob3N0 ZWQgSURhYVMgcHJvZHVjdCkgSSBhc2sgYmVjYXVzZSBPSURDIGNsaWVudHMgY2FuIHNwZWNpZml5 IG1heF9hZ2UgYW5kIGFjcl92YWx1ZXMsIGFuZCBpZiBjbGllbnQgYW5kIFJTIGFyZSBvd25lZCBi eSB0aGUgc2FtZSBlbnRpdHkgdGhlbiB0aGV5IGNhbiBkbyB3aGF0ZXZlciBwcm9wcmlldGFyeSB0 aGluZyB0aGV5IHdhbnQgdG8gaW5kaWNhdGUgdGhlIHJlYXNvbiBmb3IgYW4gYXV0aG9yaXphdGlv bg0KIGZhaWx1cmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBS aWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlZpdHRvcmlvIEJlcnRvY2NpICZsdDtW aXR0b3Jpb0BhdXRoMC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIERlY2VtYmVy IDE3LCAyMDE5IGF0IDEyOjA0IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2tt YW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDs8YnI+DQo8Yj5D YzogPC9iPlZpdHRvcmlvIEJlcnRvY2NpICZsdDtWaXR0b3Jpbz00MGF1dGgwLmNvbUBkbWFyYy5p ZXRmLm9yZyZndDssIElFVEYgb2F1dGggV0cgJmx0O29hdXRoQGlldGYub3JnJmd0OywgJnF1b3Q7 aS1kLWFubm91bmNlQGlldGYub3JnJnF1b3Q7ICZsdDtpLWQtYW5ub3VuY2VAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbT0FVVEgt V0ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMy50eHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGUgb25lLVJTLXBlci1BVCBtb2RlbCBpcyBhbiBpZGVhbCB0aGF0 IHNpbXBseSBkb2VzbuKAmXQgbWF0Y2ggcmVhbGl0eS4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0J3MgYSBw cmV0dHkgc3Ryb25nIHN0YXRlbWVudCA6KSBJIGhhdmUgd29ya2VkIHdpdGggYSB2ZXJ5IGxhcmdl IG51bWJlciBvZiBkZXZlbG9wZXJzLCBvbiBhIHZlcnkgbGFyZ2UgbnVtYmVyIG9mIGFwcGxpY2F0 aW9ucy4gSSBkb24ndCBkaXNwdXRlIHRoYXQgeW91ciBleHBlcmllbmNlIG1pZ2h0IGJlIGRpZmZl cmVudCwgYnV0IHRoZSBvbmUgQVQgcGVyIFJTIGlzIGRhaWx5IHJlYWxpdHkgZm9yIGh1bmRyZWRz DQogb2YgdGhvdXNhbmRzIG9mIGFwcHMgaW4gcHJvZHVjdGlvbiB0b2RheS4gVGhhdCdzIHJlYWwg YnkgYW55IG1lYXN1cmUgb2YgcmVhbGl0eS4gVGhlIGZhY3QgdGhhdCBBRCBvZmZlcnMgUlRzIHRo YXQgYmVoYXZlIGxpa2UgVEdUcyBtYWtlcyBpdCBwb3NzaWJsZS4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJBUiBpcyBhbiBpbnRlcmVz dGluZyBkZXZlbG9wbWVudCwgYnV0IGl0J3MgaW4gdGhlIGluY2VwdGlvbiBwaGFzZS4gVGhlIGF1 ZCBhbmQgc2NvcGVzIGNsYWltcyBhcmUgYWxyZWFkeSBpbiBuZWFybHkgYWxsIHRoZSBwcm9wcmll dGFyeSBKV1QgaW1wbGVtZW50YXRpb25zIGluIHByb2R1Y3Rpb24gdG9kYXksIGFzIHNob3duIGlu IHRoZSByZXNlYXJjaCBJIHByZXNlbnRlZCB3aGVuIHRoZSBkcmFmdCB3YXMgYWRvcHRlZA0KIGJ5 IHRoZSBXRywgaGVuY2UgaXQgc2VlbXMgbmF0dXJhbCB0byBpbmNsdWRlIHRoZW0gaW4gYW4gaW50 ZXJvcCBwcm9maWxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Tm90aGluZyBwcmV2ZW50cyB1cyBmcm9tIGRldmVsb3BpbmcgaXQgZnVydGhlciBh cyBuZXcgYXBwcm9hY2hlcyZuYnNwO2dhaW4gdHJhY3Rpb24gb24gdGhlIG1hcmtldCwgYnV0IGZv ciB0aGUgdGltZSBiZWluZyBJIHRoaW5rIHRoZSB2YWx1ZSBvZiB0aGlzIHdvdWxkIGJlIHRvIGJy aW5nIHNvbWUgb3JkZXIgaW4gZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zJm5ic3A7YW5kIGNvbnRh aW4gYWJ1c2VzIHN1Y2ggYXMgaWRfdG9rZW5zDQogdXNlZCBpbiBsaWV1IG9mIGFjY2VzcyB0b2tl bnMgdG9kYXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPknigJltIHNrZXB0aWNhbCBvZiB0aGUgaWRlYSB0aGF0IHRoZXJlIGlzIGp1 c3Qgb25lIGxldmVsIG9mIGNsaWVudCBpZGVudGl0eSBwcm9vZmluZyB0aGF0IFJTZXMgbWlnaHQg Y2FyZSBhYm91dC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgc2NlbmFyaW8gdGhhdCBsZWQgbWUgdG8gaW5jbHVk ZSB0aGlzIGl0ZW0gaW4gdGhlIGRpc2N1c3Npb24sIGtub3dsZWRnZSBvZiB0aGF0IGxldmVsIGlz bid0IG5lY2Vzc2FyeS4gQWdhaW4sIEkgYWdyZWUgaXQgd291bGQgYmUgdXNlZnVsIHRvIGRlZmlu ZSB0aG9zZSBsZXZlbHMsIGJ1dCBJIGRvbid0IHRoaW5rIGl0IHdvdWxkIGJlIGluIHNjb3BlIGhl cmUuIElmIGluY2x1c2lvbiBvZiB0aGF0IGluZm8NCiBpbiB0aGUgSldUIEFUIHdvdWxkIGJlIGNv bmRpdGlvbmFsIHRvIGRvIGFsbCB0aGF0IHdvcmssIEknZCBtdWNoIHJhdGhlciBkcm9wIHRoYXQg YXNwZWN0IGluIGZhdm9yIG9mIG1ha2luZyBmYXN0ZXIgcHJvZ3Jlc3MuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGhvdXQgdGFr aW5nIHRoZSB3aG9sZSBwaWN0dXJlIGludG8gYWNjb3VudCwgdGhlcmUgaXMgc2lnbmlmaWNhbnQg cmlzayB0aGF0IHdlIHdpbGwgZGVmaW5lIHNvbWV0aGluZyB0aGF0IHR1cm5zIG91dCB0byBiZSB3 b2VmdWxseSBpbnN1ZmZpY2llbnQgKG9yIHdvcnNlLCBlc3RhYmxpc2hlcyBhbiBhbnRpLXBhdHRl cm4pLiBUaGF0IHNhaWQsIEkgYWdyZWUgdGhhdCBpdOKAmXMgcHJvYmFibHkgbm90IGFwcHJvcHJp YXRlDQogZm9yIHRoaXMgZHJhZnQsIGFuZCByZWNvbW1lbmQgZHJvcHBpbmcgdGhlc2UgY2xhaW1z LiBUaGV5IGNhbiBhbHdheXMgYmUgZGVmaW5lZCBpbiBhIHNlcGFyYXRlIGRyYWZ0LCBhbG9uZyB3 aXRoIHRoZSBvdGhlciBlbGVtZW50cyBuZWNlc3NhcnkgdG8gY29tbXVuaWNhdGUgc3RlcC11cCBy ZXF1aXJlbWVudHMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q291bGQgeW91IGV4cGFuZCBvbiBhIGNvbmNyZXRlIHNjZW5h cmlvIHRoYXQgd291bGQgbGVhZCB0byBhbiBhbnRpcGF0dGVybiBiZWNhdXNlIG9mIHRoZSBwcmVz ZW5jZSBvZiB0aG9zZSBjbGFpbXMgaW4gdGhlIHByb2ZpbGU/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBhbHJlYWR5IGxvZ2ljIG91 dCB0aGVyZSBwcmVkaWNhdGVkIG9uIHRob3NlIGNsYWltIHZhbHVlcywgcHJlY2lzZWx5IGJlY2F1 c2UgSURfdG9rZW4gZGVmaW5lcyB0aGVtIGFuZCB2ZW5kb3JzIGxhdGNoIG9udG8gdGhlbS4gSSBh bSBjb25jZXJuZWQgdGhhdCBpZiB3ZSBkb24ndCBpbmNsdWRlIHRob3NlIGNsYWltcyBpbiB0aGUg cHJvZmlsZSwgcGVvcGxlIHdpbGwgc2ltcGx5IGtlZXAgdXNpbmcgSURfdG9rZW5zDQogZm9yIGNh bGxpbmcgQVBJcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBUdWUsIERlYyAxNywgMjAxOSBhdCAxMTozOSBBTSBSaWNoYXJkIEJhY2tt YW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iPnJp Y2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7IElu IGFueSBjYXNlIHRoZSBpbnRlbnQgd2FzIGFsd2F5cyB0byBvbmx5IGFsbG93IGEgc2luZ2UgcmVz b3VyY2UgcGVyIEFU4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NeSBjb25mdXNpb24g YWN0dWFsbHkgY29tZXMgZnJvbSB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgwqczLCB3aGVyZSBpdCBz YXlzIOKAnElmIGEgc2NvcGUgcGFyYW1ldGVyIGlzIHByZXNlbnQgaW4gdGhlIHJlcXVlc3QsIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgdXNlIGl0IHRvIGluZmVyIHRoZSB2YWx1ZQ0K IG9mIHRoZSBkZWZhdWx0IHJlc291cmNlIGluZGljYXRvciB0byBiZSB1c2VkIGluIHRoZSBhdWQg Y2xhaW0u4oCdIEkgaW50ZXJwcmV0ZWQgdGhhdCB0byBsZWF2ZSByb29tIGZvciBhbiBBUyBpbmZl cnJpbmcgdGhlIHNhbWUg4oCcZ2VuZXJpY+KAnSByZXNvdXJjZSBpbmRpY2F0b3IgZm9yIHJlc291 cmNlcyBzZXJ2ZWQgYnkgZGlmZmVyZW50IFJTZXMuIFRoZSBvbmUtUlMtcGVyLUFUIG1vZGVsIGlz IGFuIGlkZWFsIHRoYXQgc2ltcGx5IGRvZXNu4oCZdCBtYXRjaA0KIHJlYWxpdHkuIENsaWVudHMg ZG9u4oCZdCB3YW50IHRvIGhhdmUgdG8ganVnZ2xlIGEgYnVuY2ggb2YgZGlmZmVyZW50IHRva2Vu cywgbm9yIHNob3VsZCB0aGV5IG5lZWQgdG8uIEnigJltIGNvbWluZyB0byB0aGluayB0aGF0IHdl IHNob3VsZG7igJl0IGFjdHVhbGx5IHVzZSBgYXVkYCBhbmQgYHNjb3BlYCBpbiBKV1QgQVRzIGF0 IGFsbCwgYW5kIGluc3RlYWQgYWRvcHQgdGhlIHN0cnVjdHVyZSBSQVIgZGVmaW5lcyB1c2VkIGZv ciB0aGUgYGF1dGhvcml6YXRpb25fZGV0YWlsc2ANCiBwYXJhbWV0ZXIgKEkgdGhpbmsgc29tZSBp dGVyYXRpb24gaXMgcmVxdWlyZWQsIGJ1dCBpdCBzZWVtcyBuYXR1cmFsIGZvciB0aGVzZSB0d28g dG8gZGVzY3JpYmUgYXV0aG9yaXphdGlvbnMgaW4gdGhlIHNhbWUgb3IgY29tcGF0aWJsZSB3YXlz KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7IOKApnRoZSByZXNvdXJjZSB3YW50cyB0byBrbm93IHdo ZXRoZXIgdGhpcyBwYXJ0aWN1bGFyIHRva2VuIHdhcyBvYnRhaW5lZCBwcm92aW5nIHRoZSBpZGVu dGl0eSBvZiB0aGUgY2xpZW504oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J4oCZbSBz a2VwdGljYWwgb2YgdGhlIGlkZWEgdGhhdCB0aGVyZSBpcyBqdXN0IG9uZSBsZXZlbCBvZiBjbGll bnQgaWRlbnRpdHkgcHJvb2ZpbmcgdGhhdCBSU2VzIG1pZ2h0IGNhcmUgYWJvdXQuIFRoZXJlIG1p Z2h0IGJlIHNvbWUgY2xlYXIgbGluZXMgdGhhdCBjYW4gYmUgZHJhd24sIGJ1dCB3ZSBzaG91bGQg YmUNCiBleHBsaWNpdCBhYm91dCB3aGF0IHRob3NlIGxpbmVzIHJlcHJlc2VudCwgZS5nLiwg4oCc Y2xpZW50IGF1dGhlbnRpY2F0ZWQgdXNpbmcgcHJlLWVzdGFibGlzaGVkIGNyZWRlbnRpYWzigJ0s IOKAnGNsaWVudCBpcyBydW5uaW5nIG9uIGVuZCB1c2VyLWNvbnRyb2xsZWQgZGV2aWNl4oCdLCBl dGMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyBJIGFtIG5vdCB0cnlpbmcgdG8gY3JlYXRlIGEgY29t cGxldGUgZnJhbWV3b3JrIGZvciBoYW5kbGluZyBzdGVwIHVwIGFuZCB0aGUgbGlrZSwgSSBhbSB0 cnlpbmcgdG8gY3JlYXRlIGFuIGludGVyb3BlcmFibGUgcmVwcmVzZW50YXRpb24gb2YgdGhvc2Ug dmFsdWVzIG5vIG1hdHRlciBob3cgdGhleSB3ZXJlDQogb2J0YWluZWQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5XaXRob3V0IHRha2luZyB0aGUgd2hvbGUgcGljdHVyZSBpbnRvIGFjY291 bnQsIHRoZXJlIGlzIHNpZ25pZmljYW50IHJpc2sgdGhhdCB3ZSB3aWxsIGRlZmluZSBzb21ldGhp bmcgdGhhdCB0dXJucyBvdXQgdG8gYmUgd29lZnVsbHkgaW5zdWZmaWNpZW50IChvciB3b3JzZSwg ZXN0YWJsaXNoZXMgYW4gYW50aS1wYXR0ZXJuKS4NCiBUaGF0IHNhaWQsIEkgYWdyZWUgdGhhdCBp dOKAmXMgcHJvYmFibHkgbm90IGFwcHJvcHJpYXRlIGZvciB0aGlzIGRyYWZ0LCBhbmQgcmVjb21t ZW5kIGRyb3BwaW5nIHRoZXNlIGNsYWltcy4gVGhleSBjYW4gYWx3YXlzIGJlIGRlZmluZWQgaW4g YSBzZXBhcmF0ZSBkcmFmdCwgYWxvbmcgd2l0aCB0aGUgb3RoZXIgZWxlbWVudHMgbmVjZXNzYXJ5 IHRvIGNvbW11bmljYXRlIHN0ZXAtdXAgcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+QVdTIElkZW50aXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5WaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7 Vml0dG9yaW89PGEgaHJlZj0ibWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5Nb25kYXksIERlY2VtYmVyIDE2LCAyMDE5IGF0IDk6MzEgUE08YnI+DQo8Yj5Ubzog PC9iPiZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpv bi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+SUVURiBvYXV0aCBXRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+ Jmd0OywgVml0dG9yaW8gQmVydG9jY2kgJmx0OzxhIGhyZWY9Im1haWx0bzpWaXR0b3Jpb0BhdXRo MC5jb20iIHRhcmdldD0iX2JsYW5rIj5WaXR0b3Jpb0BhdXRoMC5jb208L2E+Jmd0OywgJnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmkt ZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmktZC1h bm5vdW5jZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVU SC1XR10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzLnR4 dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NClJl OiBhbGlhc2VzLCBJIHNlZSB3aGVyZSB0aGUgY29uZnVzaW9uIGlzIGNvbWluZyBmcm9tITxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQpJIHVwZGF0ZWQgdGhlIHJlcXVlc3Qgc2VjdGlvbiwgYnV0IHRo ZSBzZXNzaW9uIDIuMiBkYXRhIHN0cnVjdHVyZSBzdGlsbCBtZW50aW9ucyB0aGUgYWxpYXNlcy4g VGhhdCBzaG91bGQgYmUgY2xlYW5lZCB1cCBhcyB3ZWxsLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K SW4gYW55IGNhc2UgdGhlIGludGVudCB3YXMgYWx3YXlzIHRvIG9ubHkgYWxsb3cgYSBzaW5nZSBy ZXNvdXJjZSBwZXIgQVQsIHRoZSBhbGlhcyBsaXN0IHdhcyBvbmx5IGZvciBoZWxwaW5nIGluIGNh c2VzIHdoZXJlIGFuIEFTIGlkZW50aWZpZXMgdGhlIHNhbWUgcmVzb3VyY2UgdGhydSBtdWx0aXBs ZSBJRHMgYW5kIHRoZSBhY3R1YWwgYXVkIHZhbHVlIGRlcGVuZHMgb24gd2hhdCBJRCB0aGUgY2xp ZW50IHJlcXVlc3RlZC4gSG93ZXZlciB3ZSBkaXNjdXNzZWQNCiB0aGlzIHdpdGggQnJpYW4gYW5k IGhlIGNvbnZpbmNlZCBtZSB0aGF0IGl0IHdhcyBqdXN0IHRvbyBhbWJpZ3VvdXMtIHlvdXIgcmVt YXJrIHJlaW5mb3JjZXMgdGhhdCBpbXByZXNzaW9uLiBJ4oCZbGwgY2xlYW4gdXAgMi4yIGFuZCBl bGltaW5hdGUgcmVmZXJlbmNlcyB0byBhbGlhc2VzIGZyb20gdGhlcmUgYXMgd2VsbC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluIj4NClRoYW5rcyE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluIj4NCk9uIE1vbiwgRGVjIDE2LCAyMDE5IGF0IDIwOjE5IFZpdHRv cmlvIEJlcnRvY2NpICZsdDs8YSBocmVmPSJtYWlsdG86Vml0dG9yaW9AYXV0aDAuY29tIiB0YXJn ZXQ9Il9ibGFuayI+Vml0dG9yaW9AYXV0aDAuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NClRo YW5rcyBBbm5hYmVsbGUuIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpEb2VzIGEgbW9iaWxlIGFwcCB0aGF0IHVzZXMgRHlu YW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIHRvIGVzdGFibGlzaCBhIGNsaWVudCBzZWNyZXQgY291 bnQgYXMgYW4g4oCcYXV0aGVudGljYXRlZCBjbGllbnTigJ0/Jm5ic3A7Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0Oi41aW4iPg0KSSB0aGluayBpdCBzaG91bGQgY291bnQsIHRobyBJIGFtIG5vdCBzdXJl IHdoYXQgdGhlIFJTIHdvdWxkIGRvIHdpdGggaXQuIER5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlv biB3b3VsZCBsaWtlbHkgbm90IGhhdmUgbXVjaCB1c2UgZm9yIHRoaXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+ DQpJbiB0aGUgY2FzZXMgSSBoYXZlIHNlZW4sIHRoZSBpZGVhIGlzIHRoYXQgYSBjbGllbnQgKHdo b3NlIGNsaWVudElEIGlzIGFscmVhZHkga25vd24gdG8gdGhlIFJTKSBjYW4gb2J0YWluIHRva2Vu cyB0aHJ1IGRpZmZlcmVudCBncmFudHMsIHNvbWUgb2YgdGhlbSBjb25maWRlbnRpYWwgYW5kIG90 aGVycyBwdWJsaWM7IGFuZCB0aGUgcmVzb3VyY2Ugd2FudHMgdG8ga25vdyB3aGV0aGVyIHRoaXMg cGFydGljdWxhciB0b2tlbiB3YXMgb2J0YWluZWQgcHJvdmluZw0KIHRoZSBpZGVudGl0eSBvZiB0 aGUgY2xpZW50IHNvIHRoYXQgaXQgY2FuIGRlY2lkZSB3aGV0aGVyIHRvIGdyYW50IGV4dHJhIHBy aXZpbGVnZXMgZm9yIHRoYXQgcGFydGljdWxhciZuYnNwO2NsaWVudCBpbiB0aGUgY3VycmVudCBj YWxsLiBUaGlzIHNjZW5hcmlvIGRvZXMgbm90IHJlcXVpcmUgdGhlIGV4dHJhIGRldGFpbHMgYWJv dXQgYXV0aGVudGljYXRpb24gbWV0aG9kL3N0cmVuZ3RoIHlvdSBtZW50aW9uIHRoYXQsIEkgYWdy ZWUsIHdvdWxkIGJlIHByZXR0eQ0KIGhhcmQgdG8gcmVhY2ggY29uc2Vuc3VzIG9uLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 Oi41aW4iPg0KVEw7RFI6IHRoZXJlIGlzIGF0IGxlYXN0IG9uZSBzY2VuYXJpbyB0aGF0IGlzIHNh dGlzZmllZCBieSB0aGUgc2ltcGxlIGJvb2wsIGFzIHRoZSBwcmV2aW91cyBrbm93bGVkZ2Ugb2Yg dGhlIGNsaWVudCBzb2x2ZXMgdGhlIGlzc3VlcyB5b3UgbWVudGlvbiBvdXQgb2YgYmFuZC4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCmF1dGhlbnRpY2F0aW9uIHNlc3Npb24gcHJvcGVy dGllczombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDtMZXQgbWUgdHJ5IGFub3Ro ZXIgYW5nbGUuIFNheSB0aGF0IEkgcGVyZm9ybSBhbiBhdXRoeiBjb2RlIGdyYW50IGFza2luZyBm b3IgQVQsIElEX1QgYW5kIFJULSBvYnRhaW5pbmcgQVQnLCBJRF9UJyBhbmQgUlQnLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0Oi41aW4iPg0KVGhlIHZhbHVlcyBvZiBhdXRoX3RpbWUsIGFjciBhbmQgYW1yIGluIEFU JyB3aWxsIGJlIHRoZSBzYW1lIGFzIHRoZSBjb3JyZXNwb25kaW5nIGNsYWltcyBpbiBJRF9UJy4g V2hlbiB0aGUgY2xpZW50IHVzZXMgUlQnIHRvIG9idGFpbiBBVGBOLCBBVCdOJiM0MzsxIGV0YyBl dGMsIHRoZSB2YWx1ZXMgb2YgdGhvc2UgY2xhaW1zIHdpbGwgcmVtYWluIHRoZSBzYW1lIGZvciBl dmVyeSBBVCduIG9idGFpbmVkIGJ5IFJUJy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCk5vdywgaW1hZ2luZSB0 aGF0IHNvbWV0aGluZyBoYXBwZW5zIChpZ25vcmUgd2hhdCBmb3IgdGhlIHRpbWUgYmVpbmcpIHRo YXQgY2F1c2VzIHRoZSBjbGllbnQgdG8gcGVyZm9ybSBhIHN0ZXAgdXAgYXV0aCwgd2hpY2ggcmVx dWlyZXMgdGhlIHVzZXIgdG8gcGVyZm9ybSBpbnRlcmFjdGl2ZSBhdXRoIGhlbmNlIHJlc3VsdHMg aW4gYSBuZXcgYXV0aHogZ3JhbnQuIFRoZSBjbGllbnQgd2lsbCBvYnRhaW4gYSBuZXcgdHVwbGUm bmJzcDsgQVQmcXVvdDssIElEX1QmcXVvdDsgYW5kDQogUlQmcXVvdDsuIFRoZSBleGFjdCBzYW1l IHJ1bGVzIGRlc2NyaWJlZCBmb3IgdGhlICcgdHVwbGUgYXBwbHksIHdpdGggdGhlIG5ldyB2YWx1 ZXMgZGV0ZXJtaW5lZCBieSB0aGUgbmV3IGF1dGhlbnRpY2F0aW9uOiBBVCZxdW90OyBhdXRoX3Rp bWUvYWNyL2FtciB3aWxsIGJlIHRoZSBzYW1lIGFzIElEX1QmcXVvdDssIGFuZCB0aG9zZSB2YWx1 ZXMgd2lsbCByZW1haW4gdW5jaGFuZ2VkIGZvciBldmVyeSBBVCZxdW90O24gZGVyaXZlZCBieSBS VCZxdW90Oy48YnI+DQpJZiB3ZSB3YW50IHRoaXMgdG8gYXBwbHkgdG8gdGhlIGltcGxpY2l0IGZs b3cgYXMgd2VsbCwgeW91IGNhbiBzdWJzdGl0dXRlIHRoZSBSVCB3aXRoIHRoZSBzZXNzaW9uIGFy dGlmYWN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KRG9lcyB0aGF0IGhlbHAgY2xhcmlmeWluZyB0 aGUgaW50ZW50PyBJZiB5ZXMsIGRvIHlvdSBmZWVsIHRoYXQgdGhlIGN1cnJlbnQgbGFuZ3VhZ2Ug ZG9lcyBub3QgZGVzY3JpYmUgdGhpcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCnVzZSBjYXNl IGZvciBwdXR0aW5nIHRoZXNlIGluIHRoZSBhY2Nlc3MgdG9rZW4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQpJIGFtIG5vdCB0cnlpbmcgdG8gY3JlYXRlIGEgY29tcGxldGUgZnJhbWV3b3Jr IGZvciBoYW5kbGluZyBzdGVwIHVwIGFuZCB0aGUgbGlrZSwgSSBhbSB0cnlpbmcgdG8gY3JlYXRl IGFuIGludGVyb3BlcmFibGUgcmVwcmVzZW50YXRpb24gb2YgdGhvc2UgdmFsdWVzIG5vIG1hdHRl ciBob3cgdGhleSB3ZXJlIG9idGFpbmVkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KQ29uc2lkZXIg dGhlIGNhc2UgaW4gd2hpY2ggYW4gQVBJIGFsbG93cyBjZXJ0YWluIG9wZXJhdGlvbnMgb25seSBp ZiBhIGdpdmVuIGFtciB2YWx1ZSBpcyBwcmVzZW50IGluIHRoZSB0b2tlbi4gV2hldGhlciB0aGF0 IGFtciBpcyByZXF1aXJlZCB1cGZyb250IG9uIGZpcnN0IGF1dGhlbnRpY2F0aW9uLCBhcyBzdGVw IHVwIG9yIGFueSBvdGhlciByZWFzb24gaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIHByb2ZpbGUg SU1POiB0aGUgQVMgbWlnaHQgaGF2ZQ0KIGFsbCBzb3J0cyBvZiBoZXVyaXN0aWNzIHRoYXQgZGV0 ZXJtaW5lIHRoYXQgKHVzZXIgbWVtYmVyc2hpcCB0byBhIGdpdmVuIGdyb3VwIG9yIHJvbGU7IGdl b2ZlbmNpbmc7IHJpc2sgc2NvcmluZzsgZXRjKSB0aGF0IGhhdmUgbm90aGluZyB0byBkbyB3aXRo IHNjb3BlcyByZXF1ZXN0ZWQsIGFuZCBhcmUgbm90IHN0YXRpY2FsbHkgZGV0ZXJtaW5lZCBieSBS Uy1BUyBjb21tdW5pY2F0aW9ucy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCk5vdywgSSBhZ3JlZSB0 aGF0IGZvcm1hbGl6aW5nIGhvdyBhIFJTIGNvbW11bmljYXRlcyB0byB0aGUgQVMgdmlhIHRoZSBj bGllbnQgdGhlIG5lZWQgdG8gc3RlcCB1cCBhbmQgaW4gd2hhdCB0ZXJtcyB3b3VsZCBiZSBzdXBl ciZuYnNwO3VzZWZ1bDsgaG93ZXZlciBJIHRoaW5rIHRoYXQncyB3ZWxsIGJleW9uZCB0aGUgc2Nv cGUgb2YgdGhpcyBwcm9maWxlLi4gVmFyaW91cyB2ZW5kb3JzIGFscmVhZHkgaGF2ZSB0aGVpciBv d24gbWVjaGFuaXNtcyBmb3IgaGFuZGxpbmcNCiBzdGVwIHVwIHNpZ25hbGluZyBmcm9tIFJTIHRv IEFTIChJIGFtIHZlcnkgZmFtaWxpYXIgd2l0aCB0aGUgTWljcm9zb2Z0Jm5ic3A7b25lKSBhbmQg YWxsIEkgYW0gbG9va2luZyBmb3IgaXMgYSB3YXkgb2Ygc3RhbmRhcmRpemluZyBob3cgdG8gcmVw cmVzZW50IHRoZSBvdXRjb21lcywgc28gdGhhdCBBUEkgZ2F0ZXdheXMgYW5kIFNESyBwcm92aWRl cnMgY2FuIHByb3ZpZGUgdG9vbHMgdGhhdCB3b3JrIGFjcm9zcyB2ZW5kb3JzOyBhbmQgcG9zc2li bHkgcmV1c2UNCiBzb21lIG9mIHRoZSByZWFzb25pbmcgdGhhdCB3YXMgYWxyZWFkeSBkb25lIGZv ciBpZF90b2tlbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpUTDtEUjogSSB0aGluayB3ZSBhcmUgZG9pbmcg c29tZXRoaW5nIHVzZWZ1bCBpbiBmb3JtYWxpemluZyBob3cgdG8gZW1iZWQgdGhhdCBpbmZvIGFu IEFUcyBldmVuIGlmIHdlIGRvbid0IGZvcmNlIHZlbmRvcnMgdG8gZ2l2ZSB1cCB0aGVpciBjdXJy ZW50IG1lY2hhbmlzbXMgdG8gcG9wdWxhdGUgdGhvc2UgdmFsdWVzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 Oi41aW4iPg0KUmVnYXJkaW5nIGFjY2VzcyB0b2tlbnMgdGhhdCBhcmUgdXNlZCB0byBhY2Nlc3Mg ZGlmZmVyZW50IHJlc291cmNlIHNlcnZlcnM8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpUaGUgaW50 ZW50IGlzIHRvIGV4cGxpY2l0bHkgZGlzYWxsb3cgdGhlIHVzZSBvZiBhbiBBVCB3aXRoIG11bHRp cGxlIHJlc291cmNlIHNlcnZlcnMuIElmIGEgY2xpZW50IHdhbnRzIHRvIHRhbGsgd2l0aCAyIGRp ZmZlcmVudCBSU2VzLCB0aGUgY2xpZW50IHNob3VsZCBhc2sgZm9yIDIgZGlmZmVyZW50IEFUcy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluIj4NClRoZSBzcGVjIGlzIHVuYW1iaWd1b3VzIG9uIHRoaXMgSU1PLCBoZXJl J3MgdGhlIGxhbmd1YWdlIEkgdXNlIGluIDAzLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt3 b3JkLWJyZWFrOmJyZWFrLWFsbDtib3gtc2l6aW5nOmJvcmRlci1ib3g7Ym9yZGVyLXJhZGl1czo0 cHg7b3ZlcmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+SWYgaXQgcmVjZWl2ZXMgYSByZXF1 ZXN0IGZvciBhbiBhY2Nlc3MgdG9rZW4gY29udGFpbmluZyBtb3JlIHRoYW4gb25lPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3dvcmQtYnJlYWs6 YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVzb3VyY2UgcGFyYW1l dGVyLCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1aW5nIEpXVCBhY2Nlc3MgdG9rZW5zPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3dvcmQt YnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgTVVTVCByZWpl Y3QgdGhlIHJlcXVlc3QgYW5kIGZhaWwgd2l0aCAmcXVvdDtpbnZhbGlkX3JlcXVlc3QmcXVvdDsg YXMgZGVzY3JpYmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluO3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgaW4gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9y ZmM2NzQ5I3NlY3Rpb24tNC4xLjIuMSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjojM0QyMkIzIj5zZWN0aW9uJm5ic3A7NC4xLjIuMSBvZiBbUkZDNjc0OV08L3NwYW4+PC9hPiBv ciB3aXRoICZxdW90O2ludmFsaWRfdGFyZ2V0JnF1b3Q7IGFzIGRlZmluZWQ8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47d29yZC1icmVhazpicmVh ay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BU IE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpbiBzZWN0aW9uIDIgb2YgWzxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1v YXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzI3JlZi1SZXNvdXJjZUluZGljYXRvcnMiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzNEMjJCMyI+UmVzb3VyY2VJbmRpY2F0b3JzPC9z cGFuPjwvYT5dLiZuYnNwOyBTZWUgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMjc2VjdGlvbi0y LjIiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzNEMjJCMyI+U2VjdGlvbiAy LjI8L3NwYW4+PC9hPiBhbmQgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMjc2VjdGlvbi01IiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzRDIyQjMiPlNlY3Rpb24gNTwvc3Bh bj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluO3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg Zm9yIG1vcmUgZGV0YWlscyBvbiBob3cgdGhpcyBtZWFzdXJlIGVuc3VyZXMgdGhlcmUncyBubyBj b25mdXNpb24gb248L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW47d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyB0byB3aGF0IHJlc291cmNlIHRoZSBhY2Nlc3MgdG9rZW4gZ3JhbnRlZCBzY29wZXMgYXBw bHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDsgSXMgaXQgcG9zc2libGUgeW91IGFy ZSByZWZlcnJpbmcgdG8gYW4gb2xkZXIgZHJhZnQ/Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+ DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpP biBNb24sIERlYyAxNiwgMjAxOSBhdCA1OjI4IFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxl ICZsdDtyaWNoYW5uYT08YSBocmVmPSJtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQoxLiBSZWdhcmRpbmcgQXV0aGVudGljYXRlZENsaWVudDo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkRv ZXMgYSBtb2JpbGUgYXBwIHRoYXQgdXNlcyBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gdG8g ZXN0YWJsaXNoIGEgY2xpZW50IHNlY3JldCBjb3VudCBhcyBhbiDigJxhdXRoZW50aWNhdGVkIGNs aWVudOKAnT8gV2hhdCBpZiB0aGF0IHJlZ2lzdHJhdGlvbiBpbmNsdWRlZCBhbiBhc3NlcnRpb24g c2lnbmVkIGJ5IGEgdHJ1c3RlZCBlbnRpdHkgKGUuZy4sIGRldmljZSBtYW5hZ2VtZW50IHNvZnR3 YXJlKSB1c2luZyBhIGNlcnRpZmljYXRlIHRoYXQgaGFkDQogYmVlbiBwdXNoZWQgdG8gdGhlIGRl dmljZT8gV2l0aG91dCBzb21lIGtpbmQgb2YgTklTVCBMb0Etc3R5bGUgZGVmaW5pdGlvbiBvZiDi gJxhdXRoZW50aWNhdGVk4oCdLCBhIHNpbmdsZSBCb29sZWFuIOKAnEF1dGhlbnRpY2F0ZWRDbGll bnTigJ0gdmFsdWUgaXMgdG9vIGFtYmlndW91cyB0byBiZSB1c2VmdWwuIEhvd2V2ZXIsIEnigJlt IHNrZXB0aWNhbCB0aGF0IHdlIGNvdWxkIGZpbmQgY29uc2Vuc3VzIG9uIHdoYXQgdGhhdCBkZWZp bml0aW9uIHNob3VsZCBiZSwNCiBhbmQgaXQgbWF5IGJlIGJldHRlciB0byBkZWZpbmUgY2xpZW50 IGFuYWxvZ3MgdG8gYGFjcmAgYW5kIGBhbXJgIHRoYXQgcHJvdmlkZSBzdGFuZGFyZCB3YXlzIG9m IGV4cHJlc3NpbmcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGRldGFpbHMgd2l0aG91dCBnZXR0aW5n IHByZXNjcmlwdGl2ZSBhYm91dCB3aGF0IGtpbmQgb2YgYXV0aGVudGljYXRpb24gaXMg4oCcZ29v ZCBlbm91Z2gu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluIj4NCjIuIFJlZ2FyZGluZyBhdXRoZW50aWNhdGlvbiBzZXNzaW9u IHByb3BlcnRpZXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6LjVpbiI+DQpJ4oCZbSBjb25mdXNlZCBieSB0aGUgZGVmaW5pdGlvbnMgZ2l2ZW4gZm9y IGBhdXRoX3RpbWVgLCBgYWNyYCwgYW5kIGBhbXJgLiBGb3IgYGF1dGhfdGltZWAsIGl0IHNheXM6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+ DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDoxLjBpbiI+DQrigJzigKZpdHMgdmFsdWUgd2lsbCBlaXRoZXIgcmVtYWluIHRoZSBzYW1lIGZv ciBhbGwgdGhlIEpXVCBhY2Nlc3MgdG9rZW5zIGlzc3VlZCB3aXRoaW4gdGhhdCBzZXNzaW9uIG9y IGJlIHVwZGF0ZWQgdG8gdGhlIHRpbWUgb2YgbGF0ZXN0IGF1dGhlbnRpY2F0aW9uIGlmIHJlYXV0 aGVudGljYXRpb24gb2NjdXJyZWQgbWlkLXNlc3Npb27igKbigJ08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KQnV0IHRoZSDi gJxGb3IgZXhhbXBsZeKAnSBhdCB0aGUgZW5kIG9mIHRoYXQgZGVmaW5pdGlvbiBpbXBsaWVzIHRo YXQgYGF1dGhfdGltZWAgd2lsbCBub3QgYmUgdXBkYXRlZC4gVGhlIGRlZmluaXRpb25zIGZvciBg YWNyYCBhbmQgYGFtcmAgc2F5IHRoZSBzYW1lLCBidXQgYWxzbyBzYXkgdGhhdCB0aGUg4oCc4oCm c2FtZSBjb25zaWRlcmF0aW9ucyBwcmVzZW50ZWQgZm9yIGF1dGhfdGltZSBhcHBseeKApuKAnSBX aGF04oCZcyB0aGUgaW50ZW50aW9uIGhlcmU6IGFyZSB0aGV5DQogZml4ZWQsIHVwZGF0ZWQsIG9y IGlzIGl0IHVwIHRvIHRoZSBkZXBsb3ltZW50IHRvIGRlY2lkZT88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KSeKAmWQgbGlr ZSB0byBiZXR0ZXIgdW5kZXJzdGFuZCB0aGUgdXNlIGNhc2UgZm9yIHB1dHRpbmcgdGhlc2UgaW4g dGhlIGFjY2VzcyB0b2tlbi4gSWYgdGhlIFJTIGlzIG1ha2luZyBhdXRob3JpemF0aW9uIGRlY2lz aW9ucyBiYXNlZCBvbiB0aGVzZSBjbGFpbXMsIHRoYXQgaW1wbGllcyB0aGF0IHRoZSBSUyBjYW5u b3QgcmVseSBvbiB0aGUgQVMgdG8gZGV0ZXJtaW5lIChlLmcuLCBmcm9tIHRoZSByZXF1ZXN0ZWQg c2NvcGUpIHRoZSByZXF1aXJlZCBhdXRoZW50aWNhdGlvbg0KIG1ldGhvZChzKSwgZnJlc2huZXNz LCBldGMuIElmIHRoZSBBUyBjb3VsZCBiZSByZWxpZWQgdXBvbiBmb3IgdGhpcywgdGhlbiBwcmVz dW1hYmx5IGl0IHdvdWxkIG5vdCBpc3N1ZSBSVHMgYW5kIEFUcyBmb3IgYSBzY29wZSB3aXRob3V0 IHJlcXVpcmluZyB0aGUgZW5kIHVzZXIgdG8gbWVldCB0aGUgYXBwcm9wcmlhdGUgYXV0aGVudGlj YXRpb24gcmVxdWlyZW1lbnRzLiBJZiB0aGlzIGlzIHRoZSBjYXNlLCB0aGVuIHRoZSBSUyBtdXN0 IGhhdmUgYQ0KIHdheSB0byBzaWduYWwgdG8gdGhlIGNsaWVudCAoYW5kIHRoZW4gdGhlIEFTKSB0 aGF0IGEgc3RlcC11cCBhdXRoZW50aWNhdGlvbiBpcyByZXF1aXJlZC4gSXMgdGhlcmUgYW4gZXhp c3RpbmcgbWVjaGFuaXNtIHRocm91Z2ggd2hpY2ggdGhleSBjb3VsZCBkbyB0aGlzPyBBbGwgSSBj YW4gY29tZSB1cCB3aXRoIGlzIGNyYW1taW5nIHRoZSBpbmZvcm1hdGlvbiBpbnRvIHRoZSBzY29w ZSBhdHRyaWJ1dGUgb2YgYSBXV1ctQXV0aGVudGljYXRlIGNoYWxsZW5nZSwNCiBidXQgdGhhdCBo YXMgdGhlIHNhbWUgc2NvcGUgb3BhY2l0eSB2aW9sYXRpb24gcHJvYmxlbSBhcyBkZXNjcmliZWQg aW4gdGhpcyBkcmFmdOKAmXMgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuIFdpdGhvdXQgYSBjbGVh ciB3YXkgdG8gZXhwcmVzcyB0aGUgc3RlcC11cCByZXF1aXJlbWVudHMsIHRoaXMgZmVlbHMgaW5j b21wbGV0ZS4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluIj4NCjMuIFJlZ2FyZGluZyBhY2Nlc3MgdG9rZW5zIHRoYXQgYXJlIHVz ZWQgdG8gYWNjZXNzIGRpZmZlcmVudCByZXNvdXJjZSBzZXJ2ZXJzOjxicj4NClJlYWRpbmcgYmV0 d2VlbiB0aGUgbGluZXMsIEkgKjxiPnRoaW5rPC9iPiogdGhlIGludGVudGlvbiBpcyB0aGF0IGEg SldUIGFjY2VzcyB0b2tlbiB0aGF0IGlzIGludGVuZGVkIHRvIGJlIHVzZWQgdG8gYWNjZXNzIHR3 byBkaWZmZXJlbnQgcmVzb3VyY2VzIGF0IHR3byBkaWZmZXJlbnQgUlNlcyBzaG91bGQgbG9vayBz b21ldGhpbmcgbGlrZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIi Pns8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbjt0ZXh0LWluZGVudDo1LjI1cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNv dXJpZXIiPiZxdW90O2F1ZCZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9nZW5lcmljLXJl c291cmNlLWluZGljYXRvci5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dl bmVyaWMtcmVzb3VyY2UtaW5kaWNhdG9yLmV4YW1wbGUuY29tLzwvYT4mcXVvdDssPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW47dGV4 dC1pbmRlbnQ6NS4yNXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mcXVv dDtzY29wZSZxdW90OzogJnF1b3Q7cmVzb3VyY2VfZm9vIHJlc291cmNlX2JhciZxdW90Oyw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVp bjt0ZXh0LWluZGVudDo1LjI1cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIi Pi4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj59PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K PGJyPg0KQW5kIHRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IGVhY2ggUlMgc2hvdWxkIHJlY29nbml6 ZSB0aGF0IGdlbmVyaWMgYXVkaWVuY2UuIElzIHRoaXMgY29ycmVjdD8gSWYgc28gaXQgc2VlbXMg dG8gZ28gYWdhaW5zdCB0aGUgc3Bpcml0IG9mIHJlc291cmNlIGluZGljYXRvcnMgYXMgaW5kaWNh dGluZyB0aGUgdGFyZ2V0IG9yIGxvY2F0aW9uIG9mIGEgcmVzb3VyY2UuIEl04oCZcyBzdHJldGNo aW5nIHRoYXQgZGVmaW5pdGlvbiwgYXQgdGhlIHZlcnkgbGVhc3QuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkJ1dCBhcyBJ IHNhaWQsIEnigJltIHJlYWRpbmcgYmV0d2VlbiB0aGUgbGluZXMgaGVyZS4gSWYgdGhpcyBpcyB0 aGUgaW50ZW50aW9uLCBpdCBzaG91bGQgYmUgY2xlYXJseSBzdGF0ZWQuIEFsdGVybmF0aXZlbHks IHJlbW92ZSAob3IgY2hhbmdlIHRvIGEgU0hPVUxEKSB0aGUgcmVxdWlyZW1lbnQgdGhhdCBtdWx0 aS12YWx1ZSBgYXVkYCBjbGFpbXMgbXVzdCBvbmx5IGNvbnRhaW4gYWxpYXNlcyBmb3IgdGhlIHNh bWUgcmVzb3VyY2UgaW5kaWNhdG9yLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPuKAkyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5PQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDsgb24gYmVoYWxmIG9mIFZpdHRvcmlvIEJlcnRvY2NpICZsdDtWaXR0b3Jpbz08YSBocmVmPSJt YWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGF1dGgw LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgRGVj ZW1iZXIgMTYsIDIwMTkgYXQgMjo1MSBQTTxicj4NCjxiPlRvOiA8L2I+SUVURiBvYXV0aCBXRyAm bHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmkt ZC1hbm5vdW5jZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmktZC1hbm5vdW5jZUBpZXRmLm9y ZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6IDwvYj5SZTogW09BVVRILVdHXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9hdXRoLWFjY2Vz cy10b2tlbi1qd3QtMDMudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+ DQpEZWFyIGFsbCw8YnI+DQpJIGZpbmFsbHkgZm91bmQgdGhlIHRpbWUgdG8gcHVzaCBhIG5ldyBk cmFmdCBvZiB0aGUgSldUIHByb2ZpbGUgZm9yIEFUcy4gVGhpcyB2ZXJzaW9uIGluY29ycG9yYXRl cyB0aGUgZmVlZGJhY2sga2luZGx5IHByb3ZpZGVkIGJ5IEJyaWFuIGFuZCBBYXJvbiBhdCBJRVRG MTA1Ljxicj4NClVuZm9ydHVuYXRlbHkgSSBkaWRuJ3QgaGF2ZSBhIGNoYW5jZSB0byBwYXJ0aWNp cGF0ZSB0byBJRVRGMTA2LCBoZW5jZSB3ZSBkaWRuJ3QgZG8gbXVjaCBwcm9ncmVzcyBzaW5jZSB0 aGVuLjxicj4NClRoZXJlIGFyZSBzdGlsbCB0d28gYXJlYXMgd2UgZGlkbid0IG1hbmFnZSB0byBy ZWFjaCBjb25zZW5zdXMgb246PGJyPg0KPGJyPg0KMS4gTWVjaGFuaXNtcyBmb3Igc2lnbmFsaW5n IHdoZXRoZXIgdGhlIEFUIHdhcyBvYnRhaW5lZCBieSBhIHVzZXIgb3IgYW4gYXBwbGljYXRpb248 YnI+DQo8YnI+DQpUaGlzIHBvaW50IHdhcyB0aGUgc3ViamVjdCBvZiBpbnRlbnNlIGRlYmF0ZSBv biB0aGUgbGlzdCBsZWFkaW5nIHRvIElFVEYxMDUuLjxicj4NCk9uZSBpbnNpZ2h0IHRoYXQgZW1l cmdlZCBmcm9tIHRoZSBJRVRGMTA1IGRpc2N1c3Npb24gd2FzIHRoYXQgdGhlIHVzZSBjYXNlIGhl cmUgaXMgbW9yZSBhYm91dCB3aGV0aGVyIHRoZSBBVCBoYXMgYmVlbiBvYnRhaW5lZCB2aWEgYSBn cmFudCB0aGF0IGF1dGhlbnRpY2F0ZWQgdGhlIGNsaWVudCAocmVnYXJkbGVzcyBvZiB3aGF0IHNw ZWNpZmljIGdyYW50IHdhcyB1c2VkKSB2cyBhIHB1YmxpYyBjbGllbnQgZ3JhbnQtIHRoYXQgaW5m b3JtYXRpb24NCiBjYW4gYmUgcmVsZXZhbnQgdG8gYSByZXNvdXJjZSBhcyBpdCBkZXRlcm1pbmVz IHdoZXRoZXIgdGhlIGlkZW50aXR5IG9mIHRoZSBjbGllbnQgY2FuIGJlIHVzZWQgaW4gYXV0aG9y aXphdGlvbiBkZWNpc2lvbnMgKGluIHRoZSBmb3JtZXIgY2FzZSkgb3Igbm90IChpbiB0aGUgcHVi bGljIGNsaWVudCBjYXNlKS4gSWYgdGhhdCdzIHRoZSBzY2VuYXJpbyB3ZSBhcmUgdHJ1bHkgYWZ0 ZXIsIGEgc2ltcGxlLCBwb3NzaWJseSBvcHRpb25hbCBib29sZWFuDQogY2xhaW0gKHNheSBBdXRo ZW50aWNhdGVkQ2xpZW50KSB3b3VsZCBzdWZmaWNlLjxicj4NCk5vdGUgZm9yIHRoZSBwZW9wbGUg d2hvIGRpZG4ndCByZWFkIHRoZSBzcGVjOiBJIHJlbW92ZWQgYW55IHJlZmVyZW5jZSB0byB0aGlz IGFscmVhZHkgaW4gZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAxLiBJIHRoaW5r IHRoaXMgaXMgYW4gaW1wb3J0YW50IGFuZCB1c2VmdWwgaW5mbyBhbmQgc3RhbmRhcmRpemluZyBp dCB3b3VsZCBiZSBiZW5lZmljaWFsIGZvciBtaWRkbGV3YXJlIGFuZCBTREsgY3JlYXRvcnMsIGJ1 dCB1bHRpbWF0ZWx5DQogdGhpcyBpcyBhbiBpbnRlcm9wIHByb2ZpbGUgaGVuY2UgaWYgdGhlcmUn cyBubyBzdHJvbmcgZGVzaXJlIHRvIHJlYWNoIGFuIGFncmVlbWVudCBoZXJlLCBJIGFtIGFsc28g T0sgd2l0aCBkcm9wcGluZyB0aGUgbWF0dGVyIGFuZCBub3QgYWRkcmVzcyB0aGlzIGZ1bmN0aW9u IGluIHRoZSBzcGVjLjxicj4NClRvIHN1bW1hcml6ZSwgSSBoYXZlIHR3byBxdWVzdGlvbnMgaGVy ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KQS4gRG8gd2UgYmVsaWV2 ZSBpdCdzIHdvcnRoIGl0IHRvIGZvcm1hbGl6ZSBpbiB0aGUgcHJvZmlsZSBhIG1lY2hhbmlzbSB0 byBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBjbGllbnQgdGggb2J0YWluZWQgdGhlIEFUIGF1dGhlbnRp Y2F0ZWQgaXRzZWxmIHdpdGggdGhlIEFTPzxicj4NCkIuIElmIHllcywgYXJlIHlvdSBPSyB3aWh0 IGFuIG9wdGlvbmFsIGJvb2wgY2xhaW0gaGVyZT88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxicj4NCjIuIENsYWltcyBp bmRpY2F0aW5nIHNlc3Npb24gcHJvcGVydGllczxicj4NCjxicj4NClRoaXMgaXMgb25lIGFyZWEg d2hlcmUgSSBhbSBmYXIgbW9yZSBwYXNzaW9uYXRlIGFib3V0LCBhcyBpdCByZXByZXNlbnRzIGEg ZnVuZGFtZW50YWwgYXNwZWN0IHRoYXQgcHJvZHVjdGlvbiBzeXN0ZW1zIChhbmQgaW4gcGFydGlj dWxhciAxc3QgcGFydHkgc29sdXRpb25zKSBhbHJlYWR5IHJlbHkgb24gaW4gdGhlIGN1cnJlbnQg cHJvcHJpZXRhcnkgSlRXIEFUcy48YnI+DQpUaGUgcHJvZmlsZSBjdXJyZW50bHkgaW5jbHVkZXMg dGhlIGNsYWltcyBhdXRoX3RpbWUsIGFjciBhbmQgYW1yIC0gY2FwdHVyaW5nIHRoZSB2YWx1ZXMg b2YgdGhvc2UgcHJvcGVydGllcyBhdCB0aGUgdGltZSBvZiB0aGUgbGF0ZXN0IGF1dGhlbnRpY2F0 aW9uIHRoZSB1c2VyIHBlcmZvcm1lZCBpbiB0aGUgc2Vzc2lvbiB1c2VkIHRvIGlzc3VlIHRoZSBj dXJyZW50IEFUOiBhdCBzZXNzaW9uIGNyZWF0aW9uLCBhdCBhdXRoIHN0ZXAgdXAgdGltZSBhbmQN CiBzbyBvbi48YnI+DQpUaG9zZSBhcmUgdmFsdWVzIHRoYXQgQVBJIG5lZWQgaW4gb3JkZXIgdG8g bWFrZSBhdXRob3JpemF0aW9uIGRlY2lzaW9uczsgaW4gdGhlIGNhc2Ugb2YgMXN0IHBhcnR5IEFQ SXMsIHRoZSBBVCBpcyB0aGUgb25seSBhcnRpZmFjdCB0aGV5IGV2ZXIgcmVjZWl2ZSBoZW5jZSB0 aGVyZSBpcyBubyBvdGhlciB3YXkgZm9yIGFuIEFQSSB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUg Y2FsbGVyIHBlcmZvcm1lZCBzYXkgTUZBIGluIG9yZGVyIHRvIG9idGFpbg0KIHRoZSBjdXJyZW50 IEFULjxicj4NClNpbmNlIHRoZSBmaXJzdCBkcmFmdCwgc29tZSBwZW9wbGUgc2lnbmFsZWQgY29u Y2VybnMgYWJvdXQgdGhlIGN1cnJlbnQgbWVjaGFuaXNtcyB0aHJ1IHdoaWNoIHRob3NlIGNsYWlt cyBnZXQgdGhlaXIgdmFsdWUuIEZvciBleGFtcGxlLCBpdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBt YWludGFpbiB0aGUgb3JpZ2luYWwgdmFsdWVzIG9mIGF1dGhfdGltZSwgYWNyICZhbXA7IGFtciBh bmQgaW50cm9kdWNlIGFkZGl0aW9uYWwgY2xhaW1zIHRvIGluZGljYXRlDQogY2hhbmdlcyAobGlr ZSBzdGVwdXApLjxicj4NCkkgYW0gbm90IGNsZWFyIG9uIHdoYXQgY29sZCBnbyB3cm9uZyB3aXRo IHRoZSBjdXJyZW50IGFwcHJvYWNoLCBoZW5jZSBJIGRvbid0IGhhdmUgYW4gaW1tZWRpYXRlIGdy YXNwIG9mIGhvdyBjaGFuZ2VzIGxpa2UgdGhlIGFib3ZlIHdvdWxkIGhlbHAuPGJyPg0KSWYgdGhl IHBlb3BsZSB1bmNvbWZvcnRhYmxlIHdpdGggdGhlIGN1cnJlbnQgcHJvcG9zYWwgY291bGQgZGV0 YWlsIHRoZWlyIGNvbmNlcm4sIHdlIGNhbiBicmFpbnN0b3JtIHdheXMgdG8gbWFrZSB0aGF0IGlu Zm8gYXZhaWxhYmxlIHRvIEFQSSBpbiBhIHNhZmVyIHdheS4gVG8gc3VtbWFyaXplOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpBLiBEbyB5b3UgaGF2ZSBjb25jZXJucyB3 aXRoIHRoZSBjdXJyZW50IGF1dGhfdGltZSwgYXJtLCBhY3IgcHJvcG9zYWw/IENhbiB5b3Ugc3Bl bGwgdGhlbSBvdXQ/IChwbGVhc2UgcmVhZCB0aGUgcmVsZXZhbnQgcGFydHMgb2YgdGhlIHNwZWMg YmVmb3JlIGNoaW1pbmcgaW4gOikpPGJyPg0KQi4gSWYgeWVzLCB3aGF0IGNhbiB3ZSBkbyB0byBt YWtlIHRoYXQgaW5mbyBhdmFpbGFibGUgdG8gUlNzIGluIGEgd2F5IHRoYXQgbWFrZXMgeW91IGNv bWZvcnRhYmxlPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPGJyPg0KPGJyPg0KVGhhbmtzPGJyPg0KPGJyPg0K Vi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCk9uIE1vbiwgRGVjIDE2LCAyMDE5IGF0 IDI6NDkgUE0gJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbiI+DQo8YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBh IHdvcmsgaXRlbSBvZiB0aGUgV2ViIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgV0cgb2YgdGhlIElF VEYuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IEpTT04gV2ViIFRva2VuIChKV1QpIFBy b2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IEF1dGhvciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBWaXR0 b3JpbyBCZXJ0b2NjaTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2Vu LWp3dC0wMy50eHQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGFnZXMmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMTY8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgRGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDogMjAxOS0xMi0xNjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtU aGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIHByb2ZpbGUgZm9yIGlzc3VpbmcgT0F1dGggMi4w IGFjY2Vzczxicj4NCiZuYnNwOyAmbmJzcDt0b2tlbnMgaW4gSlNPTiB3ZWIgdG9rZW4gKEpXVCkg Zm9ybWF0LiZuYnNwOyBBdXRob3JpemF0aW9uIHNlcnZlcnMgYW5kPGJyPg0KJm5ic3A7ICZuYnNw O3Jlc291cmNlIHNlcnZlcnMgZnJvbSBkaWZmZXJlbnQgdmVuZG9ycyBjYW4gbGV2ZXJhZ2UgdGhp cyBwcm9maWxlIHRvPGJyPg0KJm5ic3A7ICZuYnNwO2lzc3VlIGFuZCBjb25zdW1lIGFjY2VzcyB0 b2tlbnMgaW4gaW50ZXJvcGVyYWJsZSBtYW5uZXIuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3Mt dG9rZW4tand0LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC88L2E+PGJyPg0KPGJyPg0KVGhl cmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tl bi1qd3QtMDMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3Mt dG9rZW4tand0LTAzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDM8L2E+PGJyPg0K PGJyPg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAz PC9hPjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxi cj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3Vz IEZUUCBhdDo8YnI+DQo8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz LyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC4uaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwv YT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_16EBA41506A94190B8C3EE96771B70BDamazoncom_-- From nobody Tue Dec 17 13:38:02 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3621200D6; Tue, 17 Dec 2019 13:37:59 -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=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 GsDA7xIjsJVn; Tue, 17 Dec 2019 13:37:54 -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 9900D12004D; Tue, 17 Dec 2019 13:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1576618674; x=1608154674; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zI0H+gInTYoW032Xbds1xWMmIFbtv8KDQfRxEP4Cj+Q=; b=e4px3rN+qIYL4tqzhbfhzEb2MpQHcpnntN1EmoUa8p3zPoVJ75kSecym RTD+npknjfFZmsHm4KxEH3OMqXkGw1EaQoG8wZlYQk64M6w+fwEq6CswJ SHqY6Nzx1WTfZwJnYUJwYeV/5J4lUdwKElxjY14p0/9d0qeomBElXubH5 E=; IronPort-SDR: kwdWihllTr2rhrGBbpQ8KHLbwrMqK4kFZp+eeoHc+0Puxc5lHZiTgAoCjRLwjQWQwOMOJ9//ud yAJL/k66UxyQ== X-IronPort-AV: E=Sophos;i="5.69,326,1571702400"; d="scan'208,217";a="9522495" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1d-2c665b5d.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 17 Dec 2019 21:37:51 +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-2c665b5d.us-east-1.amazon.com (Postfix) with ESMTPS id F3D2BA243B; Tue, 17 Dec 2019 21:37:49 +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, 17 Dec 2019 21:37:49 +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, 17 Dec 2019 21:37: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; Tue, 17 Dec 2019 21:37:48 +0000 From: "Richard Backman, Annabelle" To: Vittorio Bertocci CC: IETF oauth WG , Vittorio Bertocci , "i-d-announce@ietf.org" Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt Thread-Index: AQHVtGMkx0ZM11MJ9UuFnmHDKBqGmae9XaMA///YXwCAAIOagIAABHuAgAConoCAACEmAA== Date: Tue, 17 Dec 2019 21:37:48 +0000 Message-ID: <119EE9E6-31CC-4C25-8FD0-D9E8FE389A2E@amazon.com> References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> <2518B18A-AD93-44E4-88D1-E5F6AAE7B1BB@amazon.com> In-Reply-To: <2518B18A-AD93-44E4-88D1-E5F6AAE7B1BB@amazon.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.160.100] Content-Type: multipart/alternative; boundary="_000_119EE9E631CC4C258FD0D9E8FE389A2Eamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 21:38:00 -0000 --_000_119EE9E631CC4C258FD0D9E8FE389A2Eamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIG1vcmUgbGluZSBqdW1wZWQgb3V0IGF0IG1lLCBpbiDCpzQ6DQoNCj4gQW4gYXV0aG9yaXph dGlvbiBzZXJ2ZXIgTUFZIGVsZWN0IHRvIHVzZSBkaWZmZXJlbnQga2V5cyB0byBzaWduIGlkX3Rv a2VucyBhbmQgSldUIGFjY2VzcyB0b2tlbnMuDQoNCldoaWxlIHRoZSBqd2tzX3VyaSBtZXRhZGF0 YSBwYXJhbWV0ZXIgY2FuIHBvaW50IHRvIGEgc2V0IGNvbnRhaW5pbmcgbXVsdGlwbGUga2V5cywg dGhlcmUgaXMgbm8gd2F5IGZvciBhbiBBUCAob3IgT0lEQyBPUCkgdG8gaW5kaWNhdGUgd2hpY2gg a2V5cyBhcmUgdXNlZCBmb3Igd2hpY2ggcHVycG9zZS4gU28gd2hpbGUgYW4gQVMgbWlnaHQgY2hv b3NlIHRvIHVzZSBrZXlfYSB0byBzaWduIElEIFRva2VucyBhbmQga2V5X2IgdG8gc2lnbiBKV1Qg YWNjZXNzIHRva2VucywgdGhlcmUgaXMgbm8gd2F5IGZvciB0aGUgQVMgdG8gaW5kaWNhdGUgdGhp cyB0byBjbGllbnRzIGFuZCBSU2VzLiBUaGlzIG1lYW5zIHRoYXQgYW4gQVMgY2Fubm90IHJlbHkg dXBvbiB0aGUgdXNhZ2Ugb2YgZGlmZmVyZW50IGtleXMgdG8gZGlmZmVyZW50aWF0ZSBJRCBUb2tl bnMgZnJvbSBKV1QgYWNjZXNzIHRva2VucyBvciBhbnkgb3RoZXIgSldUIHRoYXQgdGhlIEFTIG1p Z2h0IGlzc3VlLCB1bmxlc3MgdGhleSBoYXZlIHNvbWUgb3V0LW9mLWJhbmQgbWVjaGFuaXNtIGZv ciBpbmRpY2F0aW5nIGtleSBwdXJwb3NlLiBJIHRoaW5rIGl04oCZcyB3b3J0aCBjYWxsaW5nIHRo aXMgb3V0IGluIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLCBhcyB0aGlzIG1heSBub3QgYmUgb2J2 aW91cyB0byByZWFkZXJzLg0KDQpJdOKAmXMgYWxzbyB3b3J0aCBub3RpbmcgdGhhdCDigJxzaWdu IHRoZW0gd2l0aCBkaWZmZXJlbnQga2V5c+KAnSBoYXMgYmVlbiBzdWdnZXN0ZWQgYXMgYSB0ZWNo bmlxdWUgZm9yIHByZXZlbnRpbmcgSldUcyBpc3N1ZWQgZm9yIG9uZSBwdXJwb3NlIChlLmcuLCBh IFNFVCkgZnJvbSBiZWluZyBtaXN0YWtlbiBmb3IgYSBKV1QgaXNzdWVkIGZvciBhbm90aGVyIHB1 cnBvc2UgKGUuZy4sIGFuIElEIFRva2VuKS4gVGhpcyBkcmFmdCBxdWl0ZSByZWFzb25hYmx5IGFu ZCBuYXR1cmFsbHkgcmV1c2VzIGV4aXN0aW5nIEFTIG1ldGFkYXRhLCBhbmQgaW4gc28gZG9pbmcg YnJlYWtzIHRoaXMgdGVjaG5pcXVlLiBJdCBzZXJ2ZXMgYXMgYSBnb29kIGV4YW1wbGUgb2Ygd2h5 IGV4cGxpY2l0IEpXVCB0eXBpbmcgaXMgaW1wb3J0YW50Lg0KDQrigJMNCkFubmFiZWxsZSBSaWNo YXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206ICJSaWNoYXJkIEJhY2ttYW4sIEFu bmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb20+DQpEYXRlOiBUdWVzZGF5LCBEZWNlbWJlciAx NywgMjAxOSBhdCAxMTozOSBBTQ0KVG86IFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jpbz00MGF1 dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBJRVRGIG9hdXRoIFdHIDxvYXV0aEBpZXRmLm9y Zz4sIFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jpb0BhdXRoMC5jb20+LCAiaS1kLWFubm91bmNl QGlldGYub3JnIiA8aS1kLWFubm91bmNlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVTlZFUklG SUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vYXV0aC1h Y2Nlc3MtdG9rZW4tand0LTAzLnR4dA0KDQo+IEluIGFueSBjYXNlIHRoZSBpbnRlbnQgd2FzIGFs d2F5cyB0byBvbmx5IGFsbG93IGEgc2luZ2UgcmVzb3VyY2UgcGVyIEFU4oCmDQoNCk15IGNvbmZ1 c2lvbiBhY3R1YWxseSBjb21lcyBmcm9tIHRoZSBsYXN0IHBhcmFncmFwaCBvZiDCpzMsIHdoZXJl IGl0IHNheXMg4oCcSWYgYSBzY29wZSBwYXJhbWV0ZXIgaXMgcHJlc2VudCBpbiB0aGUgcmVxdWVz dCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCB1c2UgaXQgdG8gaW5mZXIgdGhlIHZh bHVlIG9mIHRoZSBkZWZhdWx0IHJlc291cmNlIGluZGljYXRvciB0byBiZSB1c2VkIGluIHRoZSBh dWQgY2xhaW0u4oCdIEkgaW50ZXJwcmV0ZWQgdGhhdCB0byBsZWF2ZSByb29tIGZvciBhbiBBUyBp bmZlcnJpbmcgdGhlIHNhbWUg4oCcZ2VuZXJpY+KAnSByZXNvdXJjZSBpbmRpY2F0b3IgZm9yIHJl c291cmNlcyBzZXJ2ZWQgYnkgZGlmZmVyZW50IFJTZXMuIFRoZSBvbmUtUlMtcGVyLUFUIG1vZGVs IGlzIGFuIGlkZWFsIHRoYXQgc2ltcGx5IGRvZXNu4oCZdCBtYXRjaCByZWFsaXR5LiBDbGllbnRz IGRvbuKAmXQgd2FudCB0byBoYXZlIHRvIGp1Z2dsZSBhIGJ1bmNoIG9mIGRpZmZlcmVudCB0b2tl bnMsIG5vciBzaG91bGQgdGhleSBuZWVkIHRvLiBJ4oCZbSBjb21pbmcgdG8gdGhpbmsgdGhhdCB3 ZSBzaG91bGRu4oCZdCBhY3R1YWxseSB1c2UgYGF1ZGAgYW5kIGBzY29wZWAgaW4gSldUIEFUcyBh dCBhbGwsIGFuZCBpbnN0ZWFkIGFkb3B0IHRoZSBzdHJ1Y3R1cmUgUkFSIGRlZmluZXMgdXNlZCBm b3IgdGhlIGBhdXRob3JpemF0aW9uX2RldGFpbHNgIHBhcmFtZXRlciAoSSB0aGluayBzb21lIGl0 ZXJhdGlvbiBpcyByZXF1aXJlZCwgYnV0IGl0IHNlZW1zIG5hdHVyYWwgZm9yIHRoZXNlIHR3byB0 byBkZXNjcmliZSBhdXRob3JpemF0aW9ucyBpbiB0aGUgc2FtZSBvciBjb21wYXRpYmxlIHdheXMp Lg0KDQoNCj4g4oCmdGhlIHJlc291cmNlIHdhbnRzIHRvIGtub3cgd2hldGhlciB0aGlzIHBhcnRp Y3VsYXIgdG9rZW4gd2FzIG9idGFpbmVkIHByb3ZpbmcgdGhlIGlkZW50aXR5IG9mIHRoZSBjbGll bnTigKYNCg0KSeKAmW0gc2tlcHRpY2FsIG9mIHRoZSBpZGVhIHRoYXQgdGhlcmUgaXMganVzdCBv bmUgbGV2ZWwgb2YgY2xpZW50IGlkZW50aXR5IHByb29maW5nIHRoYXQgUlNlcyBtaWdodCBjYXJl IGFib3V0LiBUaGVyZSBtaWdodCBiZSBzb21lIGNsZWFyIGxpbmVzIHRoYXQgY2FuIGJlIGRyYXdu LCBidXQgd2Ugc2hvdWxkIGJlIGV4cGxpY2l0IGFib3V0IHdoYXQgdGhvc2UgbGluZXMgcmVwcmVz ZW50LCBlLmcuLCDigJxjbGllbnQgYXV0aGVudGljYXRlZCB1c2luZyBwcmUtZXN0YWJsaXNoZWQg Y3JlZGVudGlhbOKAnSwg4oCcY2xpZW50IGlzIHJ1bm5pbmcgb24gZW5kIHVzZXItY29udHJvbGxl ZCBkZXZpY2XigJ0sIGV0Yy4NCg0KDQo+IEkgYW0gbm90IHRyeWluZyB0byBjcmVhdGUgYSBjb21w bGV0ZSBmcmFtZXdvcmsgZm9yIGhhbmRsaW5nIHN0ZXAgdXAgYW5kIHRoZSBsaWtlLCBJIGFtIHRy eWluZyB0byBjcmVhdGUgYW4gaW50ZXJvcGVyYWJsZSByZXByZXNlbnRhdGlvbiBvZiB0aG9zZSB2 YWx1ZXMgbm8gbWF0dGVyIGhvdyB0aGV5IHdlcmUgb2J0YWluZWQuDQoNCldpdGhvdXQgdGFraW5n IHRoZSB3aG9sZSBwaWN0dXJlIGludG8gYWNjb3VudCwgdGhlcmUgaXMgc2lnbmlmaWNhbnQgcmlz ayB0aGF0IHdlIHdpbGwgZGVmaW5lIHNvbWV0aGluZyB0aGF0IHR1cm5zIG91dCB0byBiZSB3b2Vm dWxseSBpbnN1ZmZpY2llbnQgKG9yIHdvcnNlLCBlc3RhYmxpc2hlcyBhbiBhbnRpLXBhdHRlcm4p LiBUaGF0IHNhaWQsIEkgYWdyZWUgdGhhdCBpdOKAmXMgcHJvYmFibHkgbm90IGFwcHJvcHJpYXRl IGZvciB0aGlzIGRyYWZ0LCBhbmQgcmVjb21tZW5kIGRyb3BwaW5nIHRoZXNlIGNsYWltcy4gVGhl eSBjYW4gYWx3YXlzIGJlIGRlZmluZWQgaW4gYSBzZXBhcmF0ZSBkcmFmdCwgYWxvbmcgd2l0aCB0 aGUgb3RoZXIgZWxlbWVudHMgbmVjZXNzYXJ5IHRvIGNvbW11bmljYXRlIHN0ZXAtdXAgcmVxdWly ZW1lbnRzLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0K DQoNCkZyb206IFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jpbz00MGF1dGgwLmNvbUBkbWFyYy5p ZXRmLm9yZz4NCkRhdGU6IE1vbmRheSwgRGVjZW1iZXIgMTYsIDIwMTkgYXQgOTozMSBQTQ0KVG86 ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb20+DQpDYzog SUVURiBvYXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+LCBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9y aW9AYXV0aDAuY29tPiwgImktZC1hbm5vdW5jZUBpZXRmLm9yZyIgPGktZC1hbm5vdW5jZUBpZXRm Lm9yZz4NClN1YmplY3Q6IFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzLnR4dA0KDQpSZTogYWxp YXNlcywgSSBzZWUgd2hlcmUgdGhlIGNvbmZ1c2lvbiBpcyBjb21pbmcgZnJvbSENCkkgdXBkYXRl ZCB0aGUgcmVxdWVzdCBzZWN0aW9uLCBidXQgdGhlIHNlc3Npb24gMi4yIGRhdGEgc3RydWN0dXJl IHN0aWxsIG1lbnRpb25zIHRoZSBhbGlhc2VzLiBUaGF0IHNob3VsZCBiZSBjbGVhbmVkIHVwIGFz IHdlbGwuDQpJbiBhbnkgY2FzZSB0aGUgaW50ZW50IHdhcyBhbHdheXMgdG8gb25seSBhbGxvdyBh IHNpbmdlIHJlc291cmNlIHBlciBBVCwgdGhlIGFsaWFzIGxpc3Qgd2FzIG9ubHkgZm9yIGhlbHBp bmcgaW4gY2FzZXMgd2hlcmUgYW4gQVMgaWRlbnRpZmllcyB0aGUgc2FtZSByZXNvdXJjZSB0aHJ1 IG11bHRpcGxlIElEcyBhbmQgdGhlIGFjdHVhbCBhdWQgdmFsdWUgZGVwZW5kcyBvbiB3aGF0IElE IHRoZSBjbGllbnQgcmVxdWVzdGVkLiBIb3dldmVyIHdlIGRpc2N1c3NlZCB0aGlzIHdpdGggQnJp YW4gYW5kIGhlIGNvbnZpbmNlZCBtZSB0aGF0IGl0IHdhcyBqdXN0IHRvbyBhbWJpZ3VvdXMtIHlv dXIgcmVtYXJrIHJlaW5mb3JjZXMgdGhhdCBpbXByZXNzaW9uLiBJ4oCZbGwgY2xlYW4gdXAgMi4y IGFuZCBlbGltaW5hdGUgcmVmZXJlbmNlcyB0byBhbGlhc2VzIGZyb20gdGhlcmUgYXMgd2VsbC4N ClRoYW5rcyENCg0KDQpPbiBNb24sIERlYyAxNiwgMjAxOSBhdCAyMDoxOSBWaXR0b3JpbyBCZXJ0 b2NjaSA8Vml0dG9yaW9AYXV0aDAuY29tPG1haWx0bzpWaXR0b3Jpb0BhdXRoMC5jb20+PiB3cm90 ZToNClRoYW5rcyBBbm5hYmVsbGUuDQoNCkRvZXMgYSBtb2JpbGUgYXBwIHRoYXQgdXNlcyBEeW5h bWljIENsaWVudCBSZWdpc3RyYXRpb24gdG8gZXN0YWJsaXNoIGEgY2xpZW50IHNlY3JldCBjb3Vu dCBhcyBhbiDigJxhdXRoZW50aWNhdGVkIGNsaWVudOKAnT8NCkkgdGhpbmsgaXQgc2hvdWxkIGNv dW50LCB0aG8gSSBhbSBub3Qgc3VyZSB3aGF0IHRoZSBSUyB3b3VsZCBkbyB3aXRoIGl0LiBEeW5h bWljIGNsaWVudCByZWdpc3RyYXRpb24gd291bGQgbGlrZWx5IG5vdCBoYXZlIG11Y2ggdXNlIGZv ciB0aGlzLg0KSW4gdGhlIGNhc2VzIEkgaGF2ZSBzZWVuLCB0aGUgaWRlYSBpcyB0aGF0IGEgY2xp ZW50ICh3aG9zZSBjbGllbnRJRCBpcyBhbHJlYWR5IGtub3duIHRvIHRoZSBSUykgY2FuIG9idGFp biB0b2tlbnMgdGhydSBkaWZmZXJlbnQgZ3JhbnRzLCBzb21lIG9mIHRoZW0gY29uZmlkZW50aWFs IGFuZCBvdGhlcnMgcHVibGljOyBhbmQgdGhlIHJlc291cmNlIHdhbnRzIHRvIGtub3cgd2hldGhl ciB0aGlzIHBhcnRpY3VsYXIgdG9rZW4gd2FzIG9idGFpbmVkIHByb3ZpbmcgdGhlIGlkZW50aXR5 IG9mIHRoZSBjbGllbnQgc28gdGhhdCBpdCBjYW4gZGVjaWRlIHdoZXRoZXIgdG8gZ3JhbnQgZXh0 cmEgcHJpdmlsZWdlcyBmb3IgdGhhdCBwYXJ0aWN1bGFyIGNsaWVudCBpbiB0aGUgY3VycmVudCBj YWxsLiBUaGlzIHNjZW5hcmlvIGRvZXMgbm90IHJlcXVpcmUgdGhlIGV4dHJhIGRldGFpbHMgYWJv dXQgYXV0aGVudGljYXRpb24gbWV0aG9kL3N0cmVuZ3RoIHlvdSBtZW50aW9uIHRoYXQsIEkgYWdy ZWUsIHdvdWxkIGJlIHByZXR0eSBoYXJkIHRvIHJlYWNoIGNvbnNlbnN1cyBvbi4NClRMO0RSOiB0 aGVyZSBpcyBhdCBsZWFzdCBvbmUgc2NlbmFyaW8gdGhhdCBpcyBzYXRpc2ZpZWQgYnkgdGhlIHNp bXBsZSBib29sLCBhcyB0aGUgcHJldmlvdXMga25vd2xlZGdlIG9mIHRoZSBjbGllbnQgc29sdmVz IHRoZSBpc3N1ZXMgeW91IG1lbnRpb24gb3V0IG9mIGJhbmQuDQoNCmF1dGhlbnRpY2F0aW9uIHNl c3Npb24gcHJvcGVydGllczoNCiBMZXQgbWUgdHJ5IGFub3RoZXIgYW5nbGUuIFNheSB0aGF0IEkg cGVyZm9ybSBhbiBhdXRoeiBjb2RlIGdyYW50IGFza2luZyBmb3IgQVQsIElEX1QgYW5kIFJULSBv YnRhaW5pbmcgQVQnLCBJRF9UJyBhbmQgUlQnLg0KVGhlIHZhbHVlcyBvZiBhdXRoX3RpbWUsIGFj ciBhbmQgYW1yIGluIEFUJyB3aWxsIGJlIHRoZSBzYW1lIGFzIHRoZSBjb3JyZXNwb25kaW5nIGNs YWltcyBpbiBJRF9UJy4gV2hlbiB0aGUgY2xpZW50IHVzZXMgUlQnIHRvIG9idGFpbiBBVGBOLCBB VCdOKzEgZXRjIGV0YywgdGhlIHZhbHVlcyBvZiB0aG9zZSBjbGFpbXMgd2lsbCByZW1haW4gdGhl IHNhbWUgZm9yIGV2ZXJ5IEFUJ24gb2J0YWluZWQgYnkgUlQnLg0KTm93LCBpbWFnaW5lIHRoYXQg c29tZXRoaW5nIGhhcHBlbnMgKGlnbm9yZSB3aGF0IGZvciB0aGUgdGltZSBiZWluZykgdGhhdCBj YXVzZXMgdGhlIGNsaWVudCB0byBwZXJmb3JtIGEgc3RlcCB1cCBhdXRoLCB3aGljaCByZXF1aXJl cyB0aGUgdXNlciB0byBwZXJmb3JtIGludGVyYWN0aXZlIGF1dGggaGVuY2UgcmVzdWx0cyBpbiBh IG5ldyBhdXRoeiBncmFudC4gVGhlIGNsaWVudCB3aWxsIG9idGFpbiBhIG5ldyB0dXBsZSAgQVQi LCBJRF9UIiBhbmQgUlQiLiBUaGUgZXhhY3Qgc2FtZSBydWxlcyBkZXNjcmliZWQgZm9yIHRoZSAn IHR1cGxlIGFwcGx5LCB3aXRoIHRoZSBuZXcgdmFsdWVzIGRldGVybWluZWQgYnkgdGhlIG5ldyBh dXRoZW50aWNhdGlvbjogQVQiIGF1dGhfdGltZS9hY3IvYW1yIHdpbGwgYmUgdGhlIHNhbWUgYXMg SURfVCIsIGFuZCB0aG9zZSB2YWx1ZXMgd2lsbCByZW1haW4gdW5jaGFuZ2VkIGZvciBldmVyeSBB VCJuIGRlcml2ZWQgYnkgUlQiLg0KSWYgd2Ugd2FudCB0aGlzIHRvIGFwcGx5IHRvIHRoZSBpbXBs aWNpdCBmbG93IGFzIHdlbGwsIHlvdSBjYW4gc3Vic3RpdHV0ZSB0aGUgUlQgd2l0aCB0aGUgc2Vz c2lvbiBhcnRpZmFjdC4NCkRvZXMgdGhhdCBoZWxwIGNsYXJpZnlpbmcgdGhlIGludGVudD8gSWYg eWVzLCBkbyB5b3UgZmVlbCB0aGF0IHRoZSBjdXJyZW50IGxhbmd1YWdlIGRvZXMgbm90IGRlc2Ny aWJlIHRoaXM/DQoNCnVzZSBjYXNlIGZvciBwdXR0aW5nIHRoZXNlIGluIHRoZSBhY2Nlc3MgdG9r ZW4NCkkgYW0gbm90IHRyeWluZyB0byBjcmVhdGUgYSBjb21wbGV0ZSBmcmFtZXdvcmsgZm9yIGhh bmRsaW5nIHN0ZXAgdXAgYW5kIHRoZSBsaWtlLCBJIGFtIHRyeWluZyB0byBjcmVhdGUgYW4gaW50 ZXJvcGVyYWJsZSByZXByZXNlbnRhdGlvbiBvZiB0aG9zZSB2YWx1ZXMgbm8gbWF0dGVyIGhvdyB0 aGV5IHdlcmUgb2J0YWluZWQuDQpDb25zaWRlciB0aGUgY2FzZSBpbiB3aGljaCBhbiBBUEkgYWxs b3dzIGNlcnRhaW4gb3BlcmF0aW9ucyBvbmx5IGlmIGEgZ2l2ZW4gYW1yIHZhbHVlIGlzIHByZXNl bnQgaW4gdGhlIHRva2VuLiBXaGV0aGVyIHRoYXQgYW1yIGlzIHJlcXVpcmVkIHVwZnJvbnQgb24g Zmlyc3QgYXV0aGVudGljYXRpb24sIGFzIHN0ZXAgdXAgb3IgYW55IG90aGVyIHJlYXNvbiBpcyBv dXQgb2Ygc2NvcGUgZm9yIHRoaXMgcHJvZmlsZSBJTU86IHRoZSBBUyBtaWdodCBoYXZlIGFsbCBz b3J0cyBvZiBoZXVyaXN0aWNzIHRoYXQgZGV0ZXJtaW5lIHRoYXQgKHVzZXIgbWVtYmVyc2hpcCB0 byBhIGdpdmVuIGdyb3VwIG9yIHJvbGU7IGdlb2ZlbmNpbmc7IHJpc2sgc2NvcmluZzsgZXRjKSB0 aGF0IGhhdmUgbm90aGluZyB0byBkbyB3aXRoIHNjb3BlcyByZXF1ZXN0ZWQsIGFuZCBhcmUgbm90 IHN0YXRpY2FsbHkgZGV0ZXJtaW5lZCBieSBSUy1BUyBjb21tdW5pY2F0aW9ucy4NCk5vdywgSSBh Z3JlZSB0aGF0IGZvcm1hbGl6aW5nIGhvdyBhIFJTIGNvbW11bmljYXRlcyB0byB0aGUgQVMgdmlh IHRoZSBjbGllbnQgdGhlIG5lZWQgdG8gc3RlcCB1cCBhbmQgaW4gd2hhdCB0ZXJtcyB3b3VsZCBi ZSBzdXBlciB1c2VmdWw7IGhvd2V2ZXIgSSB0aGluayB0aGF0J3Mgd2VsbCBiZXlvbmQgdGhlIHNj b3BlIG9mIHRoaXMgcHJvZmlsZS4uIFZhcmlvdXMgdmVuZG9ycyBhbHJlYWR5IGhhdmUgdGhlaXIg b3duIG1lY2hhbmlzbXMgZm9yIGhhbmRsaW5nIHN0ZXAgdXAgc2lnbmFsaW5nIGZyb20gUlMgdG8g QVMgKEkgYW0gdmVyeSBmYW1pbGlhciB3aXRoIHRoZSBNaWNyb3NvZnQgb25lKSBhbmQgYWxsIEkg YW0gbG9va2luZyBmb3IgaXMgYSB3YXkgb2Ygc3RhbmRhcmRpemluZyBob3cgdG8gcmVwcmVzZW50 IHRoZSBvdXRjb21lcywgc28gdGhhdCBBUEkgZ2F0ZXdheXMgYW5kIFNESyBwcm92aWRlcnMgY2Fu IHByb3ZpZGUgdG9vbHMgdGhhdCB3b3JrIGFjcm9zcyB2ZW5kb3JzOyBhbmQgcG9zc2libHkgcmV1 c2Ugc29tZSBvZiB0aGUgcmVhc29uaW5nIHRoYXQgd2FzIGFscmVhZHkgZG9uZSBmb3IgaWRfdG9r ZW5zLg0KVEw7RFI6IEkgdGhpbmsgd2UgYXJlIGRvaW5nIHNvbWV0aGluZyB1c2VmdWwgaW4gZm9y bWFsaXppbmcgaG93IHRvIGVtYmVkIHRoYXQgaW5mbyBhbiBBVHMgZXZlbiBpZiB3ZSBkb24ndCBm b3JjZSB2ZW5kb3JzIHRvIGdpdmUgdXAgdGhlaXIgY3VycmVudCBtZWNoYW5pc21zIHRvIHBvcHVs YXRlIHRob3NlIHZhbHVlcy4NCg0KUmVnYXJkaW5nIGFjY2VzcyB0b2tlbnMgdGhhdCBhcmUgdXNl ZCB0byBhY2Nlc3MgZGlmZmVyZW50IHJlc291cmNlIHNlcnZlcnMNClRoZSBpbnRlbnQgaXMgdG8g ZXhwbGljaXRseSBkaXNhbGxvdyB0aGUgdXNlIG9mIGFuIEFUIHdpdGggbXVsdGlwbGUgcmVzb3Vy Y2Ugc2VydmVycy4gSWYgYSBjbGllbnQgd2FudHMgdG8gdGFsayB3aXRoIDIgZGlmZmVyZW50IFJT ZXMsIHRoZSBjbGllbnQgc2hvdWxkIGFzayBmb3IgMiBkaWZmZXJlbnQgQVRzLg0KVGhlIHNwZWMg aXMgdW5hbWJpZ3VvdXMgb24gdGhpcyBJTU8sIGhlcmUncyB0aGUgbGFuZ3VhZ2UgSSB1c2UgaW4g MDMuDQoNCg0KSWYgaXQgcmVjZWl2ZXMgYSByZXF1ZXN0IGZvciBhbiBhY2Nlc3MgdG9rZW4gY29u dGFpbmluZyBtb3JlIHRoYW4gb25lDQoNCiAgIHJlc291cmNlIHBhcmFtZXRlciwgYW4gYXV0aG9y aXphdGlvbiBzZXJ2ZXIgaXNzdWluZyBKV1QgYWNjZXNzIHRva2Vucw0KDQogICBNVVNUIHJlamVj dCB0aGUgcmVxdWVzdCBhbmQgZmFpbCB3aXRoICJpbnZhbGlkX3JlcXVlc3QiIGFzIGRlc2NyaWJl ZA0KDQogICBpbiBzZWN0aW9uIDQuMS4yLjEgb2YgW1JGQzY3NDldPGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTQuMS4yLjE+IG9yIHdpdGggImlu dmFsaWRfdGFyZ2V0IiBhcyBkZWZpbmVkDQoNCiAgIGluIHNlY3Rpb24gMiBvZiBbUmVzb3VyY2VJ bmRpY2F0b3JzPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0 Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzI3JlZi1SZXNvdXJjZUluZGljYXRvcnM+XS4gIFNl ZSBTZWN0aW9uIDIuMjxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMyNzZWN0aW9uLTIuMj4gYW5kIFNlY3Rpb24g NTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt YWNjZXNzLXRva2VuLWp3dC0wMyNzZWN0aW9uLTU+DQoNCiAgIGZvciBtb3JlIGRldGFpbHMgb24g aG93IHRoaXMgbWVhc3VyZSBlbnN1cmVzIHRoZXJlJ3Mgbm8gY29uZnVzaW9uIG9uDQoNCiAgIHRv IHdoYXQgcmVzb3VyY2UgdGhlIGFjY2VzcyB0b2tlbiBncmFudGVkIHNjb3BlcyBhcHBseS4NCiAg SXMgaXQgcG9zc2libGUgeW91IGFyZSByZWZlcnJpbmcgdG8gYW4gb2xkZXIgZHJhZnQ/DQoNCg0K T24gTW9uLCBEZWMgMTYsIDIwMTkgYXQgNToyOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxs ZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFtYXpvbi5j b21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCjEuIFJlZ2FyZGluZyBBdXRoZW50aWNhdGVkQ2xp ZW50Og0KRG9lcyBhIG1vYmlsZSBhcHAgdGhhdCB1c2VzIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJh dGlvbiB0byBlc3RhYmxpc2ggYSBjbGllbnQgc2VjcmV0IGNvdW50IGFzIGFuIOKAnGF1dGhlbnRp Y2F0ZWQgY2xpZW504oCdPyBXaGF0IGlmIHRoYXQgcmVnaXN0cmF0aW9uIGluY2x1ZGVkIGFuIGFz c2VydGlvbiBzaWduZWQgYnkgYSB0cnVzdGVkIGVudGl0eSAoZS5nLiwgZGV2aWNlIG1hbmFnZW1l bnQgc29mdHdhcmUpIHVzaW5nIGEgY2VydGlmaWNhdGUgdGhhdCBoYWQgYmVlbiBwdXNoZWQgdG8g dGhlIGRldmljZT8gV2l0aG91dCBzb21lIGtpbmQgb2YgTklTVCBMb0Etc3R5bGUgZGVmaW5pdGlv biBvZiDigJxhdXRoZW50aWNhdGVk4oCdLCBhIHNpbmdsZSBCb29sZWFuIOKAnEF1dGhlbnRpY2F0 ZWRDbGllbnTigJ0gdmFsdWUgaXMgdG9vIGFtYmlndW91cyB0byBiZSB1c2VmdWwuIEhvd2V2ZXIs IEnigJltIHNrZXB0aWNhbCB0aGF0IHdlIGNvdWxkIGZpbmQgY29uc2Vuc3VzIG9uIHdoYXQgdGhh dCBkZWZpbml0aW9uIHNob3VsZCBiZSwgYW5kIGl0IG1heSBiZSBiZXR0ZXIgdG8gZGVmaW5lIGNs aWVudCBhbmFsb2dzIHRvIGBhY3JgIGFuZCBgYW1yYCB0aGF0IHByb3ZpZGUgc3RhbmRhcmQgd2F5 cyBvZiBleHByZXNzaW5nIGNsaWVudCBhdXRoZW50aWNhdGlvbiBkZXRhaWxzIHdpdGhvdXQgZ2V0 dGluZyBwcmVzY3JpcHRpdmUgYWJvdXQgd2hhdCBraW5kIG9mIGF1dGhlbnRpY2F0aW9uIGlzIOKA nGdvb2QgZW5vdWdoLuKAnQ0KDQoyLiBSZWdhcmRpbmcgYXV0aGVudGljYXRpb24gc2Vzc2lvbiBw cm9wZXJ0aWVzOg0KSeKAmW0gY29uZnVzZWQgYnkgdGhlIGRlZmluaXRpb25zIGdpdmVuIGZvciBg YXV0aF90aW1lYCwgYGFjcmAsIGFuZCBgYW1yYC4gRm9yIGBhdXRoX3RpbWVgLCBpdCBzYXlzOg0K DQrigJzigKZpdHMgdmFsdWUgd2lsbCBlaXRoZXIgcmVtYWluIHRoZSBzYW1lIGZvciBhbGwgdGhl IEpXVCBhY2Nlc3MgdG9rZW5zIGlzc3VlZCB3aXRoaW4gdGhhdCBzZXNzaW9uIG9yIGJlIHVwZGF0 ZWQgdG8gdGhlIHRpbWUgb2YgbGF0ZXN0IGF1dGhlbnRpY2F0aW9uIGlmIHJlYXV0aGVudGljYXRp b24gb2NjdXJyZWQgbWlkLXNlc3Npb27igKbigJ0NCg0KQnV0IHRoZSDigJxGb3IgZXhhbXBsZeKA nSBhdCB0aGUgZW5kIG9mIHRoYXQgZGVmaW5pdGlvbiBpbXBsaWVzIHRoYXQgYGF1dGhfdGltZWAg d2lsbCBub3QgYmUgdXBkYXRlZC4gVGhlIGRlZmluaXRpb25zIGZvciBgYWNyYCBhbmQgYGFtcmAg c2F5IHRoZSBzYW1lLCBidXQgYWxzbyBzYXkgdGhhdCB0aGUg4oCc4oCmc2FtZSBjb25zaWRlcmF0 aW9ucyBwcmVzZW50ZWQgZm9yIGF1dGhfdGltZSBhcHBseeKApuKAnSBXaGF04oCZcyB0aGUgaW50 ZW50aW9uIGhlcmU6IGFyZSB0aGV5IGZpeGVkLCB1cGRhdGVkLCBvciBpcyBpdCB1cCB0byB0aGUg ZGVwbG95bWVudCB0byBkZWNpZGU/DQoNCknigJlkIGxpa2UgdG8gYmV0dGVyIHVuZGVyc3RhbmQg dGhlIHVzZSBjYXNlIGZvciBwdXR0aW5nIHRoZXNlIGluIHRoZSBhY2Nlc3MgdG9rZW4uIElmIHRo ZSBSUyBpcyBtYWtpbmcgYXV0aG9yaXphdGlvbiBkZWNpc2lvbnMgYmFzZWQgb24gdGhlc2UgY2xh aW1zLCB0aGF0IGltcGxpZXMgdGhhdCB0aGUgUlMgY2Fubm90IHJlbHkgb24gdGhlIEFTIHRvIGRl dGVybWluZSAoZS5nLiwgZnJvbSB0aGUgcmVxdWVzdGVkIHNjb3BlKSB0aGUgcmVxdWlyZWQgYXV0 aGVudGljYXRpb24gbWV0aG9kKHMpLCBmcmVzaG5lc3MsIGV0Yy4gSWYgdGhlIEFTIGNvdWxkIGJl IHJlbGllZCB1cG9uIGZvciB0aGlzLCB0aGVuIHByZXN1bWFibHkgaXQgd291bGQgbm90IGlzc3Vl IFJUcyBhbmQgQVRzIGZvciBhIHNjb3BlIHdpdGhvdXQgcmVxdWlyaW5nIHRoZSBlbmQgdXNlciB0 byBtZWV0IHRoZSBhcHByb3ByaWF0ZSBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudHMuIElmIHRo aXMgaXMgdGhlIGNhc2UsIHRoZW4gdGhlIFJTIG11c3QgaGF2ZSBhIHdheSB0byBzaWduYWwgdG8g dGhlIGNsaWVudCAoYW5kIHRoZW4gdGhlIEFTKSB0aGF0IGEgc3RlcC11cCBhdXRoZW50aWNhdGlv biBpcyByZXF1aXJlZC4gSXMgdGhlcmUgYW4gZXhpc3RpbmcgbWVjaGFuaXNtIHRocm91Z2ggd2hp Y2ggdGhleSBjb3VsZCBkbyB0aGlzPyBBbGwgSSBjYW4gY29tZSB1cCB3aXRoIGlzIGNyYW1taW5n IHRoZSBpbmZvcm1hdGlvbiBpbnRvIHRoZSBzY29wZSBhdHRyaWJ1dGUgb2YgYSBXV1ctQXV0aGVu dGljYXRlIGNoYWxsZW5nZSwgYnV0IHRoYXQgaGFzIHRoZSBzYW1lIHNjb3BlIG9wYWNpdHkgdmlv bGF0aW9uIHByb2JsZW0gYXMgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnTigJlzIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zLiBXaXRob3V0IGEgY2xlYXIgd2F5IHRvIGV4cHJlc3MgdGhlIHN0ZXAtdXAg cmVxdWlyZW1lbnRzLCB0aGlzIGZlZWxzIGluY29tcGxldGUuLg0KDQozLiBSZWdhcmRpbmcgYWNj ZXNzIHRva2VucyB0aGF0IGFyZSB1c2VkIHRvIGFjY2VzcyBkaWZmZXJlbnQgcmVzb3VyY2Ugc2Vy dmVyczoNClJlYWRpbmcgYmV0d2VlbiB0aGUgbGluZXMsIEkgKnRoaW5rKiB0aGUgaW50ZW50aW9u IGlzIHRoYXQgYSBKV1QgYWNjZXNzIHRva2VuIHRoYXQgaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCB0 byBhY2Nlc3MgdHdvIGRpZmZlcmVudCByZXNvdXJjZXMgYXQgdHdvIGRpZmZlcmVudCBSU2VzIHNo b3VsZCBsb29rIHNvbWV0aGluZyBsaWtlOg0KDQp7DQoiYXVkIjogImh0dHBzOi8vZ2VuZXJpYy1y ZXNvdXJjZS1pbmRpY2F0b3IuZXhhbXBsZS5jb20vIiwNCiJzY29wZSI6ICJyZXNvdXJjZV9mb28g cmVzb3VyY2VfYmFyIiwNCi4uLg0KfQ0KDQpBbmQgdGhlIGV4cGVjdGF0aW9uIGlzIHRoYXQgZWFj aCBSUyBzaG91bGQgcmVjb2duaXplIHRoYXQgZ2VuZXJpYyBhdWRpZW5jZS4gSXMgdGhpcyBjb3Jy ZWN0PyBJZiBzbyBpdCBzZWVtcyB0byBnbyBhZ2FpbnN0IHRoZSBzcGlyaXQgb2YgcmVzb3VyY2Ug aW5kaWNhdG9ycyBhcyBpbmRpY2F0aW5nIHRoZSB0YXJnZXQgb3IgbG9jYXRpb24gb2YgYSByZXNv dXJjZS4gSXTigJlzIHN0cmV0Y2hpbmcgdGhhdCBkZWZpbml0aW9uLCBhdCB0aGUgdmVyeSBsZWFz dC4NCg0KQnV0IGFzIEkgc2FpZCwgSeKAmW0gcmVhZGluZyBiZXR3ZWVuIHRoZSBsaW5lcyBoZXJl LiBJZiB0aGlzIGlzIHRoZSBpbnRlbnRpb24sIGl0IHNob3VsZCBiZSBjbGVhcmx5IHN0YXRlZC4g QWx0ZXJuYXRpdmVseSwgcmVtb3ZlIChvciBjaGFuZ2UgdG8gYSBTSE9VTEQpIHRoZSByZXF1aXJl bWVudCB0aGF0IG11bHRpLXZhbHVlIGBhdWRgIGNsYWltcyBtdXN0IG9ubHkgY29udGFpbiBhbGlh c2VzIGZvciB0aGUgc2FtZSByZXNvdXJjZSBpbmRpY2F0b3IuDQoNCuKAkw0KQW5uYWJlbGxlIFJp Y2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2Yg Vml0dG9yaW8gQmVydG9jY2kgPFZpdHRvcmlvPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPG1h aWx0bzo0MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpEYXRlOiBNb25kYXksIERlY2VtYmVy IDE2LCAyMDE5IGF0IDI6NTEgUE0NClRvOiBJRVRGIG9hdXRoIFdHIDxvYXV0aEBpZXRmLm9yZzxt YWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KQ2M6ICJpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRv OmktZC1hbm5vdW5jZUBpZXRmLm9yZz4iIDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmkt ZC1hbm5vdW5jZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMudHh0DQoNCkRlYXIgYWxsLA0K SSBmaW5hbGx5IGZvdW5kIHRoZSB0aW1lIHRvIHB1c2ggYSBuZXcgZHJhZnQgb2YgdGhlIEpXVCBw cm9maWxlIGZvciBBVHMuIFRoaXMgdmVyc2lvbiBpbmNvcnBvcmF0ZXMgdGhlIGZlZWRiYWNrIGtp bmRseSBwcm92aWRlZCBieSBCcmlhbiBhbmQgQWFyb24gYXQgSUVURjEwNS4NClVuZm9ydHVuYXRl bHkgSSBkaWRuJ3QgaGF2ZSBhIGNoYW5jZSB0byBwYXJ0aWNpcGF0ZSB0byBJRVRGMTA2LCBoZW5j ZSB3ZSBkaWRuJ3QgZG8gbXVjaCBwcm9ncmVzcyBzaW5jZSB0aGVuLg0KVGhlcmUgYXJlIHN0aWxs IHR3byBhcmVhcyB3ZSBkaWRuJ3QgbWFuYWdlIHRvIHJlYWNoIGNvbnNlbnN1cyBvbjoNCg0KMS4g TWVjaGFuaXNtcyBmb3Igc2lnbmFsaW5nIHdoZXRoZXIgdGhlIEFUIHdhcyBvYnRhaW5lZCBieSBh IHVzZXIgb3IgYW4gYXBwbGljYXRpb24NCg0KVGhpcyBwb2ludCB3YXMgdGhlIHN1YmplY3Qgb2Yg aW50ZW5zZSBkZWJhdGUgb24gdGhlIGxpc3QgbGVhZGluZyB0byBJRVRGMTA1Li4NCk9uZSBpbnNp Z2h0IHRoYXQgZW1lcmdlZCBmcm9tIHRoZSBJRVRGMTA1IGRpc2N1c3Npb24gd2FzIHRoYXQgdGhl IHVzZSBjYXNlIGhlcmUgaXMgbW9yZSBhYm91dCB3aGV0aGVyIHRoZSBBVCBoYXMgYmVlbiBvYnRh aW5lZCB2aWEgYSBncmFudCB0aGF0IGF1dGhlbnRpY2F0ZWQgdGhlIGNsaWVudCAocmVnYXJkbGVz cyBvZiB3aGF0IHNwZWNpZmljIGdyYW50IHdhcyB1c2VkKSB2cyBhIHB1YmxpYyBjbGllbnQgZ3Jh bnQtIHRoYXQgaW5mb3JtYXRpb24gY2FuIGJlIHJlbGV2YW50IHRvIGEgcmVzb3VyY2UgYXMgaXQg ZGV0ZXJtaW5lcyB3aGV0aGVyIHRoZSBpZGVudGl0eSBvZiB0aGUgY2xpZW50IGNhbiBiZSB1c2Vk IGluIGF1dGhvcml6YXRpb24gZGVjaXNpb25zIChpbiB0aGUgZm9ybWVyIGNhc2UpIG9yIG5vdCAo aW4gdGhlIHB1YmxpYyBjbGllbnQgY2FzZSkuIElmIHRoYXQncyB0aGUgc2NlbmFyaW8gd2UgYXJl IHRydWx5IGFmdGVyLCBhIHNpbXBsZSwgcG9zc2libHkgb3B0aW9uYWwgYm9vbGVhbiBjbGFpbSAo c2F5IEF1dGhlbnRpY2F0ZWRDbGllbnQpIHdvdWxkIHN1ZmZpY2UuDQpOb3RlIGZvciB0aGUgcGVv cGxlIHdobyBkaWRuJ3QgcmVhZCB0aGUgc3BlYzogSSByZW1vdmVkIGFueSByZWZlcmVuY2UgdG8g dGhpcyBhbHJlYWR5IGluIGRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMS4gSSB0 aGluayB0aGlzIGlzIGFuIGltcG9ydGFudCBhbmQgdXNlZnVsIGluZm8gYW5kIHN0YW5kYXJkaXpp bmcgaXQgd291bGQgYmUgYmVuZWZpY2lhbCBmb3IgbWlkZGxld2FyZSBhbmQgU0RLIGNyZWF0b3Jz LCBidXQgdWx0aW1hdGVseSB0aGlzIGlzIGFuIGludGVyb3AgcHJvZmlsZSBoZW5jZSBpZiB0aGVy ZSdzIG5vIHN0cm9uZyBkZXNpcmUgdG8gcmVhY2ggYW4gYWdyZWVtZW50IGhlcmUsIEkgYW0gYWxz byBPSyB3aXRoIGRyb3BwaW5nIHRoZSBtYXR0ZXIgYW5kIG5vdCBhZGRyZXNzIHRoaXMgZnVuY3Rp b24gaW4gdGhlIHNwZWMuDQpUbyBzdW1tYXJpemUsIEkgaGF2ZSB0d28gcXVlc3Rpb25zIGhlcmU6 DQpBLiBEbyB3ZSBiZWxpZXZlIGl0J3Mgd29ydGggaXQgdG8gZm9ybWFsaXplIGluIHRoZSBwcm9m aWxlIGEgbWVjaGFuaXNtIHRvIGluZGljYXRlIHdoZXRoZXIgdGhlIGNsaWVudCB0aCBvYnRhaW5l ZCB0aGUgQVQgYXV0aGVudGljYXRlZCBpdHNlbGYgd2l0aCB0aGUgQVM/DQpCLiBJZiB5ZXMsIGFy ZSB5b3UgT0sgd2lodCBhbiBvcHRpb25hbCBib29sIGNsYWltIGhlcmU/DQoNCjIuIENsYWltcyBp bmRpY2F0aW5nIHNlc3Npb24gcHJvcGVydGllcw0KDQpUaGlzIGlzIG9uZSBhcmVhIHdoZXJlIEkg YW0gZmFyIG1vcmUgcGFzc2lvbmF0ZSBhYm91dCwgYXMgaXQgcmVwcmVzZW50cyBhIGZ1bmRhbWVu dGFsIGFzcGVjdCB0aGF0IHByb2R1Y3Rpb24gc3lzdGVtcyAoYW5kIGluIHBhcnRpY3VsYXIgMXN0 IHBhcnR5IHNvbHV0aW9ucykgYWxyZWFkeSByZWx5IG9uIGluIHRoZSBjdXJyZW50IHByb3ByaWV0 YXJ5IEpUVyBBVHMuDQpUaGUgcHJvZmlsZSBjdXJyZW50bHkgaW5jbHVkZXMgdGhlIGNsYWltcyBh dXRoX3RpbWUsIGFjciBhbmQgYW1yIC0gY2FwdHVyaW5nIHRoZSB2YWx1ZXMgb2YgdGhvc2UgcHJv cGVydGllcyBhdCB0aGUgdGltZSBvZiB0aGUgbGF0ZXN0IGF1dGhlbnRpY2F0aW9uIHRoZSB1c2Vy IHBlcmZvcm1lZCBpbiB0aGUgc2Vzc2lvbiB1c2VkIHRvIGlzc3VlIHRoZSBjdXJyZW50IEFUOiBh dCBzZXNzaW9uIGNyZWF0aW9uLCBhdCBhdXRoIHN0ZXAgdXAgdGltZSBhbmQgc28gb24uDQpUaG9z ZSBhcmUgdmFsdWVzIHRoYXQgQVBJIG5lZWQgaW4gb3JkZXIgdG8gbWFrZSBhdXRob3JpemF0aW9u IGRlY2lzaW9uczsgaW4gdGhlIGNhc2Ugb2YgMXN0IHBhcnR5IEFQSXMsIHRoZSBBVCBpcyB0aGUg b25seSBhcnRpZmFjdCB0aGV5IGV2ZXIgcmVjZWl2ZSBoZW5jZSB0aGVyZSBpcyBubyBvdGhlciB3 YXkgZm9yIGFuIEFQSSB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgY2FsbGVyIHBlcmZvcm1lZCBz YXkgTUZBIGluIG9yZGVyIHRvIG9idGFpbiB0aGUgY3VycmVudCBBVC4NClNpbmNlIHRoZSBmaXJz dCBkcmFmdCwgc29tZSBwZW9wbGUgc2lnbmFsZWQgY29uY2VybnMgYWJvdXQgdGhlIGN1cnJlbnQg bWVjaGFuaXNtcyB0aHJ1IHdoaWNoIHRob3NlIGNsYWltcyBnZXQgdGhlaXIgdmFsdWUuIEZvciBl eGFtcGxlLCBpdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBtYWludGFpbiB0aGUgb3JpZ2luYWwgdmFs dWVzIG9mIGF1dGhfdGltZSwgYWNyICYgYW1yIGFuZCBpbnRyb2R1Y2UgYWRkaXRpb25hbCBjbGFp bXMgdG8gaW5kaWNhdGUgY2hhbmdlcyAobGlrZSBzdGVwdXApLg0KSSBhbSBub3QgY2xlYXIgb24g d2hhdCBjb2xkIGdvIHdyb25nIHdpdGggdGhlIGN1cnJlbnQgYXBwcm9hY2gsIGhlbmNlIEkgZG9u J3QgaGF2ZSBhbiBpbW1lZGlhdGUgZ3Jhc3Agb2YgaG93IGNoYW5nZXMgbGlrZSB0aGUgYWJvdmUg d291bGQgaGVscC4NCklmIHRoZSBwZW9wbGUgdW5jb21mb3J0YWJsZSB3aXRoIHRoZSBjdXJyZW50 IHByb3Bvc2FsIGNvdWxkIGRldGFpbCB0aGVpciBjb25jZXJuLCB3ZSBjYW4gYnJhaW5zdG9ybSB3 YXlzIHRvIG1ha2UgdGhhdCBpbmZvIGF2YWlsYWJsZSB0byBBUEkgaW4gYSBzYWZlciB3YXkuIFRv IHN1bW1hcml6ZToNCkEuIERvIHlvdSBoYXZlIGNvbmNlcm5zIHdpdGggdGhlIGN1cnJlbnQgYXV0 aF90aW1lLCBhcm0sIGFjciBwcm9wb3NhbD8gQ2FuIHlvdSBzcGVsbCB0aGVtIG91dD8gKHBsZWFz ZSByZWFkIHRoZSByZWxldmFudCBwYXJ0cyBvZiB0aGUgc3BlYyBiZWZvcmUgY2hpbWluZyBpbiA6 KSkNCkIuIElmIHllcywgd2hhdCBjYW4gd2UgZG8gdG8gbWFrZSB0aGF0IGluZm8gYXZhaWxhYmxl IHRvIFJTcyBpbiBhIHdheSB0aGF0IG1ha2VzIHlvdSBjb21mb3J0YWJsZT8NCg0KDQpUaGFua3MN Cg0KVi4NCg0KT24gTW9uLCBEZWMgMTYsIDIwMTkgYXQgMjo0OSBQTSA8aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+PiB3cm90ZToNCg0KQSBO ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQt RHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgV2Vi IEF1dGhvcml6YXRpb24gUHJvdG9jb2wgV0cgb2YgdGhlIElFVEYuDQoNCiAgICAgICAgVGl0bGUg ICAgICAgICAgIDogSlNPTiBXZWIgVG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFj Y2VzcyBUb2tlbnMNCiAgICAgICAgQXV0aG9yICAgICAgICAgIDogVml0dG9yaW8gQmVydG9jY2kN CiAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4t and0LTAzLnR4dA0KICAgICAgICBQYWdlcyAgICAgICAgICAgOiAxNg0KICAgICAgICBEYXRlICAg ICAgICAgICAgOiAyMDE5LTEyLTE2DQoNCkFic3RyYWN0Og0KICAgVGhpcyBzcGVjaWZpY2F0aW9u IGRlZmluZXMgYSBwcm9maWxlIGZvciBpc3N1aW5nIE9BdXRoIDIuMCBhY2Nlc3MNCiAgIHRva2Vu cyBpbiBKU09OIHdlYiB0b2tlbiAoSldUKSBmb3JtYXQuICBBdXRob3JpemF0aW9uIHNlcnZlcnMg YW5kDQogICByZXNvdXJjZSBzZXJ2ZXJzIGZyb20gZGlmZmVyZW50IHZlbmRvcnMgY2FuIGxldmVy YWdlIHRoaXMgcHJvZmlsZSB0bw0KICAgaXNzdWUgYW5kIGNvbnN1bWUgYWNjZXNzIHRva2VucyBp biBpbnRlcm9wZXJhYmxlIG1hbm5lci4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC8NCg0KVGhlcmUgYXJlIGFsc28gaHRt bGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMw0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMN Cg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRv a2VuLWp3dC0wMw0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rv b2xzLmlldGYub3JnPi4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLi5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPGZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBp ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1 dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo DQo= --_000_119EE9E631CC4C258FD0D9E8FE389A2Eamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <847FD1A95272CF4E88B0A4BF29738716@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjIgMCA1IDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIg NiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAy IDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2Ut MToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJQVCBN b25vIjsNCglwYW5vc2UtMToyIDYgNSA5IDIgMiA1IDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBtb3JlIGxpbmUganVtcGVkIG91dCBhdCBtZSwgaW4gwqc0 OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEFuIGF1dGhvcml6YXRpb24gc2VydmVyIE1B WSBlbGVjdCB0byB1c2UgZGlmZmVyZW50IGtleXMgdG8gc2lnbiBpZF90b2tlbnMgYW5kIEpXVCBh Y2Nlc3MgdG9rZW5zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGlsZSB0aGUgandrc191cmkg bWV0YWRhdGEgcGFyYW1ldGVyIGNhbiBwb2ludCB0byBhIHNldCBjb250YWluaW5nIG11bHRpcGxl IGtleXMsIHRoZXJlIGlzIG5vIHdheSBmb3IgYW4gQVAgKG9yIE9JREMgT1ApIHRvIGluZGljYXRl IHdoaWNoIGtleXMgYXJlIHVzZWQgZm9yIHdoaWNoIHB1cnBvc2UuIFNvIHdoaWxlIGFuIEFTIG1p Z2h0IGNob29zZSB0byB1c2Uga2V5X2EgdG8gc2lnbiBJRCBUb2tlbnMgYW5kDQoga2V5X2IgdG8g c2lnbiBKV1QgYWNjZXNzIHRva2VucywgdGhlcmUgaXMgbm8gd2F5IGZvciB0aGUgQVMgdG8gaW5k aWNhdGUgdGhpcyB0byBjbGllbnRzIGFuZCBSU2VzLiBUaGlzIG1lYW5zIHRoYXQgYW4gQVMgY2Fu bm90IHJlbHkgdXBvbiB0aGUgdXNhZ2Ugb2YgZGlmZmVyZW50IGtleXMgdG8gZGlmZmVyZW50aWF0 ZSBJRCBUb2tlbnMgZnJvbSBKV1QgYWNjZXNzIHRva2VucyBvciBhbnkgb3RoZXIgSldUIHRoYXQg dGhlIEFTIG1pZ2h0IGlzc3VlLA0KIHVubGVzcyB0aGV5IGhhdmUgc29tZSBvdXQtb2YtYmFuZCBt ZWNoYW5pc20gZm9yIGluZGljYXRpbmcga2V5IHB1cnBvc2UuIEkgdGhpbmsgaXTigJlzIHdvcnRo IGNhbGxpbmcgdGhpcyBvdXQgaW4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMsIGFzIHRoaXMgbWF5 IG5vdCBiZSBvYnZpb3VzIHRvIHJlYWRlcnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl04oCZ cyBhbHNvIHdvcnRoIG5vdGluZyB0aGF0IOKAnHNpZ24gdGhlbSB3aXRoIGRpZmZlcmVudCBrZXlz 4oCdIGhhcyBiZWVuIHN1Z2dlc3RlZCBhcyBhIHRlY2huaXF1ZSBmb3IgcHJldmVudGluZyBKV1Rz IGlzc3VlZCBmb3Igb25lIHB1cnBvc2UgKGUuZy4sIGEgU0VUKSBmcm9tIGJlaW5nIG1pc3Rha2Vu IGZvciBhIEpXVCBpc3N1ZWQgZm9yIGFub3RoZXIgcHVycG9zZSAoZS5nLiwgYW4gSUQgVG9rZW4p LiBUaGlzIGRyYWZ0DQogcXVpdGUgcmVhc29uYWJseSBhbmQgbmF0dXJhbGx5IHJldXNlcyBleGlz dGluZyBBUyBtZXRhZGF0YSwgYW5kIGluIHNvIGRvaW5nIGJyZWFrcyB0aGlzIHRlY2huaXF1ZS4g SXQgc2VydmVzIGFzIGEgZ29vZCBleGFtcGxlIG9mIHdoeSBleHBsaWNpdCBKV1QgdHlwaW5nIGlz IGltcG9ydGFudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJlbGxlIFJp Y2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBB bm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPlR1ZXNkYXksIERlY2VtYmVyIDE3LCAyMDE5IGF0IDExOjM5IEFNPGJyPg0KPGI+VG86IDwv Yj5WaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7Vml0dG9yaW89NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5JRVRGIG9hdXRoIFdHICZsdDtvYXV0aEBpZXRmLm9yZyZn dDssIFZpdHRvcmlvIEJlcnRvY2NpICZsdDtWaXR0b3Jpb0BhdXRoMC5jb20mZ3Q7LCAmcXVvdDtp LWQtYW5ub3VuY2VAaWV0Zi5vcmcmcXVvdDsgJmx0O2ktZC1hbm5vdW5jZUBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1X R10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzLnR4dDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IEluIGFueSBjYXNlIHRoZSBpbnRlbnQgd2FzIGFsd2F5cyB0byBvbmx5IGFsbG93IGEgc2luZ2Ug cmVzb3VyY2UgcGVyIEFU4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IGNvbmZ1c2lvbiBh Y3R1YWxseSBjb21lcyBmcm9tIHRoZSBsYXN0IHBhcmFncmFwaCBvZiDCpzMsIHdoZXJlIGl0IHNh eXMg4oCcSWYgYSBzY29wZSBwYXJhbWV0ZXIgaXMgcHJlc2VudCBpbiB0aGUgcmVxdWVzdCwgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCB1c2UgaXQgdG8gaW5mZXIgdGhlIHZhbHVlIG9m IHRoZSBkZWZhdWx0IHJlc291cmNlIGluZGljYXRvciB0byBiZSB1c2VkIGluIHRoZSBhdWQNCiBj bGFpbS7igJ0gSSBpbnRlcnByZXRlZCB0aGF0IHRvIGxlYXZlIHJvb20gZm9yIGFuIEFTIGluZmVy cmluZyB0aGUgc2FtZSDigJxnZW5lcmlj4oCdIHJlc291cmNlIGluZGljYXRvciBmb3IgcmVzb3Vy Y2VzIHNlcnZlZCBieSBkaWZmZXJlbnQgUlNlcy4gVGhlIG9uZS1SUy1wZXItQVQgbW9kZWwgaXMg YW4gaWRlYWwgdGhhdCBzaW1wbHkgZG9lc27igJl0IG1hdGNoIHJlYWxpdHkuIENsaWVudHMgZG9u 4oCZdCB3YW50IHRvIGhhdmUgdG8ganVnZ2xlIGEgYnVuY2ggb2YNCiBkaWZmZXJlbnQgdG9rZW5z LCBub3Igc2hvdWxkIHRoZXkgbmVlZCB0by4gSeKAmW0gY29taW5nIHRvIHRoaW5rIHRoYXQgd2Ug c2hvdWxkbuKAmXQgYWN0dWFsbHkgdXNlIGBhdWRgIGFuZCBgc2NvcGVgIGluIEpXVCBBVHMgYXQg YWxsLCBhbmQgaW5zdGVhZCBhZG9wdCB0aGUgc3RydWN0dXJlIFJBUiBkZWZpbmVzIHVzZWQgZm9y IHRoZSBgYXV0aG9yaXphdGlvbl9kZXRhaWxzYCBwYXJhbWV0ZXIgKEkgdGhpbmsgc29tZSBpdGVy YXRpb24gaXMgcmVxdWlyZWQsDQogYnV0IGl0IHNlZW1zIG5hdHVyYWwgZm9yIHRoZXNlIHR3byB0 byBkZXNjcmliZSBhdXRob3JpemF0aW9ucyBpbiB0aGUgc2FtZSBvciBjb21wYXRpYmxlIHdheXMp LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZndDsg4oCmdGhlIHJlc291cmNlIHdhbnRzIHRvIGtub3cgd2hldGhlciB0 aGlzIHBhcnRpY3VsYXIgdG9rZW4gd2FzIG9idGFpbmVkIHByb3ZpbmcgdGhlIGlkZW50aXR5IG9m IHRoZSBjbGllbnTigKY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gc2tlcHRpY2FsIG9m IHRoZSBpZGVhIHRoYXQgdGhlcmUgaXMganVzdCBvbmUgbGV2ZWwgb2YgY2xpZW50IGlkZW50aXR5 IHByb29maW5nIHRoYXQgUlNlcyBtaWdodCBjYXJlIGFib3V0LiBUaGVyZSBtaWdodCBiZSBzb21l IGNsZWFyIGxpbmVzIHRoYXQgY2FuIGJlIGRyYXduLCBidXQgd2Ugc2hvdWxkIGJlIGV4cGxpY2l0 IGFib3V0IHdoYXQgdGhvc2UgbGluZXMgcmVwcmVzZW50LCBlLmcuLCDigJxjbGllbnQNCiBhdXRo ZW50aWNhdGVkIHVzaW5nIHByZS1lc3RhYmxpc2hlZCBjcmVkZW50aWFs4oCdLCDigJxjbGllbnQg aXMgcnVubmluZyBvbiBlbmQgdXNlci1jb250cm9sbGVkIGRldmljZeKAnSwgZXRjLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDsgSSBhbSBub3QgdHJ5aW5nIHRvIGNyZWF0ZSBhIGNvbXBsZXRlIGZyYW1ld29yayBm b3IgaGFuZGxpbmcgc3RlcCB1cCBhbmQgdGhlIGxpa2UsIEkgYW0gdHJ5aW5nIHRvIGNyZWF0ZSBh biBpbnRlcm9wZXJhYmxlIHJlcHJlc2VudGF0aW9uIG9mIHRob3NlIHZhbHVlcyBubyBtYXR0ZXIg aG93IHRoZXkgd2VyZSBvYnRhaW5lZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0aG91dCB0 YWtpbmcgdGhlIHdob2xlIHBpY3R1cmUgaW50byBhY2NvdW50LCB0aGVyZSBpcyBzaWduaWZpY2Fu dCByaXNrIHRoYXQgd2Ugd2lsbCBkZWZpbmUgc29tZXRoaW5nIHRoYXQgdHVybnMgb3V0IHRvIGJl IHdvZWZ1bGx5IGluc3VmZmljaWVudCAob3Igd29yc2UsIGVzdGFibGlzaGVzIGFuIGFudGktcGF0 dGVybikuIFRoYXQgc2FpZCwgSSBhZ3JlZSB0aGF0IGl04oCZcyBwcm9iYWJseSBub3QgYXBwcm9w cmlhdGUNCiBmb3IgdGhpcyBkcmFmdCwgYW5kIHJlY29tbWVuZCBkcm9wcGluZyB0aGVzZSBjbGFp bXMuIFRoZXkgY2FuIGFsd2F5cyBiZSBkZWZpbmVkIGluIGEgc2VwYXJhdGUgZHJhZnQsIGFsb25n IHdpdGggdGhlIG90aGVyIGVsZW1lbnRzIG5lY2Vzc2FyeSB0byBjb21tdW5pY2F0ZSBzdGVwLXVw IHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJlbGxl IFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5WaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7Vml0dG9yaW89NDBhdXRoMC5jb21AZG1hcmMuaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgRGVjZW1iZXIgMTYsIDIwMTkgYXQg OTozMSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUm cXVvdDsgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5JRVRGIG9h dXRoIFdHICZsdDtvYXV0aEBpZXRmLm9yZyZndDssIFZpdHRvcmlvIEJlcnRvY2NpICZsdDtWaXR0 b3Jpb0BhdXRoMC5jb20mZ3Q7LCAmcXVvdDtpLWQtYW5ub3VuY2VAaWV0Zi5vcmcmcXVvdDsgJmx0 O2ktZC1hbm5vdW5jZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W1VOVkVSSUZJ RUQgU0VOREVSXSBSZTogW09BVVRILVdHXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9hdXRoLWFj Y2Vzcy10b2tlbi1qd3QtMDMudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5SZTogYWxpYXNlcywgSSBzZWUgd2hlcmUgdGhlIGNv bmZ1c2lvbiBpcyBjb21pbmcgZnJvbSE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgdXBk YXRlZCB0aGUgcmVxdWVzdCBzZWN0aW9uLCBidXQgdGhlIHNlc3Npb24gMi4yIGRhdGEgc3RydWN0 dXJlIHN0aWxsIG1lbnRpb25zIHRoZSBhbGlhc2VzLiBUaGF0IHNob3VsZCBiZSBjbGVhbmVkIHVw IGFzIHdlbGwuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SW4gYW55IGNhc2UgdGhlIGludGVu dCB3YXMgYWx3YXlzIHRvIG9ubHkgYWxsb3cgYSBzaW5nZSByZXNvdXJjZSBwZXIgQVQsIHRoZSBh bGlhcyBsaXN0IHdhcyBvbmx5IGZvciBoZWxwaW5nIGluIGNhc2VzIHdoZXJlIGFuIEFTIGlkZW50 aWZpZXMgdGhlIHNhbWUgcmVzb3VyY2UgdGhydSBtdWx0aXBsZSBJRHMgYW5kIHRoZSBhY3R1YWwg YXVkIHZhbHVlIGRlcGVuZHMgb24NCiB3aGF0IElEIHRoZSBjbGllbnQgcmVxdWVzdGVkLiBIb3dl dmVyIHdlIGRpc2N1c3NlZCB0aGlzIHdpdGggQnJpYW4gYW5kIGhlIGNvbnZpbmNlZCBtZSB0aGF0 IGl0IHdhcyBqdXN0IHRvbyBhbWJpZ3VvdXMtIHlvdXIgcmVtYXJrIHJlaW5mb3JjZXMgdGhhdCBp bXByZXNzaW9uLiBJ4oCZbGwgY2xlYW4gdXAgMi4yIGFuZCBlbGltaW5hdGUgcmVmZXJlbmNlcyB0 byBhbGlhc2VzIGZyb20gdGhlcmUgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGFua3Mh PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5PbiBNb24sIERlYyAxNiwgMjAxOSBhdCAyMDoxOSBWaXR0b3JpbyBC ZXJ0b2NjaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlZpdHRvcmlvQGF1dGgwLmNvbSI+Vml0dG9yaW9A YXV0aDAuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGFua3MgQW5uYWJlbGxlLiA8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5Eb2VzIGEgbW9iaWxlIGFwcCB0aGF0IHVzZXMgRHluYW1pYyBDbGll bnQgUmVnaXN0cmF0aW9uIHRvIGVzdGFibGlzaCBhIGNsaWVudCBzZWNyZXQgY291bnQgYXMgYW4g 4oCcYXV0aGVudGljYXRlZCBjbGllbnTigJ0/Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPkkgdGhpbmsgaXQgc2hvdWxkIGNvdW50LCB0aG8gSSBhbSBub3Qgc3VyZSB3aGF0 IHRoZSBSUyB3b3VsZCBkbyB3aXRoIGl0LiBEeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24gd291 bGQgbGlrZWx5IG5vdCBoYXZlIG11Y2ggdXNlIGZvciB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PkluIHRoZSBjYXNlcyBJIGhhdmUgc2VlbiwgdGhlIGlkZWEgaXMgdGhhdCBhIGNsaWVudCAod2hv c2UgY2xpZW50SUQgaXMgYWxyZWFkeSBrbm93biB0byB0aGUgUlMpIGNhbiBvYnRhaW4gdG9rZW5z IHRocnUgZGlmZmVyZW50IGdyYW50cywgc29tZSBvZiB0aGVtIGNvbmZpZGVudGlhbCBhbmQgb3Ro ZXJzIHB1YmxpYzsgYW5kIHRoZSByZXNvdXJjZSB3YW50cyB0byBrbm93DQogd2hldGhlciB0aGlz IHBhcnRpY3VsYXIgdG9rZW4gd2FzIG9idGFpbmVkIHByb3ZpbmcgdGhlIGlkZW50aXR5IG9mIHRo ZSBjbGllbnQgc28gdGhhdCBpdCBjYW4gZGVjaWRlIHdoZXRoZXIgdG8gZ3JhbnQgZXh0cmEgcHJp dmlsZWdlcyBmb3IgdGhhdCBwYXJ0aWN1bGFyJm5ic3A7Y2xpZW50IGluIHRoZSBjdXJyZW50IGNh bGwuIFRoaXMgc2NlbmFyaW8gZG9lcyBub3QgcmVxdWlyZSB0aGUgZXh0cmEgZGV0YWlscyBhYm91 dCBhdXRoZW50aWNhdGlvbiBtZXRob2Qvc3RyZW5ndGgNCiB5b3UgbWVudGlvbiB0aGF0LCBJIGFn cmVlLCB3b3VsZCBiZSBwcmV0dHkgaGFyZCB0byByZWFjaCBjb25zZW5zdXMgb24uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+VEw7RFI6IHRoZXJlIGlzIGF0IGxlYXN0IG9uZSBzY2VuYXJpbyB0aGF0IGlz IHNhdGlzZmllZCBieSB0aGUgc2ltcGxlIGJvb2wsIGFzIHRoZSBwcmV2aW91cyBrbm93bGVkZ2Ug b2YgdGhlIGNsaWVudCBzb2x2ZXMgdGhlIGlzc3VlcyB5b3UgbWVudGlvbiBvdXQgb2YgYmFuZC4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+YXV0aGVudGljYXRpb24gc2Vz c2lvbiBwcm9wZXJ0aWVzOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDtM ZXQgbWUgdHJ5IGFub3RoZXIgYW5nbGUuIFNheSB0aGF0IEkgcGVyZm9ybSBhbiBhdXRoeiBjb2Rl IGdyYW50IGFza2luZyBmb3IgQVQsIElEX1QgYW5kIFJULSBvYnRhaW5pbmcgQVQnLCBJRF9UJyBh bmQgUlQnLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSB2YWx1ZXMgb2YgYXV0aF90aW1l LCBhY3IgYW5kIGFtciBpbiBBVCcgd2lsbCBiZSB0aGUgc2FtZSBhcyB0aGUgY29ycmVzcG9uZGlu ZyBjbGFpbXMgaW4gSURfVCcuIFdoZW4gdGhlIGNsaWVudCB1c2VzIFJUJyB0byBvYnRhaW4gQVRg TiwgQVQnTiYjNDM7MSBldGMgZXRjLCB0aGUgdmFsdWVzIG9mIHRob3NlIGNsYWltcyB3aWxsIHJl bWFpbiB0aGUgc2FtZSBmb3IgZXZlcnkNCiBBVCduIG9idGFpbmVkIGJ5IFJUJy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5Ob3csIGltYWdpbmUgdGhhdCBzb21ldGhpbmcgaGFwcGVucyAoaWdub3JlIHdo YXQgZm9yIHRoZSB0aW1lIGJlaW5nKSB0aGF0IGNhdXNlcyB0aGUgY2xpZW50IHRvIHBlcmZvcm0g YSBzdGVwIHVwIGF1dGgsIHdoaWNoIHJlcXVpcmVzIHRoZSB1c2VyIHRvIHBlcmZvcm0gaW50ZXJh Y3RpdmUgYXV0aCBoZW5jZSByZXN1bHRzIGluIGEgbmV3IGF1dGh6IGdyYW50LiBUaGUNCiBjbGll bnQgd2lsbCBvYnRhaW4gYSBuZXcgdHVwbGUmbmJzcDsgQVQmcXVvdDssIElEX1QmcXVvdDsgYW5k IFJUJnF1b3Q7LiBUaGUgZXhhY3Qgc2FtZSBydWxlcyBkZXNjcmliZWQgZm9yIHRoZSAnIHR1cGxl IGFwcGx5LCB3aXRoIHRoZSBuZXcgdmFsdWVzIGRldGVybWluZWQgYnkgdGhlIG5ldyBhdXRoZW50 aWNhdGlvbjogQVQmcXVvdDsgYXV0aF90aW1lL2Fjci9hbXIgd2lsbCBiZSB0aGUgc2FtZSBhcyBJ RF9UJnF1b3Q7LCBhbmQgdGhvc2UgdmFsdWVzIHdpbGwgcmVtYWluIHVuY2hhbmdlZCBmb3INCiBl dmVyeSBBVCZxdW90O24gZGVyaXZlZCBieSBSVCZxdW90Oy48YnI+DQpJZiB3ZSB3YW50IHRoaXMg dG8gYXBwbHkgdG8gdGhlIGltcGxpY2l0IGZsb3cgYXMgd2VsbCwgeW91IGNhbiBzdWJzdGl0dXRl IHRoZSBSVCB3aXRoIHRoZSBzZXNzaW9uIGFydGlmYWN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPkRvZXMgdGhhdCBoZWxwIGNsYXJpZnlpbmcgdGhlIGludGVudD8gSWYgeWVzLCBkbyB5b3Ug ZmVlbCB0aGF0IHRoZSBjdXJyZW50IGxhbmd1YWdlIGRvZXMgbm90IGRlc2NyaWJlIHRoaXM/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnVzZSBjYXNlIGZvciBwdXR0aW5nIHRoZXNl IGluIHRoZSBhY2Nlc3MgdG9rZW4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBh bSBub3QgdHJ5aW5nIHRvIGNyZWF0ZSBhIGNvbXBsZXRlIGZyYW1ld29yayBmb3IgaGFuZGxpbmcg c3RlcCB1cCBhbmQgdGhlIGxpa2UsIEkgYW0gdHJ5aW5nIHRvIGNyZWF0ZSBhbiBpbnRlcm9wZXJh YmxlIHJlcHJlc2VudGF0aW9uIG9mIHRob3NlIHZhbHVlcyBubyBtYXR0ZXIgaG93IHRoZXkgd2Vy ZSBvYnRhaW5lZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Db25zaWRlciB0aGUgY2FzZSBp biB3aGljaCBhbiBBUEkgYWxsb3dzIGNlcnRhaW4gb3BlcmF0aW9ucyBvbmx5IGlmIGEgZ2l2ZW4g YW1yIHZhbHVlIGlzIHByZXNlbnQgaW4gdGhlIHRva2VuLiBXaGV0aGVyIHRoYXQgYW1yIGlzIHJl cXVpcmVkIHVwZnJvbnQgb24gZmlyc3QgYXV0aGVudGljYXRpb24sIGFzIHN0ZXAgdXAgb3IgYW55 IG90aGVyIHJlYXNvbiBpcyBvdXQNCiBvZiBzY29wZSBmb3IgdGhpcyBwcm9maWxlIElNTzogdGhl IEFTIG1pZ2h0IGhhdmUgYWxsIHNvcnRzIG9mIGhldXJpc3RpY3MgdGhhdCBkZXRlcm1pbmUgdGhh dCAodXNlciBtZW1iZXJzaGlwIHRvIGEgZ2l2ZW4gZ3JvdXAgb3Igcm9sZTsgZ2VvZmVuY2luZzsg cmlzayBzY29yaW5nOyBldGMpIHRoYXQgaGF2ZSBub3RoaW5nIHRvIGRvIHdpdGggc2NvcGVzIHJl cXVlc3RlZCwgYW5kIGFyZSBub3Qgc3RhdGljYWxseSBkZXRlcm1pbmVkIGJ5IFJTLUFTDQogY29t bXVuaWNhdGlvbnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Tm93LCBJIGFncmVlIHRoYXQg Zm9ybWFsaXppbmcgaG93IGEgUlMgY29tbXVuaWNhdGVzIHRvIHRoZSBBUyB2aWEgdGhlIGNsaWVu dCB0aGUgbmVlZCB0byBzdGVwIHVwIGFuZCBpbiB3aGF0IHRlcm1zIHdvdWxkIGJlIHN1cGVyJm5i c3A7dXNlZnVsOyBob3dldmVyIEkgdGhpbmsgdGhhdCdzIHdlbGwgYmV5b25kIHRoZSBzY29wZSBv ZiB0aGlzIHByb2ZpbGUuLiBWYXJpb3VzIHZlbmRvcnMNCiBhbHJlYWR5IGhhdmUgdGhlaXIgb3du IG1lY2hhbmlzbXMgZm9yIGhhbmRsaW5nIHN0ZXAgdXAgc2lnbmFsaW5nIGZyb20gUlMgdG8gQVMg KEkgYW0gdmVyeSBmYW1pbGlhciB3aXRoIHRoZSBNaWNyb3NvZnQmbmJzcDtvbmUpIGFuZCBhbGwg SSBhbSBsb29raW5nIGZvciBpcyBhIHdheSBvZiBzdGFuZGFyZGl6aW5nIGhvdyB0byByZXByZXNl bnQgdGhlIG91dGNvbWVzLCBzbyB0aGF0IEFQSSBnYXRld2F5cyBhbmQgU0RLIHByb3ZpZGVycyBj YW4gcHJvdmlkZQ0KIHRvb2xzIHRoYXQgd29yayBhY3Jvc3MgdmVuZG9yczsgYW5kIHBvc3NpYmx5 IHJldXNlIHNvbWUgb2YgdGhlIHJlYXNvbmluZyB0aGF0IHdhcyBhbHJlYWR5IGRvbmUgZm9yIGlk X3Rva2Vucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UTDtEUjogSSB0aGluayB3ZSBhcmUgZG9pbmcg c29tZXRoaW5nIHVzZWZ1bCBpbiBmb3JtYWxpemluZyBob3cgdG8gZW1iZWQgdGhhdCBpbmZvIGFu IEFUcyBldmVuIGlmIHdlIGRvbid0IGZvcmNlIHZlbmRvcnMgdG8gZ2l2ZSB1cCB0aGVpciBjdXJy ZW50IG1lY2hhbmlzbXMgdG8gcG9wdWxhdGUgdGhvc2UgdmFsdWVzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5SZWdhcmRpbmcgYWNjZXNzIHRva2VucyB0aGF0IGFyZSB1c2VkIHRv IGFjY2VzcyBkaWZmZXJlbnQgcmVzb3VyY2Ugc2VydmVyczxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5UaGUgaW50ZW50IGlzIHRvIGV4cGxpY2l0bHkgZGlzYWxsb3cgdGhlIHVzZSBvZiBhbiBB VCB3aXRoIG11bHRpcGxlIHJlc291cmNlIHNlcnZlcnMuIElmIGEgY2xpZW50IHdhbnRzIHRvIHRh bGsgd2l0aCAyIGRpZmZlcmVudCBSU2VzLCB0aGUgY2xpZW50IHNob3VsZCBhc2sgZm9yIDIgZGlm ZmVyZW50IEFUcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgc3BlYyBpcyB1bmFtYmlndW91cyBv biB0aGlzIElNTywgaGVyZSdzIHRoZSBsYW5ndWFnZSBJIHVzZSBpbiAwMy4NCjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbjt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3gtc2l6aW5nOmJvcmRl ci1ib3g7Ym9yZGVyLXJhZGl1czo0cHg7b3ZlcmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+ SWYgaXQgcmVjZWl2ZXMgYSByZXF1ZXN0IGZvciBhbiBhY2Nlc3MgdG9rZW4gY29udGFpbmluZyBt b3JlIHRoYW4gb25lPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluO3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgcmVzb3VyY2UgcGFyYW1ldGVyLCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1aW5n IEpXVCBhY2Nlc3MgdG9rZW5zPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluO3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgTVVTVCByZWplY3QgdGhlIHJlcXVlc3QgYW5kIGZhaWwgd2l0aCAmcXVvdDtp bnZhbGlkX3JlcXVlc3QmcXVvdDsgYXMgZGVzY3JpYmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaW4gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tNC4xLjIuMSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0QyMkIzIj5zZWN0aW9uJm5ic3A7NC4xLjIuMSBvZiBb UkZDNjc0OV08L3NwYW4+PC9hPiBvciB3aXRoICZxdW90O2ludmFsaWRfdGFyZ2V0JnF1b3Q7IGFz IGRlZmluZWQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW47d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBpbiBzZWN0aW9uIDIgb2YgWzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzI3JlZi1SZXNvdXJj ZUluZGljYXRvcnMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzNEMjJCMyI+ UmVzb3VyY2VJbmRpY2F0b3JzPC9zcGFuPjwvYT5dLiZuYnNwOyBTZWUgPGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10 b2tlbi1qd3QtMDMjc2VjdGlvbi0yLjIiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6IzNEMjJCMyI+U2VjdGlvbiAyLjI8L3NwYW4+PC9hPiBhbmQgPGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tl bi1qd3QtMDMjc2VjdGlvbi01IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMz RDIyQjMiPlNlY3Rpb24gNTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgZm9yIG1vcmUgZGV0YWlscyBvbiBob3cgdGhpcyBtZWFzdXJl IGVuc3VyZXMgdGhlcmUncyBubyBjb25mdXNpb24gb248L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0byB3aGF0IHJlc291cmNlIHRoZSBhY2Nlc3MgdG9r ZW4gZ3JhbnRlZCBzY29wZXMgYXBwbHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7IElzIGl0IHBvc3NpYmxlIHlvdSBhcmUgcmVmZXJyaW5nIHRvIGFuIG9sZGVyIGRyYWZ0PyZu YnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gTW9uLCBEZWMgMTYsIDIwMTkg YXQgNToyOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmE9PGEgaHJl Zj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQw YW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K MS4gUmVnYXJkaW5nIEF1dGhlbnRpY2F0ZWRDbGllbnQ6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpEb2VzIGEgbW9iaWxlIGFwcCB0aGF0 IHVzZXMgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIHRvIGVzdGFibGlzaCBhIGNsaWVudCBz ZWNyZXQgY291bnQgYXMgYW4g4oCcYXV0aGVudGljYXRlZCBjbGllbnTigJ0/IFdoYXQgaWYgdGhh dCByZWdpc3RyYXRpb24gaW5jbHVkZWQgYW4gYXNzZXJ0aW9uIHNpZ25lZCBieSBhIHRydXN0ZWQg ZW50aXR5IChlLmcuLCBkZXZpY2UgbWFuYWdlbWVudCBzb2Z0d2FyZSkgdXNpbmcgYSBjZXJ0aWZp Y2F0ZSB0aGF0IGhhZA0KIGJlZW4gcHVzaGVkIHRvIHRoZSBkZXZpY2U/IFdpdGhvdXQgc29tZSBr aW5kIG9mIE5JU1QgTG9BLXN0eWxlIGRlZmluaXRpb24gb2Yg4oCcYXV0aGVudGljYXRlZOKAnSwg YSBzaW5nbGUgQm9vbGVhbiDigJxBdXRoZW50aWNhdGVkQ2xpZW504oCdIHZhbHVlIGlzIHRvbyBh bWJpZ3VvdXMgdG8gYmUgdXNlZnVsLiBIb3dldmVyLCBJ4oCZbSBza2VwdGljYWwgdGhhdCB3ZSBj b3VsZCBmaW5kIGNvbnNlbnN1cyBvbiB3aGF0IHRoYXQgZGVmaW5pdGlvbiBzaG91bGQgYmUsDQog YW5kIGl0IG1heSBiZSBiZXR0ZXIgdG8gZGVmaW5lIGNsaWVudCBhbmFsb2dzIHRvIGBhY3JgIGFu ZCBgYW1yYCB0aGF0IHByb3ZpZGUgc3RhbmRhcmQgd2F5cyBvZiBleHByZXNzaW5nIGNsaWVudCBh dXRoZW50aWNhdGlvbiBkZXRhaWxzIHdpdGhvdXQgZ2V0dGluZyBwcmVzY3JpcHRpdmUgYWJvdXQg d2hhdCBraW5kIG9mIGF1dGhlbnRpY2F0aW9uIGlzIOKAnGdvb2QgZW5vdWdoLuKAnTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+ DQoyLiBSZWdhcmRpbmcgYXV0aGVudGljYXRpb24gc2Vzc2lvbiBwcm9wZXJ0aWVzOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KSeKAmW0g Y29uZnVzZWQgYnkgdGhlIGRlZmluaXRpb25zIGdpdmVuIGZvciBgYXV0aF90aW1lYCwgYGFjcmAs IGFuZCBgYW1yYC4gRm9yIGBhdXRoX3RpbWVgLCBpdCBzYXlzOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0K4oCc4oCmaXRz IHZhbHVlIHdpbGwgZWl0aGVyIHJlbWFpbiB0aGUgc2FtZSBmb3IgYWxsIHRoZSBKV1QgYWNjZXNz IHRva2VucyBpc3N1ZWQgd2l0aGluIHRoYXQgc2Vzc2lvbiBvciBiZSB1cGRhdGVkIHRvIHRoZSB0 aW1lIG9mIGxhdGVzdCBhdXRoZW50aWNhdGlvbiBpZiByZWF1dGhlbnRpY2F0aW9uIG9jY3VycmVk IG1pZC1zZXNzaW9u4oCm4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkJ1dCB0aGUg4oCcRm9yIGV4YW1wbGXigJ0gYXQg dGhlIGVuZCBvZiB0aGF0IGRlZmluaXRpb24gaW1wbGllcyB0aGF0IGBhdXRoX3RpbWVgIHdpbGwg bm90IGJlIHVwZGF0ZWQuIFRoZSBkZWZpbml0aW9ucyBmb3IgYGFjcmAgYW5kIGBhbXJgIHNheSB0 aGUgc2FtZSwgYnV0IGFsc28gc2F5IHRoYXQgdGhlIOKAnOKApnNhbWUgY29uc2lkZXJhdGlvbnMg cHJlc2VudGVkIGZvciBhdXRoX3RpbWUgYXBwbHnigKbigJ0gV2hhdOKAmXMgdGhlIGludGVudGlv biBoZXJlOiBhcmUgdGhleQ0KIGZpeGVkLCB1cGRhdGVkLCBvciBpcyBpdCB1cCB0byB0aGUgZGVw bG95bWVudCB0byBkZWNpZGU/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCknigJlkIGxpa2UgdG8gYmV0dGVyIHVuZGVyc3Rh bmQgdGhlIHVzZSBjYXNlIGZvciBwdXR0aW5nIHRoZXNlIGluIHRoZSBhY2Nlc3MgdG9rZW4uIElm IHRoZSBSUyBpcyBtYWtpbmcgYXV0aG9yaXphdGlvbiBkZWNpc2lvbnMgYmFzZWQgb24gdGhlc2Ug Y2xhaW1zLCB0aGF0IGltcGxpZXMgdGhhdCB0aGUgUlMgY2Fubm90IHJlbHkgb24gdGhlIEFTIHRv IGRldGVybWluZSAoZS5nLiwgZnJvbSB0aGUgcmVxdWVzdGVkIHNjb3BlKSB0aGUgcmVxdWlyZWQg YXV0aGVudGljYXRpb24NCiBtZXRob2QocyksIGZyZXNobmVzcywgZXRjLiBJZiB0aGUgQVMgY291 bGQgYmUgcmVsaWVkIHVwb24gZm9yIHRoaXMsIHRoZW4gcHJlc3VtYWJseSBpdCB3b3VsZCBub3Qg aXNzdWUgUlRzIGFuZCBBVHMgZm9yIGEgc2NvcGUgd2l0aG91dCByZXF1aXJpbmcgdGhlIGVuZCB1 c2VyIHRvIG1lZXQgdGhlIGFwcHJvcHJpYXRlIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cy4g SWYgdGhpcyBpcyB0aGUgY2FzZSwgdGhlbiB0aGUgUlMgbXVzdCBoYXZlIGENCiB3YXkgdG8gc2ln bmFsIHRvIHRoZSBjbGllbnQgKGFuZCB0aGVuIHRoZSBBUykgdGhhdCBhIHN0ZXAtdXAgYXV0aGVu dGljYXRpb24gaXMgcmVxdWlyZWQuIElzIHRoZXJlIGFuIGV4aXN0aW5nIG1lY2hhbmlzbSB0aHJv dWdoIHdoaWNoIHRoZXkgY291bGQgZG8gdGhpcz8gQWxsIEkgY2FuIGNvbWUgdXAgd2l0aCBpcyBj cmFtbWluZyB0aGUgaW5mb3JtYXRpb24gaW50byB0aGUgc2NvcGUgYXR0cmlidXRlIG9mIGEgV1dX LUF1dGhlbnRpY2F0ZSBjaGFsbGVuZ2UsDQogYnV0IHRoYXQgaGFzIHRoZSBzYW1lIHNjb3BlIG9w YWNpdHkgdmlvbGF0aW9uIHByb2JsZW0gYXMgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnTigJlzIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zLiBXaXRob3V0IGEgY2xlYXIgd2F5IHRvIGV4cHJlc3MgdGhl IHN0ZXAtdXAgcmVxdWlyZW1lbnRzLCB0aGlzIGZlZWxzIGluY29tcGxldGUuLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQoz LiBSZWdhcmRpbmcgYWNjZXNzIHRva2VucyB0aGF0IGFyZSB1c2VkIHRvIGFjY2VzcyBkaWZmZXJl bnQgcmVzb3VyY2Ugc2VydmVyczo8YnI+DQpSZWFkaW5nIGJldHdlZW4gdGhlIGxpbmVzLCBJICo8 Yj50aGluazwvYj4qIHRoZSBpbnRlbnRpb24gaXMgdGhhdCBhIEpXVCBhY2Nlc3MgdG9rZW4gdGhh dCBpcyBpbnRlbmRlZCB0byBiZSB1c2VkIHRvIGFjY2VzcyB0d28gZGlmZmVyZW50IHJlc291cmNl cyBhdCB0d28gZGlmZmVyZW50IFJTZXMgc2hvdWxkIGxvb2sgc29tZXRoaW5nIGxpa2U6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj57PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6 NS4yNXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mcXVvdDthdWQmcXVv dDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vZ2VuZXJpYy1yZXNvdXJjZS1pbmRpY2F0b3IuZXhh bXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9nZW5lcmljLXJlc291cmNlLWluZGlj YXRvci5leGFtcGxlLmNvbS88L2E+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50OjUuMjVwdCI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+JnF1b3Q7c2NvcGUmcXVvdDs6ICZxdW90 O3Jlc291cmNlX2ZvbyByZXNvdXJjZV9iYXImcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6NS4yNXB0 Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4uLi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxicj4NCkFuZCB0aGUgZXhwZWN0 YXRpb24gaXMgdGhhdCBlYWNoIFJTIHNob3VsZCByZWNvZ25pemUgdGhhdCBnZW5lcmljIGF1ZGll bmNlLiBJcyB0aGlzIGNvcnJlY3Q/IElmIHNvIGl0IHNlZW1zIHRvIGdvIGFnYWluc3QgdGhlIHNw aXJpdCBvZiByZXNvdXJjZSBpbmRpY2F0b3JzIGFzIGluZGljYXRpbmcgdGhlIHRhcmdldCBvciBs b2NhdGlvbiBvZiBhIHJlc291cmNlLiBJdOKAmXMgc3RyZXRjaGluZyB0aGF0IGRlZmluaXRpb24s IGF0IHRoZSB2ZXJ5IGxlYXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpCdXQgYXMgSSBzYWlkLCBJ4oCZbSByZWFkaW5n IGJldHdlZW4gdGhlIGxpbmVzIGhlcmUuIElmIHRoaXMgaXMgdGhlIGludGVudGlvbiwgaXQgc2hv dWxkIGJlIGNsZWFybHkgc3RhdGVkLiBBbHRlcm5hdGl2ZWx5LCByZW1vdmUgKG9yIGNoYW5nZSB0 byBhIFNIT1VMRCkgdGhlIHJlcXVpcmVtZW50IHRoYXQgbXVsdGktdmFsdWUgYGF1ZGAgY2xhaW1z IG11c3Qgb25seSBjb250YWluIGFsaWFzZXMgZm9yIHRoZSBzYW1lIHJlc291cmNlIGluZGljYXRv ci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJlbGxlIFJpY2hh cmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRl bnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbiI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJv bTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ T0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBWaXR0 b3JpbyBCZXJ0b2NjaSAmbHQ7Vml0dG9yaW89PGEgaHJlZj0ibWFpbHRvOjQwYXV0aDAuY29tQGRt YXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIERlY2VtYmVyIDE2LCAyMDE5IGF0IDI6 NTEgUE08YnI+DQo8Yj5UbzogPC9iPklFVEYgb2F1dGggV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpv YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5DYzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aS1kLWFu bm91bmNlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1X R10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzLnR4dDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KRGVhciBhbGwsPGJyPg0KSSBm aW5hbGx5IGZvdW5kIHRoZSB0aW1lIHRvIHB1c2ggYSBuZXcgZHJhZnQgb2YgdGhlIEpXVCBwcm9m aWxlIGZvciBBVHMuIFRoaXMgdmVyc2lvbiBpbmNvcnBvcmF0ZXMgdGhlIGZlZWRiYWNrIGtpbmRs eSBwcm92aWRlZCBieSBCcmlhbiBhbmQgQWFyb24gYXQgSUVURjEwNS48YnI+DQpVbmZvcnR1bmF0 ZWx5IEkgZGlkbid0IGhhdmUgYSBjaGFuY2UgdG8gcGFydGljaXBhdGUgdG8gSUVURjEwNiwgaGVu Y2Ugd2UgZGlkbid0IGRvIG11Y2ggcHJvZ3Jlc3Mgc2luY2UgdGhlbi48YnI+DQpUaGVyZSBhcmUg c3RpbGwgdHdvIGFyZWFzIHdlIGRpZG4ndCBtYW5hZ2UgdG8gcmVhY2ggY29uc2Vuc3VzIG9uOjxi cj4NCjxicj4NCjEuIE1lY2hhbmlzbXMgZm9yIHNpZ25hbGluZyB3aGV0aGVyIHRoZSBBVCB3YXMg b2J0YWluZWQgYnkgYSB1c2VyIG9yIGFuIGFwcGxpY2F0aW9uPGJyPg0KPGJyPg0KVGhpcyBwb2lu dCB3YXMgdGhlIHN1YmplY3Qgb2YgaW50ZW5zZSBkZWJhdGUgb24gdGhlIGxpc3QgbGVhZGluZyB0 byBJRVRGMTA1Li48YnI+DQpPbmUgaW5zaWdodCB0aGF0IGVtZXJnZWQgZnJvbSB0aGUgSUVURjEw NSBkaXNjdXNzaW9uIHdhcyB0aGF0IHRoZSB1c2UgY2FzZSBoZXJlIGlzIG1vcmUgYWJvdXQgd2hl dGhlciB0aGUgQVQgaGFzIGJlZW4gb2J0YWluZWQgdmlhIGEgZ3JhbnQgdGhhdCBhdXRoZW50aWNh dGVkIHRoZSBjbGllbnQgKHJlZ2FyZGxlc3Mgb2Ygd2hhdCBzcGVjaWZpYyBncmFudCB3YXMgdXNl ZCkgdnMgYSBwdWJsaWMgY2xpZW50IGdyYW50LSB0aGF0IGluZm9ybWF0aW9uDQogY2FuIGJlIHJl bGV2YW50IHRvIGEgcmVzb3VyY2UgYXMgaXQgZGV0ZXJtaW5lcyB3aGV0aGVyIHRoZSBpZGVudGl0 eSBvZiB0aGUgY2xpZW50IGNhbiBiZSB1c2VkIGluIGF1dGhvcml6YXRpb24gZGVjaXNpb25zIChp biB0aGUgZm9ybWVyIGNhc2UpIG9yIG5vdCAoaW4gdGhlIHB1YmxpYyBjbGllbnQgY2FzZSkuIElm IHRoYXQncyB0aGUgc2NlbmFyaW8gd2UgYXJlIHRydWx5IGFmdGVyLCBhIHNpbXBsZSwgcG9zc2li bHkgb3B0aW9uYWwgYm9vbGVhbg0KIGNsYWltIChzYXkgQXV0aGVudGljYXRlZENsaWVudCkgd291 bGQgc3VmZmljZS48YnI+DQpOb3RlIGZvciB0aGUgcGVvcGxlIHdobyBkaWRuJ3QgcmVhZCB0aGUg c3BlYzogSSByZW1vdmVkIGFueSByZWZlcmVuY2UgdG8gdGhpcyBhbHJlYWR5IGluIGRyYWZ0LWll dGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMS4gSSB0aGluayB0aGlzIGlzIGFuIGltcG9ydGFu dCBhbmQgdXNlZnVsIGluZm8gYW5kIHN0YW5kYXJkaXppbmcgaXQgd291bGQgYmUgYmVuZWZpY2lh bCBmb3IgbWlkZGxld2FyZSBhbmQgU0RLIGNyZWF0b3JzLCBidXQgdWx0aW1hdGVseQ0KIHRoaXMg aXMgYW4gaW50ZXJvcCBwcm9maWxlIGhlbmNlIGlmIHRoZXJlJ3Mgbm8gc3Ryb25nIGRlc2lyZSB0 byByZWFjaCBhbiBhZ3JlZW1lbnQgaGVyZSwgSSBhbSBhbHNvIE9LIHdpdGggZHJvcHBpbmcgdGhl IG1hdHRlciBhbmQgbm90IGFkZHJlc3MgdGhpcyBmdW5jdGlvbiBpbiB0aGUgc3BlYy48YnI+DQpU byBzdW1tYXJpemUsIEkgaGF2ZSB0d28gcXVlc3Rpb25zIGhlcmU6PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluIj4NCkEuIERvIHdlIGJlbGlldmUgaXQncyB3b3J0aCBpdCB0byBm b3JtYWxpemUgaW4gdGhlIHByb2ZpbGUgYSBtZWNoYW5pc20gdG8gaW5kaWNhdGUgd2hldGhlciB0 aGUgY2xpZW50IHRoIG9idGFpbmVkIHRoZSBBVCBhdXRoZW50aWNhdGVkIGl0c2VsZiB3aXRoIHRo ZSBBUz88YnI+DQpCLiBJZiB5ZXMsIGFyZSB5b3UgT0sgd2lodCBhbiBvcHRpb25hbCBib29sIGNs YWltIGhlcmU/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7 bWFyZ2luLWxlZnQ6LjVpbiI+DQo8YnI+DQoyLiBDbGFpbXMgaW5kaWNhdGluZyBzZXNzaW9uIHBy b3BlcnRpZXM8YnI+DQo8YnI+DQpUaGlzIGlzIG9uZSBhcmVhIHdoZXJlIEkgYW0gZmFyIG1vcmUg cGFzc2lvbmF0ZSBhYm91dCwgYXMgaXQgcmVwcmVzZW50cyBhIGZ1bmRhbWVudGFsIGFzcGVjdCB0 aGF0IHByb2R1Y3Rpb24gc3lzdGVtcyAoYW5kIGluIHBhcnRpY3VsYXIgMXN0IHBhcnR5IHNvbHV0 aW9ucykgYWxyZWFkeSByZWx5IG9uIGluIHRoZSBjdXJyZW50IHByb3ByaWV0YXJ5IEpUVyBBVHMu PGJyPg0KVGhlIHByb2ZpbGUgY3VycmVudGx5IGluY2x1ZGVzIHRoZSBjbGFpbXMgYXV0aF90aW1l LCBhY3IgYW5kIGFtciAtIGNhcHR1cmluZyB0aGUgdmFsdWVzIG9mIHRob3NlIHByb3BlcnRpZXMg YXQgdGhlIHRpbWUgb2YgdGhlIGxhdGVzdCBhdXRoZW50aWNhdGlvbiB0aGUgdXNlciBwZXJmb3Jt ZWQgaW4gdGhlIHNlc3Npb24gdXNlZCB0byBpc3N1ZSB0aGUgY3VycmVudCBBVDogYXQgc2Vzc2lv biBjcmVhdGlvbiwgYXQgYXV0aCBzdGVwIHVwIHRpbWUgYW5kDQogc28gb24uPGJyPg0KVGhvc2Ug YXJlIHZhbHVlcyB0aGF0IEFQSSBuZWVkIGluIG9yZGVyIHRvIG1ha2UgYXV0aG9yaXphdGlvbiBk ZWNpc2lvbnM7IGluIHRoZSBjYXNlIG9mIDFzdCBwYXJ0eSBBUElzLCB0aGUgQVQgaXMgdGhlIG9u bHkgYXJ0aWZhY3QgdGhleSBldmVyIHJlY2VpdmUgaGVuY2UgdGhlcmUgaXMgbm8gb3RoZXIgd2F5 IGZvciBhbiBBUEkgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIGNhbGxlciBwZXJmb3JtZWQgc2F5 IE1GQSBpbiBvcmRlciB0byBvYnRhaW4NCiB0aGUgY3VycmVudCBBVC48YnI+DQpTaW5jZSB0aGUg Zmlyc3QgZHJhZnQsIHNvbWUgcGVvcGxlIHNpZ25hbGVkIGNvbmNlcm5zIGFib3V0IHRoZSBjdXJy ZW50IG1lY2hhbmlzbXMgdGhydSB3aGljaCB0aG9zZSBjbGFpbXMgZ2V0IHRoZWlyIHZhbHVlLiBG b3IgZXhhbXBsZSwgaXQgaGFzIGJlZW4gcHJvcG9zZWQgdG8gbWFpbnRhaW4gdGhlIG9yaWdpbmFs IHZhbHVlcyBvZiBhdXRoX3RpbWUsIGFjciAmYW1wOyBhbXIgYW5kIGludHJvZHVjZSBhZGRpdGlv bmFsIGNsYWltcyB0byBpbmRpY2F0ZQ0KIGNoYW5nZXMgKGxpa2Ugc3RlcHVwKS48YnI+DQpJIGFt IG5vdCBjbGVhciBvbiB3aGF0IGNvbGQgZ28gd3Jvbmcgd2l0aCB0aGUgY3VycmVudCBhcHByb2Fj aCwgaGVuY2UgSSBkb24ndCBoYXZlIGFuIGltbWVkaWF0ZSBncmFzcCBvZiBob3cgY2hhbmdlcyBs aWtlIHRoZSBhYm92ZSB3b3VsZCBoZWxwLjxicj4NCklmIHRoZSBwZW9wbGUgdW5jb21mb3J0YWJs ZSB3aXRoIHRoZSBjdXJyZW50IHByb3Bvc2FsIGNvdWxkIGRldGFpbCB0aGVpciBjb25jZXJuLCB3 ZSBjYW4gYnJhaW5zdG9ybSB3YXlzIHRvIG1ha2UgdGhhdCBpbmZvIGF2YWlsYWJsZSB0byBBUEkg aW4gYSBzYWZlciB3YXkuIFRvIHN1bW1hcml6ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4iPg0KQS4gRG8geW91IGhhdmUgY29uY2VybnMgd2l0aCB0aGUgY3VycmVudCBhdXRo X3RpbWUsIGFybSwgYWNyIHByb3Bvc2FsPyBDYW4geW91IHNwZWxsIHRoZW0gb3V0PyAocGxlYXNl IHJlYWQgdGhlIHJlbGV2YW50IHBhcnRzIG9mIHRoZSBzcGVjIGJlZm9yZSBjaGltaW5nIGluIDop KTxicj4NCkIuIElmIHllcywgd2hhdCBjYW4gd2UgZG8gdG8gbWFrZSB0aGF0IGluZm8gYXZhaWxh YmxlIHRvIFJTcyBpbiBhIHdheSB0aGF0IG1ha2VzIHlvdSBjb21mb3J0YWJsZT88bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDou NWluIj4NCjxicj4NCjxicj4NClRoYW5rczxicj4NCjxicj4NClYuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6LjVpbiI+DQpPbiBNb24sIERlYyAxNiwgMjAxOSBhdCAyOjQ5IFBNICZsdDs8YSBocmVm PSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6NC4uOHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxicj4NCkEgTmV3IEludGVybmV0 LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl Y3Rvcmllcy48YnI+DQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBXZWIgQXV0aG9y aXphdGlvbiBQcm90b2NvbCBXRyBvZiB0aGUgSUVURi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzogSlNPTiBXZWIgVG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBU b2tlbnM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9yJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IFZpdHRvcmlvIEJlcnRvY2NpPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IEZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDog ZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzLnR4dDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7OiAxNjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRlJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE5LTEyLTE2PGJyPg0KPGJyPg0K QWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEg cHJvZmlsZSBmb3IgaXNzdWluZyBPQXV0aCAyLjAgYWNjZXNzPGJyPg0KJm5ic3A7ICZuYnNwO3Rv a2VucyBpbiBKU09OIHdlYiB0b2tlbiAoSldUKSBmb3JtYXQuJm5ic3A7IEF1dGhvcml6YXRpb24g c2VydmVycyBhbmQ8YnI+DQombmJzcDsgJm5ic3A7cmVzb3VyY2Ugc2VydmVycyBmcm9tIGRpZmZl cmVudCB2ZW5kb3JzIGNhbiBsZXZlcmFnZSB0aGlzIHByb2ZpbGUgdG88YnI+DQombmJzcDsgJm5i c3A7aXNzdWUgYW5kIGNvbnN1bWUgYWNjZXNzIHRva2VucyBpbiBpbnRlcm9wZXJhYmxlIG1hbm5l ci48YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3Ig dGhpcyBkcmFmdCBpczo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QvIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3Mt dG9rZW4tand0LzwvYT48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9u cyBhdmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1q d3QtMDM8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDMiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt YWNjZXNzLXRva2VuLWp3dC0wMzwvYT48YnI+DQo8YnI+DQpBIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDM8L2E+PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCjxhIGhyZWY9ImZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRw Li5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_119EE9E631CC4C258FD0D9E8FE389A2Eamazoncom_-- From nobody Tue Dec 17 13:42:22 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F28120128 for ; Tue, 17 Dec 2019 13:42:21 -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, 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=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xnu9sckULowO for ; Tue, 17 Dec 2019 13:42:13 -0800 (PST) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0F312004D for ; Tue, 17 Dec 2019 13:42:13 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id p8so9685462iln.12 for ; Tue, 17 Dec 2019 13:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GXX0wMh+k8LwSrBWlM5BpOt58d8eUiddjgSnpfdAfJU=; b=Y+1LkQacnq3sKtOYsvDBnQIRejJJ3/s08XwrMwIw6W22TAlnL/Ma75xDd3jGgnpwj5 7wmq5cOFX9NW7ZUg9eU3hssL8TdzppjAuWjGVmhXj//KRZw1bf0AmMSknRfbsREg9amd cEpBOjDScOHIKWMV4nEAUzZG147+3lTM6/prupsqmHNNph+v32ieJk0WhFdRX8kYjE4s N9OsSDAPZ65CvuRfSrbd3rVgqJ3EvLDeLqyk3ejFAQAPdCaGG2jhSzS25xDVlY249nzH k6aqPyRgKJkTeR61SPdtJ9JmajcHPaguBGvOAsrdgctaD9tgsoaWZzWEVuHl4Fr65gQZ OwLA== 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=GXX0wMh+k8LwSrBWlM5BpOt58d8eUiddjgSnpfdAfJU=; b=Jckj7Mn/QBheszlFJzyIFZNI6PzMx9YdQgGOYfJgk8hOvpAE+ymjzB5PyhrlXoWidh 5ONs3/SdJVoYd6n7YkMnbd/47V2d8bQ5T3fnhNKsZIdqGzTKBxZTGcnpoMSWuZtlpyd9 bjeph/X9KgjS+YhVmbFRu+/pSRBkKnpztrIfP4mPU9w/P0cWQZ3YjihivkFy+UexHQSe AisUu1T11QOO3Z72eFbb1FwddBA50AiG5lxxLl6+Ruw7Xaad3+gRTMWw15V8cDgGnNKt +c2m0g9u8ZAk3fG9AAAlahUfjwFFhj4xBePwlXPQrVSEsmIGmnKZrBBygozvN74Etwt6 NwlQ== X-Gm-Message-State: APjAAAU/tOO1g+UWcjhEF0vlsIaz6mZi+/seky4qPJ3wp6t9zkgjQMk3 VWJ5nzkD5GyP1FWtBHtTG6k9WtblnQCXB9C2eBa2ZJpVlSKh/g== X-Google-Smtp-Source: APXvYqyHfUzvAIZFSVU9isfTyU62zn7xBeGtY/1AMYNOLdCKO7LFm77zlaUaSOXOamYwWnGJfvBCSjbLsbeXDX86oYk= X-Received: by 2002:a92:d610:: with SMTP id w16mr18277324ilm.283.1576618931815; Tue, 17 Dec 2019 13:42:11 -0800 (PST) MIME-Version: 1.0 References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> <2518B18A-AD93-44E4-88D1-E5F6AAE7B1BB@amazon.com> <16EBA415-06A9-4190-B8C3-EE96771B70BD@amazon.com> In-Reply-To: <16EBA415-06A9-4190-B8C3-EE96771B70BD@amazon.com> From: Vittorio Bertocci Date: Tue, 17 Dec 2019 13:42:00 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: Vittorio Bertocci , IETF oauth WG , "i-d-announce@ietf.org" Content-Type: multipart/alternative; boundary="00000000000060b22b0599ed33fc" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 21:42:21 -0000 --00000000000060b22b0599ed33fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > we should not design fundamental specs that mandate its adoption. Thanks for clarifying! Here I go back to the intent, which is to provide an interoperable projection of ATs in JWT. I think it's reasonable for an interop profile to focus on the simplest case, which also happens to reflect the most common strategy in all the concrete implementations surveyed (nearly all the implementaitons considered had single value aud). This profile does not explicitly disallow vendors from doing something else if they so choose, but current usage does not justify specifying more complex behaviors. there isn=E2=80=99t a lot of value in providing a standard claim, as the c= losed > system could just as easily define a proprietary one. This I do buy, and that's exactly the kind of feedback I was hoping to get. Unless someone resurrects the matter, I'll just drop this particular aspect (which, again, was already not included in the spec). are the existing systems that use these claims reading them from ID Tokens, > or from JWT access tokens? Both Are these typically clients that are accessing their own RSes, using > tokens vended by an IdP? > Not the most frequent case. The case I have seen most frequently was with custom clients accessing a vendor API- hence client and API owned by two different entities (tho the programming model was dictated by the vendor itself, hence the client developer had limited freedom). Note that RSes receiving acr/amr might not necessarily have a strict fail/succeed reaction to the incoming values: for example, the auth level might determine whether the results returned include or exclude certain elements. On Tue, Dec 17, 2019 at 1:12 PM Richard Backman, Annabelle < richanna@amazon.com> wrote: > > That's a pretty strong statement :) > > > > One I should=E2=80=99ve clarified. =F0=9F=98=83 I don=E2=80=99t mean that= the one-RS-per-AT model > is not used at all, just that it is not universal and comes with real, > practical tradeoffs that may not be appropriate for all use cases. > Consequently, we should not design fundamental specs that mandate its > adoption. > > > > > > > =E2=80=A6knowledge of that level isn't necessary. > > > > Either the RS and AS have a shared understanding of that level, or the RS > is trusting the AS to decide what =E2=80=9CAuthenticatedClient=E2=80=9D m= eans, and set it > accordingly. The latter requires that the RS only supports ASes that have= a > shared (or substantially similar) understanding of what that level is, > which is unlikely outside of a closed system. In that case, there isn=E2= =80=99t a > lot of value in providing a standard claim, as the closed system could ju= st > as easily define a proprietary one. > > > > > Could you expand on a concrete scenario that would lead to an > antipattern because of the presence of those claims in the profile? > > > > If I could, then I wouldn=E2=80=99t be concerned about defining this piec= e of the > puzzle without the rest of it. =F0=9F=98=83 > > > > In your experience, are the existing systems that use these claims readin= g > them from ID Tokens, or from JWT access tokens? Are these typically clien= ts > that are accessing their own RSes, using tokens vended by an IdP? (e.g., = a > SaaS product that gets tokens from a hosted IDaaS product) I ask because > OIDC clients can specifiy max_age and acr_values, and if client and RS ar= e > owned by the same entity then they can do whatever proprietary thing they > want to indicate the reason for an authorization failure. > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Vittorio Bertocci > *Date: *Tuesday, December 17, 2019 at 12:04 PM > *To: *"Richard Backman, Annabelle" > *Cc: *Vittorio Bertocci , IETF oau= th > WG , "i-d-announce@ietf.org" > *Subject: *Re: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: > draft-ietf-oauth-access-token-jwt-03.txt > > > > The one-RS-per-AT model is an ideal that simply doesn=E2=80=99t match rea= lity. > > That's a pretty strong statement :) I have worked with a very large numbe= r > of developers, on a very large number of applications. I don't dispute th= at > your experience might be different, but the one AT per RS is daily realit= y > for hundreds of thousands of apps in production today. That's real by any > measure of reality. The fact that AD offers RTs that behave like TGTs mak= es > it possible. > > RAR is an interesting development, but it's in the inception phase. The > aud and scopes claims are already in nearly all the proprietary JWT > implementations in production today, as shown in the research I presented > when the draft was adopted by the WG, hence it seems natural to include > them in an interop profile. > > Nothing prevents us from developing it further as new approaches gain > traction on the market, but for the time being I think the value of this > would be to bring some order in existing implementations and contain abus= es > such as id_tokens used in lieu of access tokens today. > > > > I=E2=80=99m skeptical of the idea that there is just one level of client = identity > proofing that RSes might care about. > > In the scenario that led me to include this item in the discussion, > knowledge of that level isn't necessary. Again, I agree it would be usefu= l > to define those levels, but I don't think it would be in scope here. If > inclusion of that info in the JWT AT would be conditional to do all that > work, I'd much rather drop that aspect in favor of making faster progress= . > > > > Without taking the whole picture into account, there is significant risk > that we will define something that turns out to be woefully insufficient > (or worse, establishes an anti-pattern). That said, I agree that it=E2=80= =99s > probably not appropriate for this draft, and recommend dropping these > claims. They can always be defined in a separate draft, along with the > other elements necessary to communicate step-up requirements. > > Could you expand on a concrete scenario that would lead to an antipattern > because of the presence of those claims in the profile? > > There is already logic out there predicated on those claim values, > precisely because ID_token defines them and vendors latch onto them. I am > concerned that if we don't include those claims in the profile, people wi= ll > simply keep using ID_tokens for calling APIs. > > > > > > On Tue, Dec 17, 2019 at 11:39 AM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > > In any case the intent was always to only allow a singe resource per AT= =E2=80=A6 > > > > My confusion actually comes from the last paragraph of =C2=A73, where it = says > =E2=80=9CIf a scope parameter is present in the request, the authorizatio= n server > SHOULD use it to infer the value of the default resource indicator to be > used in the aud claim.=E2=80=9D I interpreted that to leave room for an A= S > inferring the same =E2=80=9Cgeneric=E2=80=9D resource indicator for resou= rces served by > different RSes. The one-RS-per-AT model is an ideal that simply doesn=E2= =80=99t > match reality. Clients don=E2=80=99t want to have to juggle a bunch of di= fferent > tokens, nor should they need to. I=E2=80=99m coming to think that we shou= ldn=E2=80=99t > actually use `aud` and `scope` in JWT ATs at all, and instead adopt the > structure RAR defines used for the `authorization_details` parameter (I > think some iteration is required, but it seems natural for these two to > describe authorizations in the same or compatible ways). > > > > > > > =E2=80=A6the resource wants to know whether this particular token was o= btained > proving the identity of the client=E2=80=A6 > > > > I=E2=80=99m skeptical of the idea that there is just one level of client = identity > proofing that RSes might care about. There might be some clear lines that > can be drawn, but we should be explicit about what those lines represent, > e.g., =E2=80=9Cclient authenticated using pre-established credential=E2= =80=9D, =E2=80=9Cclient is > running on end user-controlled device=E2=80=9D, etc. > > > > > > > I am not trying to create a complete framework for handling step up and > the like, I am trying to create an interoperable representation of those > values no matter how they were obtained. > > > > Without taking the whole picture into account, there is significant risk > that we will define something that turns out to be woefully insufficient > (or worse, establishes an anti-pattern). That said, I agree that it=E2=80= =99s > probably not appropriate for this draft, and recommend dropping these > claims. They can always be defined in a separate draft, along with the > other elements necessary to communicate step-up requirements. > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Vittorio Bertocci > *Date: *Monday, December 16, 2019 at 9:31 PM > *To: *"Richard Backman, Annabelle" > *Cc: *IETF oauth WG , Vittorio Bertocci < > Vittorio@auth0.com>, "i-d-announce@ietf.org" > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: > draft-ietf-oauth-access-token-jwt-03.txt > > > > Re: aliases, I see where the confusion is coming from! > > I updated the request section, but the session 2.2 data structure still > mentions the aliases. That should be cleaned up as well. > > In any case the intent was always to only allow a singe resource per AT, > the alias list was only for helping in cases where an AS identifies the > same resource thru multiple IDs and the actual aud value depends on what = ID > the client requested. However we discussed this with Brian and he convinc= ed > me that it was just too ambiguous- your remark reinforces that impression= . > I=E2=80=99ll clean up 2.2 and eliminate references to aliases from there = as well. > > Thanks! > > > > > > On Mon, Dec 16, 2019 at 20:19 Vittorio Bertocci > wrote: > > Thanks Annabelle. > > > > Does a mobile app that uses Dynamic Client Registration to establish a > client secret count as an =E2=80=9Cauthenticated client=E2=80=9D? > > I think it should count, tho I am not sure what the RS would do with it. > Dynamic client registration would likely not have much use for this. > > In the cases I have seen, the idea is that a client (whose clientID is > already known to the RS) can obtain tokens thru different grants, some of > them confidential and others public; and the resource wants to know wheth= er > this particular token was obtained proving the identity of the client so > that it can decide whether to grant extra privileges for that > particular client in the current call. This scenario does not require the > extra details about authentication method/strength you mention that, I > agree, would be pretty hard to reach consensus on. > > TL;DR: there is at least one scenario that is satisfied by the simple > bool, as the previous knowledge of the client solves the issues you menti= on > out of band. > > > > authentication session properties: > > Let me try another angle. Say that I perform an authz code grant asking > for AT, ID_T and RT- obtaining AT', ID_T' and RT'. > > The values of auth_time, acr and amr in AT' will be the same as the > corresponding claims in ID_T'. When the client uses RT' to obtain AT`N, > AT'N+1 etc etc, the values of those claims will remain the same for every > AT'n obtained by RT'. > > Now, imagine that something happens (ignore what for the time being) that > causes the client to perform a step up auth, which requires the user to > perform interactive auth hence results in a new authz grant. The client > will obtain a new tuple AT", ID_T" and RT". The exact same rules describ= ed > for the ' tuple apply, with the new values determined by the new > authentication: AT" auth_time/acr/amr will be the same as ID_T", and thos= e > values will remain unchanged for every AT"n derived by RT". > If we want this to apply to the implicit flow as well, you can substitute > the RT with the session artifact. > > Does that help clarifying the intent? If yes, do you feel that the curren= t > language does not describe this? > > > > use case for putting these in the access token > > I am not trying to create a complete framework for handling step up and > the like, I am trying to create an interoperable representation of those > values no matter how they were obtained. > > Consider the case in which an API allows certain operations only if a > given amr value is present in the token. Whether that amr is required > upfront on first authentication, as step up or any other reason is out of > scope for this profile IMO: the AS might have all sorts of heuristics tha= t > determine that (user membership to a given group or role; geofencing; ris= k > scoring; etc) that have nothing to do with scopes requested, and are not > statically determined by RS-AS communications. > > Now, I agree that formalizing how a RS communicates to the AS via the > client the need to step up and in what terms would be super useful; howev= er > I think that's well beyond the scope of this profile.. Various vendors > already have their own mechanisms for handling step up signaling from RS = to > AS (I am very familiar with the Microsoft one) and all I am looking for i= s > a way of standardizing how to represent the outcomes, so that API gateway= s > and SDK providers can provide tools that work across vendors; and possibl= y > reuse some of the reasoning that was already done for id_tokens. > > TL;DR: I think we are doing something useful in formalizing how to embed > that info an ATs even if we don't force vendors to give up their current > mechanisms to populate those values. > > > > Regarding access tokens that are used to access different resource server= s > > The intent is to explicitly disallow the use of an AT with multiple > resource servers. If a client wants to talk with 2 different RSes, the > client should ask for 2 different ATs. > > The spec is unambiguous on this IMO, here's the language I use in 03. > > > > If it receives a request for an access token containing more than one > > resource parameter, an authorization server issuing JWT access tokens > > MUST reject the request and fail with "invalid_request" as described > > in section 4.1.2.1 of [RFC6749] or with "invalid_target" as defined > > in section 2 of [ResourceIndicators ]. See Se= ction 2.2 and Section 5 > > for more details on how this measure ensures there's no confusion on > > to what resource the access token granted scopes apply. > > Is it possible you are referring to an older draft? > > > > > > On Mon, Dec 16, 2019 at 5:28 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > 1. Regarding AuthenticatedClient: > > Does a mobile app that uses Dynamic Client Registration to establish a > client secret count as an =E2=80=9Cauthenticated client=E2=80=9D? What if= that registration > included an assertion signed by a trusted entity (e.g., device management > software) using a certificate that had been pushed to the device? Without > some kind of NIST LoA-style definition of =E2=80=9Cauthenticated=E2=80=9D= , a single Boolean > =E2=80=9CAuthenticatedClient=E2=80=9D value is too ambiguous to be useful= . However, I=E2=80=99m > skeptical that we could find consensus on what that definition should be, > and it may be better to define client analogs to `acr` and `amr` that > provide standard ways of expressing client authentication details without > getting prescriptive about what kind of authentication is =E2=80=9Cgood e= nough.=E2=80=9D > > > > 2. Regarding authentication session properties: > > I=E2=80=99m confused by the definitions given for `auth_time`, `acr`, and= `amr`. > For `auth_time`, it says: > > > > =E2=80=9C=E2=80=A6its value will either remain the same for all the JWT a= ccess tokens > issued within that session or be updated to the time of latest > authentication if reauthentication occurred mid-session=E2=80=A6=E2=80=9D > > > > But the =E2=80=9CFor example=E2=80=9D at the end of that definition impli= es that > `auth_time` will not be updated. The definitions for `acr` and `amr` say > the same, but also say that the =E2=80=9C=E2=80=A6same considerations pre= sented for > auth_time apply=E2=80=A6=E2=80=9D What=E2=80=99s the intention here: are = they fixed, updated, or is > it up to the deployment to decide? > > > > I=E2=80=99d like to better understand the use case for putting these in t= he access > token. If the RS is making authorization decisions based on these claims, > that implies that the RS cannot rely on the AS to determine (e.g., from t= he > requested scope) the required authentication method(s), freshness, etc. I= f > the AS could be relied upon for this, then presumably it would not issue > RTs and ATs for a scope without requiring the end user to meet the > appropriate authentication requirements. If this is the case, then the RS > must have a way to signal to the client (and then the AS) that a step-up > authentication is required. Is there an existing mechanism through which > they could do this? All I can come up with is cramming the information in= to > the scope attribute of a WWW-Authenticate challenge, but that has the sam= e > scope opacity violation problem as described in this draft=E2=80=99s Secu= rity > Considerations. Without a clear way to express the step-up requirements, > this feels incomplete.. > > > > 3. Regarding access tokens that are used to access different resource > servers: > Reading between the lines, I **think** the intention is that a JWT access > token that is intended to be used to access two different resources at tw= o > different RSes should look something like: > > > > { > > "aud": "https://generic-resource-indicator.example.com/", > > "scope": "resource_foo resource_bar", > > ... > > } > > > And the expectation is that each RS should recognize that generic > audience. Is this correct? If so it seems to go against the spirit of > resource indicators as indicating the target or location of a resource. > It=E2=80=99s stretching that definition, at the very least. > > > > But as I said, I=E2=80=99m reading between the lines here. If this is the > intention, it should be clearly stated. Alternatively, remove (or change = to > a SHOULD) the requirement that multi-value `aud` claims must only contain > aliases for the same resource indicator. > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Vittorio Bertocci > > *Date: *Monday, December 16, 2019 at 2:51 PM > *To: *IETF oauth WG > *Cc: *"i-d-announce@ietf.org" > *Subject: *Re: [OAUTH-WG] I-D Action: > draft-ietf-oauth-access-token-jwt-03.txt > > > > Dear all, > I finally found the time to push a new draft of the JWT profile for ATs. > This version incorporates the feedback kindly provided by Brian and Aaron > at IETF105. > Unfortunately I didn't have a chance to participate to IETF106, hence we > didn't do much progress since then. > There are still two areas we didn't manage to reach consensus on: > > 1. Mechanisms for signaling whether the AT was obtained by a user or an > application > > This point was the subject of intense debate on the list leading to > IETF105.. > One insight that emerged from the IETF105 discussion was that the use cas= e > here is more about whether the AT has been obtained via a grant that > authenticated the client (regardless of what specific grant was used) vs = a > public client grant- that information can be relevant to a resource as it > determines whether the identity of the client can be used in authorizatio= n > decisions (in the former case) or not (in the public client case). If > that's the scenario we are truly after, a simple, possibly optional boole= an > claim (say AuthenticatedClient) would suffice. > Note for the people who didn't read the spec: I removed any reference to > this already in draft-ietf-oauth-access-token-jwt-01. I think this is an > important and useful info and standardizing it would be beneficial for > middleware and SDK creators, but ultimately this is an interop profile > hence if there's no strong desire to reach an agreement here, I am also O= K > with dropping the matter and not address this function in the spec. > To summarize, I have two questions here: > > A. Do we believe it's worth it to formalize in the profile a mechanism to > indicate whether the client th obtained the AT authenticated itself with > the AS? > B. If yes, are you OK wiht an optional bool claim here? > > > 2. Claims indicating session properties > > This is one area where I am far more passionate about, as it represents a > fundamental aspect that production systems (and in particular 1st party > solutions) already rely on in the current proprietary JTW ATs. > The profile currently includes the claims auth_time, acr and amr - > capturing the values of those properties at the time of the latest > authentication the user performed in the session used to issue the curren= t > AT: at session creation, at auth step up time and so on. > Those are values that API need in order to make authorization decisions; > in the case of 1st party APIs, the AT is the only artifact they ever > receive hence there is no other way for an API to determine whether the > caller performed say MFA in order to obtain the current AT. > Since the first draft, some people signaled concerns about the current > mechanisms thru which those claims get their value. For example, it has > been proposed to maintain the original values of auth_time, acr & amr and > introduce additional claims to indicate changes (like stepup). > I am not clear on what cold go wrong with the current approach, hence I > don't have an immediate grasp of how changes like the above would help. > If the people uncomfortable with the current proposal could detail their > concern, we can brainstorm ways to make that info available to API in a > safer way. To summarize: > > A. Do you have concerns with the current auth_time, arm, acr proposal? Ca= n > you spell them out? (please read the relevant parts of the spec before > chiming in :)) > B. If yes, what can we do to make that info available to RSs in a way tha= t > makes you comfortable? > > > > Thanks > > V. > > > > On Mon, Dec 16, 2019 at 2:49 PM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IET= F. > > Title : JSON Web Token (JWT) Profile for OAuth 2.0 > Access Tokens > Author : Vittorio Bertocci > Filename : draft-ietf-oauth-access-token-jwt-03.txt > Pages : 16 > Date : 2019-12-16 > > Abstract: > This specification defines a profile for issuing OAuth 2.0 access > tokens in JSON web token (JWT) format. Authorization servers and > resource servers from different vendors can leverage this profile to > issue and consume access tokens in interoperable manner. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-03 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-0= 3 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp..ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00000000000060b22b0599ed33fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
we shoul= d not design fundamental specs that mandate its adoption.=C2=A0=C2=A0
Thanks for clarifying! Here I go back to the intent, which is t= o provide an interoperable projection of ATs in JWT. I think it's reaso= nable for an interop profile to focus on the simplest case, which also happ= ens to reflect the most common strategy in all the concrete implementations= surveyed (nearly all the implementaitons considered had single value aud).= This profile does not explicitly disallow vendors from doing something=C2= =A0else if they so choose, but current usage does not justify specifying mo= re complex behaviors.

=C2=A0there isn=E2=80=99t a lot of value in providing a st= andard claim, as the closed system could just as easily define a proprietar= y one.=C2=A0
This I do buy, and that's exactly the kin= d of feedback I was hoping to get.=C2=A0 Unless someone resurrects the matt= er, I'll just drop this particular aspect (which, again, was already no= t included in the spec).

are the existing systems that use these claims reading = them from ID Tokens, or from JWT access tokens?=C2=A0=C2=A0
Both=C2=A0

=C2=A0Are these typically clients that are accessing their own RSes= , using tokens vended by an IdP?
Not the most frequent= case. The case I have seen most frequently was with custom clients accessi= ng a vendor API- hence client and API owned by two different entities (tho = the programming model was dictated by the vendor itself, hence the client d= eveloper had limited freedom).
Note that RSes receiving acr/amr m= ight not necessarily have a strict fail/succeed reaction to the incoming va= lues: for example, the auth level might determine whether the results retur= ned include or exclude certain elements.=C2=A0

On Tue, Dec 17, 2019 at= 1:12 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

> That's a pretty strong statement :)=C2=A0

=C2=A0

One I should=E2=80=99ve clarified. =F0=9F=98=83 I don=E2=80=99t mean that the one-RS-per-AT model is no= t used at all, just that it is not universal and comes with real, practical= tradeoffs that may not be appropriate for all use cases. Consequently, we = should not design fundamental specs that mandate its adoption.

=C2=A0

=C2=A0

> =E2=80=A6knowledge of that level isn't nece= ssary.

=C2=A0

Either the RS and AS have a shared understanding of = that level, or the RS is trusting the AS to decide what =E2=80=9CAuthentica= tedClient=E2=80=9D means, and set it accordingly. The latter requires that = the RS only supports ASes that have a shared (or substantially similar) understanding of what that level is, which is unlikely outside of= a closed system. In that case, there isn=E2=80=99t a lot of value in provi= ding a standard claim, as the closed system could just as easily define a p= roprietary one.

=C2=A0

> Could you expand on a concrete scenario that wo= uld lead to an antipattern because of the presence of those claims in the p= rofile?

=C2=A0

If I could, then I wouldn=E2=80=99t be concerned abo= ut defining this piece of the puzzle without the rest of it. =F0=9F=98=83

=C2=A0

In your experience, are the existing systems that us= e these claims reading them from ID Tokens, or from JWT access tokens? Are = these typically clients that are accessing their own RSes, using tokens ven= ded by an IdP? (e.g., a SaaS product that gets tokens from a hosted IDaaS product) I ask because OIDC clients c= an specifiy max_age and acr_values, and if client and RS are owned by the s= ame entity then they can do whatever proprietary thing they want to indicat= e the reason for an authorization failure.

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Bac= kman

AWS Identity

=C2=A0

=C2=A0

From: = Vittorio Bertocci <= ;Vittorio@auth0.com= >
Date: Tuesday, December 17, 2019 at 12:04 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>, IETF o= auth WG <oauth@ietf.= org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Subject: Re: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ie= tf-oauth-access-token-jwt-03.txt

=C2=A0

The one-RS-per-AT model is an ideal that simply does= n=E2=80=99t match reality.=C2=A0=C2=A0

That's a pretty strong statement :) I have worke= d with a very large number of developers, on a very large number of applica= tions. I don't dispute that your experience might be different, but the= one AT per RS is daily reality for hundreds of thousands of apps in production today. That's real by any measure o= f reality. The fact that AD offers RTs that behave like TGTs makes it possi= ble.=C2=A0

RAR is an interesting development, but it's in t= he inception phase. The aud and scopes claims are already in nearly all the= proprietary JWT implementations in production today, as shown in the resea= rch I presented when the draft was adopted by the WG, hence it seems natural to include them in an interop profile.

Nothing prevents us from developing it further as ne= w approaches=C2=A0gain traction on the market, but for the time being I thi= nk the value of this would be to bring some order in existing implementatio= ns=C2=A0and contain abuses such as id_tokens used in lieu of access tokens today.

=C2=A0

I=E2=80=99m skeptical of the idea that there is just= one level of client identity proofing that RSes might care about.=C2=A0=

In the scenario that led me to include this item in = the discussion, knowledge of that level isn't necessary. Again, I agree= it would be useful to define those levels, but I don't think it would = be in scope here. If inclusion of that info in the JWT AT would be conditional to do all that work, I'd much rathe= r drop that aspect in favor of making faster progress.

=C2=A0

Without taking the whole picture into account, there= is significant risk that we will define something that turns out to be woe= fully insufficient (or worse, establishes an anti-pattern). That said, I ag= ree that it=E2=80=99s probably not appropriate for this draft, and recommend dropping these claims. They can always be de= fined in a separate draft, along with the other elements necessary to commu= nicate step-up requirements.=C2=A0

Could you expand on a concrete scenario that would l= ead to an antipattern because of the presence of those claims in the profil= e?

There is already logic out there predicated on those= claim values, precisely because ID_token defines them and vendors latch on= to them. I am concerned that if we don't include those claims in the pr= ofile, people will simply keep using ID_tokens for calling APIs.

=C2=A0

=C2=A0

On Tue, Dec 17, 2019 at 11:39 AM Richard Backman, An= nabelle <richan= na@amazon.com> wrote:

> In any case the intent was always to only allow= a singe resource per AT=E2=80=A6

=C2=A0

My confusion actually comes from the last paragraph = of =C2=A73, where it says =E2=80=9CIf a scope parameter is present in the r= equest, the authorization server SHOULD use it to infer the value of the default resource indicator to be used in the aud claim.=E2=80=9D I = interpreted that to leave room for an AS inferring the same =E2=80=9Cgeneri= c=E2=80=9D resource indicator for resources served by different RSes. The o= ne-RS-per-AT model is an ideal that simply doesn=E2=80=99t match reality. Clients don=E2=80=99t want to have to juggle a bunch of different= tokens, nor should they need to. I=E2=80=99m coming to think that we shoul= dn=E2=80=99t actually use `aud` and `scope` in JWT ATs at all, and instead = adopt the structure RAR defines used for the `authorization_details` parameter (I think some iteration is required, but it seems natural for th= ese two to describe authorizations in the same or compatible ways).<= u>

=C2=A0

=C2=A0

> =E2=80=A6the resource wants to know whether thi= s particular token was obtained proving the identity of the client=E2=80=A6=

=C2=A0

I=E2=80=99m skeptical of the idea that there is just= one level of client identity proofing that RSes might care about. There mi= ght be some clear lines that can be drawn, but we should be explicit about what those lines represent, e.g., =E2=80=9Cclient authentic= ated using pre-established credential=E2=80=9D, =E2=80=9Cclient is running = on end user-controlled device=E2=80=9D, etc.

=C2=A0

=C2=A0

> I am not trying to create a complete framework = for handling step up and the like, I am trying to create an interoperable r= epresentation of those values no matter how they were obtained.

=C2=A0

Without taking the whole picture into account, there= is significant risk that we will define something that turns out to be woe= fully insufficient (or worse, establishes an anti-pattern). That said, I agree that it=E2=80=99s probably not appropriate for this dra= ft, and recommend dropping these claims. They can always be defined in a se= parate draft, along with the other elements necessary to communicate step-u= p requirements.

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Bac= kman

AWS Identity

=C2=A0

=C2=A0

From: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.iet= f.org>
Date: Monday, December 16, 2019 at 9:31 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: IETF oauth WG <oauth@ietf.org>, Vittorio Bertocci <Vittorio@auth0.com>, "i-d-announce@ietf.org" <i-d-announc= e@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-o= auth-access-token-jwt-03.txt

=C2=A0

Re: aliases, I see where the confusion is coming from!

I updated the request section, but the session 2.2 data structure still men= tions the aliases. That should be cleaned up as well.=C2=A0

In any case the intent was always to only allow a singe resource per AT, th= e alias list was only for helping in cases where an AS identifies the same = resource thru multiple IDs and the actual aud value depends on what ID the = client requested. However we discussed this with Brian and he convinced me that it was just too ambiguous- your r= emark reinforces that impression. I=E2=80=99ll clean up 2.2 and eliminate r= eferences to aliases from there as well.

Thanks!

=C2=A0

=C2=A0

On Mon, Dec 16, 2019 at 20:19 Vittorio Bertocci <Vittorio@auth0.com> wrote:

Thanks Annabelle.

=C2=A0

Does a mobile app that uses Dynamic Client Registration to establish a clie= nt secret count as an =E2=80=9Cauthenticated client=E2=80=9D?=C2=A0=C2=A0

I think it should count, tho I am not sure what the RS would do with it. Dy= namic client registration would likely not have much use for this.

In the cases I have seen, the idea is that a client (whose clientID is alre= ady known to the RS) can obtain tokens thru different grants, some of them = confidential and others public; and the resource wants to know whether this= particular token was obtained proving the identity of the client so that it can decide whether to grant extra pr= ivileges for that particular=C2=A0client in the current call. This scenario= does not require the extra details about authentication method/strength yo= u mention that, I agree, would be pretty hard to reach consensus on.

TL;DR: there is at least one scenario that is satisfied by the simple bool,= as the previous knowledge of the client solves the issues you mention out = of band.=C2=A0

=C2=A0

authentication session properties:=C2=A0

=C2=A0Let me try another angle. Say that I perform an authz code grant aski= ng for AT, ID_T and RT- obtaining AT', ID_T' and RT'.=C2=A0<= /u>

The values of auth_time, acr and amr in AT' will be the same as the cor= responding claims in ID_T'. When the client uses RT' to obtain AT`N= , AT'N+1 etc etc, the values of those claims will remain the same for e= very AT'n obtained by RT'.

Now, imagine that something happens (ignore what for the time being) that c= auses the client to perform a step up auth, which requires the user to perf= orm interactive auth hence results in a new authz grant. The client will ob= tain a new tuple=C2=A0 AT", ID_T" and RT". The exact same rules described for the ' tuple apply, with t= he new values determined by the new authentication: AT" auth_time/acr/= amr will be the same as ID_T", and those values will remain unchanged = for every AT"n derived by RT".
If we want this to apply to the implicit flow as well, you can substitute t= he RT with the session artifact.=C2=A0

Does that help clarifying the intent? If yes, do you feel that the current = language does not describe this?

=C2=A0

use case for putting these in the access token=C2=A0

I am not trying to create a complete framework for handling step up and the= like, I am trying to create an interoperable representation of those value= s no matter how they were obtained.=C2=A0

Consider the case in which an API allows certain operations only if a given= amr value is present in the token. Whether that amr is required upfront on= first authentication, as step up or any other reason is out of scope for t= his profile IMO: the AS might have all sorts of heuristics that determine that (user membership to a given gr= oup or role; geofencing; risk scoring; etc) that have nothing to do with sc= opes requested, and are not statically determined by RS-AS communications.= =C2=A0

Now, I agree that formalizing how a RS communicates to the AS via the clien= t the need to step up and in what terms would be super=C2=A0useful; however= I think that's well beyond the scope of this profile.. Various vendors= already have their own mechanisms for handling step up signaling from RS to AS (I am very familiar with the Microsoft=C2= =A0one) and all I am looking for is a way of standardizing how to represent= the outcomes, so that API gateways and SDK providers can provide tools tha= t work across vendors; and possibly reuse some of the reasoning that was already done for id_tokens.

TL;DR: I think we are doing something useful in formalizing how to embed th= at info an ATs even if we don't force vendors to give up their current = mechanisms to populate those values.

=C2=A0

Regarding access tokens that are used to access different resource servers<= u>

The intent is to explicitly disallow the use of an AT with multiple resourc= e servers. If a client wants to talk with 2 different RSes, the client shou= ld ask for 2 different ATs.

The spec is unambiguous on this IMO, here's the language I use in 03. <= u>

=C2=A0

If it receives a request for an access t=
oken containing more than one
=C2=A0=C2=A0 resour=
ce parameter, an authorization server issuing JWT access tokens
=C2=A0=C2=A0 MUST r=
eject the request and fail with "invalid_request" as described
=C2=A0=C2=A0 in section=C2=A04.1.2.1 of =
[RFC6749] or with "invalid_target" as defined
=C2=A0=C2=A0 in sec=
tion 2 of [ResourceIndicators].=C2=A0 See Sec=
tion 2.2 and Section 5
=C2=A0=C2=A0 for mo=
re details on how this measure ensures there's no confusion on
=C2=A0=C2=A0 to wha=
t resource the access token granted scopes apply.

=C2=A0 Is it possible you are referring to an older draft?=C2=A0=C2=A0

=C2=A0

=C2=A0

On Mon, Dec 16, 2019 at 5:28 PM Richard Backman, Annabelle <richanna=3D<= a href=3D"mailto:40amazon.com@dmarc.ietf.org" target=3D"_blank">40amazon.co= m@dmarc.ietf.org> wrote:

1. Regarding AuthenticatedClient:

Does a mobile app that uses Dynamic Client Registration to establish a clie= nt secret count as an =E2=80=9Cauthenticated client=E2=80=9D? What if that = registration included an assertion signed by a trusted entity (e.g., device= management software) using a certificate that had been pushed to the device? Without some kind of NIST LoA-style definition = of =E2=80=9Cauthenticated=E2=80=9D, a single Boolean =E2=80=9CAuthenticated= Client=E2=80=9D value is too ambiguous to be useful. However, I=E2=80=99m s= keptical that we could find consensus on what that definition should be, and it may be better to define client analogs to `acr` and `amr` that prov= ide standard ways of expressing client authentication details without getti= ng prescriptive about what kind of authentication is =E2=80=9Cgood enough.= =E2=80=9D

=C2=A0

2. Regarding authentication session properties:

I=E2=80=99m confused by the definitions given for `auth_time`, `acr`, and `= amr`. For `auth_time`, it says:

=C2=A0

=E2=80=9C=E2=80=A6its value will either remain the same for all the JWT acc= ess tokens issued within that session or be updated to the time of latest a= uthentication if reauthentication occurred mid-session=E2=80=A6=E2=80=9D=

=C2=A0

But the =E2=80=9CFor example=E2=80=9D at the end of that definition implies= that `auth_time` will not be updated. The definitions for `acr` and `amr` = say the same, but also say that the =E2=80=9C=E2=80=A6same considerations p= resented for auth_time apply=E2=80=A6=E2=80=9D What=E2=80=99s the intention= here: are they fixed, updated, or is it up to the deployment to decide?

=C2=A0

I=E2=80=99d like to better understand the use case for putting these in the= access token. If the RS is making authorization decisions based on these c= laims, that implies that the RS cannot rely on the AS to determine (e.g., f= rom the requested scope) the required authentication method(s), freshness, etc. If the AS could be relied upon for this, then p= resumably it would not issue RTs and ATs for a scope without requiring the = end user to meet the appropriate authentication requirements. If this is th= e case, then the RS must have a way to signal to the client (and then the AS) that a step-up authenticatio= n is required. Is there an existing mechanism through which they could do t= his? All I can come up with is cramming the information into the scope attr= ibute of a WWW-Authenticate challenge, but that has the same scope opacity violation problem as described in this= draft=E2=80=99s Security Considerations. Without a clear way to express th= e step-up requirements, this feels incomplete..

=C2=A0

3. Regarding access tokens that are used to access different resource serve= rs:
Reading between the lines, I *think* the intention is that a JWT acc= ess token that is intended to be used to access two different resources at = two different RSes should look something like:

=C2=A0

{

"aud": "https://gener= ic-resource-indicator.example.com/",

"scope": "resource_foo r= esource_bar",

...

}


And the expectation is that each RS should recognize that generic audience.= Is this correct? If so it seems to go against the spirit of resource indic= ators as indicating the target or location of a resource. It=E2=80=99s stre= tching that definition, at the very least.

=C2=A0

But as I said, I=E2=80=99m reading between the lines here. If this is the i= ntention, it should be clearly stated. Alternatively, remove (or change to = a SHOULD) the requirement that multi-value `aud` claims must only contain a= liases for the same resource indicator.

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org> on behalf of Vitt= orio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>
Date: Monday, December 16, 2019 at 2:51 PM
To: IETF oauth WG <oauth@ietf.org>
Cc: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jw= t-03.txt

=C2=A0

Dear all,
I finally found the time to push a new draft of the JWT profile for ATs. Th= is version incorporates the feedback kindly provided by Brian and Aaron at = IETF105.
Unfortunately I didn't have a chance to participate to IETF106, hence w= e didn't do much progress since then.
There are still two areas we didn't manage to reach consensus on:

1. Mechanisms for signaling whether the AT was obtained by a user or an app= lication

This point was the subject of intense debate on the list leading to IETF105= ..
One insight that emerged from the IETF105 discussion was that the use case = here is more about whether the AT has been obtained via a grant that authen= ticated the client (regardless of what specific grant was used) vs a public= client grant- that information can be relevant to a resource as it determines whether the identity of the= client can be used in authorization decisions (in the former case) or not = (in the public client case). If that's the scenario we are truly after,= a simple, possibly optional boolean claim (say AuthenticatedClient) would suffice.
Note for the people who didn't read the spec: I removed any reference t= o this already in draft-ietf-oauth-access-token-jwt-01. I think this is an = important and useful info and standardizing it would be beneficial for midd= leware and SDK creators, but ultimately this is an interop profile hence if there's no strong desire to reach = an agreement here, I am also OK with dropping the matter and not address th= is function in the spec.
To summarize, I have two questions here:

A. Do we believe it's worth it to formalize in the profile a mechanism = to indicate whether the client th obtained the AT authenticated itself with= the AS?
B. If yes, are you OK wiht an optional bool claim here?


2. Claims indicating session properties

This is one area where I am far more passionate about, as it represents a f= undamental aspect that production systems (and in particular 1st party solu= tions) already rely on in the current proprietary JTW ATs.
The profile currently includes the claims auth_time, acr and amr - capturin= g the values of those properties at the time of the latest authentication t= he user performed in the session used to issue the current AT: at session c= reation, at auth step up time and so on.
Those are values that API need in order to make authorization decisions; in= the case of 1st party APIs, the AT is the only artifact they ever receive = hence there is no other way for an API to determine whether the caller perf= ormed say MFA in order to obtain the current AT.
Since the first draft, some people signaled concerns about the current mech= anisms thru which those claims get their value. For example, it has been pr= oposed to maintain the original values of auth_time, acr & amr and intr= oduce additional claims to indicate changes (like stepup).
I am not clear on what cold go wrong with the current approach, hence I don= 't have an immediate grasp of how changes like the above would help. If the people uncomfortable with the current proposal could detail their co= ncern, we can brainstorm ways to make that info available to API in a safer= way. To summarize:

A. Do you have concerns with the current auth_time, arm, acr proposal? Can = you spell them out? (please read the relevant parts of the spec before chim= ing in :))
B. If yes, what can we do to make that info available to RSs in a way that = makes you comfortable?



Thanks

V.

=C2=A0

On Mon, Dec 16, 2019 at 2:49 PM <internet-drafts@ietf.org> wrote:


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Vitt= orio Bertocci
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-access-token-jwt-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-12-16

Abstract:
=C2=A0 =C2=A0This specification defines a profile for issuing OAuth 2.0 acc= ess
=C2=A0 =C2=A0tokens in JSON web token (JWT) format.=C2=A0 Authorization ser= vers and
=C2=A0 =C2=A0resource servers from different vendors can leverage this prof= ile to
=C2=A0 =C2=A0issue and consume access tokens in interoperable manner.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-ac= cess-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-tok= en-jwt-03
https://datatracker.ietf.org/doc/html/draft-i= etf-oauth-access-token-jwt-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-= oauth-access-token-jwt-03


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

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

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

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

--00000000000060b22b0599ed33fc-- From nobody Tue Dec 17 19:06:43 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B3B120090 for ; Tue, 17 Dec 2019 19:06:42 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KDXfT5wM5sBw for ; Tue, 17 Dec 2019 19:06:40 -0800 (PST) Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693C3120043 for ; Tue, 17 Dec 2019 19:06:40 -0800 (PST) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs03.index.or.jp (Postfix) with ESMTP id 9AC7217EA40; Wed, 18 Dec 2019 12:06:39 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 0AB924E0046; Wed, 18 Dec 2019 12:06:39 +0900 (JST) Received: from nriea05.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id xBI36cej018299; Wed, 18 Dec 2019 12:06:38 +0900 Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea05.index.or.jp with ESMTP id xBI36cuf018294; Wed, 18 Dec 2019 12:06:38 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id xBI36cjJ001152; Wed, 18 Dec 2019 12:06:38 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id xBI36cuw001151; Wed, 18 Dec 2019 12:06:38 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id xBI36cbj001143; Wed, 18 Dec 2019 12:06:38 +0900 Received: from CUEXE02PA.cu.nri.co.jp (192.51.23.32) by CUEXM05PA.cu.nri.co.jp (172.159.253.47) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Dec 2019 12:06:37 +0900 Received: from JPN01-OS2-obe.outbound.protection.outlook.com (104.47.92.50) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Dec 2019 12:06:37 +0900 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e1sfj+9jm13WgohoJ54JKTiVqwckdh1TSgEEXl9zO7CuhSqxOLMnz2aUcXeflRlUUD9I8ck3VlmM3JiS/mnxrjHaJOj+jeYURBOe7B80SrsWkr6tPLmBnoxm+MPvEodArgUHRdESVhaVDMMivcCU1lIbrix9IBm+44JvNQuQUrmOMboiac520lkFqIoFP3A6i4Uyl2JKOViF0/bWP75HyUkDb3uDiw/exM0Zc3wyGdo01N3Rg51352as1V7O77rac4YzSOlx7CuJ4xLISjRILEJC9G5Q/xbi/sn4NmTDBITfYwLq9neLkPBdNjWnNFRA3+A3oGKcBB9NMfyNXvn6oQ== 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=Y514MaEpHqRn2s9fPJZqDO6U8aMDLcsgV/KH4BVdCU8=; b=Vo1PpOnO8c/VHVCoL4ZNBCYn2P/4X/PyHGc9PHrxEkLfIenppc6Ih+Nkn8n9hslxM6OW/OgOeSbrLBk5Mt5NAWhtvcRnrAvJ7tqCNQKnvX55rx6Wo+ebmBKx/yVCj1nYnl1Iy2rQUsrXKTQhWAx3VaWV86Qj1GCWcCewpf2jb0GoxtWQqfQUqju7qkNL8P23x6g7/JWyu6gRIwrj8KoGnjviVDYeEfbdr/fo6XqapnzOAsiNNadPyuFFlrTX3if23gCvle5utJjA5uWFRFMDwS5npDolIcdVKq+JmeVCVi2a3KrWphintcVFo2BH3ERzU5GZoSVBKK78T432h5UZDw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cu.nri.co.jp; dmarc=pass action=none header.from=cu.nri.co.jp; dkim=pass header.d=cu.nri.co.jp; arc=none Received: from OSAPR01MB4948.jpnprd01.prod.outlook.com (20.179.179.16) by OSAPR01MB4674.jpnprd01.prod.outlook.com (20.179.177.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14; Wed, 18 Dec 2019 03:06:36 +0000 Received: from OSAPR01MB4948.jpnprd01.prod.outlook.com ([fe80::b528:1a3e:81b4:c604]) by OSAPR01MB4948.jpnprd01.prod.outlook.com ([fe80::b528:1a3e:81b4:c604%4]) with mapi id 15.20.2538.019; Wed, 18 Dec 2019 03:06:36 +0000 From: n-sakimura To: John Bradley , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests Thread-Index: AQHVtNnhOyWl2lWR5kOIrKN/VLBni6e+W0aAgAADowCAANeoIA== Date: Wed, 18 Dec 2019 03:06:36 +0000 Message-ID: References: <7cd6d76d-3734-532e-06a2-12adc9600d63@ve7jtb.com> In-Reply-To: <7cd6d76d-3734-532e-06a2-12adc9600d63@ve7jtb.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailadviser: Ver 3.40R03 authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-originating-ip: [221.248.191.246] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 314c8d9f-5060-4b43-8ed4-08d783674b6f x-ms-traffictypediagnostic: OSAPR01MB4674: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(136003)(396003)(39860400002)(199004)(189003)(365934003)(71200400001)(55016002)(8936002)(110136005)(66446008)(186003)(81156014)(7696005)(26005)(53546011)(8676002)(81166006)(9686003)(33656002)(5660300002)(76116006)(66556008)(64756008)(2906002)(52536014)(66476007)(66946007)(478600001)(6506007)(86362001)(966005)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:OSAPR01MB4674; H:OSAPR01MB4948.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:ja; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BD6goYA0cZSjpQeaJPLAsXazalICqpQvrgjqgm58Uwa5xAnUM7hB6uqG4kKhsXFyCdlcWaQ6BBa6IrsuLegAWLPiEZMCYFz6GObvT1i19G5e4O9mk+5p7IQtpnuOXxWUGcWzNwEYslKm6hnyoMkzEktsQ/XIeTcmWbIy9Cc4q+AcBMoKBNT+82XZf1cJcXpthn+URaTuURxuMwYG61ujwozCy4bVukf4dYwp1lmS/0IWqBHHw5Z8oudCLUkmvo0eXmmzjMRA/5HQB6/vojn2WH2jreYoE9aIXscBpSTooV4zC2nD1ulS6nlYHSTQRP33sHH48FXF3SbOjIvN5MWK3g31Dr2RmPie/11tIDNH8MK1aoAMVgrCyLQSB7SAeHecPl1HmbddXZI+L7z3vt/U2YVIOfL8Ecm971zixzd0ciYFjqJuZ3TlOV1OcHVGmHfKBHSPD2+LWE2TzeYv4Yn+dYiwAlJMnrYyLDcLnOGTtN5FmpS3wdgScY4xbrtZK2m8wJFviFbXyGwKibYs2EN5385zs3EaQ09kkXLQy/SgJwQ= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_OSAPR01MB494809BF5C76B72EF5FA7128F9530OSAPR01MB4948jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 314c8d9f-5060-4b43-8ed4-08d783674b6f X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2019 03:06:36.5857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BflEOz2Tu70LEz6fNC/5MSJZX+5I0cvCEjy40HIgjg7zSsMS6kISyAmEToIEUY9v3ELW6d7r0cHQFHrrd1AMdA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB4674 X-OrganizationHeadersPreserved: OSAPR01MB4674.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE02PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE02PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 03:06:43 -0000 --_000_OSAPR01MB494809BF5C76B72EF5FA7128F9530OSAPR01MB4948jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0K6YeO5p2R57eP5ZCI56CU56m25omA44CASVTln7rnm6TmioDooZPmiKbnlaXlrqQNCuS4 iuW4reeglOeptuWToeOAgOW0juadkeWkj+W9pg0KRTogbi1zYWtpbXVyYUBucmkuY28uanANClQ6 ICs4MSg5MCk2MDEzNjI3Ng0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQrjgZPjga7jg6Hjg7zjg6vjgavjga/jgIHmnKzmnaXjga7lrpvl hYjjga7mlrnjga7jgb/jgavpmZDlrprjgZXjgozjgZ/mqZ/lr4bmg4XloLHjgYzlkKvjgb7jgozj gabjgYTjgovloLTlkIjjgYzjgZTjgZbjgYTjgb7jgZnjgILjgYrlv4PjgYLjgZ/jgorjga7jgarj gYTloLTlkIjjga/jgIHpgIHkv6HogIXjgavjgZTpgKPntaHjga7jgYbjgYjjgIHjgZPjga7jg6Hj g7zjg6vjgpLliYrpmaTjgZfjgabjgY/jgaDjgZXjgYTjgb7jgZnjgojjgYbjgYrpoZjjgYTnlLPj gZfkuIrjgZLjgb7jgZnjgIINClBMRUFTRSBSRUFEOlRoaXMgZS1tYWlsIGlzIGNvbmZpZGVudGlh bCBhbmQgaW50ZW5kZWQgZm9yIHRoZSBuYW1lZCByZWNpcGllbnQgb25seS4gSWYgeW91IGFyZSBu b3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIGUtbWFpbC4NCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+ IE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkNClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE3LCAy MDE5IDExOjE1IFBNDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IENhbGwgZm9yIEFkb3B0aW9uOiBPQXV0aCAyLjAgUHVzaGVkIEF1dGhvcml6YXRpb24gUmVxdWVz dHMNCg0KDQpJIHN1cHBvcnQgYWRkb3B0aW9uDQpPbiAxMi8xNy8yMDE5IDExOjAxIEFNLCBBYXJv biBQYXJlY2tpIHdyb3RlOg0KSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiBQQVIuDQoNCkFhcm9u IFBhcmVja2kNCg0KDQpPbiBUdWUsIERlYyAxNywgMjAxOSBhdCA0OjU5IEFNIFJpZmFhdCBTaGVr aC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5j b20+PiB3cm90ZToNCkFsbCwNCg0KVGhpcyBpcyBhIGNhbGwgZm9yIGFkb3B0aW9uIG9mIGZvciB0 aGUgT0F1dGggMi4wIFB1c2hlZCBBdXRob3JpemF0aW9uIFJlcXVlc3RzIGRvY3VtZW50Lg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcGFy Lw0KDQpUaGVyZSB3YXMgYSBnb29kIHN1cHBvcnQgZm9yIHRoaXMgZG9jdW1lbnQgZHVyaW5nIHRo ZSBTaW5nYXBvcmUgbWVldGluZywgYW5kIG9uIHRoZSBtYWlsaW5nIGxpc3QgaW4gdGhlIE1lZXRp bmcgTWludXRlcyB0aHJlYWQuDQoNClBsZWFzZSwgbGV0IHVzIGtub3cgaWYgeW91IHN1cHBvcnQg b3Igb2JqZWN0IHRvIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQgYXMgYSB3b3JraW5nIGdyb3VwIGRv Y3VtZW50IGJ5IERlYyAyN3RoLg0KDQpJZiB5b3UgaGF2ZSBhbHJlYWR5IGluZGljYXRlZCB5b3Vy IHN1cHBvcnQgb24gdGhlIE1lZXRpbmcgTWludXRlcyB0aHJlYWQsIHlvdSBkbyBub3QgbmVlZCB0 byBkbyBpdCBhZ2FpbiBvbiB0aGlzIHRocmVhZC4NCg0KUmVnYXJkcywNCiBSaWZhYXQgJiBIYW5u ZXMNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCi0tDQotLS0t DQpBYXJvbiBQYXJlY2tpDQphYXJvbnBhcmVja2kuY29tPGh0dHA6Ly9hYXJvbnBhcmVja2kuY29t Pg0KQGFhcm9ucGs8aHR0cDovL3R3aXR0ZXIuY29tL2Fhcm9ucGs+DQoNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcg bGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_OSAPR01MB494809BF5C76B72EF5FA7128F9530OSAPR01MB4948jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Iu+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oua4uOOCtOOCt+OD g+OCrzsNCglwYW5vc2UtMToyIDExIDQgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToi77yt77yzIO+8sOOCtOOCt+ODg+OCryI7DQoJcGFub3Nl LTE6MiAxMSA2IDAgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDm uLjjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNCAwIDAgMCAwIDAgMCAwO30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA77yt77yzIO+8sOOCtOOCt+ODg+OCryI7DQoJcGFub3Nl LTE6MiAxMSA2IDAgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDv vK3vvLMg44K044K344OD44KvIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MG1tOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiLvvK3vvLMg77yw44K044K344OD44KvIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOabuOW8j+S7mOOBjSBcKOaWh+Wtl1wpIjsNCglt YXJnaW46MG1tOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiLvvK3vvLMg44K044K344OD44KvIjt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MG1tOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBtbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiLvvK3vvLMg77yw44K044K344OD44KvIjt9DQpzcGFuLkhUTUwNCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwg5pu45byP5LuY44GNIFwo5paH5a2XXCkiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDmm7jlvI/ku5jjgY0iOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi4yMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseTrmuLjjgrTjgrfjg4Pjgq87DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46OTkuMjVwdCAzMC4wbW0gMzAuMG1tIDMwLjBtbTt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2Ij4NCjx2 OnRleHRib3ggaW5zZXQ9IjUuODVwdCwuN3B0LDUuODVwdCwuN3B0IiAvPg0KPC9vOnNoYXBlZGVm YXVsdHM+PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkpBIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65ri444K044K344OD44KvIj4mIzQzOzE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65ri444K044K344OD44KvIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65ri444K044K344OD44KvIj7ph47m nZHnt4/lkIjnoJTnqbbmiYDjgIA8c3BhbiBsYW5nPSJFTi1VUyI+SVQ8L3NwYW4+5Z+655uk5oqA 6KGT5oim55Wl5a6kPHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTrmuLjjgrTjgrfjg4Pjgq8iPuS4iuW4reeglOeptuWToeOAgOW0juadkeWkj+W9 pjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5Oua4uOOCtOOCt+ODg+OCryI+RTogbi1zYWtpbXVyYUBucmkuY28uanA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65ri444K044K344OD44KvIj5U OiAmIzQzOzgxKDkwKTYwMTM2Mjc2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5Oua4uOOCtOOCt+ODg+OCryI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTrmuLjj grTjgrfjg4Pjgq8iPuOBk+OBruODoeODvOODq+OBq+OBr+OAgeacrOadpeOBruWum+WFiOOBruaW ueOBruOBv+OBq+mZkOWumuOBleOCjOOBn+apn+WvhuaDheWgseOBjOWQq+OBvuOCjOOBpuOBhOOC i+WgtOWQiOOBjOOBlOOBluOBhOOBvuOBmeOAguOBiuW/g+OBguOBn+OCiuOBruOBquOBhOWgtOWQ iOOBr+OAgemAgeS/oeiAheOBq+OBlOmAo+e1oeOBruOBhuOBiOOAgeOBk+OBruODoeODvOODq+OC kuWJiumZpOOBl+OBpuOBj+OBoOOBleOBhOOBvuOBmeOCiOOBhuOBiumhmOOBhOeUs+OBl+S4iuOB kuOBvuOBmeOAgjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk65ri444K044K344OD44KvIj5QTEVBU0UgUkVBRDpUaGlzIGUt bWFpbCBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZvciB0aGUgbmFtZWQgcmVjaXBpZW50 IG9ubHkuIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBlLW1haWwuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65ri444K044K344OD44KvIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMG1tIDBtbSAwbW0iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCAmbHQ7b2F1dGgt Ym91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9obiBCcmFkbGV5PGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDE3LCAyMDE5IDExOjE1IFBNPGJyPg0K PGI+VG86PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRI LVdHXSBDYWxsIGZvciBBZG9wdGlvbjogT0F1dGggMi4wIFB1c2hlZCBBdXRob3JpemF0aW9uIFJl cXVlc3RzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+SSBzdXBwb3J0IGFkZG9wdGlvbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ T24gMTIvMTcvMjAxOSAxMTowMSBBTSwgQWFyb24gUGFyZWNraSB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+SSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiBQQVIuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFhcm9uIFBh cmVja2k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgRGVjIDE3LCAyMDE5IGF0IDQ6NTkgQU0g UmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJtYWlsdG86cmlmYWF0LmlldGZAZ21haWwu Y29tIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBtbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkFsbCwgPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+VGhpcyBpcyBhIGNhbGwgZm9yIGFkb3B0aW9uIG9mIGZvciB0aGUmbmJzcDtPQXV0 aCAyLjAgUHVzaGVkIEF1dGhvcml6YXRpb24gUmVxdWVzdHMgZG9jdW1lbnQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWxvZGRlcnN0ZWR0LW9hdXRoLXBhci8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1wYXIvPC9hPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlcmUgd2Fz IGEgZ29vZCBzdXBwb3J0IGZvciB0aGlzIGRvY3VtZW50IGR1cmluZyB0aGUgU2luZ2Fwb3JlIG1l ZXRpbmcsIGFuZCBvbiB0aGUgbWFpbGluZyBsaXN0IGluIHRoZSBNZWV0aW5nIE1pbnV0ZXMgdGhy ZWFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UGxl YXNlLCBsZXQgdXMga25vdyBpZiB5b3Ugc3VwcG9ydCBvciBvYmplY3QgdG8gYWRvcHRpbmcgdGhp cyBkb2N1bWVudCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgYnkgRGVjIDI3dGguPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB5b3UgaGF2ZSBh bHJlYWR5IGluZGljYXRlZCB5b3VyIHN1cHBvcnQgb24gdGhlIE1lZXRpbmcgTWludXRlcyB0aHJl YWQsIHlvdSBkbyBub3QgbmVlZCB0byBkbyBpdCBhZ2FpbiBvbiB0aGlzIHRocmVhZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwO1JpZmFhdCAmYW1wOyBIYW5uZXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLSA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFhcm9uIFBhcmVj a2k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cDovL2Fhcm9ucGFyZWNraS5jb20i IHRhcmdldD0iX2JsYW5rIj5hYXJvbnBhcmVja2kuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48YSBocmVmPSJodHRwOi8vdHdpdHRlci5jb20vYWFyb25wayIgdGFyZ2V0PSJfYmxhbmsiPkBh YXJvbnBrPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5PQXV0aCBtYWls aW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_OSAPR01MB494809BF5C76B72EF5FA7128F9530OSAPR01MB4948jpnp_-- From nobody Tue Dec 17 23:03:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2171208D6 for ; Tue, 17 Dec 2019 23:03:23 -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, 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=zmartzone-eu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HpQENBoSS3w for ; Tue, 17 Dec 2019 23:03:19 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 144AB1208D1 for ; Tue, 17 Dec 2019 23:03:18 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id z76so1104935qka.2 for ; Tue, 17 Dec 2019 23:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JlgXuDII+cIUhyipjFh37R3rG1TmtCPQD2Ifj0z2U5Y=; b=Cd0tOUq4JfW/bn3wE1SD49acxJSwz2D+zvke7SW6Mmo2N5inFCkHriY7wHv1YHMWoA ru+oiRKPGrOze4eisciJkQ5UgujEMiHZYsZr/CYBRnU0wiRVbwSy1dktnpl1Zl8VIkYk byb1OCDNMpJv8mljzyMOm/AUVY+WT5dxCBIXfASLEiOJmG3SW51fyowwc+55ns3+XQDJ 6UgUxB91LDmER3JFyyVqus4HifMDWJFb6OX1m5EJFaNZNwTCZ9YTDrtYk0bEooooVeEf djVw3Gbu7aYJKQbiZxOf8HR1hI3gsQ8ckdj5VPNau4F7MyKJWmzyKQRGvrTawSANcEY5 6eug== 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=JlgXuDII+cIUhyipjFh37R3rG1TmtCPQD2Ifj0z2U5Y=; b=cCZ5+8POOTqdu9eg2JZWGx8CbRNUo5sj65Gnwetq/UjSIY9CHdybrby7JwokFkSYQQ XntspiF/tvwG+EF2GpNDiOYAPILQvUfLQi0yH1lhXGzZHbmdO0mwohDOH85DuNYxggXT vQ7vL/sXu2jO/fgugLmHY5pgOFQzIc6BLt+P9S9kXuxLVjmvI8A5AMcHY9DMpm639wF5 iBaYSHlX+wWtzLUC+VPl31v/v4tGIglF87wGxlUVYLvMEVETvPricyS7mW5VxD9dGcrO OXVJ6Jq+WJlyF4ra9u7cucEnIMSDvGAEYZYvjXOpo6aeI2ADfLypBOb5IxJTxUXGec4H fgpQ== X-Gm-Message-State: APjAAAWb3az6PLTompSIu8zJkelfLE8l3fDQZgY1pZvN+VKBD4X05JO7 o5yejfMHoL/f1qekFelkSqoFGUONh5snI3z7C8ILQsO1jr8RwQ== X-Google-Smtp-Source: APXvYqyCkJQzQLAgujKhuq3JC75zY7NrHqsWbj4OS/dN2VuXDcT0Bf/7UM/yM9kgmWptGaR8UeNkFkGSmMYAZoqRgZE= X-Received: by 2002:a37:a406:: with SMTP id n6mr1027783qke.63.1576652597873; Tue, 17 Dec 2019 23:03:17 -0800 (PST) MIME-Version: 1.0 References: <073c968e-627e-6927-6d9f-cad2e9fe3e89@evertpot.com> In-Reply-To: <073c968e-627e-6927-6d9f-cad2e9fe3e89@evertpot.com> From: Hans Zandbelt Date: Wed, 18 Dec 2019 15:03:06 +0800 Message-ID: To: Evert Pot Cc: oauth Content-Type: multipart/alternative; boundary="00000000000007e2050599f50a0e" Archived-At: Subject: Re: [OAUTH-WG] Recommendations for OAuth in browsers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 07:03:24 -0000 --00000000000007e2050599f50a0e Content-Type: text/plain; charset="UTF-8" there's: https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps that mentions handing OAuth through a backend component in: https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02#section-6.2 There's an implementation of such a backend in a module for the Apache webserver see: https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/ I agree that this model should be documented and spec-ed out but I also believe most people in this WG feel that it is relatively unrelated to OAuth 2.0 beyond what is in 6.2 of the doc above. Hans. On Wed, Dec 18, 2019 at 2:47 AM Evert Pot wrote: > At our company we're developing REST apis. > > One of the things that are pretty important to us, is developers being > able to access the REST apis directly, via their browsers.Our systems > typically have a middleware that converts generated hal+JSON to a HTML > interface for easily browsable. > > When using something like Digest or Basic authentication for the API, > this is pretty easy. Browsers present a pop-up, allowing the developer > to log in. > > With OAuth2 this is less easy. Being able to log in via a browser means > that at least an Authorization header needs to be injected. > > Ideally, browsers would just support OAuth2, are able to discover the > the OAuth2 token authorization and possibly use the dynamic client > registration protocol, but alas... we don't live in that world, and I'm > not aware of any browser extension that does this. In fact, I don't > think it's possible today to write a browser extension that intercepts > HTTP requests and adds this header. At least not in Chrome. > > So I'm looking at alternatives. > > One idea we had was to modify the resource service to detect browsers, > send them through the authorization_code flow and set a session cookie. > Initially our idea was to just set the actual access_token in the > cookie. Another idea was to use a JWS token that encrypts both the > access token and refresh token. > > I also don't love the idea for a resource server to support > authentication via cookies. It feels risky, but I can't put my finger on > why exactly. > > My question to this list is, are there any recommendations for this? > It's a shame that many APIs can only be accessed by purpose-built > clients, the nice thing of hypermedia-style APIs is that humans can > actually browse them. > > Evert > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --00000000000007e2050599f50a0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
there's:
that mentions handing OAuth= through a backend component in:
There's an implementation of such a backend in a module for= the Apache webserver see:

I agree=C2=A0that this model should = be documented and spec-ed out but I also believe most people in this WG fee= l that it is relatively unrelated to OAuth 2.0 beyond=C2=A0what is in 6.2 o= f the doc above.

Hans.

On Wed, Dec 18, 2019= at 2:47 AM Evert Pot <me@evertpot.co= m> wrote:
At our company we're developing REST apis.

One of the things that are pretty important to us, is developers being
able to access the REST apis directly, via their browsers.Our systems
typically have a middleware that converts generated hal+JSON to a HTML
interface for easily browsable.

When using something like Digest or Basic authentication for the API,
this is pretty easy. Browsers present a pop-up, allowing the developer
to log in.

With OAuth2 this is less easy. Being able to log in via a browser means
that at least an Authorization header needs to be injected.

Ideally, browsers would just support OAuth2, are able to discover the
the OAuth2 token authorization and possibly use the dynamic client
registration protocol, but alas... we don't live in that world, and I&#= 39;m
not aware of any browser extension that does this. In fact, I don't
think it's possible today to write a browser extension that intercepts<= br> HTTP requests and adds this header. At least not in Chrome.

So I'm looking at alternatives.

One idea we had was to modify the resource service to detect browsers,
send them through the authorization_code flow and set a session cookie.
Initially our idea was to just set the actual access_token in the
cookie. Another idea was to use a JWS token that encrypts both the
access token and refresh token.

I also don't love the idea for a resource server to support
authentication via cookies. It feels risky, but I can't put my finger o= n
why exactly.

My question to this list is, are there any recommendations for this?
It's a shame that many APIs can only be accessed by purpose-built
clients, the nice thing of hypermedia-style APIs is that humans can
actually browse them.

Evert


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


--
--00000000000007e2050599f50a0e-- From nobody Tue Dec 17 23:14:39 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DF71208DC for ; Tue, 17 Dec 2019 23:14:38 -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_KAM_HTML_FONT_INVALID=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 vDdO5HFq44QZ for ; Tue, 17 Dec 2019 23:14:35 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C081208D7 for ; Tue, 17 Dec 2019 23:14:34 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id d16so1023951wre.10 for ; Tue, 17 Dec 2019 23:14: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=6i60Igu3smJF0O+sDtr1vdbcP4XgD4T2rtcNMkRgsC8=; b=ra+1DB5HU0IdnMdQ5jk15A7JDfZ+6Ko5JDNYEiQgbCqqw5OIZHAfG7iPawC4Irt3Ro 3HrDhNU1WJ7MU9BA03YgJLfEf3GrVtiKTgTbPcRxY0X2CsgN5agLiIZ8I5xThxveh9hq 89tP/TQEqE09JGwwe4ERR/cCl8rmFz3yg/I5H+uzbqNdDLcBlAppaCneG8SeXcaNVvWv SHuoFWo6K6Y5ZK45PC6lmd+41xmJrHDUZ8nOXyu+XrDdawNVeEKEfuu042QA2jkCIym1 n0Xyf6tIT2mH1Iknrvda+e/K/ShjVccPC2etjm6sHCylMTqb52XcjrgCgVfR6QgEnGPh xnWQ== 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=6i60Igu3smJF0O+sDtr1vdbcP4XgD4T2rtcNMkRgsC8=; b=pOdH8BGgnVormciYrZP7ash+THjh8meenNjbpv32udX13I/dL8gOAyWlqyRtG1DiaI wthcNyrYIw2ld3IXjzowJ5MLRXtF8bVYGkMo9IzRUKfg10ZtiOybunlzh5UI0kqMTI3S 19Tk/BM1rXksNm75b3FZ1syZN6LiEjYqaerP/25siocKySUmbtrwFdMPqbTljAMDZXGU 2msCd0R2g0dyvPr6xhwM+TD1W0b3rrTClyqzwXWj6/Q6wBoiE0rGlqTsaAXw+sbURmsA uZv+MeFP1FKXPig1LKBAmWFl2Ln6sizqqVm4VL1kGMQ5patRl1fV9pfRDOkaQyBsd1A8 U8eQ== X-Gm-Message-State: APjAAAVcgqwWkoZwlXevDjRCGsqo5UocYJSvjRpw33b0lwXeG6xjh7k8 B6LbgbeTKX6gaOvvB41KyBqYp9OdZVMeCEmlDs0= X-Google-Smtp-Source: APXvYqw49WEWhFuylU1SF56DoFgp9fjbC2H98JwEdPMRlyb1Ng65ij5LLUAt5mUd0gjdesP/e2N02dUZETyJO4uNuWs= X-Received: by 2002:adf:8297:: with SMTP id 23mr850118wrc.379.1576653272874; Tue, 17 Dec 2019 23:14:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Wed, 18 Dec 2019 16:14:23 +0900 Message-ID: To: John Bradley Cc: Brian Campbell , oauth , Nat Sakimura Content-Type: multipart/alternative; boundary="0000000000004384520599f5326b" Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 07:14:38 -0000 --0000000000004384520599f5326b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So, no change is OK? On Wed, Dec 11, 2019 at 10:01 PM John Bradley wrote: > I also slightly prefer the merge approach. > > There are plusses and minuses to both. > > Changing again now that it is past ISEG review and backing out a Discuss > will add another three to six months at this point, if we can get them to > agree to the change. > > John B. > > On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura wrote: > >> Correct. The WG supported the precedence approach and even merge just >> like OIDC as it is very useful from the implementation point of view and >> helps with a bunch of deployment patter. >> >> The push back came in from the Ben Campbell=E2=80=99s DISCUSS. >> See >> >> https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-act= ually-specifies-the >> >> I am willing to go either way as long as people agree. My slight >> preference is to the original approach. >> >> Best, >> >> Nat Sakimura >> >> 2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell > 40pingidentity..com@dmarc.ietf.org <40pingidentity.com@dmarc.ietf.org>>: >> >>> FWIW, as best I can remember the change in question came as I result of= directorate/IESG >>> review rather than a WG decision/discussion. Which is likely why you ca= n't >>> find the "why" anywhere in the mailing list archive. >>> >>> On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan wrote= : >>> >>>> Well it kind of blows, doesn't it? I wasn't able to find the "why" >>>> anywhere in the mailing list archive around the time this was changed. >>>> >>>> My take on satisfying both worlds looks like this >>>> >>>> - allow just JAR - no other params when possible. >>>> (which btw isn't possible to do with request_uri when enforcing >>>> client based uri whitelist and the jwsreq 5.2.2 shows as much) >>>> - enforce the "dupe behaviours" defined in OIDC (if response_type or >>>> client_id is in request object it must either be missing or the same i= n >>>> regular request). >>>> - allows merging request object and regular parameters with request >>>> object taking precedence since it is a very useful feature when having >>>> pre-signed request object that's not one time use and clients using it= wish >>>> to vary state/nonce per-request. >>>> >>>> I wish the group reconsidered making this breaking change from OIDC's >>>> take on request objects - allow combination of parameters from the req= uest >>>> object with ones from regular parameters (if not present in request ob= ject). >>>> >>>> S pozdravem, >>>> *Filip Skokan* >>>> >>>> >>>> On Wed, 28 Aug 2019 at 23:02, Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>> Filip, for better or worse, I believe your assessment of the situation >>>>> is correct. I know of one AS that didn't choose which of the two to f= ollow >>>>> but rather implemented a bit of a hybrid where it basically ignores >>>>> everything outside of the request object per JAR but also checks for = and >>>>> enforces the presence and value of the few regular parameters (client= _id, >>>>> response_type) that OIDC mandates. >>>>> >>>>> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan >>>>> wrote: >>>>> >>>>>> Hello everyone, >>>>>> >>>>>> in an earlier thread I've posed the following question that might >>>>>> have gotten missed, this might have consequences for the existing >>>>>> implementations of Request Objects in OIDC implementations - its mak= ing >>>>>> pure JAR requests incompatible with OIDC Core implementations. >>>>>> >>>>>> draft 14 of jwsreq (JAR) introduced this language >>>>>> >>>>>> The client MAY send the parameters included in the request object >>>>>>> duplicated in the query parameters as well for the backward >>>>>>> compatibility etc. >>>>>>> >>>>>>> *However, the authorization server supporting thisspecification MUS= T >>>>>>> only use the parameters included in the requestobject. * >>>>>> >>>>>> >>>>>> Server MUST only use the parameters in the Request Object even if th= e >>>>>>> same parameter is provided in the query parameter. The Authorizati= on >>>>>> >>>>>> >>>>>> The client MAY send the parameters included in the request object >>>>>>> duplicated in the query parameters as well for the backward >>>>>>> compatibility etc. >>>>>>> >>>>>>> *However, the authorization server supporting thisspecification MUS= T >>>>>>> only use the parameters included in the requestobject. * >>>>>> >>>>>> >>>>>> Nat, John, everyone - *does this mean a JAR compliant AS ignores >>>>>> everything outside of the request object while OIDC Request Object o= ne >>>>>> merges the two with the ones in the request object being used over o= nes >>>>>> that are sent in clear?* The OIDC language also includes sections >>>>>> which make sure that some required arguments are still passed outsid= e of >>>>>> the request object with the same value to make sure the request is "= valid" >>>>>> OAuth 2.0 request (client_id, response_type), something which an exa= mple in >>>>>> the JAR spec does not do. Not having this language means that existi= ng >>>>>> authorization request pipelines can't simply be extended with e.g. a >>>>>> middleware, they need to branch their codepaths. >>>>>> >>>>>> Is an AS required to choose which of the two it follows? >>>>>> >>>>>> Thank you for clarifying this in advance. I think if either the >>>>>> behaviour is the same as in OIDC or different this should be called = out in >>>>>> the language to avoid confusion, especially since this already exist= s in >>>>>> OIDC and likely isn't going to be read in isolation, especially beca= use the >>>>>> Request Object is even called out to be already in place in OIDC in = the JAR >>>>>> draft. >>>>>> >>>>>> Best, >>>>>> *Filip* >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged material for the sole use of the intended recipient(s). An= y >>>>> review, use, distribution or disclosure by others is strictly prohibi= ted. >>>>> If you have received this communication in error, please notify the s= ender >>>>> immediately by e-mail and delete the message and any file attachments= from >>>>> your computer. Thank you.* >>>> >>>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> 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 f= rom >>> your computer. Thank you.* >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --0000000000004384520599f5326b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, no change is OK?=C2=A0

On Wed, Dec 11, 2019 at 10:01 PM= John Bradley <ve7jtb@ve7jtb.com> wrote:
I also slightly prefer the merge approach.=C2=A0

There are plusses and minuses to both.=C2= =A0

Changing again now t= hat it is past ISEG review and backing out a Discuss will add another three= to six months at this point, if we can get them to agree to the change.=C2= =A0

John B.=C2=A0
<= /div>
O= n Tue, Dec 10, 2019, 11:29 PM Nat Sakimura <sakimura@gmail.com> wrote:
C= orrect. The WG supported the precedence approach and even merge just like O= IDC as it is very useful from the implementation point of view and helps wi= th a bunch of deployment patter.=C2=A0

The push back came in from the Ben Campbell=E2=80=99s = DISCUSS.=C2=A0
See=C2=A0

I am willing to go either way as lo= ng as people agree. My slight preference is to the original approach.=C2=A0=

Best,=C2=A0

Nat Sakimura

2019=E5=B9= =B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell <bcampbell=3D40pingidentity..com@dmarc.ietf.org>:
FWIW, as best I can remember the chang= e in question came as I result of directorate/IESG review rather than= a WG decision/discussion. Which is likely why you can't find the "= ;why" anywhere in the mailing list archive.

On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan <panva.i= p@gmail.com> wrote:
Well it kind of blows, doesn't it? I wasn't able to f= ind the "why" anywhere in the mailing list archive around the tim= e this was changed.

My take on satisfying both wor= lds looks like this

- allow just JAR - no other pa= rams when possible.
=C2=A0 =C2=A0 (which btw isn't possible t= o do with request_uri when enforcing client based uri whitelist and the jws= req 5.2.2 shows as much)
- enforce the "dupe behaviours"= ; defined in OIDC (if response_type or client_id is in request object it mu= st either be missing or the same in regular request).
- allows me= rging request object and regular parameters with request object taking=C2= =A0precedence since it is a very useful feature when having pre-signed requ= est object that's not one time use and clients using it wish to vary st= ate/nonce per-request.

I wish the group reconsider= ed making this breaking change from OIDC's take on request objects - al= low combination of parameters from the request object with ones from regula= r parameters (if not present in request object).

S pozdravem,
Filip Skokan


On We= d, 28 Aug 2019 at 23:02, Brian Campbell <bcampbell@pingidentity.= com> wrote:
Filip, for better or worse, I beli= eve your assessment of the situation is correct. I know of one AS that didn= 't choose which of the two to follow but rather implemented a bit of a = hybrid where it basically ignores everything outside of the request object = per JAR but also checks for and enforces the presence and value of the few = regular parameters (client_id, response_type) that OIDC mandates.

On Tu= e, Aug 27, 2019 at 5:47 AM Filip Skokan <panva.ip@gmail.com> wrot= e:
Hello everyone,

in an earlier threa= d I've posed the following question that might have gotten missed, this= might have consequences for the existing implementations of Request Object= s in OIDC implementations - its making pure JAR requests incompatible with = OIDC Core implementations.

<= div style=3D"color:rgb(0,0,0)">draft 14 of jwsreq (JAR) introduced this lan= guage

The client MAY send the parameters incl= uded in the request object
duplicated in the query parameters as well fo= r the backward
compatibility etc. =C2=A0However, the authorization se= rver supporting this
specification MUST only use the parameters included= in the request
object.=C2=A0

Server MUST = only use the parameters in the Request Object even if the
same parameter= is provided in the query parameter.=C2=A0 The Authorization

The client MAY send the parameters included in the r= equest object
duplicated in the query parameters as well for the backwar= d
compatibility etc. =C2=A0However, the authorization server supporti= ng this
specification MUST only use the parameters included in the reque= st
object.=C2=A0

Nat, John, everyone -=C2=A0does this mean a JAR compliant= AS ignores everything outside of the request object while OIDC Request Obj= ect one merges the two with the ones in the request object being used over = ones that are sent in clear?=C2=A0The OIDC language also includes secti= ons which make sure that some required arguments are still passed outside o= f the request object with the same value to make sure the request is "= valid" OAuth 2.0 request (client_id, response_type), something which a= n example in the JAR spec does not do. Not having this language means that = existing authorization request pipelines can't simply be extended with = e.g. a middleware, they need to branch their codepaths.

Is an AS requir= ed to choose which of the two it follows?

Thank you for clarifying this= in advance. I think if either the behaviour is the same as in OIDC or diff= erent this should be called out in the language to avoid confusion, especia= lly since this already exists in OIDC and likely isn't going to be read= in isolation, especially because the Request Object is even called out to = be already in place in OIDC in the JAR draft.

Best,
Filip
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confide= ntial and privileged material for the sole use of the intended recipient(s)= . Any review, use, distribution or disclosure by others is strictly prohibi= ted.=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 attach= ments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and= privileged material for the sole use of the intended recipient(s). Any rev= iew, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 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 f= rom your computer. Thank you.____________________________= ___________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Nat Sakimura (=3Dnat)
--0000000000004384520599f5326b-- From nobody Tue Dec 17 23:44:30 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86021208DF for ; Tue, 17 Dec 2019 23:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.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 njLNM5_Nv5lT for ; Tue, 17 Dec 2019 23:44:24 -0800 (PST) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94EDB1208DC for ; Tue, 17 Dec 2019 23:44:24 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id f71so1344604otf.2 for ; Tue, 17 Dec 2019 23:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F5tr63KToC4gL9nmf/amArUIwsNSHtNT3AWsuuMleoE=; b=ADdARjb3zLIytVF4QrP8YF1tmIhwDdWRiNZqUcuQ6YNXj230SRB7It6hiNhl72sVA3 gprG/UK7/HSmJRyhAXf/apTh4eItdM6JB3eXeaP8hOEro4Mb/BqTo8+wq1Gt+Mizg8L/ XfA5MwZgfoo7rjLc+1QktlNCdUyQaUgN82iD4xKNr6C1Zy15AUDgh6OLULSkpumsJPP+ sZr42IauiXpgPyUGPXpU59FiI0F1nn/S2cyIApyzLIvZukvmiGIR/+ptPqo4bYHR8th0 2r2Hv1S44qQ9Kdmq6c63vHJwBlq0ilfD7t8cTvTC8B6hyyBrVUvU36XzPgiVjsF7M/rI 5JYA== 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=F5tr63KToC4gL9nmf/amArUIwsNSHtNT3AWsuuMleoE=; b=bzqtXilR0oolOhbY66hDKzXRfkM98/ntwP3g+chkKA8QaO4V9SyAIo36m3QSfjkT5D /3S/55KL2w9b6782N7cJq8gS43G6ovcZrbzzUOp4DPmh9tO0GyhX17+1FmBLJhIOUNi2 clnoCcGMZipIWmlQIU093PZRI3eWpsozj82T3ehvPbr2O9Kf9FXFMOOVYbfCWSzVVoZc yQ1wXJyvhS3aN6NTyZdE/4JUhyb6mwHOOKodELTh0oQHajh94FnHbxNYjU5T7gZh9//a gUF+8mEDLrISeC2mjUCI6hIr3Yilnyk7grJXFCkkmaWoqzqAFuqyyOF8jbIw+mXJW7Lc X//g== X-Gm-Message-State: APjAAAWd9kQLn+u28ZlUjyzOBbf6LXzkHE1N4HMJyewyHpLj9ekf+Vs8 UuMxKhJE7bFF2gsqPcgz54seHcaTQGHbxrwrwZ7alg== X-Google-Smtp-Source: APXvYqz6NSoNppKbgnBa1mpEAj4OSTCXIOmElC1YPuehv7EaDPbMBm5RAatpurYSJ5s/6fACMl2nE8Q8EEtwx/zHDFA= X-Received: by 2002:a9d:754a:: with SMTP id b10mr1187974otl.273.1576655063532; Tue, 17 Dec 2019 23:44:23 -0800 (PST) MIME-Version: 1.0 References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> In-Reply-To: From: Steinar Noem Date: Wed, 18 Dec 2019 08:44:12 +0100 Message-ID: To: "Richard Backman, Annabelle" Cc: Vittorio Bertocci , IETF oauth WG , "i-d-announce@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fed87f0599f59c47" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 07:44:29 -0000 --000000000000fed87f0599f59c47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Vittorio! At HelseID we indicate the method that was used for client authentication in our ATs. For us, this is the case both with or without a user. If the client used a client-assertion for authentication we would give some indication about the key material that was used. In our case that would be either a x.509 enterprise certificate (that carries an organizational number) or a key-pair. We actually use a client analog to *amr*, as Anabelle suggests. These claims add value for the resources that rely on for several reasons, one being authorization policies for APIs that expose sensitive data. - Steinar tir. 17. des. 2019 kl. 02:28 skrev Richard Backman, Annabelle : > 1. Regarding AuthenticatedClient: > > Does a mobile app that uses Dynamic Client Registration to establish a > client secret count as an =E2=80=9Cauthenticated client=E2=80=9D? What if= that registration > included an assertion signed by a trusted entity (e.g., device management > software) using a certificate that had been pushed to the device? Without > some kind of NIST LoA-style definition of =E2=80=9Cauthenticated=E2=80=9D= , a single Boolean > =E2=80=9CAuthenticatedClient=E2=80=9D value is too ambiguous to be useful= . However, I=E2=80=99m > skeptical that we could find consensus on what that definition should be, > and it may be better to define client analogs to `acr` and `amr` that > provide standard ways of expressing client authentication details without > getting prescriptive about what kind of authentication is =E2=80=9Cgood e= nough.=E2=80=9D > > > > 2. Regarding authentication session properties: > > I=E2=80=99m confused by the definitions given for `auth_time`, `acr`, and= `amr`. > For `auth_time`, it says: > > > > =E2=80=9C=E2=80=A6its value will either remain the same for all the JWT a= ccess tokens > issued within that session or be updated to the time of latest > authentication if reauthentication occurred mid-session=E2=80=A6=E2=80=9D > > > > But the =E2=80=9CFor example=E2=80=9D at the end of that definition impli= es that > `auth_time` will not be updated. The definitions for `acr` and `amr` say > the same, but also say that the =E2=80=9C=E2=80=A6same considerations pre= sented for > auth_time apply=E2=80=A6=E2=80=9D What=E2=80=99s the intention here: are = they fixed, updated, or is > it up to the deployment to decide? > > > > I=E2=80=99d like to better understand the use case for putting these in t= he access > token. If the RS is making authorization decisions based on these claims, > that implies that the RS cannot rely on the AS to determine (e.g., from t= he > requested scope) the required authentication method(s), freshness, etc. I= f > the AS could be relied upon for this, then presumably it would not issue > RTs and ATs for a scope without requiring the end user to meet the > appropriate authentication requirements. If this is the case, then the RS > must have a way to signal to the client (and then the AS) that a step-up > authentication is required. Is there an existing mechanism through which > they could do this? All I can come up with is cramming the information in= to > the scope attribute of a WWW-Authenticate challenge, but that has the sam= e > scope opacity violation problem as described in this draft=E2=80=99s Secu= rity > Considerations. Without a clear way to express the step-up requirements, > this feels incomplete. > > > > 3. Regarding access tokens that are used to access different resource > servers: > Reading between the lines, I **think** the intention is that a JWT access > token that is intended to be used to access two different resources at tw= o > different RSes should look something like: > > > > { > > "aud": "https://generic-resource-indicator.example.com/", > > "scope": "resource_foo resource_bar", > > ... > > } > > > And the expectation is that each RS should recognize that generic > audience. Is this correct? If so it seems to go against the spirit of > resource indicators as indicating the target or location of a resource. > It=E2=80=99s stretching that definition, at the very least. > > > > But as I said, I=E2=80=99m reading between the lines here. If this is the > intention, it should be clearly stated. Alternatively, remove (or change = to > a SHOULD) the requirement that multi-value `aud` claims must only contain > aliases for the same resource indicator. > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Vittorio Bertocci > > *Date: *Monday, December 16, 2019 at 2:51 PM > *To: *IETF oauth WG > *Cc: *"i-d-announce@ietf.org" > *Subject: *Re: [OAUTH-WG] I-D Action: > draft-ietf-oauth-access-token-jwt-03.txt > > > > Dear all, > I finally found the time to push a new draft of the JWT profile for ATs. > This version incorporates the feedback kindly provided by Brian and Aaron > at IETF105. > Unfortunately I didn't have a chance to participate to IETF106, hence we > didn't do much progress since then. > There are still two areas we didn't manage to reach consensus on: > > 1. Mechanisms for signaling whether the AT was obtained by a user or an > application > > This point was the subject of intense debate on the list leading to > IETF105. > One insight that emerged from the IETF105 discussion was that the use cas= e > here is more about whether the AT has been obtained via a grant that > authenticated the client (regardless of what specific grant was used) vs = a > public client grant- that information can be relevant to a resource as it > determines whether the identity of the client can be used in authorizatio= n > decisions (in the former case) or not (in the public client case). If > that's the scenario we are truly after, a simple, possibly optional boole= an > claim (say AuthenticatedClient) would suffice. > Note for the people who didn't read the spec: I removed any reference to > this already in draft-ietf-oauth-access-token-jwt-01. I think this is an > important and useful info and standardizing it would be beneficial for > middleware and SDK creators, but ultimately this is an interop profile > hence if there's no strong desire to reach an agreement here, I am also O= K > with dropping the matter and not address this function in the spec. > To summarize, I have two questions here: > > A. Do we believe it's worth it to formalize in the profile a mechanism to > indicate whether the client th obtained the AT authenticated itself with > the AS? > B. If yes, are you OK wiht an optional bool claim here? > > > 2. Claims indicating session properties > > This is one area where I am far more passionate about, as it represents a > fundamental aspect that production systems (and in particular 1st party > solutions) already rely on in the current proprietary JTW ATs. > The profile currently includes the claims auth_time, acr and amr - > capturing the values of those properties at the time of the latest > authentication the user performed in the session used to issue the curren= t > AT: at session creation, at auth step up time and so on. > Those are values that API need in order to make authorization decisions; > in the case of 1st party APIs, the AT is the only artifact they ever > receive hence there is no other way for an API to determine whether the > caller performed say MFA in order to obtain the current AT. > Since the first draft, some people signaled concerns about the current > mechanisms thru which those claims get their value. For example, it has > been proposed to maintain the original values of auth_time, acr & amr and > introduce additional claims to indicate changes (like stepup). > I am not clear on what cold go wrong with the current approach, hence I > don't have an immediate grasp of how changes like the above would help. > If the people uncomfortable with the current proposal could detail their > concern, we can brainstorm ways to make that info available to API in a > safer way. To summarize: > > A. Do you have concerns with the current auth_time, arm, acr proposal? Ca= n > you spell them out? (please read the relevant parts of the spec before > chiming in :)) > B. If yes, what can we do to make that info available to RSs in a way tha= t > makes you comfortable? > > > > Thanks > > V. > > > > On Mon, Dec 16, 2019 at 2:49 PM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IET= F. > > Title : JSON Web Token (JWT) Profile for OAuth 2.0 > Access Tokens > Author : Vittorio Bertocci > Filename : draft-ietf-oauth-access-token-jwt-03.txt > Pages : 16 > Date : 2019-12-16 > > Abstract: > This specification defines a profile for issuing OAuth 2.0 access > tokens in JSON web token (JWT) format. Authorization servers and > resource servers from different vendors can leverage this profile to > issue and consume access tokens in interoperable manner. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-03 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-0= 3 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | --000000000000fed87f0599f59c47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vittorio!

=
At HelseID we indicate the method that was used for= client authentication in our ATs. For us, this is the=C2=A0case both with = or without a user.
If the client used a client-asser= tion for authentication we would give some indication about the key materia= l that was used. In our case that would be either a x.509 enterprise=C2=A0c= ertificate (that carries=C2=A0an organizational number) or a key-pair.
We actually use a client analog to amr, as Anabelle suggests.<= br>

These claims add value for the resources that = rely on=20 for several reasons, one being authorization policies for APIs that expose = sensitive data.

- Steinar=C2=A0

tir. 17. des.= 2019 kl. 02:28 skrev Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:

1. Regarding AuthenticatedClient:

Does a mobile app that uses Dynamic Client Registrat= ion to establish a client secret count as an =E2=80=9Cauthenticated client= =E2=80=9D? What if that registration included an assertion signed by a trus= ted entity (e.g., device management software) using a certificate that had been pushed to the device? Without some kind of NIS= T LoA-style definition of =E2=80=9Cauthenticated=E2=80=9D, a single Boolean= =E2=80=9CAuthenticatedClient=E2=80=9D value is too ambiguous to be useful.= However, I=E2=80=99m skeptical that we could find consensus on what that definition should be, and it may be better to define client analogs to `ac= r` and `amr` that provide standard ways of expressing client authentication= details without getting prescriptive about what kind of authentication is = =E2=80=9Cgood enough.=E2=80=9D

=C2=A0

2. Regarding authentication session properties:

I=E2=80=99m confused by the definitions given for `a= uth_time`, `acr`, and `amr`. For `auth_time`, it says:

=C2=A0

=E2=80=9C=E2=80=A6its va= lue will either remain the same for all the JWT access tokens issued within= that session or be updated to the time of latest authentication if reauthe= ntication occurred mid-session=E2=80=A6=E2=80=9D

=C2=A0

But the =E2=80=9CFor example=E2=80=9D at the end of = that definition implies that `auth_time` will not be updated. The definitio= ns for `acr` and `amr` say the same, but also say that the =E2=80=9C=E2=80= =A6same considerations presented for auth_time apply=E2=80=A6=E2=80=9D What= =E2=80=99s the intention here: are they fixed, updated, or is it up to the deployment to decide?=

=C2=A0

I=E2=80=99d like to better understand the use case f= or putting these in the access token. If the RS is making authorization dec= isions based on these claims, that implies that the RS cannot rely on the A= S to determine (e.g., from the requested scope) the required authentication method(s), freshness, etc. If the AS could be = relied upon for this, then presumably it would not issue RTs and ATs for a = scope without requiring the end user to meet the appropriate authentication= requirements. If this is the case, then the RS must have a way to signal to the client (and then the AS) that= a step-up authentication is required. Is there an existing mechanism throu= gh which they could do this? All I can come up with is cramming the informa= tion into the scope attribute of a WWW-Authenticate challenge, but that has the same scope opacity violatio= n problem as described in this draft=E2=80=99s Security Considerations. Wit= hout a clear way to express the step-up requirements, this feels incomplete= .

=C2=A0

3. Regarding access tokens that are used to access d= ifferent resource servers:
Reading between the lines, I *think* the intention is that a JWT acc= ess token that is intended to be used to access two different resources at = two different RSes should look something like:

=C2=A0

{<= /span>

"aud": "https://generic-resource-indicator.e= xample.com/",

"scope": "resource_foo resource_bar",

...

}<= /span>


And the expectation is that each RS should recognize that generic audience.= Is this correct? If so it seems to go against the spirit of resource indic= ators as indicating the target or location of a resource. It=E2=80=99s stre= tching that definition, at the very least.

=C2=A0

But as I said, I=E2=80=99m reading between the lines= here. If this is the intention, it should be clearly stated. Alternatively= , remove (or change to a SHOULD) the requirement that multi-value `aud` cla= ims must only contain aliases for the same resource indicator.

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Bac= kman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org><= br> Date: Monday, December 16, 2019 at 2:51 PM
To: IETF oauth WG <oauth@ietf.org>
Cc: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jw= t-03.txt

=C2=A0

Dear all,
I finally found the time to push a new draft of the JWT profile for ATs. Th= is version incorporates the feedback kindly provided by Brian and Aaron at = IETF105.
Unfortunately I didn't have a chance to participate to IETF106, hence w= e didn't do much progress since then.
There are still two areas we didn't manage to reach consensus on:

1. Mechanisms for signaling whether the AT was obtained by a user or an app= lication

This point was the subject of intense debate on the list leading to IETF105= .
One insight that emerged from the IETF105 discussion was that the use case = here is more about whether the AT has been obtained via a grant that authen= ticated the client (regardless of what specific grant was used) vs a public= client grant- that information can be relevant to a resource as it determines whether the identity of the= client can be used in authorization decisions (in the former case) or not = (in the public client case). If that's the scenario we are truly after,= a simple, possibly optional boolean claim (say AuthenticatedClient) would suffice.
Note for the people who didn't read the spec: I removed any reference t= o this already in draft-ietf-oauth-access-token-jwt-01. I think this is an = important and useful info and standardizing it would be beneficial for midd= leware and SDK creators, but ultimately this is an interop profile hence if there's no strong desire to reach = an agreement here, I am also OK with dropping the matter and not address th= is function in the spec.
To summarize, I have two questions here:

A. Do we believe it's worth it to formalize in t= he profile a mechanism to indicate whether the client th obtained the AT au= thenticated itself with the AS?
B. If yes, are you OK wiht an optional bool claim here?


2. Claims indicating session properties

This is one area where I am far more passionate about, as it represents a f= undamental aspect that production systems (and in particular 1st party solu= tions) already rely on in the current proprietary JTW ATs.
The profile currently includes the claims auth_time, acr and amr - capturin= g the values of those properties at the time of the latest authentication t= he user performed in the session used to issue the current AT: at session c= reation, at auth step up time and so on.
Those are values that API need in order to make authorization decisions; in= the case of 1st party APIs, the AT is the only artifact they ever receive = hence there is no other way for an API to determine whether the caller perf= ormed say MFA in order to obtain the current AT.
Since the first draft, some people signaled concerns about the current mech= anisms thru which those claims get their value. For example, it has been pr= oposed to maintain the original values of auth_time, acr & amr and intr= oduce additional claims to indicate changes (like stepup).
I am not clear on what cold go wrong with the current approach, hence I don= 't have an immediate grasp of how changes like the above would help. If the people uncomfortable with the current proposal could detail their co= ncern, we can brainstorm ways to make that info available to API in a safer= way. To summarize:

A. Do you have concerns with the current auth_time, = arm, acr proposal? Can you spell them out? (please read the relevant parts = of the spec before chiming in :))
B. If yes, what can we do to make that info available to RSs in a way that = makes you comfortable?



Thanks

V.

=C2=A0

On Mon, Dec 16, 2019 at 2:49 PM <internet-drafts@ietf.org&= gt; wrote:


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Vitt= orio Bertocci
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-access-token-jwt-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-12-16

Abstract:
=C2=A0 =C2=A0This specification defines a profile for issuing OAuth 2.0 acc= ess
=C2=A0 =C2=A0tokens in JSON web token (JWT) format.=C2=A0 Authorization ser= vers and
=C2=A0 =C2=A0resource servers from different vendors can leverage this prof= ile to
=C2=A0 =C2=A0issue and consume access tokens in interoperable manner.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-ac= cess-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-tok= en-jwt-03
https://datatracker.ietf.org/doc/html/draft-i= etf-oauth-access-token-jwt-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-= oauth-access-token-jwt-03


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

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

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

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


--
Vennlig hilsen=

Steinar Noem
Partner Udelt AS
Systemutvikler<= /div>
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@udelt.n= o=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.= no=C2=A0|=C2=A0
--000000000000fed87f0599f59c47-- From nobody Wed Dec 18 00:09:23 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E791208DC for ; Wed, 18 Dec 2019 00:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yedsRxAylB2z for ; Wed, 18 Dec 2019 00:09:19 -0800 (PST) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0: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 51E661208DF for ; Wed, 18 Dec 2019 00:09:19 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id i1so492498oie.8 for ; Wed, 18 Dec 2019 00:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vzz1b41fFTrXCf5ZkK8D0u/TPYi7cLNHH1Uu7gVyYco=; b=RYQE0vRAKU6cn2NbXQH8r1yTuIzyc5UtXgibaxBmy0KgAjRA2O4MBvsXgv6jGOz8dg b1ARq3P++ZS/reIp8Bray1eFmC0GHWwXrtf1tCyva6XA7+UFmRO3OZnQH+Dz89B4oz/0 J1riDzHMSwbgw4kRhkIMx4EGsU+MDwE5mIYp0= 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=Vzz1b41fFTrXCf5ZkK8D0u/TPYi7cLNHH1Uu7gVyYco=; b=BOb9V5chNbbMUa2RNcn5M8jNhehiZ0iv8dMu5+4cElleBQLXVVLFJC754Oyvzoy+qL zEMoOoOL79J+O32Dl/0rQFnM4oeWf73HHfdpUmkvnv6abDcovqurqF3tsKiJI9QetlCj 3mPTiCZwfadgT7Cpv7vTNcyhiLVamhWbySpvkqijsWUglyz5l4ioB92o1mZ7a0IgspNo F5BxrZN2FzrA15w35jn1cVQWuBFl9rnUCD5pxnK7xFkembeX39sHfoAiXsdPWFiL2d9Y PP3fOhshA2NZ3Zw91nWS99Pb8BEFBgXwad+OLUt5nA/VkRCOaDy7ivqPRInZe1EtDdGH SCAg== X-Gm-Message-State: APjAAAXEQF/ipIoCIuiiNn2gWSvfgqkkNX7i+5He7QRbV17VbrKs4tDy u37Gif8EK3r28AFIbijAPTSnQkpm88ZGwOf0gOs1RRJaFWyXjA== X-Google-Smtp-Source: APXvYqz4QYtIX6ZbMs+soT06+dtnY5NjUyt92HdWGEY0jI+ISpR5At0aG8wNxkY7h2Zqg+q5VwLOsqeCIojcWEXdXSU= X-Received: by 2002:aca:180a:: with SMTP id h10mr78610oih.99.1576656558316; Wed, 18 Dec 2019 00:09:18 -0800 (PST) MIME-Version: 1.0 References: <7cd6d76d-3734-532e-06a2-12adc9600d63@ve7jtb.com> In-Reply-To: From: Dave Tonge Date: Wed, 18 Dec 2019 09:09:07 +0100 Message-ID: To: n-sakimura Cc: John Bradley , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001778130599f5f601" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 08:09:21 -0000 --0000000000001778130599f5f601 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support the adoption of PAR On Wed, 18 Dec 2019 at 04:06, n-sakimura wrote: > +1 > > > > =E9=87=8E=E6=9D=91=E7=B7=8F=E5=90=88=E7=A0=94=E7=A9=B6=E6=89=80 IT=E5=9F= =BA=E7=9B=A4=E6=8A=80=E8=A1=93=E6=88=A6=E7=95=A5=E5=AE=A4 > > =E4=B8=8A=E5=B8=AD=E7=A0=94=E7=A9=B6=E5=93=A1 =E5=B4=8E=E6=9D=91=E5=A4=8F= =E5=BD=A6 > > E: n-sakimura@nri.co.jp > > T: +81(90)60136276 > > --------------------------------------------------------- > > > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81= =E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3= =81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF= =86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84= =E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3= =81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81= =AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85= =E3=81=AB=E3=81=94=E9=80=A3=E7=B5=A1=E3=81=AE=E3=81=86=E3=81=88=E3=80=81=E3= =81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=82=92=E5=89=8A=E9=99=A4=E3=81= =97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=BE=E3=81=99=E3=82=88= =E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=E4=B8=8A=E3=81=92=E3= =81=BE=E3=81=99=E3=80=82 > > PLEASE READ:This e-mail is confidential and intended for the named > recipient only. If you are not an intended recipient, please notify the > sender and delete this e-mail. > > > > *From:* OAuth *On Behalf Of *John Bradley > *Sent:* Tuesday, December 17, 2019 11:15 PM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed > Authorization Requests > > > > I support addoption > > On 12/17/2019 11:01 AM, Aaron Parecki wrote: > > I support the adoption of PAR. > > > > Aaron Parecki > > > > > > On Tue, Dec 17, 2019 at 4:59 AM Rifaat Shekh-Yusef > wrote: > > All, > > > > This is a call for adoption of for the OAuth 2.0 Pushed Authorization > Requests document. > > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ > > > > There was a good support for this document during the Singapore meeting, > and on the mailing list in the Meeting Minutes thread. > > > > Please, let us know if you support or object to adopting this document as > a working group document by Dec 27th. > > > > If you have already indicated your support on the Meeting Minutes thread, > you do not need to do it again on this thread. > > > > Regards, > > Rifaat & Hannes > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > ---- > > Aaron Parecki > > aaronparecki.com > > @aaronpk > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Dave Tonge CTO [image: Moneyhub Enterprise] Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772 . Moneyhub Financial Technology Limited 2018 =C2=A9 DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company. --0000000000001778130599f5f601 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the adoption of PAR

On Wed, 18 Dec 2019 at = 04:06, n-sakimura <n-sakimura@nr= i.co.jp> wrote:

+1=

=C2=A0

=E9=87=8E=E6=9D=91=E7=B7=8F=E5=90=88= =E7=A0=94=E7=A9=B6=E6=89=80=E3=80=80IT=E5=9F=BA= =E7=9B=A4=E6=8A=80=E8=A1=93=E6=88=A6=E7=95=A5=E5=AE=A4=

=E4=B8=8A=E5=B8=AD=E7=A0=94=E7=A9=B6= =E5=93=A1=E3=80=80=E5=B4=8E=E6=9D=91=E5=A4=8F=E5=BD=A6=

E: n-sakimura@nri.co.jp

T: +81(90)60136276

-----------------------= ----------------------------------

=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC= =E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5= =85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81= =95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB= =E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3= =81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81= =82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF= =E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=AB=E3=81=94=E9=80=A3=E7=B5=A1=E3= =81=AE=E3=81=86=E3=81=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB=E3=82=92=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95= =E3=81=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7= =94=B3=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82

PLEASE READ:This e-mail = is confidential and intended for the named recipient only. If you are not a= n intended recipient, please notify the sender and delete this e-mail.

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Tuesday, December 17, 2019 11:15 PM
To: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authoriz= ation Requests

=C2=A0

I support addoption

On 12/17/2019 11:01 AM, Aaron P= arecki wrote:

I support the adoption of PAR.<= u>

=C2=A0

Aaron Parecki

=C2=A0

=C2=A0

On Tue, Dec 17, 2019 at 4:59 AM= Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

=C2=A0

This is a call for adoption of = for the=C2=A0OAuth 2.0 Pushed Authorization Requests document.

=C2=A0

There was a good support for th= is document during the Singapore meeting, and on the mailing list in the Me= eting Minutes thread.

=C2=A0

Please, let us know if you supp= ort or object to adopting this document as a working group document by Dec = 27th.

=C2=A0

If you have already indicated y= our support on the Meeting Minutes thread, you do not need to do it again o= n this thread.

=C2=A0

Regards,

=C2=A0Rifaat & Hannes

=C2=A0

=C2=A0

=C2=A0

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

--

----

Aaron Parecki

=C2=A0



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


--
Da= ve Tonge
CTO
3D"Moneyhub
Moneyhub Financial Technology, 5th Fl= oor, 10 Temple Back, Bristol, BS1 6FL
t:=C2=A0+44 (0)117 280 512= 0

Moneyhub = Enterprise is a trading style of Moneyhub Financial Technology Limited whic= h is authorised and regulated by the Financial Conduct Authority ("FCA= ").=C2=A0Moneyhub Financial Technology is entered on the Financial Ser= vices Register=C2=A0(FRN=C2=A0809360) at fca.= org.uk/register. Moneyhub=C2=A0Financial Technology is registered in England &= ; Wales, company registration number=C2=A0=C2=A006909772=C2=A0.<= /span>
Moneyhub=C2=A0Financial Technology L= imited 2018=C2=A0=C2=A9<= /div>

DISCLAIMER: This email (including any attachments) is subject to co= pyright, and the information in it is confidential. Use of this email or of= any information in it other than by the addressee is unauthorised and unla= wful. Whilst reasonable efforts are made to ensure that any attachments are= virus-free, it is the recipient's sole responsibility to scan all atta= chments for viruses. All calls and emails to and from this company may be m= onitored and recorded for legitimate purposes relating to this company'= s business. Any opinions expressed in this email (or in any attachments) ar= e those of the author and do not necessarily represent the opinions of Mone= yhub Financial Technology Limited or of any other group company.
<= /div>
--0000000000001778130599f5f601-- From nobody Wed Dec 18 06:20:25 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3795A1200D8 for ; Wed, 18 Dec 2019 06:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=authlete-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 LdPUb-dJZ1Ho for ; Wed, 18 Dec 2019 06:20:22 -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 5375D1200BA for ; Wed, 18 Dec 2019 06:20:22 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id u2so2091182wmc.3 for ; Wed, 18 Dec 2019 06:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=zmgy3yrkzM+tNQw0D0zrkSOt7HZAU6SOyvxBC2oqIa4=; b=yPq2JGYf7MfUay+6Xo6dTgnkM9pL04RvXJfYOY33kamZLI7Cp7xMEuB2BPmAVmwc+N ro/K9KK4q89TVBSevLBxs3ZiBILc96OKP01mFdXP7ZTGhUxJaAysJaQOCMMOBth6KxJ9 beU97E4JRt+owC1gLvrAwJTjcAbIyT4eWr4YQDyEYx3kDgsFKdonWsetT9Dr7xfKNVo6 HmSkL43yc1Xy08uvhsy9k0mwqe90wbLAUiQWkU3+sdT5PQR7MwZPCt7Kr2bKRYJnzw0D WqhdfxxZwoXw8wNwiHG5L/PBrXvdBvesh25AQOyqE/flA7HFtJ1bxb+TTDC2cf+BO9/t qJZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=zmgy3yrkzM+tNQw0D0zrkSOt7HZAU6SOyvxBC2oqIa4=; b=Kp4LBRsD/hjH2F4DIc3UpIc6S9sPPx2L55xM5eRg5/Ibce2a4RcG6M1/HpxTgwGu+S rWsQAjsbJVJh5T3rx+6xkgCgmSNxt31WjrBbjZXcFwSM9gX6mZO64pJejcTUL1GIYTZ0 vmtj53gFFSa8OVo4l6Y/DIuldFsetJeHny9/9mYEkGBGn+be5WIiriRAsPu7HkzCtDPd 9oVVz7o5Vwx9aHSLYmOz2ClTqZGv2rqaHa1HYe65p+oY74tzqSnXcrT+fSw1XCUF/l7X dR+2Nli37GoEE0JQq6xQFfo3OlntwqtZKwmwuo1EIz0ghOvoojvT/IKdcplv1WvVEX4C zm3A== X-Gm-Message-State: APjAAAWgqUxsBnP4OZq9MrWyDHNcYn0r5yFUh5CIPWoD8I2hj//7i+w0 tjPdpqV2Y3mjikbiZWJyoOJuCQjF36aQXQ== X-Google-Smtp-Source: APXvYqw0S629A3V0bZOUMLybEnqFQBWgVQjxcvpBtszPcwdTvP52w44Fr5VUXAk0XguTHMKtoeh77A== X-Received: by 2002:a05:600c:2148:: with SMTP id v8mr3725223wml.111.1576678820649; Wed, 18 Dec 2019 06:20:20 -0800 (PST) Received: from [192.168.78.199] (glasgow.emobix.co.uk. [87.117.93.88]) by smtp.gmail.com with ESMTPSA id v83sm2662685wmg.16.2019.12.18.06.20.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Dec 2019 06:20:19 -0800 (PST) From: Joseph Heenan Content-Type: multipart/alternative; boundary="Apple-Mail=_E1884F19-F418-4C10-B58B-3AE186B7EDF5" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 18 Dec 2019 14:20:18 +0000 References: To: oauth In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 14:20:24 -0000 --Apple-Mail=_E1884F19-F418-4C10-B58B-3AE186B7EDF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support the adoption of PAR. Thanks Joseph > On 17 Dec 2019, at 12:59, Rifaat Shekh-Yusef = wrote: >=20 > All, >=20 > This is a call for adoption of for the OAuth 2.0 Pushed Authorization = Requests document. > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ = =20 >=20 > There was a good support for this document during the Singapore = meeting, and on the mailing list in the Meeting Minutes thread. >=20 > Please, let us know if you support or object to adopting this document = as a working group document by Dec 27th. >=20 > If you have already indicated your support on the Meeting Minutes = thread, you do not need to do it again on this thread. >=20 > Regards, > Rifaat & Hannes >=20 >=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_E1884F19-F418-4C10-B58B-3AE186B7EDF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = support the adoption of PAR.

Thanks

Joseph


= --Apple-Mail=_E1884F19-F418-4C10-B58B-3AE186B7EDF5-- From nobody Wed Dec 18 13:09:17 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56090120C01 for ; Wed, 18 Dec 2019 13:09: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, 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=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 2pz8_tqYz5Ya for ; Wed, 18 Dec 2019 13:09:13 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13C5D1200EB for ; Wed, 18 Dec 2019 13:09:13 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id l18so2748141lfc.1 for ; Wed, 18 Dec 2019 13:09:12 -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=A8ab23f7denEOfkYqbAHaLF18l//e9tggzI6BP6QqXw=; b=RXYF4YnTmoUIOViZqdPUgI2pgYwO3lYkdW3wEN63W2avDl0kbgB7MGXXLbgbjkuJu4 81IgO4L5Bslg/+mbvdz1ti3fNP5OsYk7oumY7Ddu22tSWBrbiwN/n3qRHFf0ve67uQOE iZjMMx1+Jn85JpaZ/BiG7JEYdBjoVeWe0MRRY95KkGJEAcvdxhiorCSRuFqswprXAII+ CDUA8xVkm0LzoYCK7CDmkbnSCG1yY5hLAkDAkAJ+ankgOfsnQNwZ2m4bbQq/EhiZAvXs b1Kj3Sqb0wgPjYjbIkB+Sr3xVnX0/zBXk7moMgKukjIEpBvqjAKaS4s4wXdxRyNuAuTq w2IQ== 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=A8ab23f7denEOfkYqbAHaLF18l//e9tggzI6BP6QqXw=; b=Y5nWQ8QhAa7ANlojDS6gAIxIowRRbDjpWEtWkz+owqSBIKg3KJIeyVgBhcEtY0Z9vb kFK8EvNwR7m63XmQxQAgu1TjCwx31dBDo/y9kK+2h5eIyEGNz0Y3NN83JWAs/BVjn5fc ZXRojungEfwyRnT14Nrt0ycr5eEmIyth2T2T3V/sJxfQW13JSJEKWBqYCdffJ54Br0La IYGeB9ZrkxKc5qkDKT5jrCcGmZRVI1YHd73Ivdz/MnQkfIL7i8V1frY+lNP5JLAOEip8 cQ0BK0k0P9lBKG6AIJNQtHuA19ZRHjRO9C0pBEX0VZ5b/DDvQcz1qRKqqfOcG0xQpP4m qdjA== X-Gm-Message-State: APjAAAVVQ34PF3WL54izk2R75XYuEtnjijj5bTMrB6jeOmcBEugmgI+r aw+huPa/vU63FT89e+javYdfIRgHEbPvjQkJSqUTzLCJwK0PR2bjLR93N/QjgZDHvMagPhfszMI uIMFYpazdjpIvbg== X-Google-Smtp-Source: APXvYqz/IvOCeW0uxvSJA7YWjf/AoeAntnvA9GEYCmVodJbwPGBd4xiUjI0DtOdy/EdYff3fodK/1iC392U3oS966R8= X-Received: by 2002:ac2:4884:: with SMTP id x4mr3025332lfc.92.1576703351101; Wed, 18 Dec 2019 13:09:11 -0800 (PST) MIME-Version: 1.0 References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Wed, 18 Dec 2019 14:08:44 -0700 Message-ID: To: Vittorio Bertocci Cc: "Richard Backman, Annabelle" , IETF oauth WG , "i-d-announce@ietf.org" Content-Type: multipart/alternative; boundary="00000000000028bd79059a00db21" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 21:09:16 -0000 --00000000000028bd79059a00db21 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 16, 2019 at 9:20 PM Vittorio Bertocci wrote: > > authentication session properties: > > Let me try another angle. Say that I perform an authz code grant asking > for AT, ID_T and RT- obtaining AT', ID_T' and RT'. > The values of auth_time, acr and amr in AT' will be the same as the > corresponding claims in ID_T'. When the client uses RT' to obtain AT`N, > AT'N+1 etc etc, the values of those claims will remain the same for every > AT'n obtained by RT'. > Now, imagine that something happens (ignore what for the time being) that > causes the client to perform a step up auth, which requires the user to > perform interactive auth hence results in a new authz grant. The client > will obtain a new tuple AT", ID_T" and RT". The exact same rules describ= ed > for the ' tuple apply, with the new values determined by the new > authentication: AT" auth_time/acr/amr will be the same as ID_T", and thos= e > values will remain unchanged for every AT"n derived by RT". > If we want this to apply to the implicit flow as well, you can substitute > the RT with the session artifact. > Does that help clarifying the intent? If yes, do you feel that the curren= t > language does not describe this? > That makes sense. The current language for auth_time could be tightened up somewhat, however. I think there's still potential for it to be interpreted such that AT'N+1 would somehow magically get a new auth_time value based on a step-up or re-auth that happened after, and independent of, the authentication event that led to the code that obtained RT'. Which is nonsensical. Also "authenticaiton" is spelled funny. Here's an attempt at some words for auth_time: Suggested(ish) Text: auth_time OPTIONAL - as defined in section 2 of [OpenID.Core]. This claim represents the time at which the end user last authenticated during the session that was used to obtain the token. This means that all the JWT access tokens obtained with a given refresh token will all have the same value of auth_time, corresponding to the instant in which the user authenticated to obtain the refresh token. Current Text: auth_time OPTIONAL - as defined in section 2 of [OpenID.Core]. Important: as this claim represents the time at which the end user last authenticated, its value will either remain the same for all the JWT access tokens issued within that session or be updated to the time of latest authentication if reauthentication occurred mid-session (as it is the case for step up authenticaiton and similar occurrences). For example: all the JWT access tokens obtained with a given refresh token will all have the same value of auth_time, corresponding to the instant in which the user first authenticated to obtain the refresh token. --=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._ --00000000000028bd79059a00db21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Dec 16, 2019 at 9:20 PM Vittorio = Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

authentication session properties:= =C2=A0
=C2=A0Let me try another angle. Say that I perform = an authz code grant asking for AT, ID_T and RT- obtaining AT', ID_T'= ; and RT'.=C2=A0
The values of auth_time, acr and amr in AT&#= 39; will be the same as the corresponding claims in ID_T'. When the cli= ent uses RT' to obtain AT`N, AT'N+1 etc etc, the values of those cl= aims will remain the same for every AT'n obtained by RT'.
Now, imagine that something happens (ignore what for the time being) that = causes the client to perform a step up auth, which requires the user to per= form interactive auth hence results in a new authz grant. The client will o= btain a new tuple=C2=A0 AT", ID_T" and RT". The exact same rules described for the &= #39; tuple apply, with the new values determined by the new authentication:= AT" auth_time/acr/amr will be the same as ID_T", and those value= s will remain unchanged for every AT"n derived by RT".
If we w= ant this to apply to the implicit flow as well, you can substitute the RT w= ith the session artifact.=C2=A0
Does that help clarifying the int= ent? If yes, do you feel that the current language does not describe this?<= /div>

That makes sense. The cur= rent language for auth_time could be tightened up somewhat, however. I thin= k there's still potential for it to be interpreted such that AT'N+1= would somehow magically get a new auth_time=C2=A0value based on a step-up = or re-auth that happened after, and independent of, the authentication even= t that led to the code that obtained RT'. Which is nonsensical. Also &q= uot;authenticaiton" is spelled funny. Here's an attempt at some wo= rds for auth_time:


Suggested(is= h) Text:
=C2=A0=C2=A0 auth_time =C2=A0OPTIONAL - as defined i= n section 2 of [OpenID.Core].
=C2=A0 =C2=A0 =C2=A0 This claim represents= the time at which the end user
=C2=A0 =C2=A0 =C2=A0 last authenticated = during the session that was used to obtain the token.
=C2=A0 =C2=A0=C2= =A0=C2=A0 This means that all the JWT access tokens
=C2=A0 =C2=A0 =C2=A0= obtained with a given refresh token will all have the same value
=C2=A0= =C2=A0 =C2=A0 of auth_time, corresponding to the instant in which the user=
=C2=A0 =C2=A0 =C2=A0 authenticated to obtain the refresh token.


Current Text:
=C2=A0 =C2=A0auth_time = =C2=A0OPTIONAL - as defined in section 2 of [OpenID.Core].
=C2=A0 =C2=A0= =C2=A0 Important: as this claim represents the time at which the end user<= br>=C2=A0 =C2=A0 =C2=A0 last authenticated, its value will either remain th= e same for all
=C2=A0 =C2=A0 =C2=A0 the JWT access tokens issued within = that session or be updated to
=C2=A0 =C2=A0 =C2=A0 the time of latest au= thentication if reauthentication occurred
=C2=A0 =C2=A0 =C2=A0 mid-sessi= on (as it is the case for step up authenticaiton and
=C2=A0 =C2=A0 =C2= =A0 similar occurrences).=C2=A0 For example: all the JWT access tokens
= =C2=A0 =C2=A0 =C2=A0 obtained with a given refresh token will all have the = same value
=C2=A0 =C2=A0 =C2=A0 of auth_time, corresponding to the insta= nt in which the user first
=C2=A0 =C2=A0 =C2=A0 authenticated to obtain = the refresh token.
=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000028bd79059a00db21-- From nobody Wed Dec 18 13:19:34 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A08120A8C for ; Wed, 18 Dec 2019 13:19:31 -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 007SO6vx7JnL for ; Wed, 18 Dec 2019 13:19:29 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D69120232 for ; Wed, 18 Dec 2019 13:19:29 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id k8so3764873ljh.5 for ; Wed, 18 Dec 2019 13:19:29 -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=siyVp3YqTHugvkUYDzhkPKGPkt47K4LLCpu1nN7DYgg=; b=M7iHSMhQom8ak1KZD7R/n9uDcgnjak9pFI8QnTMvjF0xXYXF25cuhDB+pwUy8wsBIh 5iD8oFwPlohhe6Yds9i3hkzadRO1qn6Y87LYcex63v96vWKnqSCNYXeDhUsGvR8FOU8y zK73qqTMrpqCjpgol4A5hrdt6XesCJNOeeqHo/WogJIn7uwcz+fT7ZP3CWFyRaezil+b kki+BIykj71yJnwHdns0M0HnYOcTUDcjz42x6V7/aZW3C+yn53texMvIMarRBT2lJrnV r6Nt0OH+RYP6OYbKBIB9rA/CQwrFnxWro07NX6Ma8FVeDqCCu3Nnb8qBiUEHhX+3pVmd xMOQ== 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=siyVp3YqTHugvkUYDzhkPKGPkt47K4LLCpu1nN7DYgg=; b=RBSStq7uF2EP9jHCCcAv/CivkCn5qzHheWNFrvBhID8bO2+/ZvocZ2iJpQBacY2vct lJYUo2tadUDeIqqfgehXzY6Twuz/hZKsSqeaDqeDLl3E6+ulf1aZbiEQAeSrl9qQfzLm HgdnA91SfAHYmW/l9TFgtRyWg5+u3UJRZjg6FPtfUTR9h4hshBGiNq0wGK4wwfas92HF aL7VG6e4IhPhOaioNReY1HwEfH2Ad4ZANI0c+e5FFOcuN4+HZNWQlTBAdAJNntMLx4x3 Ji68o0OHy4NBtr9uUYFT5S/fXmi4Ymw1ysblzQmNZ/HTeVezj1cxMWOeDg7lv0XLRfgR WxGQ== X-Gm-Message-State: APjAAAV5fvIofIIvWgoBBIEYEBp+e+RpKWsIkAG8IAPuv1xxibDcgB+t h8BED6KMuMYLIWlbVGgvjSUC8NSdjG4SEWLqLr0ltyLaqV2ZXrI6r7DAPblP0fZb0yqjx6jHWhv R8w8zd6+KoWJ/dw== X-Google-Smtp-Source: APXvYqzPpfrg4kWja7KWFeE47OZgpj7vX9pazCQZvgFD8mb8xzLEcX+qEwJDgNxXu3mz/TJwUkGgHbuQ8tlqm0juHoE= X-Received: by 2002:a2e:81c7:: with SMTP id s7mr3382697ljg.3.1576703967428; Wed, 18 Dec 2019 13:19:27 -0800 (PST) MIME-Version: 1.0 References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Wed, 18 Dec 2019 14:19:00 -0700 Message-ID: To: Vittorio Bertocci Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000e51987059a00ffb9" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 21:19:32 -0000 --000000000000e51987059a00ffb9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable -03 Sec 2.1 has: "The typ header parameter for a JWT access token MUST be at+jwt. See the security considerations section for details on the importance of preventing JWT access tokens to be interpreted as id_tokens." As previously mentioned in https://mailarchive.ietf.org/arch/msg/oauth/BWH6BEhKt29aJ4TUYtcLckdCqO4 Connect doesn't say anything about checking the "typ" header of id tokens so typing ATs with "at+jwt" doesn't actually do anything to prevent JWT access tokens being used as id tokens. It can prevent misuse in the other direction. But this document probably shouldn't overstate what typing the JWT can accomplish. On Mon, Dec 16, 2019 at 3:50 PM Vittorio Bertocci wrote: > Dear all, > I finally found the time to push a new draft of the JWT profile for ATs. > This version incorporates the feedback kindly provided by Brian and Aaron > at IETF105. > Unfortunately I didn't have a chance to participate to IETF106, hence we > didn't do much progress since then. > There are still two areas we didn't manage to reach consensus on: > > 1. Mechanisms for signaling whether the AT was obtained by a user or an > application > > This point was the subject of intense debate on the list leading to > IETF105. > One insight that emerged from the IETF105 discussion was that the use cas= e > here is more about whether the AT has been obtained via a grant that > authenticated the client (regardless of what specific grant was used) vs = a > public client grant- that information can be relevant to a resource as it > determines whether the identity of the client can be used in authorizatio= n > decisions (in the former case) or not (in the public client case). If > that's the scenario we are truly after, a simple, possibly optional boole= an > claim (say AuthenticatedClient) would suffice. > Note for the people who didn't read the spec: I removed any reference to > this already in draft-ietf-oauth-access-token-jwt-01. I think this is an > important and useful info and standardizing it would be beneficial for > middleware and SDK creators, but ultimately this is an interop profile > hence if there's no strong desire to reach an agreement here, I am also O= K > with dropping the matter and not address this function in the spec. > To summarize, I have two questions here: > > A. Do we believe it's worth it to formalize in the profile a mechanism to > indicate whether the client th obtained the AT authenticated itself with > the AS? > B. If yes, are you OK wiht an optional bool claim here? > > > 2. Claims indicating session properties > > This is one area where I am far more passionate about, as it represents a > fundamental aspect that production systems (and in particular 1st party > solutions) already rely on in the current proprietary JTW ATs. > The profile currently includes the claims auth_time, acr and amr - > capturing the values of those properties at the time of the latest > authentication the user performed in the session used to issue the curren= t > AT: at session creation, at auth step up time and so on. > Those are values that API need in order to make authorization decisions; > in the case of 1st party APIs, the AT is the only artifact they ever > receive hence there is no other way for an API to determine whether the > caller performed say MFA in order to obtain the current AT. > Since the first draft, some people signaled concerns about the current > mechanisms thru which those claims get their value. For example, it has > been proposed to maintain the original values of auth_time, acr & amr and > introduce additional claims to indicate changes (like stepup). > I am not clear on what cold go wrong with the current approach, hence I > don't have an immediate grasp of how changes like the above would help. > If the people uncomfortable with the current proposal could detail their > concern, we can brainstorm ways to make that info available to API in a > safer way. To summarize: > > A. Do you have concerns with the current auth_time, arm, acr proposal? Ca= n > you spell them out? (please read the relevant parts of the spec before > chiming in :)) > B. If yes, what can we do to make that info available to RSs in a way tha= t > makes you comfortable? > > > > Thanks > > V. > > On Mon, Dec 16, 2019 at 2:49 PM wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol WG of the >> IETF. >> >> Title : JSON Web Token (JWT) Profile for OAuth 2.0 >> Access Tokens >> Author : Vittorio Bertocci >> Filename : draft-ietf-oauth-access-token-jwt-03.txt >> Pages : 16 >> Date : 2019-12-16 >> >> Abstract: >> This specification defines a profile for issuing OAuth 2.0 access >> tokens in JSON web token (JWT) format. Authorization servers and >> resource servers from different vendors can leverage this profile to >> issue and consume access tokens in interoperable manner. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-= 03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-03 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000e51987059a00ffb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
-03 Sec 2.1 has:
=C2=A0"The typ header parameter f= or a JWT access token MUST be at+jwt.=C2=A0 See=C2=A0 =C2=A0the security co= nsiderations section for details on the importance of
=C2=A0 =C2=A0= preventing JWT access tokens to be interpreted as id_tokens."

As previously mentioned in https://mailarchive.ietf.or= g/arch/msg/oauth/BWH6BEhKt29aJ4TUYtcLckdCqO4 Connect doesn't say an= ything about checking the "typ" header of id tokens so typing ATs= with "at+jwt" doesn't actually do anything to prevent JWT ac= cess tokens being used as id tokens. It can prevent misuse in the other dir= ection. But this document probably shouldn't overstate what typing the = JWT can accomplish.

On Mon, Dec 16, 2019 at 3:50 PM Vittorio Bertocci <Vi= ttorio=3D40auth0.com@dmarc.ie= tf.org> wrote:
Dear all,
I finally found the time to push a new = draft of the JWT profile for ATs. This version incorporates the feedback ki= ndly provided by Brian and Aaron at IETF105.
Unfortunately I didn't = have a chance to participate to IETF106, hence we didn't do much progre= ss since then.
There are still two areas we didn't manage to reach c= onsensus on:

1. Mechanisms for signaling whether the AT was obtained= by a user or an application

This point was the subject of intense d= ebate on the list leading to IETF105.
One insight that emerged from the = IETF105 discussion was that the use case here is more about whether the AT = has been obtained via a grant that authenticated the client (regardless of = what specific grant was used) vs a public client grant- that information ca= n be relevant to a resource as it determines whether the identity of the cl= ient can be used in authorization decisions (in the former case) or not (in= the public client case). If that's the scenario we are truly after, a = simple, possibly optional boolean claim (say AuthenticatedClient) would suf= fice.
Note for the people who didn't read the spec: I removed any re= ference to this already in draft-ietf-oauth-access-token-jwt-01. I think th= is is an important and useful info and standardizing it would be beneficial= for middleware and SDK creators, but ultimately this is an interop profile= hence if there's no strong desire to reach an agreement here, I am als= o OK with dropping the matter and not address this function in the spec.To summarize, I have two questions here:

A. Do we believe it'= s worth it to formalize in the profile a mechanism to indicate whether the = client th obtained the AT authenticated itself with the AS?
B. If yes, a= re you OK wiht an optional bool claim here?

2. Claims indic= ating session properties

This is one area where I am far more passio= nate about, as it represents a fundamental aspect that production systems (= and in particular 1st party solutions) already rely on in the current propr= ietary JTW ATs.
The profile currently includes the claims auth_time, acr= and amr - capturing the values of those properties at the time of the late= st authentication the user performed in the session used to issue the curre= nt AT: at session creation, at auth step up time and so on.
Those are va= lues that API need in order to make authorization decisions; in the case of= 1st party APIs, the AT is the only artifact they ever receive hence there = is no other way for an API to determine whether the caller performed say MF= A in order to obtain the current AT.
Since the first draft, some people = signaled concerns about the current mechanisms thru which those claims get = their value. For example, it has been proposed to maintain the original val= ues of auth_time, acr & amr and introduce additional claims to indicate= changes (like stepup).
I am not clear on what cold go wrong with the cu= rrent approach, hence I don't have an immediate grasp of how changes li= ke the above would help.
If the people uncomfortable with the current pr= oposal could detail their concern, we can brainstorm ways to make that info= available to API in a safer way. To summarize:

A. Do you have con= cerns with the current auth_time, arm, acr proposal? Can you spell them out= ? (please read the relevant parts of the spec before chiming in :))
B. I= f yes, what can we do to make that info available to RSs in a way that make= s you comfortable?


Thanks

V.

On Mon, Dec 16, = 2019 at 2:49 PM <internet-drafts@ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Vitt= orio Bertocci
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-access-token-jwt-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-12-16

Abstract:
=C2=A0 =C2=A0This specification defines a profile for issuing OAuth 2.0 acc= ess
=C2=A0 =C2=A0tokens in JSON web token (JWT) format.=C2=A0 Authorization ser= vers and
=C2=A0 =C2=A0resource servers from different vendors can leverage this prof= ile to
=C2=A0 =C2=A0issue and consume access tokens in interoperable manner.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-oauth-access-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-oauth-access-token-jwt-03
https://datatracker.ietf.o= rg/doc/html/draft-ietf-oauth-access-token-jwt-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-oauth-access-token-jwt-03


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

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

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000e51987059a00ffb9-- From nobody Wed Dec 18 13:24:10 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE171208A3 for ; Wed, 18 Dec 2019 13:24:08 -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 x9CX8SRGMVS6 for ; Wed, 18 Dec 2019 13:24: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 E52EB120836 for ; Wed, 18 Dec 2019 13:24:06 -0800 (PST) Received: from [192.168.1.3] (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 xBILO403013326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Dec 2019 16:24:04 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6D8FA482-FD8D-46ED-9D60-1FC521852D03" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 18 Dec 2019 16:24:04 -0500 In-Reply-To: Cc: oauth To: Rifaat Shekh-Yusef References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 21:24:09 -0000 --Apple-Mail=_6D8FA482-FD8D-46ED-9D60-1FC521852D03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support adoption of PAR and have already implemented the draft = specification. - Justin > On Dec 17, 2019, at 7:59 AM, Rifaat Shekh-Yusef = wrote: >=20 > All, >=20 > This is a call for adoption of for the OAuth 2.0 Pushed Authorization = Requests document. > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ = =20 >=20 > There was a good support for this document during the Singapore = meeting, and on the mailing list in the Meeting Minutes thread. >=20 > Please, let us know if you support or object to adopting this document = as a working group document by Dec 27th. >=20 > If you have already indicated your support on the Meeting Minutes = thread, you do not need to do it again on this thread. >=20 > Regards, > Rifaat & Hannes >=20 >=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_6D8FA482-FD8D-46ED-9D60-1FC521852D03 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = support adoption of PAR and have already implemented the draft = specification.

 -= Justin

= --Apple-Mail=_6D8FA482-FD8D-46ED-9D60-1FC521852D03-- From nobody Wed Dec 18 13:30:49 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05FC1208A8 for ; Wed, 18 Dec 2019 13:30:47 -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 CaC8xUZu8JbI for ; Wed, 18 Dec 2019 13:30:46 -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 33470120836 for ; Wed, 18 Dec 2019 13:30:46 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id u71so3779391lje.11 for ; Wed, 18 Dec 2019 13:30:46 -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=rCdb0jcCQlF/Y13RWSefGx7aBb8lTyukzZlhz73WUn8=; b=AwFd5rm4viHrL9Magk5m3+y52kYwipwsdNHy3Sskh6Fb6zd6gFBMSqUABf8JsOAogr eWlJGwnSkJO93gfQbckJYrf9uNVnOW60eAsRzrbbJPgQ3C+JuEDaK+pXu0FojQXH3WG6 WOaWPn9w9qowczE+SjQjhVXrK9zTRkX+uUJJZnQFJK2pXnhMGKemR9Jy2hWZwaFFD8ho dhPXg05DNGczn6nZ692NEiB5OVe0US8E4sB5ErSLAQDGtkWGx8Cn0K4Ly5wF5GtYhXUi WWeoswmymqD3gm4Mq8Wp+5O6d0g3yB2zmfuMRppvoYCx8/35DZG0o2jbs727LUPtfHc+ Kjdw== 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=rCdb0jcCQlF/Y13RWSefGx7aBb8lTyukzZlhz73WUn8=; b=XdyGYRtEFt3Pra2qqpdoitAE5Yij7RrzRtQfl/gM78s7pJ/c2pOseCFCSmXHquAY1N arzucWVwaR68Kd8Sdmcl9LxacVkiv1qmKzU/MDnEdR3dUQrWz6vCMThNK/LKvHoJ/NxC waFqpnH+DqDlEHekVTGcb4Wk3rbLtiK2o7i72LtBg9QLbzqz1IUsU+PHCTKSyb6ltXp2 3ON4q8fu6ittpJYBMP9udRGLSgdyar9X8PYnViAAWa56OKOUe/mWRHDGnpmUiOjog6ot h+GZ3GzhuFjO5kSQ9vmd8uQAblPkGFWRq5y4CK3vykPe7mMkZmVHnd8rallC4GJVVfzo 2h2w== X-Gm-Message-State: APjAAAXpv6FhrjDoBQR38k/8/qdJNTZCXjN9THJApyUKtbzZMAQzuhg3 JKOmKNWDxGfpZ3MT6yT/aJT688szKTYebk0Is+2g9X4aKKD0ffqVQ6pyHi3ICxwL1oXfI5cPlXb ZteGnq3ZdCWUsMw== X-Google-Smtp-Source: APXvYqy/FXmPw1mZAwWmYKlm15hpL2LSbyzcLz2rfZm/ncH5EmP4WR6ZwlzFvMD0rksN2a58Tlypf96LNQs4igOlmuI= X-Received: by 2002:a2e:7005:: with SMTP id l5mr3499284ljc.230.1576704644459; Wed, 18 Dec 2019 13:30:44 -0800 (PST) MIME-Version: 1.0 References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Wed, 18 Dec 2019 14:30:18 -0700 Message-ID: To: Vittorio Bertocci Cc: "Richard Backman, Annabelle" , IETF oauth WG , "i-d-announce@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003fcd99059a0128e9" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 21:30:48 -0000 --0000000000003fcd99059a0128e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 16, 2019 at 10:31 PM Vittorio Bertocci wrote: > Re: aliases, I see where the confusion is coming from! > I updated the request section, but the session 2.2 data structure still > mentions the aliases. That should be cleaned up as well. > In any case the intent was always to only allow a singe resource per AT, > the alias list was only for helping in cases where an AS identifies the > same resource thru multiple IDs and the actual aud value depends on what = ID > the client requested. However we discussed this with Brian and he convinc= ed > me that it was just too ambiguous- your remark reinforces that impression= . > I=E2=80=99ll clean up 2.2 and eliminate references to aliases from there = as well. > Thanks! > Yes, please clean up sec 2.2. --=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._ --0000000000003fcd99059a0128e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 16, 2019 at 10:31 PM Vitt= orio Bertocci <Vittorio=3D= 40auth0.com@dmarc.ietf.org> wrote:
Re: aliases, I see where t= he confusion is coming from!
I updated the req= uest section, but the session 2.2 data structure still mentions the aliases= . That should be cleaned up as well.=C2=A0
In any ca= se the intent was always to only allow a singe resource per AT, the alias l= ist was only for helping in cases where an AS identifies the same resource = thru multiple IDs and the actual aud value depends on what ID the client re= quested. However we discussed this with Brian and he convinced me that it w= as just too ambiguous- your remark reinforces that impression. I=E2=80=99ll= clean up 2.2 and eliminate references to aliases from there as well.
=
Thanks!

Yes, p= lease clean up sec 2.2.

<= 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. --0000000000003fcd99059a0128e9-- From nobody Wed Dec 18 13:53:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A74120236 for ; Wed, 18 Dec 2019 13:53:45 -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 I0x755QgA9jb for ; Wed, 18 Dec 2019 13:53:44 -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 A6458120089 for ; Wed, 18 Dec 2019 13:53:43 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id h23so3838219ljc.8 for ; Wed, 18 Dec 2019 13:53:43 -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=BUEIYSm5zLkHzLPGPUsE5IgnAAMnNeJwkEcmZszj8ms=; b=ez4+MDhdVdnLkcnVKG2KInx6mug0kxTeYbyK7WnKmYi7XZ13yKSZule4M2mXnXG7gP hBNsLjNBvBJtzkbOo5+x/Mqp16apXaS9JcJ8Mh4yNXiTGTceM8kG6e52B9gm555+5xV9 uIcNVBLmja+Ire71FAI5f4gJJtRvPyLrnj2jx0EclP1rInOwqYRLpL+cGXisTch2vAaU OavaaXLafa/l/JzOlsecBqH4wVvvkQuPawAoF1oPd031hsEiIp6nUe4fgdVwzzefozFb KbgGEssdeIC87ZU2FtUUkjPDsD9QoX75pmm8Pk1kfU2/u/oGFgVFClwOvqZi+xYfU+i1 rE3w== 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=BUEIYSm5zLkHzLPGPUsE5IgnAAMnNeJwkEcmZszj8ms=; b=oCkdVenqQ4d4o2yepCkFAdsgC57Y2Et/sSM0X2VbcoBOn7z07EBIgnv585TfqRxmrp og3UaBZliXm7bJTL0a5K3W/00oq+KHoNo7jJCnKW2/4+7DAxVSj0gj7VHLcD9rz1/DoA AglG4KpgrYCV9tKucwwU7E2fGIraf/wnbpgmeBUlyEb7dgzjWXSHzOVA6TF4aRHKh21b e51eoVYQyjHfdBbqYsyQ6hjO3FfCde1xY/nb5k4F+/h5R81MhRM+eAILScXgp0LbCtSC kNFBa56/Hf5eCZH7j7Mc/7frPD7SrDFD0YQXGlYHvptKER59W3Xet2+ZLq8p5IOQI2PI +mYA== X-Gm-Message-State: APjAAAXaQdC2MTX+69F0/8rkW94yCqylWaaVf22agAcuA8uOQBldaDbi yRa2Pm9tdcmVB04khJbJhWKC8ktCeUlQmvoqFRbZ34RLlZtGg0mOXc7fxuvTYa3dMezJ9CWZzRx IE75fPzM5EES7QQ== X-Google-Smtp-Source: APXvYqx8/qYk9VsVbrFCUFBB4CllN+T/eJ0bi923mNbpv94q78St41rKDoj7DUSEpTmlQ/PA5tkWdDjRbOCc9VhfaXQ= X-Received: by 2002:a2e:9592:: with SMTP id w18mr3460990ljh.98.1576706021803; Wed, 18 Dec 2019 13:53:41 -0800 (PST) MIME-Version: 1.0 References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Wed, 18 Dec 2019 14:53:15 -0700 Message-ID: To: Vittorio Bertocci Cc: "Richard Backman, Annabelle" , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000586106059a017a70" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 21:53:46 -0000 --000000000000586106059a017a70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable But there's more going on with aud that needs to be looked at and/or wasn't updated. I think this "The aud claim MAY include a list of individual resource indicators if they are all aliases referring to the same requested resource known by the authorization server." should be removed from 2.2. Resource Indicators is about how the client conveys the target to the AS and says " The authorization server may use the exact 'resource' value as the audience or it may map from that value to a more general URI or abstract identifier for the given resource". The following from sec 3 is more restrictive / prescriptive, which seems to reach beyond the scope of the JWT access token profile. "If the request includes a resource parameter (as defined in [ResourceIndicators]), the resulting JWT access token aud claim MUST have the same value as the resource parameter in the request." And sec 4 also has talk of aliases. " 4. The resource server MUST validate that the aud claim contains the resource indicator value corresponding to the identifier the resource server expects for itself. The aud claim MAY contain an array with more than one element. The JWT access token MUST be rejected if aud does not list the resource indicator of the current resource server as a valid audience, or if it contains additional audiences that are not known aliases of the resource indicator of the current resource server. I'd suggest deleting everything after the comma. If you really want to limit things to a single aud value (and my understanding is that you do), maybe just place the restriction on the AS to only issue with a single aud value. On Wed, Dec 18, 2019 at 2:30 PM Brian Campbell wrote: > > > On Mon, Dec 16, 2019 at 10:31 PM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > >> Re: aliases, I see where the confusion is coming from! >> I updated the request section, but the session 2.2 data structure still >> mentions the aliases. That should be cleaned up as well. >> In any case the intent was always to only allow a singe resource per AT, >> the alias list was only for helping in cases where an AS identifies the >> same resource thru multiple IDs and the actual aud value depends on what= ID >> the client requested. However we discussed this with Brian and he convin= ced >> me that it was just too ambiguous- your remark reinforces that impressio= n. >> I=E2=80=99ll clean up 2.2 and eliminate references to aliases from there= as well. >> Thanks! >> > > Yes, please clean up sec 2.2. > --=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._ --000000000000586106059a017a70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But there's more going on with aud that needs to = be looked at and/or wasn't updated.

I thi= nk this
=C2=A0=C2=A0=C2=A0 "The aud
=C2=A0 =C2=A0 = =C2=A0 claim MAY include a list of individual resource indicators if they=C2=A0 =C2=A0 =C2=A0 are all aliases referring to the same requested reso= urce known by
=C2=A0 =C2=A0 =C2=A0 the authorization server." =
should be removed from 2.2.

Resourc= e Indicators is about how the client conveys the target to the AS and says = " The authorization server may use the exact 'resource' value = as the audience or it may map from that value to a more general URI or abst= ract identifier for the given resource". The following from sec 3 is m= ore restrictive / prescriptive, which seems to reach beyond the scope of th= e JWT access token profile.
=C2=A0=C2=A0 "If the reques= t includes a resource parameter (as defined in
=C2=A0 =C2=A0[ResourceInd= icators]), the resulting JWT access token aud claim MUST
=C2=A0 =C2=A0ha= ve the same value as the resource parameter in the request."

And sec 4 also has talk of aliases.
"= =C2=A0=C2=A0 4.=C2=A0 The resource server MUST validate that the aud claim = contains the
=C2=A0 =C2=A0 =C2=A0 =C2=A0resource indicator value corresp= onding to the identifier the
=C2=A0 =C2=A0 =C2=A0 =C2=A0resource server = expects for itself.=C2=A0 The aud claim MAY contain an
=C2=A0 =C2=A0 =C2= =A0 =C2=A0array with more than one element.=C2=A0 The JWT access token MUST= be
=C2=A0 =C2=A0 =C2=A0 =C2=A0rejected if aud does not list the resourc= e indicator of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0current resource server as= a valid audience, or if it contains
=C2=A0 =C2=A0 =C2=A0 =C2=A0addition= al audiences that are not known aliases of the resource
=C2=A0 =C2=A0 = =C2=A0 =C2=A0indicator of the current resource server.
I'd su= ggest deleting everything after the comma.

If= you really want to limit things to a single aud value (and my understandin= g is that you do), maybe just place the restriction on the AS to only issue= with a single aud value.

On Wed, Dec 18, 2019 at 2:30 PM Brian C= ampbell <bcampbell@pingide= ntity.com> wrote:


On Mon, Dec 16, 2019 at 10= :31 PM Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:
<= /div>
Re: aliases, I see where the confusion is coming from!
I updated the request section, but the session 2.2 data structu= re still mentions the aliases. That should be cleaned up as well.=C2=A0
In any case the intent was always to only allow a singe= resource per AT, the alias list was only for helping in cases where an AS = identifies the same resource thru multiple IDs and the actual aud value dep= ends on what ID the client requested. However we discussed this with Brian = and he convinced me that it was just too ambiguous- your remark reinforces = that impression. I=E2=80=99ll clean up 2.2 and eliminate references to alia= ses from there as well.
Thanks!

Yes, please clean up sec 2.2.

<= 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. --000000000000586106059a017a70-- From nobody Wed Dec 18 14:31:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F30120A7D; Wed, 18 Dec 2019 14:31:45 -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 5CjKpZDTbNOo; Wed, 18 Dec 2019 14:31:42 -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 4E285120086; Wed, 18 Dec 2019 14:31:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1576708303; x=1608244303; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vThWTCsDzj2DbHlOY8LAJbnF/IZP+RfA0qfGVIYIv4A=; b=i3rIbC7FS8s5KNJmau2U5p/7z0C1Y0VUvwmY7VmG9u2GM2PvOErJCDFq 1A77XpaFyJ3j0Fp9HRMSM3thgwWSH8D85VrvRXsMEE/nhMoFa2nkLvQgM HSsMz3R2sNhee+imlugKrkM+CamuZcAq92b7EupPe1+tYJFS+sJd42Rd4 k=; IronPort-SDR: /t1D8myFEqOWuvTeKvLefgowVxr5MBhX7I6zYc6RmtQIZk6Q3XKCtb67X0HpnW2YtZF2ujfxym qL9QUjga3Jjw== X-IronPort-AV: E=Sophos;i="5.69,330,1571702400"; d="scan'208,217";a="9180932" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1e-27fb8269.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 18 Dec 2019 22:31:41 +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 97120A2068; Wed, 18 Dec 2019 22:31:39 +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, 18 Dec 2019 22:31:38 +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, 18 Dec 2019 22:31:38 +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, 18 Dec 2019 22:31:38 +0000 From: "Richard Backman, Annabelle" To: Brian Campbell , "Vittorio Bertocci" CC: IETF oauth WG , "i-d-announce@ietf.org" Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt Thread-Index: AQHVtGMkx0ZM11MJ9UuFnmHDKBqGmae9XaMA///YXwCAAIOagIACrEcA///DVwA= Date: Wed, 18 Dec 2019 22:31:38 +0000 Message-ID: <249E9439-30C5-4925-A767-62E605D864C1@amazon.com> References: <157653653318.24509.15075582637514649078@ietfa.amsl.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.162.83] Content-Type: multipart/alternative; boundary="_000_249E943930C54925A76762E605D864C1amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 22:31:45 -0000 --_000_249E943930C54925A76762E605D864C1amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBhIHByb3BlciBleHBsYW5hdGlvbiBpcyBhIGxpdHRsZSB0b28gbXVjaCB0byBjcmFt IGludG8gYSBkZWZpbml0aW9uIGxpc3QgZW50cnkuIEkgc3VnZ2VzdCBrZWVwaW5nIHRob3NlIGRl ZmluaXRpb25zIGxpZ2h0LCBhbmQgcmVmZXJlbmNlIGEgc3Vic2VjdGlvbiB3aXRoIHNvbWV0aGlu ZyBsaWtlIHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0KVGhlIGBhY3JgLCBgYW1yYCwgYW5kIGBhdXRo X3RpbWVgIGNsYWltcyBkZXNjcmliZSB0aGUgdHlwZXMgYW5kIHN0cmVuZ3RoIG9mIGF1dGhlbnRp Y2F0aW9uIHRoYXQgdGhlIGF1dGhlbnRpY2F0aW9uIHNlcnZlciBlbmZvcmNlZCBwcmlvciB0byBy ZXR1cm5pbmcgdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UgdG8gdGhlIGNsaWVudC4gIFRoZWly IHZhbHVlcyBhcmUgZml4ZWQsIGFuZCByZW1haW4gdGhlIHNhbWUgYWNyb3NzIGFsbCBhY2Nlc3Mg dG9rZW5zIHRoYXQgZGVyaXZlIGZyb20gYSBnaXZlbiBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCB3 aGV0aGVyIHRoZSBhY2Nlc3MgdG9rZW4gd2FzIG9idGFpbmVkIGRpcmVjdGx5IGluIHRoZSByZXNw b25zZSAoZS5nLiwgdmlhIHRoZSBpbXBsaWNpdCBmbG93KSBvciBhZnRlciBvbmUgb3IgbW9yZSB0 b2tlbiBleGNoYW5nZXMgKGUuZy4sIG9idGFpbmluZyBhIGZyZXNoIGFjY2VzcyB0b2tlbiB1c2lu ZyBhIHJlZnJlc2ggdG9rZW4sIG9yIGV4Y2hhbmdpbmcgb25lIGFjY2VzcyB0b2tlbiBmb3IgYW5v dGhlciB2aWEgW1Rva2VuRXhjaGFuZ2VdKS4NCg0KVGhlc2UgY2xhaW1zIHByb3ZpZGUgYSBzbmFw c2hvdCB2aWV3IG9mIGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uIGF0IGEgc3BlY2lmaWMgcG9p bnQgaW4gdGltZSwgYW5kIG1heSBub3QgbmVjZXNzYXJpbHkgcmVmbGVjdCB0aGUgY3VycmVudCBz dGF0dXMgb2YgdGhlIHJlc291cmNlIG93bmVy4oCZcyBzZXNzaW9uIGF0IHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciwgZm9yIGV4YW1wbGUgaWYgdGhlIHJlc291cmNlIG93bmVyIGhhcyBzaW5jZSBj b21wbGV0ZWQgYWRkaXRpb25hbCBjaGFsbGVuZ2VzLCBvciBzaWduZWQgb3V0LiAgSW4gb3JkZXIg dG8gb2J0YWluIGFuIHVwLXRvLWRhdGUgdmlldyBvZiB0aGlzIGluZm9ybWF0aW9uLCB0aGUgY2xp ZW50IG11c3QgbWFrZSBhIG5ldyBhdXRob3JpemF0aW9uIHJlcXVlc3QuDQoNCldl4oCZcmUgZGFu Y2luZyBhcm91bmQgdGhlIGlkZWEgb2YgYW4g4oCcYXV0aG9yaXphdGlvbiBzZXNzaW9u4oCdIGhl cmUsIHdoaWNoIGlzIHNvbWV0aGluZyBJIHRoaW5rIGEgbG90IG9mIHVzIGludHVpdGl2ZWx5IHVu ZGVyc3RhbmQgYnV0IGlzIG5vdCBhY3R1YWxseSBmb3JtYWxseSBkZXNjcmliZWQgYW55d2hlcmUu IEnigJltIG5vdCBzdXJlIGlmIGV4cGxpY2l0bHkgZGVzY3JpYmluZyBpdCBoZXJlIHdvdWxkIG1h a2UgdGhpbmdzIG1vcmUgb3IgbGVzcyBjb25mdXNpbmcuIPCfpLfwn4+74oCN4pmA77iPDQoNCuKA kw0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogQnJp YW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+ DQpEYXRlOiBXZWRuZXNkYXksIERlY2VtYmVyIDE4LCAyMDE5IGF0IDE6MDkgUE0NClRvOiBWaXR0 b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW9AYXV0aDAuY29tPg0KQ2M6ICJSaWNoYXJkIEJhY2ttYW4s IEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb20+LCBJRVRGIG9hdXRoIFdHIDxvYXV0aEBp ZXRmLm9yZz4sICJpLWQtYW5ub3VuY2VAaWV0Zi5vcmciIDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbT0FVVEgtV0ddIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMy50eHQNCg0KDQpPbiBNb24sIERl YyAxNiwgMjAxOSBhdCA5OjIwIFBNIFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jpbz00MGF1dGgw LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3 cm90ZToNCg0KYXV0aGVudGljYXRpb24gc2Vzc2lvbiBwcm9wZXJ0aWVzOg0KIExldCBtZSB0cnkg YW5vdGhlciBhbmdsZS4gU2F5IHRoYXQgSSBwZXJmb3JtIGFuIGF1dGh6IGNvZGUgZ3JhbnQgYXNr aW5nIGZvciBBVCwgSURfVCBhbmQgUlQtIG9idGFpbmluZyBBVCcsIElEX1QnIGFuZCBSVCcuDQpU aGUgdmFsdWVzIG9mIGF1dGhfdGltZSwgYWNyIGFuZCBhbXIgaW4gQVQnIHdpbGwgYmUgdGhlIHNh bWUgYXMgdGhlIGNvcnJlc3BvbmRpbmcgY2xhaW1zIGluIElEX1QnLiBXaGVuIHRoZSBjbGllbnQg dXNlcyBSVCcgdG8gb2J0YWluIEFUYE4sIEFUJ04rMSBldGMgZXRjLCB0aGUgdmFsdWVzIG9mIHRo b3NlIGNsYWltcyB3aWxsIHJlbWFpbiB0aGUgc2FtZSBmb3IgZXZlcnkgQVQnbiBvYnRhaW5lZCBi eSBSVCcuDQpOb3csIGltYWdpbmUgdGhhdCBzb21ldGhpbmcgaGFwcGVucyAoaWdub3JlIHdoYXQg Zm9yIHRoZSB0aW1lIGJlaW5nKSB0aGF0IGNhdXNlcyB0aGUgY2xpZW50IHRvIHBlcmZvcm0gYSBz dGVwIHVwIGF1dGgsIHdoaWNoIHJlcXVpcmVzIHRoZSB1c2VyIHRvIHBlcmZvcm0gaW50ZXJhY3Rp dmUgYXV0aCBoZW5jZSByZXN1bHRzIGluIGEgbmV3IGF1dGh6IGdyYW50LiBUaGUgY2xpZW50IHdp bGwgb2J0YWluIGEgbmV3IHR1cGxlICBBVCIsIElEX1QiIGFuZCBSVCIuIFRoZSBleGFjdCBzYW1l IHJ1bGVzIGRlc2NyaWJlZCBmb3IgdGhlICcgdHVwbGUgYXBwbHksIHdpdGggdGhlIG5ldyB2YWx1 ZXMgZGV0ZXJtaW5lZCBieSB0aGUgbmV3IGF1dGhlbnRpY2F0aW9uOiBBVCIgYXV0aF90aW1lL2Fj ci9hbXIgd2lsbCBiZSB0aGUgc2FtZSBhcyBJRF9UIiwgYW5kIHRob3NlIHZhbHVlcyB3aWxsIHJl bWFpbiB1bmNoYW5nZWQgZm9yIGV2ZXJ5IEFUIm4gZGVyaXZlZCBieSBSVCIuDQpJZiB3ZSB3YW50 IHRoaXMgdG8gYXBwbHkgdG8gdGhlIGltcGxpY2l0IGZsb3cgYXMgd2VsbCwgeW91IGNhbiBzdWJz dGl0dXRlIHRoZSBSVCB3aXRoIHRoZSBzZXNzaW9uIGFydGlmYWN0Lg0KRG9lcyB0aGF0IGhlbHAg Y2xhcmlmeWluZyB0aGUgaW50ZW50PyBJZiB5ZXMsIGRvIHlvdSBmZWVsIHRoYXQgdGhlIGN1cnJl bnQgbGFuZ3VhZ2UgZG9lcyBub3QgZGVzY3JpYmUgdGhpcz8NCg0KVGhhdCBtYWtlcyBzZW5zZS4g VGhlIGN1cnJlbnQgbGFuZ3VhZ2UgZm9yIGF1dGhfdGltZSBjb3VsZCBiZSB0aWdodGVuZWQgdXAg c29tZXdoYXQsIGhvd2V2ZXIuIEkgdGhpbmsgdGhlcmUncyBzdGlsbCBwb3RlbnRpYWwgZm9yIGl0 IHRvIGJlIGludGVycHJldGVkIHN1Y2ggdGhhdCBBVCdOKzEgd291bGQgc29tZWhvdyBtYWdpY2Fs bHkgZ2V0IGEgbmV3IGF1dGhfdGltZSB2YWx1ZSBiYXNlZCBvbiBhIHN0ZXAtdXAgb3IgcmUtYXV0 aCB0aGF0IGhhcHBlbmVkIGFmdGVyLCBhbmQgaW5kZXBlbmRlbnQgb2YsIHRoZSBhdXRoZW50aWNh dGlvbiBldmVudCB0aGF0IGxlZCB0byB0aGUgY29kZSB0aGF0IG9idGFpbmVkIFJUJy4gV2hpY2gg aXMgbm9uc2Vuc2ljYWwuIEFsc28gImF1dGhlbnRpY2FpdG9uIiBpcyBzcGVsbGVkIGZ1bm55LiBI ZXJlJ3MgYW4gYXR0ZW1wdCBhdCBzb21lIHdvcmRzIGZvciBhdXRoX3RpbWU6DQoNCg0KU3VnZ2Vz dGVkKGlzaCkgVGV4dDoNCiAgIGF1dGhfdGltZSAgT1BUSU9OQUwgLSBhcyBkZWZpbmVkIGluIHNl Y3Rpb24gMiBvZiBbT3BlbklELkNvcmVdLg0KICAgICAgVGhpcyBjbGFpbSByZXByZXNlbnRzIHRo ZSB0aW1lIGF0IHdoaWNoIHRoZSBlbmQgdXNlcg0KICAgICAgbGFzdCBhdXRoZW50aWNhdGVkIGR1 cmluZyB0aGUgc2Vzc2lvbiB0aGF0IHdhcyB1c2VkIHRvIG9idGFpbiB0aGUgdG9rZW4uDQogICAg ICBUaGlzIG1lYW5zIHRoYXQgYWxsIHRoZSBKV1QgYWNjZXNzIHRva2Vucw0KICAgICAgb2J0YWlu ZWQgd2l0aCBhIGdpdmVuIHJlZnJlc2ggdG9rZW4gd2lsbCBhbGwgaGF2ZSB0aGUgc2FtZSB2YWx1 ZQ0KICAgICAgb2YgYXV0aF90aW1lLCBjb3JyZXNwb25kaW5nIHRvIHRoZSBpbnN0YW50IGluIHdo aWNoIHRoZSB1c2VyDQogICAgICBhdXRoZW50aWNhdGVkIHRvIG9idGFpbiB0aGUgcmVmcmVzaCB0 b2tlbi4NCg0KDQpDdXJyZW50IFRleHQ6DQogICBhdXRoX3RpbWUgIE9QVElPTkFMIC0gYXMgZGVm aW5lZCBpbiBzZWN0aW9uIDIgb2YgW09wZW5JRC5Db3JlXS4NCiAgICAgIEltcG9ydGFudDogYXMg dGhpcyBjbGFpbSByZXByZXNlbnRzIHRoZSB0aW1lIGF0IHdoaWNoIHRoZSBlbmQgdXNlcg0KICAg ICAgbGFzdCBhdXRoZW50aWNhdGVkLCBpdHMgdmFsdWUgd2lsbCBlaXRoZXIgcmVtYWluIHRoZSBz YW1lIGZvciBhbGwNCiAgICAgIHRoZSBKV1QgYWNjZXNzIHRva2VucyBpc3N1ZWQgd2l0aGluIHRo YXQgc2Vzc2lvbiBvciBiZSB1cGRhdGVkIHRvDQogICAgICB0aGUgdGltZSBvZiBsYXRlc3QgYXV0 aGVudGljYXRpb24gaWYgcmVhdXRoZW50aWNhdGlvbiBvY2N1cnJlZA0KICAgICAgbWlkLXNlc3Np b24gKGFzIGl0IGlzIHRoZSBjYXNlIGZvciBzdGVwIHVwIGF1dGhlbnRpY2FpdG9uIGFuZA0KICAg ICAgc2ltaWxhciBvY2N1cnJlbmNlcykuICBGb3IgZXhhbXBsZTogYWxsIHRoZSBKV1QgYWNjZXNz IHRva2Vucw0KICAgICAgb2J0YWluZWQgd2l0aCBhIGdpdmVuIHJlZnJlc2ggdG9rZW4gd2lsbCBh bGwgaGF2ZSB0aGUgc2FtZSB2YWx1ZQ0KICAgICAgb2YgYXV0aF90aW1lLCBjb3JyZXNwb25kaW5n IHRvIHRoZSBpbnN0YW50IGluIHdoaWNoIHRoZSB1c2VyIGZpcnN0DQogICAgICBhdXRoZW50aWNh dGVkIHRvIG9idGFpbiB0aGUgcmVmcmVzaCB0b2tlbi4NCg0KDQpDT05GSURFTlRJQUxJVFkgTk9U SUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBt YXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFu eSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0 aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1t YWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20g eW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0K --_000_249E943930C54925A76762E605D864C1amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <19561CFF0F6FE64EA9A3F80740410EF5@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9zZS0xOjIg MCA1IDMgMCAwIDAgMiAwIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHRoaW5rIGEgcHJvcGVyIGV4cGxhbmF0aW9uIGlzIGEgbGl0dGxlIHRvbyBtdWNo IHRvIGNyYW0gaW50byBhIGRlZmluaXRpb24gbGlzdCBlbnRyeS4gSSBzdWdnZXN0IGtlZXBpbmcg dGhvc2UgZGVmaW5pdGlvbnMgbGlnaHQsIGFuZCByZWZlcmVuY2UgYSBzdWJzZWN0aW9uIHdpdGgg c29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZyB0ZXh0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGBhY3JgLCBgYW1yYCwgYW5kIGBhdXRoX3Rp bWVgIGNsYWltcyBkZXNjcmliZSB0aGUgdHlwZXMgYW5kIHN0cmVuZ3RoIG9mIGF1dGhlbnRpY2F0 aW9uIHRoYXQgdGhlIGF1dGhlbnRpY2F0aW9uIHNlcnZlciBlbmZvcmNlZCBwcmlvciB0byByZXR1 cm5pbmcgdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UgdG8gdGhlIGNsaWVudC4mbmJzcDsgVGhl aXIgdmFsdWVzIGFyZSBmaXhlZCwNCiBhbmQgcmVtYWluIHRoZSBzYW1lIGFjcm9zcyBhbGwgYWNj ZXNzIHRva2VucyB0aGF0IGRlcml2ZSBmcm9tIGEgZ2l2ZW4gYXV0aG9yaXphdGlvbiByZXNwb25z ZSwgd2hldGhlciB0aGUgYWNjZXNzIHRva2VuIHdhcyBvYnRhaW5lZCBkaXJlY3RseSBpbiB0aGUg cmVzcG9uc2UgKGUuZy4sIHZpYSB0aGUgaW1wbGljaXQgZmxvdykgb3IgYWZ0ZXIgb25lIG9yIG1v cmUgdG9rZW4gZXhjaGFuZ2VzIChlLmcuLCBvYnRhaW5pbmcgYSBmcmVzaCBhY2Nlc3MNCiB0b2tl biB1c2luZyBhIHJlZnJlc2ggdG9rZW4sIG9yIGV4Y2hhbmdpbmcgb25lIGFjY2VzcyB0b2tlbiBm b3IgYW5vdGhlciB2aWEgW1Rva2VuRXhjaGFuZ2VdKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGVzZSBj bGFpbXMgcHJvdmlkZSBhIHNuYXBzaG90IHZpZXcgb2YgYXV0aGVudGljYXRpb24gaW5mb3JtYXRp b24gYXQgYSBzcGVjaWZpYyBwb2ludCBpbiB0aW1lLCBhbmQgbWF5IG5vdCBuZWNlc3NhcmlseSBy ZWZsZWN0IHRoZSBjdXJyZW50IHN0YXR1cyBvZiB0aGUgcmVzb3VyY2Ugb3duZXLigJlzIHNlc3Np b24gYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBmb3INCiBleGFtcGxlIGlmIHRoZSByZXNv dXJjZSBvd25lciBoYXMgc2luY2UgY29tcGxldGVkIGFkZGl0aW9uYWwgY2hhbGxlbmdlcywgb3Ig c2lnbmVkIG91dC4mbmJzcDsgSW4gb3JkZXIgdG8gb2J0YWluIGFuIHVwLXRvLWRhdGUgdmlldyBv ZiB0aGlzIGluZm9ybWF0aW9uLCB0aGUgY2xpZW50IG11c3QgbWFrZSBhIG5ldyBhdXRob3JpemF0 aW9uIHJlcXVlc3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldl4oCZcmUgZGFuY2luZyBhcm91 bmQgdGhlIGlkZWEgb2YgYW4g4oCcYXV0aG9yaXphdGlvbiBzZXNzaW9u4oCdIGhlcmUsIHdoaWNo IGlzIHNvbWV0aGluZyBJIHRoaW5rIGEgbG90IG9mIHVzIGludHVpdGl2ZWx5IHVuZGVyc3RhbmQg YnV0IGlzIG5vdCBhY3R1YWxseSBmb3JtYWxseSBkZXNjcmliZWQgYW55d2hlcmUuIEnigJltIG5v dCBzdXJlIGlmIGV4cGxpY2l0bHkgZGVzY3JpYmluZyBpdCBoZXJlIHdvdWxkIG1ha2UgdGhpbmdz DQogbW9yZSBvciBsZXNzIGNvbmZ1c2luZy4gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FwcGxlIENvbG9yIEVtb2ppJnF1b3Q7Ij4mIzEyOTMzNTsmIzEyNzk5NTs8L3NwYW4+4oCNPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FwcGxlIENvbG9yIEVtb2ppJnF1b3Q7Ij7imYA8 L3NwYW4+77iPPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNo YXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJl bGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5XZWRuZXNkYXksIERlY2VtYmVyIDE4LCAyMDE5IGF0IDE6MDkgUE08YnI+DQo8Yj5UbzogPC9i PlZpdHRvcmlvIEJlcnRvY2NpICZsdDtWaXR0b3Jpb0BhdXRoMC5jb20mZ3Q7PGJyPg0KPGI+Q2M6 IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmFA YW1hem9uLmNvbSZndDssIElFVEYgb2F1dGggV0cgJmx0O29hdXRoQGlldGYub3JnJmd0OywgJnF1 b3Q7aS1kLWFubm91bmNlQGlldGYub3JnJnF1b3Q7ICZsdDtpLWQtYW5ub3VuY2VAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1X R10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzLnR4dDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRGVjIDE2LCAyMDE5IGF0IDk6MjAgUE0gVml0dG9y aW8gQmVydG9jY2kgJmx0O1ZpdHRvcmlvPTxhIGhyZWY9Im1haWx0bzo0MGF1dGgwLmNvbUBkbWFy Yy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmF1dGhlbnRpY2F0aW9uIHNlc3Npb24gcHJvcGVy dGllczombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDtMZXQgbWUgdHJ5IGFub3RoZXIgYW5nbGUuIFNheSB0aGF0IEkg cGVyZm9ybSBhbiBhdXRoeiBjb2RlIGdyYW50IGFza2luZyBmb3IgQVQsIElEX1QgYW5kIFJULSBv YnRhaW5pbmcgQVQnLCBJRF9UJyBhbmQgUlQnLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHZhbHVlcyBvZiBhdXRoX3RpbWUsIGFj ciBhbmQgYW1yIGluIEFUJyB3aWxsIGJlIHRoZSBzYW1lIGFzIHRoZSBjb3JyZXNwb25kaW5nIGNs YWltcyBpbiBJRF9UJy4gV2hlbiB0aGUgY2xpZW50IHVzZXMgUlQnIHRvIG9idGFpbiBBVGBOLCBB VCdOJiM0MzsxIGV0YyBldGMsIHRoZSB2YWx1ZXMgb2YgdGhvc2UgY2xhaW1zIHdpbGwgcmVtYWlu IHRoZSBzYW1lIGZvciBldmVyeSBBVCduIG9idGFpbmVkIGJ5IFJUJy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdywgaW1hZ2luZSB0aGF0IHNv bWV0aGluZyBoYXBwZW5zIChpZ25vcmUgd2hhdCBmb3IgdGhlIHRpbWUgYmVpbmcpIHRoYXQgY2F1 c2VzIHRoZSBjbGllbnQgdG8gcGVyZm9ybSBhIHN0ZXAgdXAgYXV0aCwgd2hpY2ggcmVxdWlyZXMg dGhlIHVzZXIgdG8gcGVyZm9ybSBpbnRlcmFjdGl2ZSBhdXRoIGhlbmNlIHJlc3VsdHMgaW4gYSBu ZXcgYXV0aHogZ3JhbnQuIFRoZSBjbGllbnQgd2lsbCBvYnRhaW4gYSBuZXcNCiB0dXBsZSZuYnNw OyBBVCZxdW90OywgSURfVCZxdW90OyBhbmQgUlQmcXVvdDsuIFRoZSBleGFjdCBzYW1lIHJ1bGVz IGRlc2NyaWJlZCBmb3IgdGhlICcgdHVwbGUgYXBwbHksIHdpdGggdGhlIG5ldyB2YWx1ZXMgZGV0 ZXJtaW5lZCBieSB0aGUgbmV3IGF1dGhlbnRpY2F0aW9uOiBBVCZxdW90OyBhdXRoX3RpbWUvYWNy L2FtciB3aWxsIGJlIHRoZSBzYW1lIGFzIElEX1QmcXVvdDssIGFuZCB0aG9zZSB2YWx1ZXMgd2ls bCByZW1haW4gdW5jaGFuZ2VkIGZvciBldmVyeSBBVCZxdW90O24gZGVyaXZlZCBieSBSVCZxdW90 Oy48YnI+DQpJZiB3ZSB3YW50IHRoaXMgdG8gYXBwbHkgdG8gdGhlIGltcGxpY2l0IGZsb3cgYXMg d2VsbCwgeW91IGNhbiBzdWJzdGl0dXRlIHRoZSBSVCB3aXRoIHRoZSBzZXNzaW9uIGFydGlmYWN0 LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RG9lcyB0aGF0IGhlbHAgY2xhcmlmeWluZyB0aGUgaW50ZW50PyBJZiB5ZXMsIGRvIHlvdSBm ZWVsIHRoYXQgdGhlIGN1cnJlbnQgbGFuZ3VhZ2UgZG9lcyBub3QgZGVzY3JpYmUgdGhpcz88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgbWFrZXMgc2Vuc2UuIFRoZSBjdXJyZW50IGxh bmd1YWdlIGZvciBhdXRoX3RpbWUgY291bGQgYmUgdGlnaHRlbmVkIHVwIHNvbWV3aGF0LCBob3dl dmVyLiBJIHRoaW5rIHRoZXJlJ3Mgc3RpbGwgcG90ZW50aWFsIGZvciBpdCB0byBiZSBpbnRlcnBy ZXRlZCBzdWNoIHRoYXQgQVQnTiYjNDM7MSB3b3VsZCBzb21laG93IG1hZ2ljYWxseSBnZXQgYSBu ZXcgYXV0aF90aW1lJm5ic3A7dmFsdWUgYmFzZWQgb24gYSBzdGVwLXVwDQogb3IgcmUtYXV0aCB0 aGF0IGhhcHBlbmVkIGFmdGVyLCBhbmQgaW5kZXBlbmRlbnQgb2YsIHRoZSBhdXRoZW50aWNhdGlv biBldmVudCB0aGF0IGxlZCB0byB0aGUgY29kZSB0aGF0IG9idGFpbmVkIFJUJy4gV2hpY2ggaXMg bm9uc2Vuc2ljYWwuIEFsc28gJnF1b3Q7YXV0aGVudGljYWl0b24mcXVvdDsgaXMgc3BlbGxlZCBm dW5ueS4gSGVyZSdzIGFuIGF0dGVtcHQgYXQgc29tZSB3b3JkcyBmb3IgYXV0aF90aW1lOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1Z2dl c3RlZChpc2gpIFRleHQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgYXV0aF90aW1lICZuYnNwO09QVElPTkFMIC0gYXMgZGVm aW5lZCBpbiBzZWN0aW9uIDIgb2YgW09wZW5JRC5Db3JlXS48YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyBUaGlzIGNsYWltIHJlcHJlc2VudHMgdGhlIHRpbWUgYXQgd2hpY2ggdGhlIGVuZCB1c2Vy PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgbGFzdCBhdXRoZW50aWNhdGVkIGR1cmluZyB0aGUg c2Vzc2lvbiB0aGF0IHdhcyB1c2VkIHRvIG9idGFpbiB0aGUgdG9rZW4uPGJyPg0KJm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyBUaGlzIG1lYW5zIHRoYXQgYWxsIHRoZSBKV1QgYWNjZXNzIHRva2Vu czxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IG9idGFpbmVkIHdpdGggYSBnaXZlbiByZWZyZXNo IHRva2VuIHdpbGwgYWxsIGhhdmUgdGhlIHNhbWUgdmFsdWU8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyBvZiBhdXRoX3RpbWUsIGNvcnJlc3BvbmRpbmcgdG8gdGhlIGluc3RhbnQgaW4gd2hpY2gg dGhlIHVzZXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBhdXRoZW50aWNhdGVkIHRvIG9idGFp biB0aGUgcmVmcmVzaCB0b2tlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5DdXJyZW50IFRleHQ6PGJyPg0KJm5ic3A7ICZuYnNwO2F1dGhf dGltZSAmbmJzcDtPUFRJT05BTCAtIGFzIGRlZmluZWQgaW4gc2VjdGlvbiAyIG9mIFtPcGVuSUQu Q29yZV0uPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW1wb3J0YW50OiBhcyB0aGlzIGNsYWlt IHJlcHJlc2VudHMgdGhlIHRpbWUgYXQgd2hpY2ggdGhlIGVuZCB1c2VyPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgbGFzdCBhdXRoZW50aWNhdGVkLCBpdHMgdmFsdWUgd2lsbCBlaXRoZXIgcmVt YWluIHRoZSBzYW1lIGZvciBhbGw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgSldUIGFj Y2VzcyB0b2tlbnMgaXNzdWVkIHdpdGhpbiB0aGF0IHNlc3Npb24gb3IgYmUgdXBkYXRlZCB0bzxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSB0aW1lIG9mIGxhdGVzdCBhdXRoZW50aWNhdGlv biBpZiByZWF1dGhlbnRpY2F0aW9uIG9jY3VycmVkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg bWlkLXNlc3Npb24gKGFzIGl0IGlzIHRoZSBjYXNlIGZvciBzdGVwIHVwIGF1dGhlbnRpY2FpdG9u IGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHNpbWlsYXIgb2NjdXJyZW5jZXMpLiZuYnNw OyBGb3IgZXhhbXBsZTogYWxsIHRoZSBKV1QgYWNjZXNzIHRva2Vuczxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IG9idGFpbmVkIHdpdGggYSBnaXZlbiByZWZyZXNoIHRva2VuIHdpbGwgYWxsIGhh dmUgdGhlIHNhbWUgdmFsdWU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBvZiBhdXRoX3RpbWUs IGNvcnJlc3BvbmRpbmcgdG8gdGhlIGluc3RhbnQgaW4gd2hpY2ggdGhlIHVzZXIgZmlyc3Q8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyBhdXRoZW50aWNhdGVkIHRvIG9idGFpbiB0aGUgcmVmcmVz aCB0b2tlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzU1NTU1NTtib3Jk ZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkgTk9U SUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBt YXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFu eSByZXZpZXcsDQogdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMg c3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29t bXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50 cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj4NCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_249E943930C54925A76762E605D864C1amazoncom_-- From nobody Sat Dec 21 01:58:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0EE120A3B for ; Sat, 21 Dec 2019 01:58:45 -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, 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] 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 pmgj_4U7aCqT for ; Sat, 21 Dec 2019 01:58:43 -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 DEDDF120A32 for ; Sat, 21 Dec 2019 01:58:42 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id a5so11266036wmb.0 for ; Sat, 21 Dec 2019 01:58:42 -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=VXRgcIrbLCp32XIKfSvL5nMjeN9eJwn9DQrw4epvo5A=; b=GCNEFdPZa1BCcqgT2k5vPPzJzyXTtjCt6TAqyOhUVKJyXUFp/VptWUH1ieQsx0Z+iY bhQRhKd4yR7b1dMD5dt6AX3mbCvrOlSWyuC2SBFPFqJ4Pr3RRKAioUuG1Uxzrh0T8v82 SOm5zadlesy7r2+1MtvkHV3sOQ/yPzl+BlR3edTDAzDAPaEzSe2FZ+jzwdxLa8DBGGsi IsBpAuKyWvaEA2uIoP4mW80uf7sbdm5VwE3rYkL/mNdFHpxuGudfzSRcE4Ek9lNZ6hBv 7AcFhEP2UOwP1HwnqPq7kFTdxf1abfMZrQZj8UldIftW81irMXw6BqKIpKlpgLd1zMSk c+Hw== 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=VXRgcIrbLCp32XIKfSvL5nMjeN9eJwn9DQrw4epvo5A=; b=fJA98Pl4IPLgASu5Anpyd5/Vfb+iYvyDQ3K1pycYpfC4Stc9r4k4mDWOrR6cvquUJ6 TMSjTT/Jk9wM2JUTzwFyztTfo9XgdzFBClhtleU9dh8tfhs4qXU80ZyTHfng7l7KEFz5 0J/Z6piq4QojIxA/X4IzmuQjdSDizrPER05U9uMqSo4jUWlMlssP3bpq4IiBBE1JIXnD Rl9q/DPeD/DwVkRaJgEUQ2Yhw6hlhm2d23idkoNfvuMYorfItSXtkaI8C0FZmn27Zsr4 hSK2ERpFxJvfoXr49K+g2E4JFWFa/laC++gP2Y84TUTpdyxy2vujV//tFxOfYFqiFnAT v8pA== X-Gm-Message-State: APjAAAVA4ucLNf96ENfDqzpFB4K+kZakSF5rWBhZ5hgSW6VFpEeJd0cu A+TY3eSRfynX/D3vPsv0TqT91bnYN/l3xA== X-Google-Smtp-Source: APXvYqwapzJZTG2yQ2m1nNR+11lKQS8v337b+9Wzj70/khczfkaY/guDw+sr03TyAsDWMrJYWJb92A== X-Received: by 2002:a05:600c:220e:: with SMTP id z14mr21253092wml.114.1576922320829; Sat, 21 Dec 2019 01:58:40 -0800 (PST) Received: from ?IPv6:2003:eb:8f1a:5097:b897:bd5c:a0a3:46db? (p200300EB8F1A5097B897BD5CA0A346DB.dip0.t-ipconnect.de. [2003:eb:8f1a:5097:b897:bd5c:a0a3:46db]) by smtp.gmail.com with ESMTPSA id w22sm11997138wmk.34.2019.12.21.01.58.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 21 Dec 2019 01:58:39 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-27F60F39-0CB0-498E-9A10-C0CB89E36503 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sat, 21 Dec 2019 10:58:39 +0100 Message-Id: <1CF11B26-F4AC-4BD5-8B72-ED582E162B26@lodderstedt.net> References: Cc: "oauth@ietf.org" In-Reply-To: To: Hannes Tschofenig X-Mailer: iPad Mail (17C54) Archived-At: Subject: Re: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 09:58:45 -0000 --Apple-Mail-27F60F39-0CB0-498E-9A10-C0CB89E36503 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable With respect to Rich Authorization Requests, the minutes state that a call f= or adoption will be sent to the list. When will this call for adoption being= sent to the list? > Am 03.12.2019 um 09:26 schrieb Hannes Tschofenig : >=20 > =EF=BB=BF > Here are the meeting minutes from the Singapore IETF meeting: > https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03 > =20 > Tony was our scribe. Thanks! > =20 > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are confi= dential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-27F60F39-0CB0-498E-9A10-C0CB89E36503 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
With respect to Rich Autho= rization Requests, the minutes state that a call for adoption will be sent t= o the list. When will this call for adoption being sent to the list?

Am 03.12.2019 um 09:26 schrieb H= annes Tschofenig <Hannes.Tschofenig@arm.com>:

=EF=BB=BF =

Here are the meeting minutes from the Singapore IETF m= eeting:

https://datatracker.ietf.org/meeting/106/mate= rials/minutes-106-oauth-03

 

Tony was our scribe. Thanks!

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confide= ntial and may also be privileged. If you are not the intended recipient, ple= ase notify the sender immediately and do not disclose the contents to any ot= her person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
= --Apple-Mail-27F60F39-0CB0-498E-9A10-C0CB89E36503-- From nobody Mon Dec 23 07:57:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6CB12087F for ; Mon, 23 Dec 2019 07:57:43 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=DITW8ZUk; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=xr0IT27i Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7phsPBhZGTUl for ; Mon, 23 Dec 2019 07:57:38 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50077.outbound.protection.outlook.com [40.107.5.77]) (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 383CB12080F for ; Mon, 23 Dec 2019 07:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uPCpL3SwbTFNmdCcFWC+vgM1ldtZhUrptjc67YW/hrU=; b=DITW8ZUksh+NNV3Y2Oy3L8tVXfkOOSVl7cpXMZvPrAZMhmcdYJeQsAU1BwtWpxpE6K/+fZjvG+nxCYOnDo6O/tH2wXXHsbyW53/yVsfNtBmu8jNpOZuMIGpNf+g1LB/C16VMjSnsHGM2rydQ5ADDhx85Zqs7tsvCrZ6Gm5Rhe0Q= Received: from VI1PR0802CA0036.eurprd08.prod.outlook.com (2603:10a6:800:a9::22) by DB7PR08MB3593.eurprd08.prod.outlook.com (2603:10a6:10:49::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.19; Mon, 23 Dec 2019 15:57:01 +0000 Received: from DB5EUR03FT015.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::202) by VI1PR0802CA0036.outlook.office365.com (2603:10a6:800:a9::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14 via Frontend Transport; Mon, 23 Dec 2019 15:57:01 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT015.mail.protection.outlook.com (10.152.20.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14 via Frontend Transport; Mon, 23 Dec 2019 15:57:00 +0000 Received: ("Tessian outbound 1da651c29646:v40"); Mon, 23 Dec 2019 15:57:00 +0000 X-CR-MTA-TID: 64aa7808 Received: from 5b296e172018.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 076DC076-ECB6-4DC2-9FA5-1A870D93C679.1; Mon, 23 Dec 2019 15:56:55 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 5b296e172018.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 23 Dec 2019 15:56:55 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LT9S/ms8/pdeCtb/i2R7AtRzmJ8LUyuZppqu+TkWlPWKBcTLYZA6gIsjn2oiqDIFwkNT/v8N3TKB2qK5XR8HnP7beGV9WwUTpHj4tawgdhESsYg6G+qUWZ+b5sNx2qu11r+mVdblg4Dk2gxpHznf1MRzNvbY9qtI1DSs9QjmaTP7VHydF8ZmQT0eudzt5gSbUizV4fpTU6sWm8RYExDU+HeA0jZb06NskVyLMu4q2u173WlCtMZChifwaryThyJy/zX12UKywIvLFJbjUdUlCamsZnvqRai/O+esXl8SobGsgwmTutXlWvT2REOAEbke272tPrDUlpFhRmQKi2LGXQ== 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=jR71MSIRPcK8bdPQbFB+SmQzUEcH+ORpDUKspZUawWQ=; b=J8knoKgwmPVKKWj/GfSabJZw0gSQIbfMxrSjl3JjNvS5lBYvKM8AL8BxubjQZprP0uCfYw3GgCydPDIIxROunBYtDnDic1yY5Jfj9/8U9hfl6Fh8E9o2ynyshUqi4Vgzk6R+eucLfcpL6YYzTnjYzTwV7wkHG5MWgT+vI0HKMfC/ogjl7bcVNWUTskPFWyG+iClqdGJKLQbf1CUBtPI3RS1a3x6t5SYK67dhcI7m7qYYFsgtNXo6bmfkYp+9vYZ6CLx8ZkagmtBWjIscpkAyya8cp16b8wLU9tMP0onotRvjGhTO/1X0KD0wJrXlsTWuLqJ6gb1obuEYddbCeA6u5Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jR71MSIRPcK8bdPQbFB+SmQzUEcH+ORpDUKspZUawWQ=; b=xr0IT27ibx8rjEMqqJwynvmTb+kkxpqLd25jzuFoF6E1lCaAXBD7nVMhzsmrPnUopUb1B4a6sgQS4m9Kxpy25eJhNHmQXgTj+RP1vcgmlwS7T/h6QY4kb6tDeUG/uuoEOqysTAxaMaQznPs1A3aS5x1DXsYqMftjjK5Qo0h9y0M= Received: from AM6PR08MB5285.eurprd08.prod.outlook.com (20.179.0.161) by AM6PR08MB3573.eurprd08.prod.outlook.com (20.177.114.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14; Mon, 23 Dec 2019 15:56:54 +0000 Received: from AM6PR08MB5285.eurprd08.prod.outlook.com ([fe80::1581:c3da:22ee:41b9]) by AM6PR08MB5285.eurprd08.prod.outlook.com ([fe80::1581:c3da:22ee:41b9%7]) with mapi id 15.20.2559.017; Mon, 23 Dec 2019 15:56:54 +0000 From: Hannes Tschofenig To: Torsten Lodderstedt CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Meeting Minutes Thread-Index: AdWpsxnoY3xdV5m/R9Wrqb/JoSj/HAOMh32AAHEHmaA= Date: Mon, 23 Dec 2019 15:56:54 +0000 Message-ID: References: <1CF11B26-F4AC-4BD5-8B72-ED582E162B26@lodderstedt.net> In-Reply-To: <1CF11B26-F4AC-4BD5-8B72-ED582E162B26@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 34ae2610-aa3c-4569-83f7-ed4ecdc7bb8a.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [195.149.223.43] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 8ad7a975-99a5-4acd-cdce-08d787c0bf29 X-MS-TrafficTypeDiagnostic: AM6PR08MB3573:|DB7PR08MB3593: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 0260457E99 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(39860400002)(376002)(396003)(346002)(199004)(189003)(40434004)(966005)(52536014)(26005)(64756008)(9686003)(186003)(66446008)(66946007)(33656002)(66556008)(66476007)(76116006)(55016002)(81156014)(53546011)(6506007)(81166006)(5660300002)(316002)(6916009)(4326008)(8676002)(2906002)(7696005)(8936002)(86362001)(71200400001)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3573; H:AM6PR08MB5285.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: j7QUfEu5x/SPO+diWOm9i1VbRNF7qpyn09dmqilSqVyenvtIWgkq8NgsGx+UOph3KNiefDlKp0oRhtrFG9EKQOWr5FAA/h99ty9+/DLkFUUX/E5pu1pQQTS/5iy8ADCSn9ZOLUvUTdz97KzqqqBLuHyYN7OYCyxp9TQveQXGJGnoDcum7GLHUmdKy+kAs7UNGmVmE/y3NHHuAsTf/ZQPjfPbO9D0sFdrC6PsCV/+6JqJO0q1JEPhFVMIuIo8pc74KpCKe+v1MGP9pbOGZH+eRP9ekA1hSCzGtu5EN9C8EAYWGeyV1Dqt/YgQcjPivdOkfsUgNzgdAbc4coOtMq8Ew499B0pY+P2ZO/am4chNkmFH2TO0Ghw9Xfa3QkSUi5fRGUZ6v7eACeYryGWpThO26SH6hXyMFjLdAjYiBoiIiMJfbWZCOzkWYQ8ZwH9jJGQlGwqbPQc4S4WvScbLpwk0UTfkPYY6FmCoAx4PaY6chAg1tIqSqm0cgMADVHZL/GZnNLBuRWSGdfmcIQVE4dpeKB6yuJqIQS/ubEf6g16vJPY= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB5285F837699F1F4FA5719E4DFA2E0AM6PR08MB5285eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3573 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT015.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(136003)(376002)(40434004)(189003)(199004)(5660300002)(8676002)(356004)(70586007)(9686003)(70206006)(52536014)(86362001)(81166006)(2906002)(8936002)(81156014)(33656002)(55016002)(4326008)(6506007)(33964004)(186003)(478600001)(316002)(26005)(26826003)(966005)(7696005)(6862004)(76130400001)(336012)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR08MB3593; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; MX:1; A:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 9b459e6a-dc46-4719-266c-08d787c0bb82 X-Forefront-PRVS: 0260457E99 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gwTws9EVC7S2mf8/Jb0mR1bP8iRuVBbpz6Axm89uKCR3LIpL/HzubbxOSY39bgFdpBHiH4BJjDbsVRsmCew+1RQwPXLpBsiN1SPuFnPkC+qYsyeiTvp5MOZb+FVrjPD7vyk+LtyavQlTNz7efcI9waGM+0dHryne0iYph8ukJrlqiI6RMqo989633pnr7bvPPs4OynKiZ6SaHb2ekzo6bp5sLdISW6y79RP9M4y9I7FsmWiYicxbfKZ5lP/XFnlDzEQ0Ep0BUak7lKo+j6iAiel2qDrIlRRj/eN9HwZpgb3P/vFSTJCh510KbrtfXDcc8+ryv6YJCVpfmxxvD32z+y2us+1wGJoKGvjcSrNHajukzX4cQJPjPnSsCIV4MIwErFVycofmA6WLfa50PTQmj8sBCpW/ubkRzIUn7PI/0NZc5XbCqDzCS3gsPF0xO6DLp7aV+R0/qmjC7sRYAMXnQPpOeeeUaqp1MErzLI8+hcpRcOXFd9LrYiDiZqYEhvlljOCDa0zrTdIQph2poTQ8vkdc/9FDxtuNR5MYAq59YJk= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Dec 2019 15:57:00.6172 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8ad7a975-99a5-4acd-cdce-08d787c0bf29 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3593 Archived-At: Subject: Re: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 15:57:43 -0000 --_000_AM6PR08MB5285F837699F1F4FA5719E4DFA2E0AM6PR08MB5285eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RHVyaW5nIHRoZSB2YWNhdGlvbiBwZXJpb2QgZmV3IHBlb3BsZSBwYXkgYXR0ZW50aW9uIHRvIHRo ZSBsaXN0LiBJIGd1ZXNzIGVhcmx5IDIwMjAgd291bGQgYmUgdXNlZnVsLg0KSWYgeW91IG1hbmFn ZSB0byBwaW5nIHNvbWUgZm9sa3MgdG8gcmV2aWV3IHRoZSBkcmFmdCB0aGF0IHdvdWxkIGJlIGdy ZWF0LiBUb28gZmV3IHJhaXNlZCB0aGVpciBoYW5kcyBpbiBTaW5nYXBvcmUgd2hlbiB3ZSBhc2tl ZC4NCg0KSGFwcHkgaG9saWRheXMhDQoNCkZyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0 ZW5AbG9kZGVyc3RlZHQubmV0Pg0KU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDIxLCAyMDE5IDEw OjU5IEFNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+ DQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE1lZXRpbmcgTWlu dXRlcw0KDQpXaXRoIHJlc3BlY3QgdG8gUmljaCBBdXRob3JpemF0aW9uIFJlcXVlc3RzLCB0aGUg bWludXRlcyBzdGF0ZSB0aGF0IGEgY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBiZSBzZW50IHRvIHRo ZSBsaXN0LiBXaGVuIHdpbGwgdGhpcyBjYWxsIGZvciBhZG9wdGlvbiBiZWluZyBzZW50IHRvIHRo ZSBsaXN0Pw0KDQpBbSAwMy4xMi4yMDE5IHVtIDA5OjI2IHNjaHJpZWIgSGFubmVzIFRzY2hvZmVu aWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFy bS5jb20+PjoNCu+7vw0KSGVyZSBhcmUgdGhlIG1lZXRpbmcgbWludXRlcyBmcm9tIHRoZSBTaW5n YXBvcmUgSUVURiBtZWV0aW5nOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5n LzEwNi9tYXRlcmlhbHMvbWludXRlcy0xMDYtb2F1dGgtMDMNCg0KVG9ueSB3YXMgb3VyIHNjcmli ZS4gVGhhbmtzIQ0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVt YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUg cHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0 b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KSU1QT1JUQU5UIE5PVElDRTogVGhl IGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50 aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRv IG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZv ciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1l ZGl1bS4gVGhhbmsgeW91Lg0K --_000_AM6PR08MB5285F837699F1F4FA5719E4DFA2E0AM6PR08MB5285eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5EdXJpbmcgdGhlIHZhY2F0aW9uIHBlcmlvZCBmZXcgcGVvcGxlIHBheSBhdHRl bnRpb24gdG8gdGhlIGxpc3QuIEkgZ3Vlc3MgZWFybHkgMjAyMCB3b3VsZCBiZSB1c2VmdWwuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSBtYW5hZ2UgdG8gcGlu ZyBzb21lIGZvbGtzIHRvIHJldmlldyB0aGUgZHJhZnQgdGhhdCB3b3VsZCBiZSBncmVhdC4gVG9v IGZldyByYWlzZWQgdGhlaXIgaGFuZHMgaW4gU2luZ2Fwb3JlIHdoZW4gd2UgYXNrZWQuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhhcHB5IGhvbGlkYXlzISA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBUb3JzdGVu IExvZGRlcnN0ZWR0ICZsdDt0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCZndDsgPGJyPg0KPGI+U2Vu dDo8L2I+IFNhdHVyZGF5LCBEZWNlbWJlciAyMSwgMjAxOSAxMDo1OSBBTTxicj4NCjxiPlRvOjwv Yj4gSGFubmVzIFRzY2hvZmVuaWcgJmx0O0hhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBNZWV0aW5nIE1pbnV0ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XaXRoIHJlc3BlY3QgdG8gUmljaCBBdXRob3JpemF0aW9uIFJlcXVlc3Rz LCB0aGUgbWludXRlcyBzdGF0ZSB0aGF0IGEgY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBiZSBzZW50 IHRvIHRoZSBsaXN0LiBXaGVuIHdpbGwgdGhpcyBjYWxsIGZvciBhZG9wdGlvbiBiZWluZyBzZW50 IHRvIHRoZSBsaXN0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5B bSAwMy4xMi4yMDE5IHVtIDA5OjI2IHNjaHJpZWIgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhy ZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tIj5IYW5uZXMuVHNjaG9mZW5pZ0Bh cm0uY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4w cHQ7bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPg0K77u/IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGVyZSBhcmUgdGhlIG1lZXRpbmcgbWludXRlcyBmcm9tIHRoZSBTaW5nYXBvcmUg SUVURiBtZWV0aW5nOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwNi9tYXRlcmlhbHMvbWlu dXRlcy0xMDYtb2F1dGgtMDMiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8x MDYvbWF0ZXJpYWxzL21pbnV0ZXMtMTA2LW9hdXRoLTAzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Ub255IHdhcyBvdXIgc2NyaWJlLiBUaGFua3MhPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1QT1JUQU5UIE5P VElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUg Y29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwN CiB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlv biBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xv c2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBv c2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhh bmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM6PR08MB5285F837699F1F4FA5719E4DFA2E0AM6PR08MB5285eurp_-- From nobody Mon Dec 23 08:34:55 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6BB1209DF for ; Mon, 23 Dec 2019 08:34:51 -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 Qe43koXaiFfA for ; Mon, 23 Dec 2019 08:34:49 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E310A1209C5 for ; Mon, 23 Dec 2019 08:34:47 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id d16so17171575wre.10 for ; Mon, 23 Dec 2019 08:34:47 -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=/yMN4rAGgH/zIEHxAguo5qUudMdQk3tamz+kmAFTnbk=; b=ZHd8mC1B9qc1LDby1ORVrYhztwoDR+nIshEAbtGIaDkKPjhbCfI9DzwCJNOE0hCLFu 2AxtvRhsq9KWq7DfhW6LRYwEyB2EETNyws+XFUhbLFw2QZRMP2o1hU8G8CDJnlSGONhB 1tGCArE88XNP6SLzU2agv9zl0LAF3Lu8v+DpMAyM0dkbs9aDjAk0D5hzOTaX4BxsvOxI aoQJnk9/K/YR6fYGHJRssyRCjI0PRlZSXHSK8BGgbIjHr7WHfu9SVMX8Ih22mVMHOBmI +c5wCsli1o8e5nYE12fGvgKxSLtzcZJxSlQqOhau4bt9YhUkaHOOIaOXou1KD0qH5UBp 9xCA== 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=/yMN4rAGgH/zIEHxAguo5qUudMdQk3tamz+kmAFTnbk=; b=nXqfa5QKjLYwFwaLuU/Ajgj8/8nWBjjyuzkJ7tdavA2UokfDD4XhQRycTmsBSxa8tI Q6m7SnrAuONcs4L4n7aZqGmncO9OXH1LkMR5Jt6iM5rt6jxCKnXJwri+GlOs60SyMQci cT5rS4jPPnMUZKkDLLRUiB4bJSMA3gsQEzlj5XN6ksdYUe0ne1/kRq3mysF5374xaCHi 7qAdMUx0i6iFoVq916NdffYYYe+y4EJEUd92aDgR2brcDWj9TvL+ncPcnV8iJZy+O9DJ hIKm3WPhhpwgKn6zC1cD0XvSkSx0vI+/AW9q3NVLq/ImxPZ9V313qRovGfi2IoqZHdBE g+Tw== X-Gm-Message-State: APjAAAXeO3kUvvBRRoGh4HiQthYKP/Tx5Kkauk3vl3GGCmsiw1gaXuLY x0Uno8Qr3tsJJ+s0LbVwA0QZCCI+6Uv0Vm8T X-Google-Smtp-Source: APXvYqzSOcu2sUHfS66ct0Wzsge8q9/3sR687vICDv+J0YJ8rncO9mxcFZydU3b3NxyTj69dGL2iDA== X-Received: by 2002:a5d:494f:: with SMTP id r15mr32194159wrs.143.1577118886303; Mon, 23 Dec 2019 08:34:46 -0800 (PST) Received: from p200300eb8f1a502359000f38e95807bd.dip0.t-ipconnect.de ([2003:eb:8f1a:5023:5900:f38:e958:7bd]) by smtp.gmail.com with ESMTPSA id z83sm20416778wmg.2.2019.12.23.08.34.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Dec 2019 08:34:45 -0800 (PST) From: Torsten Lodderstedt Message-Id: <0483300E-97BE-4E45-9BC4-A371ED7F6403@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_D982E346-753B-481A-8607-04E973931B97"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Mon, 23 Dec 2019 17:34:11 +0100 In-Reply-To: Cc: "oauth@ietf.org" To: Hannes Tschofenig References: <1CF11B26-F4AC-4BD5-8B72-ED582E162B26@lodderstedt.net> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 16:34:54 -0000 --Apple-Mail=_D982E346-753B-481A-8607-04E973931B97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If I got you right you want to see more people reading the draft?=20 6 non authors had read the draft in Singapore + more people already = indicated their support for WG adoption in this thread.=20 How many readers does it take to qualify for a call for adoption?=20 > On 23. Dec 2019, at 16:56, Hannes Tschofenig = wrote: >=20 > During the vacation period few people pay attention to the list. I = guess early 2020 would be useful. > If you manage to ping some folks to review the draft that would be = great. Too few raised their hands in Singapore when we asked. > =20 > Happy holidays!=20 > =20 > From: Torsten Lodderstedt =20 > Sent: Saturday, December 21, 2019 10:59 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Meeting Minutes > =20 > With respect to Rich Authorization Requests, the minutes state that a = call for adoption will be sent to the list. When will this call for = adoption being sent to the list? > =20 >=20 > Am 03.12.2019 um 09:26 schrieb Hannes Tschofenig = : >=20 > =EF=BB=BF=20 > Here are the meeting minutes from the Singapore IETF meeting: > = https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03 > =20 > Tony was our scribe. Thanks! > =20 > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. = _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. --Apple-Mail=_D982E346-753B-481A-8607-04E973931B97 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 Fw0xOTEyMjMxNjM0MTFaMC8GCSqGSIb3DQEJBDEiBCB2i4RYtjB8LmgPALr1ZVJNBj0G7VgSnOor uc8drm9KPzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAJgGJipkxd0Tx/dpgDzXxlZ0cG5v5/4dZnznI0aS/xnLwRKf8hhVMyWxO3HN 5SEWfZe7et5nQ4M/+ZkMEYtLDMX4iIEyi3YL3i+gfHC+aTSCt4wDfL06pwcAznLShxYXmyIQe3Rw uCL/iXWD5Sw1Kv+GrmhwkrqAYk4RK7tkj8X3ILHvgs9bHFTtsxl/ZmcKvgvmHb0tGu6ggg1x27yZ KIG7LnOrdNOWT3tVeX9/B0zUqDyno0u/AM/cCncwIJ12z+RaEDesWQ9DftFR0MClRRXsGfJqggWH gU5fogpdb7xUuNDoUEuOzRd8rXHKvwanIG0E5gIfmR/3WJLBi98razwAAAAAAAA= --Apple-Mail=_D982E346-753B-481A-8607-04E973931B97-- From nobody Mon Dec 23 11:13:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831E7120CDA; Mon, 23 Dec 2019 11:13:53 -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=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 iuHfIGcZo4Qh; Mon, 23 Dec 2019 11:13:53 -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 C68AB120CD8; Mon, 23 Dec 2019 11:13:52 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBNJDiH1023772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Dec 2019 14:13:47 -0500 Date: Mon, 23 Dec 2019 11:13:44 -0800 From: Benjamin Kaduk To: "Richard Backman, Annabelle" Cc: Vittorio Bertocci , Vittorio Bertocci , IETF oauth WG , "i-d-announce@ietf.org" Message-ID: <20191223191344.GD35479@kduck.mit.edu> References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> <2518B18A-AD93-44E4-88D1-E5F6AAE7B1BB@amazon.com> <16EBA415-06A9-4190-B8C3-EE96771B70BD@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <16EBA415-06A9-4190-B8C3-EE96771B70BD@amazon.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 19:13:53 -0000 On Tue, Dec 17, 2019 at 09:12:26PM +0000, Richard Backman, Annabelle wrote: > > That's a pretty strong statement :) > > One I should’ve clarified. 😃 I don’t mean that the one-RS-per-AT model is not used at all, just that it is not universal and comes with real, practical tradeoffs that may not be appropriate for all use cases. Consequently, we should not design fundamental specs that mandate its adoption. > > > > …knowledge of that level isn't necessary. > > Either the RS and AS have a shared understanding of that level, or the RS is trusting the AS to decide what “AuthenticatedClient” means, and set it accordingly. The latter requires that the RS only supports ASes that have a shared (or substantially similar) understanding of what that level is, which is unlikely outside of a closed system. In that case, there isn’t a lot of value in providing a standard claim, as the closed system could just as easily define a proprietary one. Talk of the different potential levels of authentication calls to mind RFC 8485's "Vectors of Trust" idiom, though, IIUC, it would require some adaptation to be useful here. -Ben From nobody Mon Dec 23 13:19:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207C71200FB for ; Mon, 23 Dec 2019 13:19:43 -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 Qv3vwwX9bkgf for ; Mon, 23 Dec 2019 13:19:40 -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 26209120043 for ; Mon, 23 Dec 2019 13:19:40 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id z22so14182698ljg.1 for ; Mon, 23 Dec 2019 13:19:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BfyoC5dUMHR6qIetJotLBJO2WtVslj9nEqQOiB2O2ws=; b=YkSbuyupCiRk0TMmffBsR4K/fhXm7NvdGurVHcr56L1nekvKn824Sk95IB3s9qq4v+ anW+8fZmsLVDpUONzajTDytElOTChjWYX1FerspXhmZoNqQJJr2tPfSIt/sFEujmjXEm 2p89bt/2IAjZHXXRQO0SeLAHmj8jmi2QY5fULo+mKG7uMGd2uugzdiUWlXkPiINjUMPT a6TlsAi76Eqf4nx44wpQdTrEgch8yCBvOZq6fQ5qlDocR4XZh5/ekMrwRNcW7NZtYWD9 M3HjUHUsk4mcUz6C3ilrtx8vEND4N1WbgETfv4SFfWyB9b7owSVy4yUJ11z1N0rkh7Nr KUiw== 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=BfyoC5dUMHR6qIetJotLBJO2WtVslj9nEqQOiB2O2ws=; b=kxPqR6tR/DQFRCoARbfFsBEZkTgoGykwBRtHKJULIBa38W6qLvwgt88TvyjbzE9C16 /RmTdQJWKNcf01O7wI9H1KyE0vEQiPitdkhxu+6TmR7mMGeP7YHym4i9zMGhr+KD+/Hp RGe27kbkh2skTZ167k9DyTBqKaUCpbIrL5eSUGGBjdib1jTRLqU7x2BP3ptXYHhrY+UZ TvIdOanzXT1wqivHUBdt4v6EKZPd0W3C0aIf1xTBVkSCSRGAWe/h0LWBQofeXJxl0DJ6 VVUkg6/PUt1j3h/JZ9K3+t/MLAUYc4hWb/ARyidvZP+nDs79u13PkJyEjKj4yLyyt6Oy 2Iig== X-Gm-Message-State: APjAAAUshZLOmDzpoz74cGSasYIuAFU+5g6bcwmvPioswn2zk+au4kTI v1hl/GjPJR8CxQsOUia1PZAWMTAgKtTryP+C/AFMm/5p2dyJDnvtltF7tWB+iPLpYVb1mn1iVPR IFeCKW7Q7Dwh/eN3CUVk= X-Google-Smtp-Source: APXvYqwu4bIuWCFetOCve37Me2NMQJgGeHs6MrprUlcC6ABDiPOfoU0wUhyz/yOOa6rf/UCgXVWbKhLmxQNMlVSQf3Q= X-Received: by 2002:a2e:8197:: with SMTP id e23mr10935595ljg.250.1577135978250; Mon, 23 Dec 2019 13:19:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 23 Dec 2019 14:19:11 -0700 Message-ID: To: Hannes Tschofenig Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bf2bf0059a6595be" Archived-At: Subject: Re: [OAUTH-WG] Doodle Poll for OAuth Virtual Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 21:19:43 -0000 --000000000000bf2bf0059a6595be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable BTW and FWIW the mention of a virtual interim first came up in Singapore in the context of continuing the discussion around DPoP/PoP. https://www.youtube.com/watch?v=3DhVQZR1IvS1E&feature=3Dyoutu.be&t=3D3924 On Mon, Dec 16, 2019 at 11:12 AM Hannes Tschofenig < Hannes.Tschofenig@arm.com> wrote: > Hi all, > > > > at the Singapore IETF meeting we had a discussion about a possible update > of RFC 6749 (with the codename of =E2=80=9COAuth 2.1=E2=80=9D). A discuss= ion at a > side-meeting in Singapore made clear that there is no common view about t= he > goals of such an effort and whether there are other options to reach the > same benefits. > > > > To continue the discussion and to provide some clarity in our decision > making progress we would like to schedule a virtual interim meeting early > next year. Here is a Doodle poll: https://doodle.com/poll/z7ue3gsu5tuskq7= 9 > > > > Please indicate your preference by the end of the year. > > > > Ciao > > Hannes & Rifaat > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=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._ --000000000000bf2bf0059a6595be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
BTW and FWIW the mention of a virtual interim first c= ame up in Singapore in the context of continuing the discussion around DPoP= /PoP.


=

= On Mon, Dec 16, 2019 at 11:12 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
=

Hi all,

=C2=A0

at the Singapore IETF meeting we had a discussion ab= out a possible update of RFC 6749 (with the codename of =E2=80=9COAuth 2.1= =E2=80=9D). A discussion at a side-meeting in Singapore made clear that the= re is no common view about the goals of such an effort and whether there are other options to reach the same benefits. =

=C2=A0

To continue the discussion and to provide some clari= ty in our decision making progress we would like to schedule a virtual inte= rim meeting early next year. Here is a Doodle poll: http= s://doodle.com/poll/z7ue3gsu5tuskq79

=C2=A0

Please indicate your preference by the end of the ye= ar.

=C2=A0

Ciao

Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= 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. --000000000000bf2bf0059a6595be-- From nobody Mon Dec 23 14:00:04 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF64C1201DB for ; Mon, 23 Dec 2019 14:00:02 -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=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 J16akE72nWM4 for ; Mon, 23 Dec 2019 14:00:02 -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 CB45B12011A for ; Mon, 23 Dec 2019 14:00:01 -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 xBNLxwl4000484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Dec 2019 16:59:59 -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: <20191223191344.GD35479@kduck.mit.edu> Date: Mon, 23 Dec 2019 16:59:58 -0500 Cc: "Richard Backman, Annabelle" , Vittorio Bertocci , IETF oauth WG Content-Transfer-Encoding: quoted-printable Message-Id: <2A1C50C8-24E3-49EA-AE59-7D85F52DDAA0@mit.edu> References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> <2518B18A-AD93-44E4-88D1-E5F6AAE7B1BB@amazon.com> <16EBA415-06A9-4190-B8C3-EE96771B70BD@amazon.com> <20191223191344.GD35479@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action: draft-ietf-oauth-access-token-jwt-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 22:00:03 -0000 Vectors of Trust was meant to be used in place of things like = AuthenticationContextReference (acr) and its kin, so this is a fair = assessment.=20 It does still require a shared understanding of what a given vector = means by processing it in the context of its trust mark. =E2=80=94 Justin > On Dec 23, 2019, at 2:13 PM, Benjamin Kaduk wrote: >=20 > On Tue, Dec 17, 2019 at 09:12:26PM +0000, Richard Backman, Annabelle = wrote: >>> That's a pretty strong statement :) >>=20 >> One I should=E2=80=99ve clarified. =F0=9F=98=83 I don=E2=80=99t mean = that the one-RS-per-AT model is not used at all, just that it is not = universal and comes with real, practical tradeoffs that may not be = appropriate for all use cases. Consequently, we should not design = fundamental specs that mandate its adoption. >>=20 >>=20 >>> =E2=80=A6knowledge of that level isn't necessary. >>=20 >> Either the RS and AS have a shared understanding of that level, or = the RS is trusting the AS to decide what =E2=80=9CAuthenticatedClient=E2=80= =9D means, and set it accordingly. The latter requires that the RS only = supports ASes that have a shared (or substantially similar) = understanding of what that level is, which is unlikely outside of a = closed system. In that case, there isn=E2=80=99t a lot of value in = providing a standard claim, as the closed system could just as easily = define a proprietary one. >=20 > Talk of the different potential levels of authentication calls to mind = RFC > 8485's "Vectors of Trust" idiom, though, IIUC, it would require some > adaptation to be useful here. >=20 > -Ben >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Dec 23 14:56:33 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84869120D15 for ; Mon, 23 Dec 2019 14:56:32 -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 BOef-0GfnOXD for ; Mon, 23 Dec 2019 14:56:30 -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 844DA120D11 for ; Mon, 23 Dec 2019 14:56:30 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id u1so19171651ljk.7 for ; Mon, 23 Dec 2019 14:56:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=EnME33OXEJ0anh25ArGcfDGS0xAhIc4mlPcLZSU6tEI=; b=LeKZyuB2JQAYWh3aX6MEzvo6a6vgRySS+feD7aosicHYo9ZT3fCdobwzwCI/NrWB/R SWeRjNR0fdxD7YPPuM6TxX5rvqsuaSGubjCnTbbZEPJwdRP0xzqxTD4pqR6UDVW2UwlB mvvr1Www3oDmAZoBrSNGQtX71jM922qo0M1k1VLzmJK6GA2u6cVETuLwmsvTfgsOWttZ tJ8bh9tdL1gdfMSG9HlL2jCmkYhXjfW4m84fe122Wny9Jk+5Pxqz+LEswCpz8BKAymtz qQbH3XD8UU9/eQjouxF6/S4clJb2k/6RAQD/JBzW0EbnMAsW7LF96aDBIFATgBoF/MzK uB2w== 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=EnME33OXEJ0anh25ArGcfDGS0xAhIc4mlPcLZSU6tEI=; b=lV/+fibUrUtPwSYd7bncyGlzemOkQ89lXGvOlgGG8mMtMhfCe7Y6qj2qFU0aPFWoAx xNkF5cXjDOJ7+tfdm6FZOgSLu3qRaVuR5jL+spJAARYMOS6BKh/53TB33NUbN6EZdOxC j4UVbRAqtQ2UCBcT/yIOyRZMW8eiD+eNI/+bVMVNXVyMpPTpGpkaI5vJmY5rvRMLhVnT 5C5SYo9JVvC4DuEc+5zsnWnNb6fvnVEWRIbJXbpJqq7opLDiHMmhz3jx9hVHuIG5Aplw pQDYqkbfq4v6TcFJWCEcA8aSit4Grl868D+53PikN/mQw7ndHfldSEWEGZBXi2EFiG+o uiDQ== X-Gm-Message-State: APjAAAUu36SPdMdvB0D885meHPMZD5VvRYs+3cuFjAYXjjyGOMQxHs7h PlvH+TUEgEOIttndR1ezow3dRyhVHqGYsMccyd5yJbYiA+17Oq1fNQGLWHI/53UJOv1Vw8f2rPt LGyARr1KZZGNN37oD X-Google-Smtp-Source: APXvYqzV6evMd4HYUoMisDdLkIH8RkoO3awNWSoPiYYBqr1dyBtO73QZnCTz3zlI+w855/LqR1ggCVhamePLbPjfb8Y= X-Received: by 2002:a2e:8e85:: with SMTP id z5mr5040818ljk.212.1577141788251; Mon, 23 Dec 2019 14:56:28 -0800 (PST) MIME-Version: 1.0 From: Brian Campbell Date: Mon, 23 Dec 2019 15:56:02 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000000cb23c059a66f09d" Archived-At: Subject: [OAUTH-WG] !@s in -security-topics-13 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 22:56:32 -0000 --0000000000000cb23c059a66f09d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are a few occurrences of [!@RFC...] which presumably come from a typo in the markdown source for mmark (switching the order of '@' and '!'). --=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._ --0000000000000cb23c059a66f09d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are a few occurrences of [!@RFC...] which presumably= come from a typo in the markdown source for mmark (switching the order of = '@' and '!').=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000000cb23c059a66f09d-- From nobody Mon Dec 23 15:23:01 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18B6120D5B for ; Mon, 23 Dec 2019 15:22:58 -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 sVcmNZ7dYNaP for ; Mon, 23 Dec 2019 15:22:56 -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 097CB12002F for ; Mon, 23 Dec 2019 15:22:56 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id l18so5628192lfc.1 for ; Mon, 23 Dec 2019 15:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=brFLNr85IifzaPWLkodO5w8YfScOzYcrNohiLVXndLo=; b=HtkIksyiCAM4cgCbUVsp+D2rgHjVgEEm+p/jQs7V3Siur5sADHmtWgdjTO4MogDBGP /7TQllzZet226sP5GFqDR6r4s3pdMPbeWA6YV5CHZjPoP6bzy8HNkuFBgDISHqGOX7It U/SWKymBoda/T1oAhq77OLl8VT0t8++uXI4hPYvPkDgXl2zUsGsFoLI6SXjQ9dwAXlzE W6sEN5qowk+DDeEU1yxRNJcRYgTYhPGUaP4h50VYGxVjWemx4fxRPr0/8Q4uuXqjr5t5 MSFSkjZ9DupPOCl1Rf7adjIHkIa1MzsUgj5a58Qp6m17KzMj9JwwKc/kNSByahTsgEtN BjYA== 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=brFLNr85IifzaPWLkodO5w8YfScOzYcrNohiLVXndLo=; b=LZHM1h8fImmIfvpz71c61w78gzfCoGaRwejQgv96GW+SedFAIeI7Al4gQZWJdJg1IO PwdZsAKWfjXvdz9DcEiHfFXbv80FVLxq0BpOik5RYtU6yMvquWXQKZ/0XpqfO54w/fDi 0g87pf65GtXLMOSUUV9nHqqUEbu5yzfdQg6m6GUzNr6wQN6+LPhLuXeWOIaQsQP8i0p0 FrwsGRNfnVei5yPMZx/ehBkZep3XJIRzfa1ir3B41Yb9CgkrG4VQ7JHIWJoU086Ib6Kh G8lvAEXUhdn5iLNU4lyZhkbzgUiOWdH+ysouh7dZYjzJw9cekQjL7lCFDKWIdxwRnpDl imKQ== X-Gm-Message-State: APjAAAXLyMBOYZglC3YxIYeFBtXAPGDbOrVCfS5R3J2svu0Wg70gPgV8 EcLDQkIFQn7ZnLxCmz3rZdAwH50RpMVTqzp253ktML/xjXKldt3hVCXRQ+cvfwIr9Vv1hM5dU1H LPk4yekkRwgE2z4CenNA= X-Google-Smtp-Source: APXvYqxsP69WsIgVDcY0pt9aDvioWcB2pMYE6kCI2Yo7ziil5SsV0mkSXx5Zl6At6FLQ5A/q1TjqwjKsY9CbCFObGII= X-Received: by 2002:ac2:4884:: with SMTP id x4mr17663075lfc.92.1577143373882; Mon, 23 Dec 2019 15:22:53 -0800 (PST) MIME-Version: 1.0 From: Brian Campbell Date: Mon, 23 Dec 2019 16:22:26 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000008faaf9059a674eb4" Archived-At: Subject: [OAUTH-WG] Token Binding & -security-topics-13? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 23:22:59 -0000 --0000000000008faaf9059a674eb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 mentions or suggests the use of token binding as an option in a few places. However, the OAuth 2.0 Token Binding draft expired back in April and is looking highly unlikely to progress or be updated further. It's also pretty much undeployable given the current lack of support in platforms, browsers and TLS/HTTP libraries. Perhaps the Security Best Current Practice document should remove reference to draft-ietf-oauth-token-binding or at least de-emphasize it considerably? That token binding isn't a viable option leaves only the soon-to-be RFC of MTLS as the only real option in recommendation of https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.2 which has: Authorization servers SHOULD use TLS-based methods for sender- constrained access tokens as described in Section 4.8.1.2, such as token binding [I-D.ietf-oauth-token-binding] or Mutual TLS for OAuth 2.0 [I-D.ietf-oauth-mtls] in order to prevent token replay. Maybe this already rather aspirational SHOULD should allow for non-TLS or application-based methods as well, to at least allow room in the BCP for the possibility of using some yet-to-be-determined PoP method that might come along in the future? --=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._ --0000000000008faaf9059a674eb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https://tools.ietf.org/html/draft-ietf-oauth-securit= y-topics-13 mentions or suggests the use of token binding as an option = in a few places. However, the OAuth 2.0 Token Binding draft expired back in= April and is looking highly unlikely to progress or be updated further.=C2= =A0 It's also pretty much undeployable given the current lack of suppor= t in platforms, browsers and TLS/HTTP libraries. Perhaps the Security Best = Current Practice document should remove reference to draft-ietf-oauth-token= -binding or at least de-emphasize it considerably?

=
That token binding isn't a viable option leaves only the soon-to-b= e RFC of MTLS as the only real option in recommendation of htt= ps://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.2 which has:




<= 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. --0000000000008faaf9059a674eb4-- From nobody Mon Dec 23 15:27:39 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95526120D20 for ; Mon, 23 Dec 2019 15:27:37 -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 AJ_yJyWKvmvb for ; Mon, 23 Dec 2019 15:27:36 -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 0B6AB1200C5 for ; Mon, 23 Dec 2019 15:27:36 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id r14so13817219lfm.5 for ; Mon, 23 Dec 2019 15:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=iRlhmNsMdt/iJKb1LQG9MgSLm9j5sYhMxE2guqvb/Bc=; b=ZWYV9rYSJ8hbpVHBDAC5HzhYCWUQ7wAuA65gd7AaHj6q0R7QgS4XCLee+BjzPXWLiN hgLAk1chyLIiqPB5ms7It9tBWpBYEF1MehDgA9o6F/LuAQEbxHyWnXQtEVSHAGCtzMGH udXTIDWA20edP4icZeXLe6Ueo4L/eqo51pz2N7bF7Rb4n6Bv2PNfxYc7U3YSTowm4sFB gvN7nMZis/JhqMVNX9Sbxi7bHtGCULvbJtn9c1eJl/gwVAFl5kcUJXTbcySEoM6u7Cyw 73k8xLq9iD8OnD8gaN/vUVP8jvLOmlQPL9A4wWMEZncMzk4Hndp9vkszrfuP3lNkobt9 jg8w== 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=iRlhmNsMdt/iJKb1LQG9MgSLm9j5sYhMxE2guqvb/Bc=; b=P23oe60liPULot4ioEWKvhzMd03OmAAHzHG6IrUTFz3GTIp3gTTVRpzyLWz9+mYMla kuLoWSazo681k6DTJf07O1PJyKc5lO+oJ6XkugbgU840Fzu2n1x1y5/cDLP+4wmHyeEa ubAagD1iRelJSkxAr25GfFKXF5iqCRvcGDZgjlOapkKY9hAmSr76L83DdcNz30XOtC6+ 4hEcpqpyHOXi8tvdZidlulIkqDAEzaemWzrpdDvI5NyWO1n6NR5Hm2MZ9cxAuVbRAspx +hGSOFCBgDLpBIdwPmOh+7HODrlQltpH9plmRbzS9cefL8ql4M1iDrtu1qKekSurWcLx Ay9g== X-Gm-Message-State: APjAAAULXLm9Z5Es9DgG/Fpmrvcx818lYK2tDJ5xRty2zfz5/DJYkeAT /RItkL5lOakQx7PqbE+jPdXidbsTiJZOQx2PbO/FofIY1sQf+3zVEbtbEcd59w1MMBThyDCxyOy 4bgrN7WRvHlL2xlpvLU8= X-Google-Smtp-Source: APXvYqxO5XO2k0LyT9y1JCOO1kr2YrU8FK4ZAsyI9Yui4/wHu9Osq5mI71tdKPCKMLXKB9loUcBW3t+Tp61dHN/dhpg= X-Received: by 2002:ac2:5592:: with SMTP id v18mr16942938lfg.17.1577143654071; Mon, 23 Dec 2019 15:27:34 -0800 (PST) MIME-Version: 1.0 From: Brian Campbell Date: Mon, 23 Dec 2019 16:27:08 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000042d8cb059a675f66" Archived-At: Subject: [OAUTH-WG] postmessage communication in -security-topics-13 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 23:27:38 -0000 --00000000000042d8cb059a675f66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.3= .2 has "Replace implicit flow with postmessage communication or ..." but without a defined and interoperable way of using postmessage communication in place of the implicit flow that "proposed countermeasure" seems a problematic suggestion. --=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._ --00000000000042d8cb059a675f66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https://tools.ietf.org/html/draft-ietf= -oauth-security-topics-13#section-4.3.2 has "Replace implicit flow= with postmessage communication or ..." but without a defined and inte= roperable way of using postmessage communication in place of the implicit f= low that "proposed countermeasure" seems a problematic suggestion= .


<= 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. --00000000000042d8cb059a675f66-- From nobody Mon Dec 23 15:36:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59276120D21 for ; Mon, 23 Dec 2019 15:36:43 -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 85OovvBvrfgo for ; Mon, 23 Dec 2019 15:36:41 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529E912003E for ; Mon, 23 Dec 2019 15:36:41 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id y1so13812741lfb.6 for ; Mon, 23 Dec 2019 15:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=w5Jer1DdstFlXD28ira5Nu6cQW71o0xEZFvZqKWEV50=; b=B9yXTGoLCWoV8avjCKYshiIJACWTLvQUEzkpy0nGJ1a87bGbvyhafLJ14E1zECU8Gp msFP26FlujU/mkeLBqX8Oh2uGn4wO50JxUr3dzipSztO6CUrq5rmRArmQaNFpKvHWQsm M7K6NNZsFynFC3y7mV8B/TVblCgW7WAp9GAqWM15ekUmrHmbgmkomOfVFy5NfcEnoBa8 wipaJvgT3m+wSwbH3HO1bifj5BB048k0Tth/utH5rEL9oa8d9rr6Y8fSeasQ2zAvBxaS fYuH8K/IItmXqGJgvmkVDS+wWajbVBQ+e19g0FarPF8zXHdN1Jtu5U1s00JgcMwoI4v9 5BAg== 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=w5Jer1DdstFlXD28ira5Nu6cQW71o0xEZFvZqKWEV50=; b=jGJJvX4s9bZxR/PHGW3Goc3M5cbPg4GCTOjbuZ/+eq+ihbgHXtXf9bnvZhhz4xckN/ QoUUP/69oNO6X3RgLQ6lAiRwltby8pBRxiissviqQY+qyJnbpy0QHn+NGSCpfjOWjCE5 Hr1FyyokoOzv65fARfp91KHHafB1m53eQJSnf3OQJLWRLr68n2wl7okjbL1Bk3YjsQrK B+LrCW0Q9NaRyLK9se4hXKGwfT6zbakcUJ+GD1Ufczykexq57rtfKkiPsR86xcpuDYhK dIuBhn062inCEXuMqhf6iu1MpNBmiCXb/yJA6Iss8vFAcYPISfv82jHZA+jGf47b+8ij BW0A== X-Gm-Message-State: APjAAAX2BiNuYrz/LWbfJRCX5wEaazKSpYEcFtvBAP7uadTLtXIHxm/L fjDVpHRaFAvzjgpXbKUTlieph17S3ZI0TvFwHfMkD0UAR7Sa29s96vKpEaO50DkfGSP3wl3zjLk oFqf03e0XG+MD5ld3Y3U= X-Google-Smtp-Source: APXvYqw5++UnfiG1TpYPb5Oz7ZBcWTJcICShgB6zg9u4jE1wkZssDTgNDZ93swbO9YT5vVu0YfL4StuB3oqw6KTNZ7A= X-Received: by 2002:a19:5057:: with SMTP id z23mr17929223lfj.132.1577144199274; Mon, 23 Dec 2019 15:36:39 -0800 (PST) MIME-Version: 1.0 From: Brian Campbell Date: Mon, 23 Dec 2019 16:36:12 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000c204b5059a677fea" Archived-At: Subject: [OAUTH-WG] key vs. cert fingerprint in -security-topics-13 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 23:36:43 -0000 --000000000000c204b5059a677fea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The description of OAuth Mutual TLS in https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8= .1.2 says the "client is identified towards the resource server by the fingerprint of its public key" but it's actually a fingerprint/hash of the certificate not the public key. See https://tools.ietf.org/html/draft-ietf-oauth-mtls-17#section-3.1 for example. --=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._ --000000000000c204b5059a677fea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The description of OAuth Mutual TLS in ht= tps://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8.1= .2 says the "client is identified towards the resource server by t= he fingerprint of its public key" but it's actually a fingerprint/= hash of the certificate not the public key. See https://tools.ietf.org/ht= ml/draft-ietf-oauth-mtls-17#section-3.1 for example.=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000c204b5059a677fea-- From nobody Tue Dec 24 02:44:16 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ED0120D38 for ; Tue, 24 Dec 2019 02:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke-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 oDYQIs0RYLtm for ; Tue, 24 Dec 2019 02:44:11 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0: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 C4647120D31 for ; Tue, 24 Dec 2019 02:44:11 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id h9so23316433otj.11 for ; Tue, 24 Dec 2019 02:44:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TrvhvKRFDOZYCghnmiJMsvNAJwUfl1Xh/9av0go6Z4A=; b=dR9ldmAGm8gPrVgNeJOAnZ8APO0GFii+uqgPRMKSeqC+GWMXBmk4c2juL7Tp2BY4ZY MA5lYV+LIwBVUIxO6C6MpJFncVQGk6X83b0G1fHfd0BCdc7Fhb3CNJ/ZxoP2kQuEb30D p9HWGWNHnE4356dHgy3tOShOWRekWfI2Xb/ElKUmRSIJgQVQUGPOzpUA6q9VYEINSUM1 FnQKe3Iy3FRYoMnImtA2risMs9OcCUCmZVTqFKXVTcU8+rFo67iR30S7ESzrxK/tnjYn sYqMJvHZ99d5w1Zy8YwZXwhImrbBK5q58VMjKARYB3JB5f4XpPy1eeM7TWgSg7c5Wgq6 kSBg== 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=TrvhvKRFDOZYCghnmiJMsvNAJwUfl1Xh/9av0go6Z4A=; b=E+eqYhE7kMZiMYIuCDmGBmvR2Mnc2suEy9scjhImWN7G1up9shzo3o/a39bsn7xeKu 5Xb80zQ39v3mMx4+PUmBcU5zAWThZJCSOcxHdF68acclHts4imrJSfvhiKQ4nrysbt6Y IC0NwNxxZbSjXvltOl1L/p36rry+3DZflYVVPUfXzh3RS/t0gde/CQMf8jFSz+UW3MfT 1CMexNI+rgSPUaMmJgbmAXTdFfk7h1oGmRH9SIByBynU6Y30oFBomGrY9jr409GaM/WV GkEeIF5G9Zu4Cx8QfLcAuWk1APgz9RZYcqh8hI1MP0tRqYoB73y4G7ue/4h9wBaHL3jN OqsA== X-Gm-Message-State: APjAAAXvCxCbijqk0trLZEkQJy5LFId2lfkIGPJlVQyZN4H4/aDEgxva 44nVIX05477mH/4KEGxKWWyShZxfelehUPLGVUS6QA== X-Google-Smtp-Source: APXvYqymGmZCM7atan1sCiT1oLFyh5JErdDlTnUdbe7592L/Jt4u802pgkDGw1bTQ9LYW7dE3IzOH6fFmMPJ2Eo7XrA= X-Received: by 2002:a9d:7ad9:: with SMTP id m25mr35802446otn.13.1577184250970; Tue, 24 Dec 2019 02:44:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jim Willeke Date: Tue, 24 Dec 2019 05:43:35 -0500 Message-ID: To: Brian Campbell Cc: oauth Content-Type: multipart/alternative; boundary="000000000000065bdf059a70d35a" Archived-At: Subject: Re: [OAUTH-WG] !@s in -security-topics-13 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2019 10:44:14 -0000 --000000000000065bdf059a70d35a Content-Type: text/plain; charset="UTF-8" Yes and some are wrong: 3.1.1. Authorization Code Grant ... AS metadata ([!@RFC8418]) Where RFC8418 is "Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)" and has no Metadata entries. Happy Holiday Jitter? -- -jim Jim Willeke On Mon, Dec 23, 2019 at 5:56 PM Brian Campbell wrote: > There are a few occurrences of [!@RFC...] which presumably come from a > typo in the markdown source for mmark (switching the order of '@' and > '!'). > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000065bdf059a70d35a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes and some are wrong:
3.1.1. Authorization Code = Grant=C2=A0
... AS metadata ([!@RFC8418]= )=C2=A0
Where=C2=A0RFC8418= =C2=A0is "Use of the Elliptic Curve Di= ffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptograp= hic Message Syntax (CMS)" and has no Metadata entries.

<= /div>
Happy Holiday Jitter?


--
-jim
Jim Willeke

<= /div>
O= n Mon, Dec 23, 2019 at 5:56 PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
There are a few occurrences of [!@RFC...] which presumably c= ome from a typo in the markdown source for mmark (switching the order of &#= 39;@' and '!').=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000065bdf059a70d35a-- From nobody Tue Dec 24 04:05:10 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416C6120D28 for ; Tue, 24 Dec 2019 04:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=a/haM8kA; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=VjMOvTYd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_cb1FcKitfA for ; Tue, 24 Dec 2019 04:05:06 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30068.outbound.protection.outlook.com [40.107.3.68]) (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 B74B2120099 for ; Tue, 24 Dec 2019 04:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=szVz5ZjCaMJXkgtpCUMbVyLzFEn4AwsCnnqSkOAgFAw=; b=a/haM8kA+wton4x+wKIzy/oq5RdzlayD2KzxRThFjQ74N3be3FWMaSJ2FgzFRlnx+CyWt4aUSrQ44JdPeZ9b+V6LfSWf7LnOcvHeG4N+lXULM/0V6uB0hMXVb0DNG9spaMa/GYeWRnx8KrIXnIVZLsuxBDK49+zme7rjRjDsiDM= Received: from AM6PR08CA0017.eurprd08.prod.outlook.com (2603:10a6:20b:b2::29) by DB8PR08MB4138.eurprd08.prod.outlook.com (2603:10a6:10:a4::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.17; Tue, 24 Dec 2019 12:05:02 +0000 Received: from DB5EUR03FT028.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::208) by AM6PR08CA0017.outlook.office365.com (2603:10a6:20b:b2::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14 via Frontend Transport; Tue, 24 Dec 2019 12:05:02 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT028.mail.protection.outlook.com (10.152.20.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14 via Frontend Transport; Tue, 24 Dec 2019 12:05:02 +0000 Received: ("Tessian outbound 0eaff1016ea4:v40"); Tue, 24 Dec 2019 12:05:02 +0000 X-CR-MTA-TID: 64aa7808 Received: from c7da9eb0fff3.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 048AC586-E054-4D89-841B-AC000CCEC8ED.1; Tue, 24 Dec 2019 12:04:57 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c7da9eb0fff3.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 24 Dec 2019 12:04:57 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n74f76HQDk+RNHMM8o4bdmgM/JiLLINwCsT5ydrQ2PSSJXZcgNrhgyvfaU9Cf36Bpdwcu78BZglpJ2OW5K0gHD+kB5jc+0/VMxBfmrHB5NlK4OknQLwxlyPrfxUg3wCGze6K5aMn2DX3TQK+v0tFQygKX1WHVsYfzsYG5xRFbaAMUkQfntK5YUuuhCGZQHq40xIeXx1fK0nBOFj68iag2pUiU+pbmTSKEAYSP2CmOGmK/+AgxWGXiEQazOvN5Neuv1ssVur2TlwuEw85y1XERuIIHTfmKpBnszDgWCJZg2bQ0ekA6uhcbnrAZ3VRCXfiq2R4coEfUVQNcOsOp5DnnA== 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=7LLN25C9/KH1hVYr/eSJ3ILFWPuwmtqnx059tFmRpQI=; b=HeQJtdPuSM+92m5bs1C2hEmrYOj6MMtILSOr1/aErcaSpwk2/fVaEeDEh66/3Q3mnNnR2Ri45FAz/7ltiPczcr+3pdglv6VsWodbgqvoPswEfcJsRC9SA2dIzm0RRVw6XAyMd9D5g3SOEIcbgokgPuDvHLwok57CIjv/YojFniTPTrbfEc/5VlIvszZvTr1GFuXPnsMiWVv/bLzHFrKszvDuBd98Sd2vkP8ez7d+JSKySNMobWzwMtL5Y2apGlCcDja3igK+HbtuxDcL7wQ2m7vDN2ojHwpKsTEaPbL3rMKoqMRbYCs3Tmr/uVGvlMXJ/Fh45szrEv382ukxRY0Vdg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7LLN25C9/KH1hVYr/eSJ3ILFWPuwmtqnx059tFmRpQI=; b=VjMOvTYdzu9YqsXkwNiBA58GLfj2LO92L3Db7lf2xcEMEMkV3hejq/kTWAGETeQZM59Ppakr0p76bOvzP3IcmVaQ1l9pec84WfWxIxKt0Dgm63rt5++Q8c4hCny4nC74rR0PNWPteBtfDCHgXOv3MJW3s5QWvlR9oc/50Jd2PNo= Received: from AM0PR08MB5283.eurprd08.prod.outlook.com (20.178.117.20) by AM0PR08MB5523.eurprd08.prod.outlook.com (52.132.212.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14; Tue, 24 Dec 2019 12:04:56 +0000 Received: from AM0PR08MB5283.eurprd08.prod.outlook.com ([fe80::ec3a:92ca:f8e1:d314]) by AM0PR08MB5283.eurprd08.prod.outlook.com ([fe80::ec3a:92ca:f8e1:d314%7]) with mapi id 15.20.2559.017; Tue, 24 Dec 2019 12:04:56 +0000 From: Hannes Tschofenig To: Brian Campbell CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Doodle Poll for OAuth Virtual Interim Meeting Thread-Index: AdW0Oz45HKRgAXCsR6CnGXONoCCMnQFm2A+AAB7kgXA= Date: Tue, 24 Dec 2019 12:04:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: e3cf3a0f-0da3-4b3f-bfd9-a0bd77832d1e.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [195.149.223.43] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 5dbf1dad-3fc1-441b-a85f-08d7886981c1 X-MS-TrafficTypeDiagnostic: AM0PR08MB5523:|DB8PR08MB4138: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 0261CCEEDF X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(346002)(136003)(366004)(39860400002)(53754006)(40434004)(189003)(199004)(4326008)(478600001)(966005)(66476007)(64756008)(33656002)(52536014)(86362001)(7696005)(66946007)(66556008)(66446008)(76116006)(26005)(186003)(9686003)(55016002)(5660300002)(316002)(6916009)(71200400001)(8936002)(6506007)(53546011)(2906002)(8676002)(81166006)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB5523; H:AM0PR08MB5283.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: nHybckubBOaeMqf0zKzoV/XbxWrOgiY82AmPd//xkQan+uimN6Co53/WEmoQHPfbPCnFkgYsVbdpZs6bpwdHzeKGyMv2BqaihTKv1WVRSIfPHNghzKUiroS8rgfGN0gDVRUOPWtT2kRSodLwGYrUERiwMByU3xmmHaMd6ZCmTUDbjJ7oscGsdYYMbtgW/2C5kQMtEkmJcQAciGZj14EfTwmyXR19aUb+sin+zBVIn+m3gqGDP+KhT9bpQOEhbmnF26QFymNtDQq6vBl1A19/NWEvbb47sutT0LNBqYLQoUK0F9r9lC9pR0MC7BsiZGG9M7if0BGuU2SYwRL4zxsqqh6GnmNndvZolODaNFt4PcUxFdLE70ZjfPScjAJ9bKY6duKWfZhyWeTWozx++2D/0pa6t8oEz4UjhUZN7Pna9ZaVos3GnvLRrSPsjxtu3QZcNLeIoyrwJXEX2lWKK268nUxvhByiZUiKmQBPHHYNIqdEjW3gMOA0s6NRI/h78PAsdsqpWzCoZ3rnD67fhLZkdTVyDhScp8N4L3Vy31m2uQ2PJ53CRgjL8JT8oHW1Wg8h x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB5283F82096CDA5BBFBD93BD6FA290AM0PR08MB5283eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5523 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT028.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(396003)(346002)(189003)(199004)(40434004)(53754006)(26826003)(52536014)(33656002)(8676002)(966005)(8936002)(5660300002)(356004)(316002)(81156014)(81166006)(2906002)(55016002)(53546011)(186003)(26005)(4326008)(336012)(70586007)(70206006)(6862004)(6506007)(86362001)(33964004)(478600001)(9686003)(76130400001)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB8PR08MB4138; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; MX:1; A:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 50b1d666-ef45-4934-01ce-08d788697e29 X-Forefront-PRVS: 0261CCEEDF X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xKOmOQuqe2L5PQUgrYqxz4zkZH1zW5bnkfTULaQ+K11Akkrg4aVWum2i5zyWmMMxmukLBswZ+wLi+CG6lI7NdgNY7ggmRuf63oclWGsH/3iAavDSgxzOaM8jPPa4wTTWjAFnXjuiquVc4JVYdtH7JOvx0tCe9NIi1hpOY7Aqc/qTuFyLbNtv1WwH5M++6mLzixwy8714lg7k0Lmw9JJ2GF8rRv9e+DHOeL9L4KjiOVCsAdo4jM5vsWFS1x8kNUnG156svCrcyWH0VnWNJuVRya1t67/AZI1FRs4UA5Wi58X+AJacileekmYw46AsDBJ/7jzpQNxXANZRYbddxuwVVenuVGoYeS8HBU9Rd3Fs+CrM/81O1VGdh8o2AcQZIHIrHQTXvg4GZ0I2AYzB6ZCs/1ncbJ1S2gKfkvUJyRflst/Ajq9Qodzx0MtmkmpxIQBVMIWvjWHYg4qOaaQuYRm/uXY61MyaxNOh8SDrnPgxL40+RDIrAmSBbIZhRqAq5wC4ji4AN6f7w/PnNjgTY98iic6Td2AQZNnuHL04MmXxkwBfZZDzb9Hp34XZcnH/nNUP X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Dec 2019 12:05:02.5430 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5dbf1dad-3fc1-441b-a85f-08d7886981c1 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB4138 Archived-At: Subject: Re: [OAUTH-WG] Doodle Poll for OAuth Virtual Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2019 12:05:09 -0000 --_000_AM0PR08MB5283F82096CDA5BBFBD93BD6FA290AM0PR08MB5283eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RldJVyBSaWZhYXQsIFJvbWFuIGFuZCBJIGhhdmUgYSBkaXNjdXNzaW9uIG9uIGhvdyB0byBhZHZh bmNlIHRoZSBwcm9vZi1vZi1wb3NzZXNzaW9uIHRva2VuIGRpc2N1c3Npb24uIEV4cGVjdCBzb21l IGFjdGlvbiBlYXJseSAyMDIwIGFzIHdlbGwuDQoNClRoZXJlIGlzIGEgbG90IGhhcHBlbmluZyBp biB0aGUgT0F1dGggd29ya2luZyBncm91cCBhdCB0aGUgc2FtZSB0aW1lLi4uDQoNCkZyb206IEJy aWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4NClNlbnQ6IE1vbmRheSwg RGVjZW1iZXIgMjMsIDIwMTkgMTA6MTkgUE0NClRvOiBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVz LlRzY2hvZmVuaWdAYXJtLmNvbT4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtP QVVUSC1XR10gRG9vZGxlIFBvbGwgZm9yIE9BdXRoIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nDQoN CkJUVyBhbmQgRldJVyB0aGUgbWVudGlvbiBvZiBhIHZpcnR1YWwgaW50ZXJpbSBmaXJzdCBjYW1l IHVwIGluIFNpbmdhcG9yZSBpbiB0aGUgY29udGV4dCBvZiBjb250aW51aW5nIHRoZSBkaXNjdXNz aW9uIGFyb3VuZCBEUG9QL1BvUC4NCg0KaHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1o VlFaUjFJdlMxRSZmZWF0dXJlPXlvdXR1LmJlJnQ9MzkyNA0KDQoNCk9uIE1vbiwgRGVjIDE2LCAy MDE5IGF0IDExOjEyIEFNIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0u Y29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj4gd3JvdGU6DQpIaSBhbGwsDQoN CmF0IHRoZSBTaW5nYXBvcmUgSUVURiBtZWV0aW5nIHdlIGhhZCBhIGRpc2N1c3Npb24gYWJvdXQg YSBwb3NzaWJsZSB1cGRhdGUgb2YgUkZDIDY3NDkgKHdpdGggdGhlIGNvZGVuYW1lIG9mIOKAnE9B dXRoIDIuMeKAnSkuIEEgZGlzY3Vzc2lvbiBhdCBhIHNpZGUtbWVldGluZyBpbiBTaW5nYXBvcmUg bWFkZSBjbGVhciB0aGF0IHRoZXJlIGlzIG5vIGNvbW1vbiB2aWV3IGFib3V0IHRoZSBnb2FscyBv ZiBzdWNoIGFuIGVmZm9ydCBhbmQgd2hldGhlciB0aGVyZSBhcmUgb3RoZXIgb3B0aW9ucyB0byBy ZWFjaCB0aGUgc2FtZSBiZW5lZml0cy4NCg0KVG8gY29udGludWUgdGhlIGRpc2N1c3Npb24gYW5k IHRvIHByb3ZpZGUgc29tZSBjbGFyaXR5IGluIG91ciBkZWNpc2lvbiBtYWtpbmcgcHJvZ3Jlc3Mg d2Ugd291bGQgbGlrZSB0byBzY2hlZHVsZSBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIGVhcmx5 IG5leHQgeWVhci4gSGVyZSBpcyBhIERvb2RsZSBwb2xsOiBodHRwczovL2Rvb2RsZS5jb20vcG9s bC96N3VlM2dzdTV0dXNrcTc5DQoNClBsZWFzZSBpbmRpY2F0ZSB5b3VyIHByZWZlcmVuY2UgYnkg dGhlIGVuZCBvZiB0aGUgeWVhci4NCg0KQ2lhbw0KSGFubmVzICYgUmlmYWF0DQpJTVBPUlRBTlQg Tk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFy ZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29u LCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlv biBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ug b2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRp b24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdl IGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4N CklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBv dGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhl IGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_AM0PR08MB5283F82096CDA5BBFBD93BD6FA290AM0PR08MB5283eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GV0lXIFJpZmFhdCwgUm9tYW4gYW5kIEkgaGF2 ZSBhIGRpc2N1c3Npb24gb24gaG93IHRvIGFkdmFuY2UgdGhlIHByb29mLW9mLXBvc3Nlc3Npb24g dG9rZW4gZGlzY3Vzc2lvbi4gRXhwZWN0IHNvbWUgYWN0aW9uIGVhcmx5IDIwMjAgYXMgd2VsbC4N CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBhIGxvdCBoYXBwZW5pbmcgaW4gdGhl IE9BdXRoIHdvcmtpbmcgZ3JvdXAgYXQgdGhlIHNhbWUgdGltZS4uLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBEZWNlbWJlciAyMywgMjAx OSAxMDoxOSBQTTxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWcgJmx0O0hhbm5lcy5U c2Nob2ZlbmlnQGFybS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBEb29kbGUgUG9sbCBmb3IgT0F1dGggVmly dHVhbCBJbnRlcmltIE1lZXRpbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5CVFcgYW5kIEZXSVcgdGhlIG1lbnRpb24gb2YgYSB2aXJ0dWFsIGludGVyaW0gZmlyc3QgY2Ft ZSB1cCBpbiBTaW5nYXBvcmUgaW4gdGhlIGNvbnRleHQgb2YgY29udGludWluZyB0aGUgZGlzY3Vz c2lvbiBhcm91bmQgRFBvUC9Qb1AuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0 Y2g/dj1oVlFaUjFJdlMxRSZhbXA7ZmVhdHVyZT15b3V0dS5iZSZhbXA7dD0zOTI0Ij5odHRwczov L3d3dy55b3V0dWJlLmNvbS93YXRjaD92PWhWUVpSMUl2UzFFJmFtcDtmZWF0dXJlPXlvdXR1LmJl JmFtcDt0PTM5MjQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gTW9uLCBEZWMgMTYsIDIwMTkgYXQgMTE6MTIgQU0gSGFubmVzIFRzY2hvZmVuaWcgJmx0Ozxh IGhyZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tIj5IYW5uZXMuVHNjaG9mZW5p Z0Bhcm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIGFsbCwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+YXQgdGhlIFNpbmdhcG9yZSBJRVRGIG1lZXRpbmcgd2UgaGFkIGEgZGlzY3Vzc2lvbiBhYm91 dCBhIHBvc3NpYmxlIHVwZGF0ZSBvZiBSRkMgNjc0OSAod2l0aCB0aGUgY29kZW5hbWUgb2Yg4oCc T0F1dGggMi4x4oCdKS4gQSBkaXNjdXNzaW9uIGF0IGEgc2lkZS1tZWV0aW5nIGluIFNpbmdhcG9y ZSBtYWRlIGNsZWFyDQogdGhhdCB0aGVyZSBpcyBubyBjb21tb24gdmlldyBhYm91dCB0aGUgZ29h bHMgb2Ygc3VjaCBhbiBlZmZvcnQgYW5kIHdoZXRoZXIgdGhlcmUgYXJlIG90aGVyIG9wdGlvbnMg dG8gcmVhY2ggdGhlIHNhbWUgYmVuZWZpdHMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRvIGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIGFuZCB0byBwcm92aWRlIHNvbWUgY2xhcml0eSBp biBvdXIgZGVjaXNpb24gbWFraW5nIHByb2dyZXNzIHdlIHdvdWxkIGxpa2UgdG8gc2NoZWR1bGUg YSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBlYXJseSBuZXh0IHllYXIuIEhlcmUgaXMgYSBEb29k bGUgcG9sbDoNCjxhIGhyZWY9Imh0dHBzOi8vZG9vZGxlLmNvbS9wb2xsL3o3dWUzZ3N1NXR1c2tx NzkiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Rvb2RsZS5jb20vcG9sbC96N3VlM2dzdTV0dXNr cTc5PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UGxlYXNlIGluZGljYXRlIHlvdXIg cHJlZmVyZW5jZSBieSB0aGUgZW5kIG9mIHRoZSB5ZWFyLg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJERS1BVCI+Q2lhbzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iREUtQVQiPkhhbm5lcyAmYW1wOyBSaWZh YXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklN UE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24sDQogdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTti b3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkg Tk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdl ZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocyku DQogQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBj b21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1l bnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBl bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJl IHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9y IHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM0PR08MB5283F82096CDA5BBFBD93BD6FA290AM0PR08MB5283eurp_-- From nobody Fri Dec 27 11:04:02 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10622120B4C for ; Fri, 27 Dec 2019 11:04:02 -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 q_I379eoUKil for ; Fri, 27 Dec 2019 11:03:59 -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 7B4271208E0 for ; Fri, 27 Dec 2019 11:03:59 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id v201so21243436lfa.11 for ; Fri, 27 Dec 2019 11:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=7H9590KM3lZB9tzgeW2WQcVLsyUJPsRYW0+62/27vms=; b=ZjRz7CSEeJpx/Bq/7V4+nShHUFkNjUj2tp6SGjphOkKxasE8minS4JbhMHJLiVOyIa zJuKesdzm+PkdoeHOvfj0TZsZg4pDe/xR+qTPZMYWqWfvBNOEXro1/+XXtvrHinMVgMH 4ZkctHMcYQaK52v8yG5Q2g6lP3jsRHxp2cosgzG4ROPYPiHK7uMMTkOrN73t/HAin+ik jzk8rbWEUud0lKl0QPZZa10/0miUHgtQioEe3x8QsH8yOdQ+GP+QvooNFca215CBD/Hm HR/PDTXMbAzHbnhvX0fzmUKEAmEp3RSJ7R6Cu+GOXwgZbcStJdlE/Oiq0TeZ8653OwOO H3qg== 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=7H9590KM3lZB9tzgeW2WQcVLsyUJPsRYW0+62/27vms=; b=N+a085AUEAaSMoarlmd8hCMof+TqZjnQCx6h+t9yXw3hd4tn3ia6czYChdQ0Inv2bE +QhA6vmYFCFbbd9arOIexW9tskKOc2L09j9R4E9QAJCl49nO1y5c7am2X7Q4Fbn8dqdk TI2PBiqQriFHFZap2LA3qtyZpWguUsedqCtQuWc0Ru7hVOruQjn+ipA++JLF46DPPtxp eMIbvQKeMzEQbt1EvWCMHKwv/uBTu/+qa4+QIuPF3xw1ul4JDSkA6DTexkNjlKsqTbsq w7hyzHM3F8GLTSEPRb7bwLi0rt0kPsdFEiSkQRsNAruvcZvHVrbcEo5rRsNuP54M+jKB qFAg== X-Gm-Message-State: APjAAAUYdlqmsuh7/MBkb5SreoIXnB7ptfGpL3Wanv9P+rNmmeAm5eqC hLGlBIl2O3ilnn8Ws6eSuOyezxgFmHC33wMKMRqu0NdNpacscX2YZphU85hA57bHBKPzT6OBwXI GQzu92tJ6P09BT19eC3c= X-Google-Smtp-Source: APXvYqxr8B5BThbZDxGvULjp2yj6i27H9nSR7sMh21ogh1425voxQJPlIlcgkI1A7DtoY4M+zJXvtZi1UMe3hkFILZI= X-Received: by 2002:ac2:4884:: with SMTP id x4mr29213148lfc.92.1577473437021; Fri, 27 Dec 2019 11:03:57 -0800 (PST) MIME-Version: 1.0 From: Brian Campbell Date: Fri, 27 Dec 2019 12:03:30 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000db4f1a059ab42770" Archived-At: Subject: [OAUTH-WG] -security-topics-13 and OIDC response types + form_post response mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 19:04:02 -0000 --000000000000db4f1a059ab42770 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We have a-sometimes used scenario where a client makes an authorization/authentication request with a "token id_token" response type and "form_post" response mode (nonce is also sent and exact redirect URI matching is done at the AS). The access token is never exposed in any URLs and access token injection is prevented by the at_hash claim in the id token. That seems to me like a legitimate and reasonable usage scenario. However, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be , which has: In order to avoid these issues, clients SHOULD NOT use the implicit grant (response type "token") or any other response type issuing access tokens in the authorization response, such as "token id_token" and "code token id_token", unless the issued access tokens are sender-constrained and access token injection in the authorization response is prevented. I know this particular text has been discussed over and over again so I hate to revisit it. But based on the aforementioned scenario I think maybe it still doesn't quite hit the mark. Access token injection is prevented. The token leakage scenarios mentioned in that section are all avoided. And while I know sender-constrained is recommended elsewhere in the draft, it's not really a realistic option for the majority of deployments. --=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._ --000000000000db4f1a059ab42770 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have a-sometimes used scenario where a client make= s an authorization/authentication request with a "token id_token"= response type and "form_post" response mode (nonce is also sent = and exact redirect URI matching is done at the AS). The access token is nev= er exposed in any URLs and access token injection is prevented by the at_ha= sh claim in the id token.

That seems to me li= ke a legitimate and reasonable usage scenario. However, it would fall on th= e wrong side of the SHOULD NOT in Section 3.1.2 of the Secur= ity BCP-to-be, which has:

=C2=A0=C2=A0 In order to av= oid these issues, clients SHOULD NOT use the implicit
=C2=A0 =C2=A0grant= (response type "token") or any other response type issuing
= =C2=A0 =C2=A0access tokens in the authorization response, such as "tok= en id_token"
=C2=A0 =C2=A0and "code token id_token", unle= ss the issued access tokens are
=C2=A0 =C2=A0sender-constrained and acce= ss token injection in the authorization
=C2=A0 =C2=A0response is prevent= ed.

I know this particular text has been discussed= over and over again so I hate to revisit it. But based on the aforemention= ed scenario I think maybe it still doesn't quite hit the mark. Access t= oken injection is prevented. The token leakage scenarios mentioned in that = section are all avoided. And while I know sender-constrained is recommended= elsewhere in the draft, it's not really a realistic option for the maj= ority of deployments.

<= 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. --000000000000db4f1a059ab42770-- From nobody Fri Dec 27 12:28:27 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834A3120137 for ; Fri, 27 Dec 2019 12:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] 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 MCEFB9lW2mmR for ; Fri, 27 Dec 2019 12:28:22 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640134.outbound.protection.outlook.com [40.107.64.134]) (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 3323D12006F for ; Fri, 27 Dec 2019 12:28:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F8czZ8AUADWsXOing4yj0kMJlXpepYqxjbAPYKOb/BC3eORvAdXUDqUccPH3KyYmhO+tsfITFvWPDv1woPDhIFlAoX9F9oKQ5os+wSE7sjKDTXLahXALw5CfwrWGD8WZamcJDC4Rz/MErCapy09Kv49LKyfn12iCVacGNW5mcHcSYEE7N49e+w2P5Mkf1lhQBT+hd6WqwgcrKxgA70RaI64uEZcZdNsJ49v2Prsca7qOxRvjTg8tYg6H6JMpN4IFimcbs/jRMrlrcvrY2d2JkgT4z3yBUbjmVvm0QslwGsrdK5Jy3akE3hUPL2rv1IGXTfiHB5WHNNrlEP7hzjtgqA== 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=A5gGIIFosrCsddPnTTyKY5/mDBFzX6e4gp6ZgShcQuw=; b=Mh7Vj/k8FIULP6g/cLPkeqThnF6ghXigLHmLbUWzJUPR20ByvZuSM5ZUc9Vma+QJypJbwMExwdUU5dMAdWDbkKOnB1bFbSnZMJyryjem3rKFUf4HGsS9cJdLs7J7XlzZooJ7hCHyKHsVH4iaprL5JjcVfZz2FYfIIA+jOztmbuQli4VpIDwOOd7Fa0CNmPYtRIfQ/cUvJDJ1jlvsMTdBRWIH1uFOh1d9pcW7+DPRZ/Wawrr82WZN9cIAFQRfCOmwvgA527nd7YwJ81e5amTyz2kAAYH6CLvtfADIpks3Oopn9Hv0VlvuYLdPJaPUiDzVz1toeAc2/QgXJIZ3o/7SEg== 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=A5gGIIFosrCsddPnTTyKY5/mDBFzX6e4gp6ZgShcQuw=; b=VEpkft2sWTFEB4h41APpLr7n2WYaWj/HBDgSy8Y/ZO4ENTtchjUwdE9R9BF1j5Zp6xMcdh5kGyOF11lGcO/cY2zB/gkiMUzCjVLdSx5m7GKdLHWPf2bDSnz3cD8e15RORz0vTxF3u4MycUQM2xj1soze60a99/PyxEXmNahfop0= Received: from DM6PR00MB0847.namprd00.prod.outlook.com (20.179.227.78) by DM6PR00MB0751.namprd00.prod.outlook.com (20.179.226.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2624.0; Fri, 27 Dec 2019 20:28:20 +0000 Received: from DM6PR00MB0847.namprd00.prod.outlook.com ([fe80::a141:1c00:178e:79f5]) by DM6PR00MB0847.namprd00.prod.outlook.com ([fe80::a141:1c00:178e:79f5%6]) with mapi id 15.20.2625.000; Fri, 27 Dec 2019 20:28:20 +0000 From: Mike Jones To: Brian Campbell , oauth Thread-Topic: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response types + form_post response mode Thread-Index: AQHVvOhu3i7FmmC9Mkq5Fkx+V4A7XKfObhvX Date: Fri, 27 Dec 2019 20:28:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-12-27T20:26:47.0256528Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [107.77.205.151] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 07f61412-89f2-4271-8557-08d78b0b5069 x-ms-traffictypediagnostic: DM6PR00MB0751: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(39860400002)(376002)(346002)(189003)(199004)(66476007)(55016002)(478600001)(5660300002)(8936002)(66946007)(81156014)(10290500003)(8676002)(81166006)(91956017)(76116006)(66556008)(64756008)(66446008)(9686003)(7696005)(52536014)(86362001)(33656002)(2906002)(6506007)(71200400001)(53546011)(15650500001)(316002)(110136005)(8990500004)(186003)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0751; H:DM6PR00MB0847.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: b0+osop7TMxzqp8bpjgy96btrETX6tGiabkFz1z0tZcWfkUEZUIQwfoL0kg/RemjTMGbVzXfjSp9XzyhQq87OsbOFOCXf4UEK1KIR+5TAHUgmGfxYPEmpo8GcmVKlL4yGw9GB/Elyo3q3x9u2Zz0epQ37Ss7DhN++XQNkpOy2EwES56qUPnotWtlsbPB15GnpMu6Ogb/jHR9owNQ4Bflkyb5zKxjHez5W1lImZD/MjHELjjOfrmqEZrbE1vVafZ3QZqYDcVfDRog3qmcqVBZVuP1bT4CGa9lIA4Hpi5o4fU9Fpo1Ds5aF9cxFSgLA1CJ/Fht4v2C9W9zavfbnm9CJbgcQQfQvlHiQN4+PFg8xFQmiLX1Wybh72FunRHaNfewx0oYCFSSlojydHdBcSwvaQIgG9k20xrJuokPVFOArgAgVqM/o4tu+pzfe/CgZuJ5G97aNjZkottmKd08EtxqSpGmyOU94I77DZNLBgdEj9g= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB08478D98FE0A4A2AADAF479AF52A0DM6PR00MB0847namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 07f61412-89f2-4271-8557-08d78b0b5069 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2019 20:28:20.5123 (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: ZVhbgETBBLGm3eTHqc83otPHbNgVCB71MP8Sc2huuL7U9PYrZec2fbrFbBOPGvx4yFnFU+g8P+YHO8y36xv2gw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0751 Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 20:28:26 -0000 --_000_DM6PR00MB08478D98FE0A4A2AADAF479AF52A0DM6PR00MB0847namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Brian. Please update the text to describe this already safe us= age. -- Mike ________________________________ From: OAuth on behalf of Brian Campbell Sent: Friday, December 27, 2019 11:03:30 AM To: oauth Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response types = + form_post response mode We have a-sometimes used scenario where a client makes an authorization/aut= hentication request with a "token id_token" response type and "form_post" r= esponse mode (nonce is also sent and exact redirect URI matching is done at= the AS). The access token is never exposed in any URLs and access token in= jection is prevented by the at_hash claim in the id token. That seems to me like a legitimate and reasonable usage scenario. However, = it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the S= ecurity BCP-to-be, which has: In order to avoid these issues, clients SHOULD NOT use the implicit grant (response type "token") or any other response type issuing access tokens in the authorization response, such as "token id_token" and "code token id_token", unless the issued access tokens are sender-constrained and access token injection in the authorization response is prevented. I know this particular text has been discussed over and over again so I hat= e to revisit it. But based on the aforementioned scenario I think maybe it = still doesn't quite hit the mark. Access token injection is prevented. The = token leakage scenarios mentioned in that section are all avoided. And whil= e I know sender-constrained is recommended elsewhere in the draft, it's not= really a realistic option for the majority of deployments. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged = material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by= e-mail and delete the message and any file attachments from your computer.= Thank you. --_000_DM6PR00MB08478D98FE0A4A2AADAF479AF52A0DM6PR00MB0847namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree with Brian. Please update the text to describe this already safe us= age.

-- Mike

From: OAuth <oauth-bounc= es@ietf.org> on behalf of Brian Campbell <bcampbell=3D40pingidentity.= com@dmarc.ietf.org>
Sent: Friday, December 27, 2019 11:03:30 AM
To: oauth <oauth@ietf.org>
Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response= types + form_post response mode
 
We have a-sometimes used scenario where a client makes an authorizatio= n/authentication request with a "token id_token" response type an= d "form_post" response mode (nonce is also sent and exact redirec= t URI matching is done at the AS). The access token is never exposed in any URLs and access token injection is prevented by th= e at_hash claim in the id token.

That seems to me like a legitimate and reasonable usage scenario. Howe= ver, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be, which has:

   In order to avoid these issues, clients SHOULD NOT use th= e implicit
   grant (response type "token") or any other response = type issuing
   access tokens in the authorization response, such as "tok= en id_token"
   and "code token id_token", unless the issued access = tokens are
   sender-constrained and access token injection in the authoriza= tion
   response is prevented.

I know this particular text has been discussed over and over again so = I hate to revisit it. But based on the aforementioned scenario I think mayb= e it still doesn't quite hit the mark. Access token injection is prevented.= The token leakage scenarios mentioned in that section are all avoided. And while I know sender-constrained is re= commended elsewhere in the draft, it's not really a realistic option for th= e majority of deployments.

CONFIDENTIALI= TY NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or d= isclosure by others is strictly prohibited..  If you have received thi= s communication in error, please notify the sender immediately by e-mail and delete the message and any file attac= hments from your computer. Thank you.
--_000_DM6PR00MB08478D98FE0A4A2AADAF479AF52A0DM6PR00MB0847namp_-- From nobody Fri Dec 27 12:41:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1A112006F for ; Fri, 27 Dec 2019 12:41:44 -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, 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C26OgfTd7rHH for ; Fri, 27 Dec 2019 12:41:42 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEA31200A1 for ; Fri, 27 Dec 2019 12:41:41 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id c9so27167715wrw.8 for ; Fri, 27 Dec 2019 12:41:41 -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=bdXmJciefwk53Fye1Oi8FeOYravyWoRxLF853/Qgyxg=; b=By59F22zEm5PC5rqrrWxM+ucnkjrdC4H3ZsmA3iaLJOu0Pn6ZtyzJcJ53+L4IB/cET aTX8eerIV5/i1pYnHoWtlXT5DZMlG9HpFf4OZK1ZjL94C5RAhUzNmRHb1YAuhsgR59rn svHjV2ZG9GtxMwu9k+peJDYNNyMTmY5Y1Jr1RPaFpSHS6CLIMT6x9+o3Mfs4nANQj/cd a9k7DX6/Qw/xR0ZFVXEYM9foa5GbS4Sjh8zeJF25CjZf/yhGJ2+OcbXUWo5AbUETLIJ5 n13mv/W4ODZYmDb9q2lw/ry9lYH+odQ4qzRzqOW1CB9cDMkT/ZMrMOleu3JCduoR5S9I BVGQ== 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=bdXmJciefwk53Fye1Oi8FeOYravyWoRxLF853/Qgyxg=; b=sI7pzPumgg7S+Nxe8mRzfJZCKdHpEthFuoskQeQitwDnSHmj8pOezEv4sycNv0+mnp cn9zIkPkPnR1B9+jvPyiOZtigODSxWCgrWMvG7FxvY1ve2V4lE0lS4ETtVTYSRwEalss IqqunYfJn6P7INRiuFQKSyAoQ/v+dhuxXpHX/Va0W1WK+J4dIkzXe+KPPud7AsmWlSxo 2pOvii4ZkMHJyuyZpOXuq0mgm/uFqunE43EeC2xC993wHVJaR/96yx2zb5EQPX980q8i PJvIDeQWdsUauhQsUgv32GIO1upQqt3PG5blYh6scbATt7836EKGjrALj6LOhxg07wze CWAA== X-Gm-Message-State: APjAAAW2T4MUODxYzU7B/a29fzFOy6IqjrZC141OU5M57B1c4URz7nZP ub1RFKUtk9wwWXpv0uy2s6vN1Q== X-Google-Smtp-Source: APXvYqzAo3plk6GyjBrPWnHC+ORRPj/IFb6r5cbwvJ2JEkuKB3RItd+Wz9t+gtFJkCEMLiXwkGm2wA== X-Received: by 2002:a5d:46d0:: with SMTP id g16mr55022327wrs.287.1577479300378; Fri, 27 Dec 2019 12:41:40 -0800 (PST) Received: from ?IPv6:2a01:598:818b:b98e:e918:9ad0:f05c:d5d2? ([2a01:598:818b:b98e:e918:9ad0:f05c:d5d2]) by smtp.gmail.com with ESMTPSA id n14sm12101067wmi.26.2019.12.27.12.41.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Dec 2019 12:41:38 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-C58CF7C4-9F86-492E-B256-DDC7339FEB03; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Fri, 27 Dec 2019 21:41:36 +0100 Message-Id: <0D6C9677-D8B5-4005-95FE-4F783EB28961@lodderstedt.net> References: Cc: Brian Campbell , oauth In-Reply-To: To: Mike Jones X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 20:41:44 -0000 --Apple-Mail-C58CF7C4-9F86-492E-B256-DDC7339FEB03 Content-Type: multipart/alternative; boundary=Apple-Mail-4A0D922C-843B-401E-B062-D06D88A58499 Content-Transfer-Encoding: 7bit --Apple-Mail-4A0D922C-843B-401E-B062-D06D88A58499 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable As Brian said, we have discussed this several times and this text found cons= ensus. Using post reduces the attack surface but does not allow to bind the access t= oken to the legitimate client. We are recommending sender constrained access= tokens in the BCP. So recommending a flow that does not support sender cons= trained access tokens is a contradiction. What do other WG members think? > Am 27.12.2019 um 21:28 schrieb Mike Jones : >=20 > =EF=BB=BF > I agree with Brian. Please update the text to describe this already safe u= sage. >=20 > -- Mike >=20 > From: OAuth on behalf of Brian Campbell > Sent: Friday, December 27, 2019 11:03:30 AM > To: oauth > Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response types= + form_post response mode > =20 > We have a-sometimes used scenario where a client makes an authorization/au= thentication request with a "token id_token" response type and "form_post" r= esponse mode (nonce is also sent and exact redirect URI matching is done at t= he AS). The access token is never exposed in any URLs and access token injec= tion is prevented by the at_hash claim in the id token.=20 >=20 > That seems to me like a legitimate and reasonable usage scenario. However,= it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the S= ecurity BCP-to-be, which has: >=20 > In order to avoid these issues, clients SHOULD NOT use the implicit > grant (response type "token") or any other response type issuing > access tokens in the authorization response, such as "token id_token" > and "code token id_token", unless the issued access tokens are > sender-constrained and access token injection in the authorization > response is prevented. >=20 > I know this particular text has been discussed over and over again so I ha= te to revisit it. But based on the aforementioned scenario I think maybe it s= till doesn't quite hit the mark. Access token injection is prevented. The to= ken leakage scenarios mentioned in that section are all avoided. And while I= know sender-constrained is recommended elsewhere in the draft, it's not rea= lly a realistic option for the majority of deployments.=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-4A0D922C-843B-401E-B062-D06D88A58499 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
As Brian said, we have dis= cussed this several times and this text found consensus.

Using post reduces the attack surface but does= not allow to bind the access token to the legitimate client. We are recomme= nding sender constrained access tokens in the BCP. So recommending a flow th= at does not support sender constrained access tokens is a contradiction.

What do other WG members think= ?

Am 27.12.2019 um 21:28= schrieb Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>:<= br>
=EF=BB=BF= =
I agree with Brian. Please update the text to describe this already safe usa= ge.

-- Mike

From: OAuth <oauth-bounces= @ietf.org> on behalf of Brian Campbell <bcampbell=3D40pingidentity.com= @dmarc.ietf.org>
Sent: Friday, December 27, 2019 11:03:30 AM
To: oauth <oauth@ietf.org>
Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response t= ypes + form_post response mode
 
We have a-sometimes used scenario where a client makes an authorization= /authentication request with a "token id_token" response type and "form_post= " response mode (nonce is also sent and exact redirect URI matching is done a= t the AS). The access token is never exposed in any URLs and access token injection is prevented by the= at_hash claim in the id token.

That seems to me like a legitimate and reasonable usage scenario. Howev= er, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be, which has:

   In order to avoid these issues, clients SHOULD NOT use the= implicit
   grant (response type "token") or any other response type issuin= g
   access tokens in the authorization response, such as "token id_= token"
   and "code token id_token", unless the issued access tokens are<= br>    sender-constrained and access token injection in the authorizat= ion
   response is prevented.

I know this particular text has been discussed over and over again so I= hate to revisit it. But based on the aforementioned scenario I think maybe i= t still doesn't quite hit the mark. Access token injection is prevented. The= token leakage scenarios mentioned in that section are all avoided. And while I know sender-constrained is rec= ommended elsewhere in the draft, it's not really a realistic option for the m= ajority of deployments.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the= sole use of the intended recipient(s). Any review, use, distribution or dis= closure by others is strictly prohibited..  If you have received this c= ommunication in error, please notify the sender immediately by e-mail and delete the message and any file attach= ments from your computer. Thank you.
_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
= --Apple-Mail-4A0D922C-843B-401E-B062-D06D88A58499-- --Apple-Mail-C58CF7C4-9F86-492E-B256-DDC7339FEB03 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 GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMjI3MjA0MTM3WjAv BgkqhkiG9w0BCQQxIgQg0X8ixj76UTaMI5bL1lj/eGkBEa62ZmGI7pTXhZVKT+Iwgb0GCSsGAQQB gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQAGR5xN 6RXkYNL0fAvNNmw8o2aUzEKQAWzl4O/f3Klef8LxTpT8PCYb7jJ1lp7jePiIG0nsX2QfKRK/53Tx hM0tmFaFyh7SRHB3nrAobvfzdGV84/oFqcpfCrEH72tn1Yx3jHGPL0B/3ZsCOD+SZiucPcl8Yfxa sZlYyfDETnc4aiAj2LCKytHgsG5uZjyOeSlcAX8lGFn/P4FbPi6rjC6L9rvSpPlz6fqw/NW+gihp +z0hxBo0cfDjukcrBxDThf5vk/5KlKm6166wzrTqh8TbT7RrID1pjViAyFh6a49yRNXOTn6v4GsD aqfQeev8tt9/AdFOcdcDJhKvKR3XraLYAAAAAAAA --Apple-Mail-C58CF7C4-9F86-492E-B256-DDC7339FEB03-- From nobody Fri Dec 27 14:27:20 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86901200E7 for ; Fri, 27 Dec 2019 14:27:19 -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, MIME_QP_LONG_LINE=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 GHrQ-6ePoVaM for ; Fri, 27 Dec 2019 14:27:17 -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 B8B8C1200DB for ; Fri, 27 Dec 2019 14:27:16 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id t2so27371937wrr.1 for ; Fri, 27 Dec 2019 14:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:in-reply-to:to; bh=wFeGvxCoeAGard2mj3W/m6wSBUqtlVrV1RuYlvnCQPw=; b=HewhuERTHMG3SW9kxFcmz1dH4fTKowCOHgqeBiOeZUfTjmkDU56AzDzvjDdzd/tmI1 ecvaYv2rZkQngeLSZ7KbG/mFVXHfriFtUifCiLXxohLGuvcf62qTwOIymWCRl6JfmJW4 e0GN4p2sbkobS2WSAzTX8U1vjvMbsOKAOTpv9vcLmeX4QgfGd6jHX3F8XkmeruuuTa+q 1eH1a+rg2vTrIeSrfYzGQFfrhLZvWah6BpigPXm5P71enISqEkRSsfFO1YeNd6KKWJ66 rmCfMSqrv5owHOeKGOzU4Br6Mz5V+/bgPMIXtxxqtLIMVuH4BN0bGAKZv1SYueyftWXS 8m5Q== 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:in-reply-to:to; bh=wFeGvxCoeAGard2mj3W/m6wSBUqtlVrV1RuYlvnCQPw=; b=JYPODa+Snl75xK/sydTBR0Ng1nXhO1gGS/2MxQZoyET6B8E5ORLWNYCdAxDdX4bFAu O6pQhZy0MNN0Spqqp/oVabUJ93aW7dm/CU9ulvoMD3Ktkk4JjhS+leyhMSNEuGXyzjtY TZpjlSflM9Ou00JGzhqjt3OrBsG3VjdyiAgfE2xH78HeiInUEJDIBesFENQu8jJbQnvX 1f4zt1Th5R28Un7TZXmT1mSY7cdoMqocMYGeT44LqjsUIukE8ddPbnDLYGodiDamxBql 6/hjTeA5kJ0FoOeTSO28Q+EaZKtCnsNcncncl/wpgXxW1uyi9JQ1symyQxoEEHzh9LqR ipGw== X-Gm-Message-State: APjAAAWZRTkRPNLRyrZ68R3TdNpkm5iJZPA/amjifyv+Fs76AgN9bHFV 3UrpEpaWvLL+UACA6U3PX/EnsgmPng== X-Google-Smtp-Source: APXvYqxWJ9SlrBCpAVYBhEb2k6rXXhjO7URwl2JKri46g+HT5qmdyTelo30TgUodef8sF3iZfG07qg== X-Received: by 2002:adf:f3d1:: with SMTP id g17mr53800314wrp.378.1577485634799; Fri, 27 Dec 2019 14:27:14 -0800 (PST) Received: from [192.168.1.107] (ip-37-188-164-151.eurotel.cz. [37.188.164.151]) by smtp.gmail.com with ESMTPSA id z11sm35973058wrt.82.2019.12.27.14.27.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Dec 2019 14:27:13 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-FAB27BA0-0A67-46DE-920E-ECBF2E76B197 Content-Transfer-Encoding: 7bit From: Filip Skokan Mime-Version: 1.0 (1.0) Date: Fri, 27 Dec 2019 23:27:11 +0100 Message-Id: References: <0D6C9677-D8B5-4005-95FE-4F783EB28961@lodderstedt.net> In-Reply-To: <0D6C9677-D8B5-4005-95FE-4F783EB28961@lodderstedt.net> To: oauth X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 22:27:20 -0000 --Apple-Mail-FAB27BA0-0A67-46DE-920E-ECBF2E76B197 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Encrypted JARM responses are in a very similar position. Access Token value i= s not part of the URL and the response itself is protected. Such response is= usually only consumed by a server side application. Same as any form_post r= esponse.=20 We could go into further clarifying the client application topology to enabl= e these uses but i don=E2=80=99t think it=E2=80=99s worth it. Why make excus= es to keep implicit issued access tokens around in when code flow is the way= the WG has decided to go. (Here we go again...) Best, Filip > 27. 12. 2019 v 21:41, Torsten Lodderstedt : >=20 > =EF=BB=BF > As Brian said, we have discussed this several times and this text found co= nsensus. >=20 > Using post reduces the attack surface but does not allow to bind the acces= s token to the legitimate client. We are recommending sender constrained acc= ess tokens in the BCP. So recommending a flow that does not support sender c= onstrained access tokens is a contradiction. >=20 > What do other WG members think? >=20 >>> Am 27.12.2019 um 21:28 schrieb Mike Jones : >>>=20 >> =EF=BB=BF >> I agree with Brian. Please update the text to describe this already safe u= sage. >>=20 >> -- Mike >>=20 >> From: OAuth on behalf of Brian Campbell >> Sent: Friday, December 27, 2019 11:03:30 AM >> To: oauth >> Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response type= s + form_post response mode >> =20 >> We have a-sometimes used scenario where a client makes an authorization/a= uthentication request with a "token id_token" response type and "form_post" r= esponse mode (nonce is also sent and exact redirect URI matching is done at t= he AS). The access token is never exposed in any URLs and access token injec= tion is prevented by the at_hash claim in the id token.=20 >>=20 >> That seems to me like a legitimate and reasonable usage scenario. However= , it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the S= ecurity BCP-to-be, which has: >>=20 >> In order to avoid these issues, clients SHOULD NOT use the implicit >> grant (response type "token") or any other response type issuing >> access tokens in the authorization response, such as "token id_token" >> and "code token id_token", unless the issued access tokens are >> sender-constrained and access token injection in the authorization >> response is prevented. >>=20 >> I know this particular text has been discussed over and over again so I h= ate to revisit it. But based on the aforementioned scenario I think maybe it= still doesn't quite hit the mark. Access token injection is prevented. The t= oken leakage scenarios mentioned in that section are all avoided. And while I= know sender-constrained is recommended elsewhere in the draft, it's not rea= lly a realistic option for the majority of deployments.=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-FAB27BA0-0A67-46DE-920E-ECBF2E76B197 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Encrypted JARM responses are in a very simi= lar position. Access Token value is not part of the URL and the response its= elf is protected. Such response is usually only consumed by a server side ap= plication. Same as any form_post response. 

We could= go into further clarifying the client application topology to enable these u= ses but i don=E2=80=99t think it=E2=80=99s worth it. Why make excuses to kee= p implicit issued access tokens around in when code flow is the way the WG h= as decided to go. (Here we go again...)

Best,
=
Filip

27. 12. 2= 019 v 21:41, Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.= ietf.org>:

=EF=BB=BF
As Brian said, we have discussed this several t= imes and this text found consensus.

Using post reduces the attack surface but does not allow to bind th= e access token to the legitimate client. We are recommending sender constrai= ned access tokens in the BCP. So recommending a flow that does not support s= ender constrained access tokens is a contradiction.
What do other WG members think?

Am 27.12.2019 um 21:28 schrieb Mike Jones &= lt;Michael.Jones=3D40microsoft.com@dmarc.ietf.org>:

<= /div>
=EF=BB=BF =
I agree with Brian. Please update the text to describe this already safe usa= ge.

-- Mike

From: OAuth <oauth-bounces= @ietf.org> on behalf of Brian Campbell <bcampbell=3D40pingidentity.com= @dmarc.ietf.org>
Sent: Friday, December 27, 2019 11:03:30 AM
To: oauth <oauth@ietf.org>
Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response t= ypes + form_post response mode
 
We have a-sometimes used scenario where a client makes an authorization= /authentication request with a "token id_token" response type and "form_post= " response mode (nonce is also sent and exact redirect URI matching is done a= t the AS). The access token is never exposed in any URLs and access token injection is prevented by the= at_hash claim in the id token.

That seems to me like a legitimate and reasonable usage scenario. Howev= er, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be, which has:

   In order to avoid these issues, clients SHOULD NOT use the= implicit
   grant (response type "token") or any other response type issuin= g
   access tokens in the authorization response, such as "token id_= token"
   and "code token id_token", unless the issued access tokens are<= br>    sender-constrained and access token injection in the authorizat= ion
   response is prevented.

I know this particular text has been discussed over and over again so I= hate to revisit it. But based on the aforementioned scenario I think maybe i= t still doesn't quite hit the mark. Access token injection is prevented. The= token leakage scenarios mentioned in that section are all avoided. And while I know sender-constrained is rec= ommended elsewhere in the draft, it's not really a realistic option for the m= ajority of deployments.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the= sole use of the intended recipient(s). Any review, use, distribution or dis= closure by others is strictly prohibited..  If you have received this c= ommunication in error, please notify the sender immediately by e-mail and delete the message and any file attach= ments from your computer. Thank you.
_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
<= /div>= --Apple-Mail-FAB27BA0-0A67-46DE-920E-ECBF2E76B197-- From nobody Fri Dec 27 15:02:02 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E2B12013B for ; Fri, 27 Dec 2019 15:02:01 -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 r_J4URM7dYhw for ; Fri, 27 Dec 2019 15:01:58 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50ED31200B6 for ; Fri, 27 Dec 2019 15:01:58 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id y1so21601784lfb.6 for ; Fri, 27 Dec 2019 15:01:58 -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=r9Z8OC34vdueDgYpgaR0ymZkkyB1j2vNL3RKysg0Xog=; b=E81fBEgJ9BwlG3Z05QdA59Euba/z1RDPqRNlgf+3LqiABi+jUiv73P9dgR3LN+Rqo7 3oz8aS3aKQLLbzOf40UBBV4GhoIjKlqWgnwFucJeIxyEtXIy/Gxi0H12ojkfylJsaACm m5Bf9jMoXUSjgtecjssCVNu9dFeAJJAULyjUXAqZG9Rxdb1Q4sIXbTvRMnGBda4L0ipV d1YoTDTI+CsYlP0GAMO+bcprVWK3qJSs1H5YdhLe6FsGcohcYNgFbK5VHZ4eMWozwIbc 6JsNpjrhTTB1dc5glCWXSkrVdxfFeoV7YCPiVATggxKccHDj66TsCtz/ie4XPzRDn73e u1uQ== 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=r9Z8OC34vdueDgYpgaR0ymZkkyB1j2vNL3RKysg0Xog=; b=hnlxH4BYTpKYOxLzf1Z/PJs0mqk3ztauP7Vk7tmOSOL2u8LOLnOA9FInqXErVhslHV XhuWrmBn25mH0AqkR6VNyK875SaXOTmJwQ4ptXmoh0WLQpZVTlUggVVoGdaiyUxZAgf7 274jOAhr/I2CSs+e+rqAl2Bk2GEeYmQbf7UxAgu5RQzfM5+QSCSsNo+e2vq19vLCzTn0 un9brMwWuEQp0zuauA6Vm09pwpzsx/mDaXrQRPphSIVk+W8M5s7/KeYA7DI0lGmrJ73E 7iICLV8//TJUKPU0w/aHbjUv09hnC0gSxiLwDa32iJi2WwrSLrZI2nIE4jYIoD9je9Ue ROrg== X-Gm-Message-State: APjAAAUx/TD1O/ImLRp1LADroBkiwwECHrZJ5DfC74P5LIGvZDNL4XUJ /WpqLObIqoCIhhrLihj+dzIXNwhAVDtGzwWfjphV5hv8nZepUn+XT8PX3Z7n0M7+O4bm7b2pcF9 rGiTX5a1DnFx4ug== X-Google-Smtp-Source: APXvYqx+UkXREgpdxuCl2Rn/S3qS9mn21Za00i/ItHxMAotVRqikbGrzTWQ9X8/wGTmq6L1AFatwa9lmT3xn+ZTqx/c= X-Received: by 2002:a19:5057:: with SMTP id z23mr30033015lfj.132.1577487716345; Fri, 27 Dec 2019 15:01:56 -0800 (PST) MIME-Version: 1.0 References: <0D6C9677-D8B5-4005-95FE-4F783EB28961@lodderstedt.net> In-Reply-To: <0D6C9677-D8B5-4005-95FE-4F783EB28961@lodderstedt.net> From: Brian Campbell Date: Fri, 27 Dec 2019 16:01:29 -0700 Message-ID: To: Torsten Lodderstedt Cc: Mike Jones , oauth Content-Type: multipart/alternative; boundary="000000000000f8885a059ab77a66" Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 23:02:01 -0000 --000000000000f8885a059ab77a66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not suggesting that it should be a recommended flow. But recommending against it, as the text does now, seems overreaching and unnecessary. I know *consensus* was previously found on the text in -13 but best I can recall that discussion was mostly around Nat advocating to allow room for some future self-issued IDP type case and the conversation kind of got hung up on that. Here's some proposed text, which I think still largely captures the intent of the BCP while not explicitly recommending against legitimate cases like the one I brought here or Nat's or something like JARM. In order to avoid these issues, clients SHOULD NOT use the implicit grant (response type "token") or other response types issuing access tokens in the authorization response, unless access token injection in the authorization response is prevented and the aforementioned token leakage vectors are mitigated. The draft already recommends sender-constrained access tokens elsewhere in the document. It doesn't need to be repeated as a qualifying condition around this SHOULD NOT. I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefully is evident from several attempts at bringing/doing related work here) but I do worry that the recommendation in the draft is sufficiently unachievable to the vast majority that it might undermine the credibility of the document. But I get the aspirational aspect of it and, other than some suggested tweaks , am resigned to see it stay in the document. But let's let that recommendation stand on its own in the document and not also tie it to other considerations. On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt wrote: > As Brian said, we have discussed this several times and this text found > consensus. > > Using post reduces the attack surface but does not allow to bind the > access token to the legitimate client. We are recommending sender > constrained access tokens in the BCP. So recommending a flow that does no= t > support sender constrained access tokens is a contradiction. > > What do other WG members think? > > Am 27.12.2019 um 21:28 schrieb Mike Jones 40microsoft.com@dmarc.ietf.org>: > > =EF=BB=BF > I agree with Brian. Please update the text to describe this already safe > usage. > > -- Mike > > ------------------------------ > *From:* OAuth on behalf of Brian Campbell > > *Sent:* Friday, December 27, 2019 11:03:30 AM > *To:* oauth > *Subject:* [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response > types + form_post response mode > > We have a-sometimes used scenario where a client makes an > authorization/authentication request with a "token id_token" response typ= e > and "form_post" response mode (nonce is also sent and exact redirect URI > matching is done at the AS). The access token is never exposed in any URL= s > and access token injection is prevented by the at_hash claim in the id > token. > > That seems to me like a legitimate and reasonable usage scenario. However= , > it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the > Security BCP-to-be > , > which has: > > In order to avoid these issues, clients SHOULD NOT use the implicit > grant (response type "token") or any other response type issuing > access tokens in the authorization response, such as "token id_token" > and "code token id_token", unless the issued access tokens are > sender-constrained and access token injection in the authorization > response is prevented. > > I know this particular text has been discussed over and over again so I > hate to revisit it. But based on the aforementioned scenario I think mayb= e > it still doesn't quite hit the mark. Access token injection is prevented. > The token leakage scenarios mentioned in that section are all avoided. An= d > while I know sender-constrained is recommended elsewhere in the draft, it= 's > not really a realistic option for the majority of deployments. > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000f8885a059ab77a66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not suggesting that it should be a recommende= d flow. But recommending against it, as the text does now, seems overreachi= ng and unnecessary. I know *consensus* was previously found on the text in = -13 but best I can recall that discussion was mostly around Nat advocating = to allow room for some future self-issued IDP type case and the conversatio= n kind of got hung up on that.

Here's som= e proposed text, which I think still largely captures the intent of the BCP= while not explicitly recommending against legitimate cases like the one I = brought here or Nat's or something like JARM.

=
=C2=A0=C2=A0 In order to avoid these issues, clients SHOULD NOT use th= e implicit
=C2=A0 =C2=A0grant (response type "token") or other response type= s issuing
=C2=A0 =C2=A0access tokens in the authorization response, unless access tok= en injection
=C2=A0=C2=A0 in the authorization response is preven= ted and the aforementioned token leakage
=C2=A0=C2=A0 vector= s are mitigated.

The draft already recommends= sender-constrained access tokens elsewhere in the document. It doesn't= need to be repeated as a qualifying condition around this SHOULD NOT.
=

I am a proponent of PoP/HoK/sender-constrained ac= cess tokens (as hopefully is evident from several attempts at bringing/doin= g related work here) but I do worry that the recommendation in the draft is= sufficiently unachievable to the vast majority that it might undermine the= credibility of the document. But I get the aspirational aspect of it and, = other than some suggested tweaks, am resigned to see it stay i= n the document. But let's let that recommendation stand on its own in t= he document and not also tie it to other considerations.=C2=A0


On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt <torsten=3D40lodde= rstedt.net@dmarc.ietf.org> wrote:
As Brian said, = we have discussed this several times and this text found consensus.

Using post reduces the attack sur= face but does not allow to bind the access token to the legitimate client. = We are recommending sender constrained access tokens in the BCP. So recomme= nding a flow that does not support sender constrained access tokens is a co= ntradiction.

What do other= WG members think?

Am 2= 7.12.2019 um 21:28 schrieb Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ie= tf.org>:

=EF=BB=BF
I agree with Brian. Please update the text to describe this already safe us= age.

-- Mike

From: OAuth = <oauth-bounc= es@ietf.org> on behalf of Brian Campbell <bcampbell=3D40pingidentity.= com@dmarc.ietf.org>
Sent: Friday, December 27, 2019 11:03:30 AM
To: oauth <oa= uth@ietf.org>
Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response= types + form_post response mode
=C2=A0
We have a-sometimes used scenario where a client makes an authorizatio= n/authentication request with a "token id_token" response type an= d "form_post" response mode (nonce is also sent and exact redirec= t URI matching is done at the AS). The access token is never exposed in any URLs and access token injection is prevented by th= e at_hash claim in the id token.

That seems to me like a legitimate and reasonable usage scenario. Howe= ver, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be, which has:

=C2=A0=C2=A0 In order to avoid these issues, clients SHOULD NOT use th= e implicit
=C2=A0 =C2=A0grant (response type "token") or any other response = type issuing
=C2=A0 =C2=A0access tokens in the authorization response, such as "tok= en id_token"
=C2=A0 =C2=A0and "code token id_token", unless the issued access = tokens are
=C2=A0 =C2=A0sender-constrained and access token injection in the authoriza= tion
=C2=A0 =C2=A0response is prevented.

I know this particular text has been discussed over and over again so = I hate to revisit it. But based on the aforementioned scenario I think mayb= e it still doesn't quite hit the mark. Access token injection is preven= ted. The token leakage scenarios mentioned in that section are all avoided. And while I know sender-constrained is re= commended elsewhere in the draft, it's not really a realistic option fo= r the majority of deployments.

CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or d= isclosure by others is strictly prohibited..=C2=A0 If you have received thi= s communication in error, please notify the sender immediately by e-mail and delete the message and any file attac= hments from your computer. Thank you.
_______________________________________________
OAuth= mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000f8885a059ab77a66-- From nobody Fri Dec 27 16:00:09 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DDD1200CE for ; Fri, 27 Dec 2019 16:00:08 -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, 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] 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 IIilvzdM-TjV for ; Fri, 27 Dec 2019 16:00:06 -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 BFCB1120639 for ; Fri, 27 Dec 2019 16:00:05 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id q9so7762447wmj.5 for ; Fri, 27 Dec 2019 16:00:05 -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=msbPNGGWUu07DqX3ziNcU3nfJuB8GlXpSfH4j301NWY=; b=qYMnrRYlWdu+FAXJz0l1JSU3STdjlj1rWYMlWs7fCArRcyHP0QJbRAeVNMACMK0q1H YVUxvPqOphGEAB5REunOTe+2ytT2MXmfxC0v+EBEbTQpYaUVgp8vIRGqiVX+4eXUqAEv yH3LfZyPjr1HQLQJOhfKGncdEoSBLaRMkKaqmeC1YvM9W02cpSn7YxRPIvLk7l3mCl14 a5j2JQAuca+cpWU2sVrRm43yT8tTc7fUabMPfejSSPALN40GDNo+HKhqW/lZ67eb7+vq TjMmg/TIdZqfV0fQd09eVCjESzr8DJrzeS2BF4nCvCOjsxtL+MrEJtP4vRHwowUTr301 3Csw== 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=msbPNGGWUu07DqX3ziNcU3nfJuB8GlXpSfH4j301NWY=; b=f+t+v1IiAs1AzTlCw/t0CEssFALGaZ9dZFEfnR0wCVSe6hY9mUcTiGOJJqNHnxUr/g f8+qktTyc1R2nSedvnpxsdy0M/iHZwl3qVS5kM1+oXiEBXxaWArVYI6MfiqQcSwvQ0Mr SuCGqZKGG3oqPaPq8qWS/8RaofWV+Dkb3TDp8kC00MuK+7UuKjYlL0ePopcaKaN3Q7MP xKVNBKi4tpLYfmIq5YYIybKwUVNQJEPm6RKMckgHlaLnIRHU89ds8QceXnbkKEvOT5EM +pqbMpkEBJUf7KbcGhVCNBZDkdFX9o87+0Og0v3HIyWCr30I6adBXIeiKAbjaJsT5/E8 T+qA== X-Gm-Message-State: APjAAAVDnE2+IjGryXkn5bv1+/PPLL/hs5hXB6ISZbxqzv1nvj3phzUG d0G44W6pQrBQ5sDBZuL/ZOFlYTdbwmY= X-Google-Smtp-Source: APXvYqxJx3VTktTTeNwXk98jNOB1WC2XDVaOeH1Blt1mp1IqX3x4Ir3xG9e34ig4vFQ2QCZd+TuaRQ== X-Received: by 2002:a05:600c:1009:: with SMTP id c9mr22013359wmc.162.1577491203742; Fri, 27 Dec 2019 16:00:03 -0800 (PST) Received: from ?IPv6:2a01:598:818b:b98e:e918:9ad0:f05c:d5d2? ([2a01:598:818b:b98e:e918:9ad0:f05c:d5d2]) by smtp.gmail.com with ESMTPSA id p5sm36184332wrt.79.2019.12.27.16.00.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Dec 2019 16:00:02 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-5074200D-A012-4C49-B84B-0F816C2E8673; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sat, 28 Dec 2019 01:00:01 +0100 Message-Id: References: Cc: Mike Jones , oauth In-Reply-To: To: Brian Campbell X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 00:00:09 -0000 --Apple-Mail-5074200D-A012-4C49-B84B-0F816C2E8673 Content-Type: multipart/alternative; boundary=Apple-Mail-3BA789A1-2246-481E-BBFC-1AA9FB5ED9B9 Content-Transfer-Encoding: 7bit --Apple-Mail-3BA789A1-2246-481E-BBFC-1AA9FB5ED9B9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Your proposal sounds reasonable on first sight. But thinking again, it would= mean to keep token injection prevention in authorization responses a requir= ement while dropping the requirement for replay/injection prevention at reso= urce servers. To me this feels inconsistent. > Am 28.12.2019 um 00:02 schrieb Brian Campbell : >=20 > =EF=BB=BF > I'm not suggesting that it should be a recommended flow. But recommending a= gainst it, as the text does now, seems overreaching and unnecessary. I know *= consensus* was previously found on the text in -13 but best I can recall tha= t discussion was mostly around Nat advocating to allow room for some future s= elf-issued IDP type case and the conversation kind of got hung up on that.=20= >=20 > Here's some proposed text, which I think still largely captures the intent= of the BCP while not explicitly recommending against legitimate cases like t= he one I brought here or Nat's or something like JARM.=20 >=20 > In order to avoid these issues, clients SHOULD NOT use the implicit > grant (response type "token") or other response types issuing > access tokens in the authorization response, unless access token inject= ion > in the authorization response is prevented and the aforementioned token= leakage=20 > vectors are mitigated.=20 >=20 > The draft already recommends sender-constrained access tokens elsewhere in= the document. It doesn't need to be repeated as a qualifying condition arou= nd this SHOULD NOT.=20 >=20 > I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefully= is evident from several attempts at bringing/doing related work here) but I= do worry that the recommendation in the draft is sufficiently unachievable t= o the vast majority that it might undermine the credibility of the document.= But I get the aspirational aspect of it and, other than some suggested twea= ks, am resigned to see it stay in the document. But let's let that recommend= ation stand on its own in the document and not also tie it to other consider= ations. =20 >=20 >=20 >> On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt wrote: >> As Brian said, we have discussed this several times and this text found c= onsensus. >>=20 >> Using post reduces the attack surface but does not allow to bind the acce= ss token to the legitimate client. We are recommending sender constrained ac= cess tokens in the BCP. So recommending a flow that does not support sender c= onstrained access tokens is a contradiction. >>=20 >> What do other WG members think? >>=20 >>>> Am 27.12.2019 um 21:28 schrieb Mike Jones : >>>>=20 >>> =EF=BB=BF >>> I agree with Brian. Please update the text to describe this already safe= usage. >>>=20 >>> -- Mike >>>=20 >>> From: OAuth on behalf of Brian Campbell >>> Sent: Friday, December 27, 2019 11:03:30 AM >>> To: oauth >>> Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response typ= es + form_post response mode >>> =20 >>> We have a-sometimes used scenario where a client makes an authorization/= authentication request with a "token id_token" response type and "form_post"= response mode (nonce is also sent and exact redirect URI matching is done a= t the AS). The access token is never exposed in any URLs and access token in= jection is prevented by the at_hash claim in the id token.=20 >>>=20 >>> That seems to me like a legitimate and reasonable usage scenario. Howeve= r, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the= Security BCP-to-be, which has: >>>=20 >>> In order to avoid these issues, clients SHOULD NOT use the implicit >>> grant (response type "token") or any other response type issuing >>> access tokens in the authorization response, such as "token id_token"= >>> and "code token id_token", unless the issued access tokens are >>> sender-constrained and access token injection in the authorization >>> response is prevented. >>>=20 >>> I know this particular text has been discussed over and over again so I h= ate to revisit it. But based on the aforementioned scenario I think maybe it= still doesn't quite hit the mark. Access token injection is prevented. The t= oken leakage scenarios mentioned in that section are all avoided. And while I= know sender-constrained is recommended elsewhere in the draft, it's not rea= lly a realistic option for the majority of deployments.=20 >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileg= ed material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. --Apple-Mail-3BA789A1-2246-481E-BBFC-1AA9FB5ED9B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Your proposal sounds reaso= nable on first sight. But thinking again, it would mean to keep token inject= ion prevention in authorization responses a requirement while dropping the r= equirement for replay/injection prevention at resource servers. To me this f= eels inconsistent.

Am 28= .12.2019 um 00:02 schrieb Brian Campbell <bcampbell=3D40pingidentity.com@= dmarc.ietf.org>:

=EF=BB=BF
I'm not suggesting that it shoul= d be a recommended flow. But recommending against it, as the text does now, s= eems overreaching and unnecessary. I know *consensus* was previously found o= n the text in -13 but best I can recall that discussion was mostly around Na= t advocating to allow room for some future self-issued IDP type case and the= conversation kind of got hung up on that.

Her= e's some proposed text, which I think still largely captures the intent of t= he BCP while not explicitly recommending against legitimate cases like the o= ne I brought here or Nat's or something like JARM.

=
   In order to avoid these issues, clients SHOULD NOT use the= implicit
   grant (response type "token") or other response types issuing    access tokens in the authorization response, unless access toke= n injection
   in the authorization response is prevente= d and the aforementioned token leakage
   vectors a= re mitigated.

The draft already recommends sen= der-constrained access tokens elsewhere in the document. It doesn't need to b= e repeated as a qualifying condition around this SHOULD NOT.
=
I am a proponent of PoP/HoK/sender-constrained access tokens (= as hopefully is evident from several attempts at bringing/doing related work= here) but I do worry that the recommendation in the draft is sufficiently u= nachievable to the vast majority that it might undermine the credibility of t= he document. But I get the aspirational aspect of it and, other than some suggested tweaks, am resigned to see it stay in the document. But l= et's let that recommendation stand on its own in the document and not also t= ie it to other considerations. 


On Fri, Dec 27, 2019 a= t 1:41 PM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org&g= t; wrote:
As Brian said, we have discussed this several tim= es and this text found consensus.

Using post reduces the attack surface but does not allow to bind the a= ccess token to the legitimate client. We are recommending sender constrained= access tokens in the BCP. So recommending a flow that does not support send= er constrained access tokens is a contradiction.

<= /div>
What do other WG members think?
=
Am 27.12.2019 um 21:28 schrieb Mike Jones <= Michael.Jones=3D40microsoft.com@dmarc.ietf.org>:

=EF=BB=BF
I agree with Brian. Please update the text to describe this already safe usa= ge.

-- Mike

From: OAuth <= ;oauth-bounces@i= etf.org> on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dm= arc.ietf.org>
Sent: Friday, December 27, 2019 11:03:30 AM
To: oauth <oau= th@ietf.org>
Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response t= ypes + form_post response mode
 
We have a-sometimes used scenario where a client makes an authorization= /authentication request with a "token id_token" response type and "form_post= " response mode (nonce is also sent and exact redirect URI matching is done a= t the AS). The access token is never exposed in any URLs and access token injection is prevented by the= at_hash claim in the id token.

That seems to me like a legitimate and reasonable usage scenario. Howev= er, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be, which has:

   In order to avoid these issues, clients SHOULD NOT use the= implicit
   grant (response type "token") or any other response type issuin= g
   access tokens in the authorization response, such as "token id_= token"
   and "code token id_token", unless the issued access tokens are<= br>    sender-constrained and access token injection in the authorizat= ion
   response is prevented.

I know this particular text has been discussed over and over again so I= hate to revisit it. But based on the aforementioned scenario I think maybe i= t still doesn't quite hit the mark. Access token injection is prevented. The= token leakage scenarios mentioned in that section are all avoided. And while I know sender-constrained is rec= ommended elsewhere in the draft, it's not really a realistic option for the m= ajority of deployments.

CONFIDENTIAL= ITY NOTICE: This email may contain confidential and privileged material for the= sole use of the intended recipient(s). Any review, use, distribution or dis= closure by others is strictly prohibited..  If you have received this c= ommunication in error, please notify the sender immediately by e-mail and delete the message and any file attach= ments from your computer. Thank you.
_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth

CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.= --Apple-Mail-3BA789A1-2246-481E-BBFC-1AA9FB5ED9B9-- --Apple-Mail-5074200D-A012-4C49-B84B-0F816C2E8673 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 GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMjI4MDAwMDAxWjAv BgkqhkiG9w0BCQQxIgQgLk13dX9B7MKvf3zuTUule/mkr49sCA1RntdhZ+K9+wkwgb0GCSsGAQQB gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQCMch8v X6RLQQq6Ax3TGsz1ght5JsQvvlYU12HW1qDnQoAV/dMEkdmsuZMUm5HEHho+Hxcf7Z+Pk8LVwUUE 1unKP89YNiLNA97bbNO7S3EuViWr7TjJIRwZynqYDbttYBL/iFk60/a0bDlu3WV6VmA/Yjr8NlkE NeaUZCutgY77b3mafMIoZG2ZcYuo39h0Xy/pHppzFoL1XX/KpjTmkxoRB39GxhwMU81e0l7SlQrB XbqJ1PGCuojMX2tjIIAVng2SKOmpMs2Z9AEUNpXf+DTA3A+ZWXM63GGUTL+p3+dTkcUYNeJBx5Rg hkevYvryjsYbUAS/63NHjZMwGVDSMXLvAAAAAAAA --Apple-Mail-5074200D-A012-4C49-B84B-0F816C2E8673-- From nobody Sat Dec 28 05:33:57 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04872120088 for ; Sat, 28 Dec 2019 05:33:56 -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, 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=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 SayfFzIoDd2h for ; Sat, 28 Dec 2019 05:33:53 -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 37C2512004F for ; Sat, 28 Dec 2019 05:33:53 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id j1so21900343lja.2 for ; Sat, 28 Dec 2019 05:33:53 -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=g1hGR9yVflWAWkXqZoFgJZYqnlKiY4Bdiw0icALMtHM=; b=E4w4WNXokHAqV08O8Vl1Rsfwx2k1bIxlUAhulx8RLojOzf7pmuUefLP1VdEmV1y+ph CiktFAbobhgOCVt18arjUCEMxaDWkQSjpndYtvVm+JPhOEz2x3HWBibYFNvpCZWUp+Sk e36bre7uHLGn4bdZ1gXKLWPw3hSawa6chANPrOFYRKEFtKWhN1weEE5gbSfP1AO+wKZL hZdO2iIWkHPB4eQtrHKxqMrtj7BoQpv8KonCj4TuQ4e0MABf/5WkDZtn66y2T65rTdJP NNPz5n1RagTlBV+x70HLyXGu+0Wa3IoeqLVZpz56/cO/Wv6dDrweh1IOxLR7bKyHjpn5 ErCA== 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=g1hGR9yVflWAWkXqZoFgJZYqnlKiY4Bdiw0icALMtHM=; b=nXWYToDE7qfVFqSBSeCn2SWJEZwrp1XxvcZjn6gp1wEhnCiWoweOh5pFQBDdY/4b6d M7+cdzqY9V4ICziVPrRIaiMezWESTfd8KboUtiWugdXas7gaL+nBbhM3i/mgG0ugXBUu w2x5KLiQE04sU+xWfmy/PHvT/CRlvG0aU8Kr2WqkMaai7yBHTvl/j8lZyWhUPQ47EVk6 kjI1b69PtMJ2umhrcP6UtjF42iLN7O/i+eVO2DCcE8eNg5nGLiuC9KVFhfqfp6wH7F0s lYkP5r8jvJSzZs9xbFrbBRCIOq8O99ALGamGzwayMtGAkUBGT50oUJVtnJSMeDWyDOMb JJ0A== X-Gm-Message-State: APjAAAU6MErPW84kHCFU0zH+dh2VuxJ8DNQYnLMDlH8EVbnHC/zDpZ45 DBCV1mMvZBXazh2xUD+ENRSQ8NzdjohVGhTPHcVSWA8cYXvYTWSTwTbrMSUNnPKKgf4nCjPy1yn wqEKoMKggJ4aWbN1pzQU= X-Google-Smtp-Source: APXvYqwUdUlFLYpDi9TXSAo1DgunYgGWSfHVxpkHrKN2oEpisYnbGTVJz6D/BJgJ/Csl+FlEpx/sDQ/nHfKlTg+jlqE= X-Received: by 2002:a2e:9110:: with SMTP id m16mr31222819ljg.140.1577540031375; Sat, 28 Dec 2019 05:33:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Sat, 28 Dec 2019 06:33:24 -0700 Message-ID: To: Torsten Lodderstedt Cc: Mike Jones , oauth Content-Type: multipart/alternative; boundary="000000000000308601059ac3a92c" Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 13:33:56 -0000 --000000000000308601059ac3a92c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The requirement for replay/injection prevention at resource servers is still there in section 3.2. This change only drops it as a specific qualification on that SHOULD NOT for flows that send access tokens in the authorization response. And instead focuses that qualification on the additional risks that come with sending access tokens in the authorization response. To me, this feels more consistent. Looking again at section 3, I'd suggest also moving the fourth paragraph of section 3.1.2 into section 3.2 so that the description of sender-constrained is in the subsection that is about sender-constraining. On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt wrote: > Your proposal sounds reasonable on first sight. But thinking again, it > would mean to keep token injection prevention in authorization responses = a > requirement while dropping the requirement for replay/injection preventio= n > at resource servers. To me this feels inconsistent. > > Am 28..12.2019 um 00:02 schrieb Brian Campbell 40pingidentity.com@dmarc.ietf.org>: > > =EF=BB=BF > I'm not suggesting that it should be a recommended flow. But recommending > against it, as the text does now, seems overreaching and unnecessary. I > know *consensus* was previously found on the text in -13 but best I can > recall that discussion was mostly around Nat advocating to allow room for > some future self-issued IDP type case and the conversation kind of got hu= ng > up on that. > > Here's some proposed text, which I think still largely captures the inten= t > of the BCP while not explicitly recommending against legitimate cases lik= e > the one I brought here or Nat's or something like JARM. > > In order to avoid these issues, clients SHOULD NOT use the implicit > grant (response type "token") or other response types issuing > access tokens in the authorization response, unless access token > injection > in the authorization response is prevented and the aforementioned toke= n > leakage > vectors are mitigated. > > The draft already recommends sender-constrained access tokens elsewhere i= n > the document. It doesn't need to be repeated as a qualifying condition > around this SHOULD NOT. > > I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefull= y > is evident from several attempts at bringing/doing related work here) but= I > do worry that the recommendation in the draft is sufficiently unachievabl= e > to the vast majority that it might undermine the credibility of the > document. But I get the aspirational aspect of it and, other than some > suggested tweaks > = , > am resigned to see it stay in the document. But let's let that > recommendation stand on its own in the document and not also tie it to > other considerations. > > > On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt 40lodderstedt.net@dmarc.ietf.org> wrote: > >> As Brian said, we have discussed this several times and this text found >> consensus. >> >> Using post reduces the attack surface but does not allow to bind the >> access token to the legitimate client. We are recommending sender >> constrained access tokens in the BCP. So recommending a flow that does n= ot >> support sender constrained access tokens is a contradiction. >> >> What do other WG members think? >> >> Am 27.12.2019 um 21:28 schrieb Mike Jones > 40microsoft.com@dmarc.ietf.org>: >> >> =EF=BB=BF >> I agree with Brian. Please update the text to describe this already safe >> usage. >> >> -- Mike >> >> ------------------------------ >> *From:* OAuth on behalf of Brian Campbell >> >> *Sent:* Friday, December 27, 2019 11:03:30 AM >> *To:* oauth >> *Subject:* [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response >> types + form_post response mode >> >> We have a-sometimes used scenario where a client makes an >> authorization/authentication request with a "token id_token" response ty= pe >> and "form_post" response mode (nonce is also sent and exact redirect URI >> matching is done at the AS). The access token is never exposed in any UR= Ls >> and access token injection is prevented by the at_hash claim in the id >> token. >> >> That seems to me like a legitimate and reasonable usage scenario. >> However, it would fall on the wrong side of the SHOULD NOT in Section >> 3.1.2 of the Security BCP-to-be >> , >> which has: >> >> In order to avoid these issues, clients SHOULD NOT use the implicit >> grant (response type "token") or any other response type issuing >> access tokens in the authorization response, such as "token id_token" >> and "code token id_token", unless the issued access tokens are >> sender-constrained and access token injection in the authorization >> response is prevented. >> >> I know this particular text has been discussed over and over again so I >> hate to revisit it. But based on the aforementioned scenario I think may= be >> it still doesn't quite hit the mark. Access token injection is prevented= . >> The token leakage scenarios mentioned in that section are all avoided. A= nd >> while I know sender-constrained is recommended elsewhere in the draft, i= t's >> not really a realistic option for the majority of deployments. >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > --=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._ --000000000000308601059ac3a92c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The requirement for replay/injection prevention at re= source servers is still there in section 3.2. This change only drops it as = a specific qualification on that SHOULD NOT for flows that send access toke= ns in the authorization response. And instead focuses that qualification on= the additional risks that come with sending access tokens in the authoriza= tion response. To me, this feels more consistent.=C2=A0

Looking again at section 3, I'd suggest also moving the fourth = paragraph of section 3.1.2 into section 3.2 so that the description of send= er-constrained is in the subsection that is about sender-constraining.=C2= =A0


<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, Dec 27, 2019, 5:00 PM Torsten = Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
Your proposal sounds reasonable on first sight. But thinking a= gain, it would mean to keep token injection prevention in authorization res= ponses a requirement while dropping the requirement for replay/injection pr= evention at resource servers. To me this feels inconsistent.

Am 28..12.2019 um 00:02 schrieb Bria= n Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org= >:

=EF=BB=BF
I'm not suggesting that it should be= a recommended flow. But recommending against it, as the text does now, see= ms overreaching and unnecessary. I know *consensus* was previously found on= the text in -13 but best I can recall that discussion was mostly around Na= t advocating to allow room for some future self-issued IDP type case and th= e conversation kind of got hung up on that.

H= ere's some proposed text, which I think still largely captures the inte= nt of the BCP while not explicitly recommending against legitimate cases li= ke the one I brought here or Nat's or something like JARM.

=C2=A0=C2=A0 In order to avoid these issues, clients SHOU= LD NOT use the implicit
=C2=A0 =C2=A0grant (response type "token") or other response type= s issuing
=C2=A0 =C2=A0access tokens in the authorization response, unless access tok= en injection
=C2=A0=C2=A0 in the authorization response is preven= ted and the aforementioned token leakage
=C2=A0=C2=A0 vector= s are mitigated.

The draft already recommends= sender-constrained access tokens elsewhere in the document. It doesn't= need to be repeated as a qualifying condition around this SHOULD NOT.
=

I am a proponent of PoP/HoK/sender-constrained ac= cess tokens (as hopefully is evident from several attempts at bringing/doin= g related work here) but I do worry that the recommendation in the draft is= sufficiently unachievable to the vast majority that it might undermine the= credibility of the document. But I get the aspirational aspect of it and, = other than some suggested twe= aks, am resigned to see it stay in the document. But let's let that= recommendation stand on its own in the document and not also tie it to oth= er considerations.=C2=A0


On Fri, Dec 27, 2019 at 1:41 PM= Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ie= tf.org> wrote:
As Brian said, we have discussed t= his several times and this text found consensus.

=
Using post reduces the attack surface but does not a= llow to bind the access token to the legitimate client. We are recommending= sender constrained access tokens in the BCP. So recommending a flow that d= oes not support sender constrained access tokens is a contradiction.
<= div dir=3D"ltr">
What do other WG members think?<= /div>

Am 27.12.2019 um 21:28 = schrieb Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ie= tf.org>:

=EF=BB=BF
I agree with Brian. Please update the text to describe this already safe us= age.

-- Mike

From: OAuth <oauth-bounces@ietf.= org> on behalf of Brian Campbell <bcampbell=3D40pi= ngidentity.com@dmarc.ietf.org>
Sent: Friday, December 27, 2019 11:03:30 AM
To: oauth <oauth@ietf.org>
Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response= types + form_post response mode
=C2=A0
We have a-sometimes used scenario where a client makes an authorizatio= n/authentication request with a "token id_token" response type an= d "form_post" response mode (nonce is also sent and exact redirec= t URI matching is done at the AS). The access token is never exposed in any URLs and access token injection is prevented by th= e at_hash claim in the id token.

That seems to me like a legitimate and reasonable usage scenario. Howe= ver, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be, which has:

=C2=A0=C2=A0 In order to avoid these issues, clients SHOULD NOT use th= e implicit
=C2=A0 =C2=A0grant (response type "token") or any other response = type issuing
=C2=A0 =C2=A0access tokens in the authorization response, such as "tok= en id_token"
=C2=A0 =C2=A0and "code token id_token", unless the issued access = tokens are
=C2=A0 =C2=A0sender-constrained and access token injection in the authoriza= tion
=C2=A0 =C2=A0response is prevented.

I know this particular text has been discussed over and over again so = I hate to revisit it. But based on the aforementioned scenario I think mayb= e it still doesn't quite hit the mark. Access token injection is preven= ted. The token leakage scenarios mentioned in that section are all avoided. And while I know sender-constrained is re= commended elsewhere in the draft, it's not really a realistic option fo= r the majority of deployments.

CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or d= isclosure by others is strictly prohibited..=C2=A0 If you have received thi= s communication in error, please notify the sender immediately by e-mail and delete the message and any file attac= hments from your computer. Thank you.
_______________________________________________
OAuth= mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited..=C2=A0 If you have received this communication in er= ror, please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank you.

<= 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. --000000000000308601059ac3a92c-- From nobody Sat Dec 28 09:46:39 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FD3120143 for ; Sat, 28 Dec 2019 09:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwdYNAuaEe1L for ; Sat, 28 Dec 2019 09:46:34 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650121.outbound.protection.outlook.com [40.107.65.121]) (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 3B33712013C for ; Sat, 28 Dec 2019 09:46:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XAWMXfkguabH6VmhhV8d25Kcsg6fVUXKCc4P2cbWZBbnj5K4FUynmbg7I3HpkwUsvAaw5I36mr3K1D/PtGzAlHNOFE0r27ZE03TV6ym0PQ7jgyMil25mE4oaDWz7nV5nCbIcwNz5YAjeaDiXTDm+lY6VDP1IwXHxUxKxe1MwlATz8/gaYNovvRRLEKO06o4Q7676m5MaJacrGDfzax0fShNrrhU6A8Ypv0NSHtJjUGW4R0WzksBgnsZLWM+nb2Wo22PCihKNR9WrZ3jzSf1DEyQk5vFicwGwffHVUcWpXDlCX3fy+5XeBcn3qanr/6L/DyJEtKUPdQnu0hdyfFPBfw== 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=lTonBBF0Y92hCgr209S3LfbOaqCEtXKeu59Wwr++XSg=; b=JOqc1HUra2zbeYKscqmzmlpHkRyyRDYcHUBMt7TMTCYpeJo6JBtMqWseto8NqDPOJorqDAdFqHPqdvu+1T+mfu0I2D5fP4Sgmi/wb8SgejVxSRjT22rxK6j2626JJrhxQK+V6Mfh+e2NG6M9XI6RKLOgWZBbgq9HDHOsDKhBVoMQh2EQFWzdn7/tkyzc4iDGN45ISdTdi3lU8TAi7yCjKC13cT5mGOLkLu6uSG1mBQMLuDGtjOLCMarww2UGHVC+eTajKc1hDf6gfAEGp6CB4+fMVrRQ+ZauGoZ5xbmpZxtY2ZXlTtpfkMRJ31yiczpSr8NEsr2sZ3cN/FSFyh6jZw== 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=lTonBBF0Y92hCgr209S3LfbOaqCEtXKeu59Wwr++XSg=; b=iGCjY5plcweC7UX5L0U994bXo8gvm5iJpJYnK37o/JZ94kh0mhaPKhSDsjhCTiJUasexn9HLmhP/dEz7NvGfw87AeyVSd4jc2zIioXPnR3vCqKXCoxtPtXX9J9DAg5RW6gdCcLAFGGn9BX1bPaPn7dsfly5okaZabce8kccD2Zo= Received: from BL0PR00MB0836.namprd00.prod.outlook.com (52.135.44.19) by BL0PR00MB0801.namprd00.prod.outlook.com (52.135.45.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2629.0; Sat, 28 Dec 2019 17:46:13 +0000 Received: from BL0PR00MB0836.namprd00.prod.outlook.com ([fe80::a091:4d84:bc09:f09a]) by BL0PR00MB0836.namprd00.prod.outlook.com ([fe80::a091:4d84:bc09:f09a%9]) with mapi id 15.20.2629.000; Sat, 28 Dec 2019 17:46:13 +0000 From: Mike Jones To: Brian Campbell , Torsten Lodderstedt CC: oauth Thread-Topic: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode Thread-Index: AQHVvPYQJWd52MbkQ0qzxtYUrLLBV6fOmTmAgAAQWoCAAONCAIAARnpR Date: Sat, 28 Dec 2019 17:46:13 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-12-28T17:45:38.1618482Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [107.77.205.135] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a5a50f3b-1b60-4b61-b83c-08d78bbdd4db x-ms-traffictypediagnostic: BL0PR00MB0801: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 02652BD10A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(376002)(39860400002)(396003)(366004)(199004)(189003)(316002)(110136005)(5660300002)(8936002)(86362001)(186003)(8990500004)(26005)(7696005)(15650500001)(52536014)(71200400001)(6506007)(53546011)(81166006)(8676002)(81156014)(10290500003)(66946007)(966005)(33656002)(66556008)(9686003)(66476007)(64756008)(4326008)(55016002)(2906002)(66446008)(478600001)(91956017)(76116006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0801; H:BL0PR00MB0836.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SLT3veULOjeOqeOcO7dAww+jual042gv7WnloeuH+9DphRSdw0V09jrSLzrYeyrieJ6zXxTZbAn31Lh7wmkifJvIZXvAdNJU6xphKVOPL+upkSvEI4GiSRSQ3mWcUoGHnQOp3tApDaUGHEkVHBfCUHf9qbxQhTB91vDCzu+XOfB/ZGtVAlXGE9DZHcIqXB/pc1Dw9+Tw4Z211G2irD1PH2jdjW/QWnx2EFGvw1qLWxbgu3bjYggPdB7NUjVtkeFGC5Pqf2xAvjdSX+oI1OrkIK20n7a/M84agdpVRjc5eSrGEP5YavXOo2OnbxCFDeIwVY2PXuPnPqDsvJxDh/X4oRk+RSplLWBRghXYlt0//p0QJWXkkWZRxHvJrl8ZLWpyI4yrDvlnBrVPpsprHZR8/WuiQQyTMQEim/CqIHYwqVr46Wsi12TRkjifKmbn3dHBPCRScbfWTQyiuCpGbMkp+i3+e3gmBVenAWe+/G2oLp82CdvG5RLTOONFgkRQ44Ovw9d+qPR24Fap1HkX419XXg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0836155876E1356943AA669AF5250BL0PR00MB0836namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5a50f3b-1b60-4b61-b83c-08d78bbdd4db X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Dec 2019 17:46:13.0810 (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: j3639k2AjnPD4/hs9L00An0uqnKpvRHvZsafWZDUqdIcMKxkq3byGi9BU1ldLgyg92KR0Wk/bWGLhuah79qcIA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0801 Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 17:46:37 -0000 --_000_BL0PR00MB0836155876E1356943AA669AF5250BL0PR00MB0836namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEJyaWFuJ3Mgc3VnZ2VzdGVkIHRleHQgY2hhbmdlcy4NCg0KLS0gTWlrZQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEJyaWFuIENhbXBiZWxsIDxi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4NClNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAyOCwg MjAxOSA1OjMzOjI0IEFNDQpUbzogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3Rlbj00MGxvZGRl cnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZz4NCkNjOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20+OyBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09B VVRILVdHXSBbRVhURVJOQUxdIC1zZWN1cml0eS10b3BpY3MtMTMgYW5kIE9JREMgcmVzcG9uc2Ug dHlwZXMgKyBmb3JtX3Bvc3QgcmVzcG9uc2UgbW9kZQ0KDQpUaGUgcmVxdWlyZW1lbnQgZm9yIHJl cGxheS9pbmplY3Rpb24gcHJldmVudGlvbiBhdCByZXNvdXJjZSBzZXJ2ZXJzIGlzIHN0aWxsIHRo ZXJlIGluIHNlY3Rpb24gMy4yLiBUaGlzIGNoYW5nZSBvbmx5IGRyb3BzIGl0IGFzIGEgc3BlY2lm aWMgcXVhbGlmaWNhdGlvbiBvbiB0aGF0IFNIT1VMRCBOT1QgZm9yIGZsb3dzIHRoYXQgc2VuZCBh Y2Nlc3MgdG9rZW5zIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlLiBBbmQgaW5zdGVhZCBm b2N1c2VzIHRoYXQgcXVhbGlmaWNhdGlvbiBvbiB0aGUgYWRkaXRpb25hbCByaXNrcyB0aGF0IGNv bWUgd2l0aCBzZW5kaW5nIGFjY2VzcyB0b2tlbnMgaW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9u c2UuIFRvIG1lLCB0aGlzIGZlZWxzIG1vcmUgY29uc2lzdGVudC4NCg0KTG9va2luZyBhZ2FpbiBh dCBzZWN0aW9uIDMsIEknZCBzdWdnZXN0IGFsc28gbW92aW5nIHRoZSBmb3VydGggcGFyYWdyYXBo IG9mIHNlY3Rpb24gMy4xLjIgaW50byBzZWN0aW9uIDMuMiBzbyB0aGF0IHRoZSBkZXNjcmlwdGlv biBvZiBzZW5kZXItY29uc3RyYWluZWQgaXMgaW4gdGhlIHN1YnNlY3Rpb24gdGhhdCBpcyBhYm91 dCBzZW5kZXItY29uc3RyYWluaW5nLg0KDQoNCk9uIEZyaSwgRGVjIDI3LCAyMDE5LCA1OjAwIFBN IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0 Zi5vcmc8bWFpbHRvOjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpZ b3VyIHByb3Bvc2FsIHNvdW5kcyByZWFzb25hYmxlIG9uIGZpcnN0IHNpZ2h0LiBCdXQgdGhpbmtp bmcgYWdhaW4sIGl0IHdvdWxkIG1lYW4gdG8ga2VlcCB0b2tlbiBpbmplY3Rpb24gcHJldmVudGlv biBpbiBhdXRob3JpemF0aW9uIHJlc3BvbnNlcyBhIHJlcXVpcmVtZW50IHdoaWxlIGRyb3BwaW5n IHRoZSByZXF1aXJlbWVudCBmb3IgcmVwbGF5L2luamVjdGlvbiBwcmV2ZW50aW9uIGF0IHJlc291 cmNlIHNlcnZlcnMuIFRvIG1lIHRoaXMgZmVlbHMgaW5jb25zaXN0ZW50Lg0KDQpBbSAyOC4uMTIu MjAxOSB1bSAwMDowMiBzY2hyaWViIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRl bnRpdHkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMu aWV0Zi5vcmc+PjoNCg0K77u/DQpJJ20gbm90IHN1Z2dlc3RpbmcgdGhhdCBpdCBzaG91bGQgYmUg YSByZWNvbW1lbmRlZCBmbG93LiBCdXQgcmVjb21tZW5kaW5nIGFnYWluc3QgaXQsIGFzIHRoZSB0 ZXh0IGRvZXMgbm93LCBzZWVtcyBvdmVycmVhY2hpbmcgYW5kIHVubmVjZXNzYXJ5LiBJIGtub3cg KmNvbnNlbnN1cyogd2FzIHByZXZpb3VzbHkgZm91bmQgb24gdGhlIHRleHQgaW4gLTEzIGJ1dCBi ZXN0IEkgY2FuIHJlY2FsbCB0aGF0IGRpc2N1c3Npb24gd2FzIG1vc3RseSBhcm91bmQgTmF0IGFk dm9jYXRpbmcgdG8gYWxsb3cgcm9vbSBmb3Igc29tZSBmdXR1cmUgc2VsZi1pc3N1ZWQgSURQIHR5 cGUgY2FzZSBhbmQgdGhlIGNvbnZlcnNhdGlvbiBraW5kIG9mIGdvdCBodW5nIHVwIG9uIHRoYXQu DQoNCkhlcmUncyBzb21lIHByb3Bvc2VkIHRleHQsIHdoaWNoIEkgdGhpbmsgc3RpbGwgbGFyZ2Vs eSBjYXB0dXJlcyB0aGUgaW50ZW50IG9mIHRoZSBCQ1Agd2hpbGUgbm90IGV4cGxpY2l0bHkgcmVj b21tZW5kaW5nIGFnYWluc3QgbGVnaXRpbWF0ZSBjYXNlcyBsaWtlIHRoZSBvbmUgSSBicm91Z2h0 IGhlcmUgb3IgTmF0J3Mgb3Igc29tZXRoaW5nIGxpa2UgSkFSTS4NCg0KICAgSW4gb3JkZXIgdG8g YXZvaWQgdGhlc2UgaXNzdWVzLCBjbGllbnRzIFNIT1VMRCBOT1QgdXNlIHRoZSBpbXBsaWNpdA0K ICAgZ3JhbnQgKHJlc3BvbnNlIHR5cGUgInRva2VuIikgb3Igb3RoZXIgcmVzcG9uc2UgdHlwZXMg aXNzdWluZw0KICAgYWNjZXNzIHRva2VucyBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSwg dW5sZXNzIGFjY2VzcyB0b2tlbiBpbmplY3Rpb24NCiAgIGluIHRoZSBhdXRob3JpemF0aW9uIHJl c3BvbnNlIGlzIHByZXZlbnRlZCBhbmQgdGhlIGFmb3JlbWVudGlvbmVkIHRva2VuIGxlYWthZ2UN CiAgIHZlY3RvcnMgYXJlIG1pdGlnYXRlZC4NCg0KVGhlIGRyYWZ0IGFscmVhZHkgcmVjb21tZW5k cyBzZW5kZXItY29uc3RyYWluZWQgYWNjZXNzIHRva2VucyBlbHNld2hlcmUgaW4gdGhlIGRvY3Vt ZW50LiBJdCBkb2Vzbid0IG5lZWQgdG8gYmUgcmVwZWF0ZWQgYXMgYSBxdWFsaWZ5aW5nIGNvbmRp dGlvbiBhcm91bmQgdGhpcyBTSE9VTEQgTk9ULg0KDQpJIGFtIGEgcHJvcG9uZW50IG9mIFBvUC9I b0svc2VuZGVyLWNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMgKGFzIGhvcGVmdWxseSBpcyBldmlk ZW50IGZyb20gc2V2ZXJhbCBhdHRlbXB0cyBhdCBicmluZ2luZy9kb2luZyByZWxhdGVkIHdvcmsg aGVyZSkgYnV0IEkgZG8gd29ycnkgdGhhdCB0aGUgcmVjb21tZW5kYXRpb24gaW4gdGhlIGRyYWZ0 IGlzIHN1ZmZpY2llbnRseSB1bmFjaGlldmFibGUgdG8gdGhlIHZhc3QgbWFqb3JpdHkgdGhhdCBp dCBtaWdodCB1bmRlcm1pbmUgdGhlIGNyZWRpYmlsaXR5IG9mIHRoZSBkb2N1bWVudC4gQnV0IEkg Z2V0IHRoZSBhc3BpcmF0aW9uYWwgYXNwZWN0IG9mIGl0IGFuZCwgb3RoZXIgdGhhbiBzb21lIHN1 Z2dlc3RlZCB0d2Vha3M8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGbWFpbGFyY2hpdmUuaWV0Zi5vcmclMkZhcmNoJTJGbXNn JTJGb2F1dGglMkZSS3VqT05lai05MmRUNWxyOWNMdTZoSG53OEkmZGF0YT0wMiU3QzAxJTdDTWlj aGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0NmYzI4ZDUxM2IwNGY0ODliMzcxZDA4ZDc4Yjlh OTQ4OCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxMzEz NjgzNDIwOTY5MjMmc2RhdGE9M2ZDR2pUT0FENDN4WEx6RmF3M2Q2VkMxa1k0M1F2QmZ6TndkTmZE Y2tFMCUzRCZyZXNlcnZlZD0wPiwgYW0gcmVzaWduZWQgdG8gc2VlIGl0IHN0YXkgaW4gdGhlIGRv Y3VtZW50LiBCdXQgbGV0J3MgbGV0IHRoYXQgcmVjb21tZW5kYXRpb24gc3RhbmQgb24gaXRzIG93 biBpbiB0aGUgZG9jdW1lbnQgYW5kIG5vdCBhbHNvIHRpZSBpdCB0byBvdGhlciBjb25zaWRlcmF0 aW9ucy4NCg0KDQpPbiBGcmksIERlYyAyNywgMjAxOSBhdCAxOjQxIFBNIFRvcnN0ZW4gTG9kZGVy c3RlZHQgPHRvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQw bG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpBcyBCcmlhbiBzYWlkLCB3 ZSBoYXZlIGRpc2N1c3NlZCB0aGlzIHNldmVyYWwgdGltZXMgYW5kIHRoaXMgdGV4dCBmb3VuZCBj b25zZW5zdXMuDQoNClVzaW5nIHBvc3QgcmVkdWNlcyB0aGUgYXR0YWNrIHN1cmZhY2UgYnV0IGRv ZXMgbm90IGFsbG93IHRvIGJpbmQgdGhlIGFjY2VzcyB0b2tlbiB0byB0aGUgbGVnaXRpbWF0ZSBj bGllbnQuIFdlIGFyZSByZWNvbW1lbmRpbmcgc2VuZGVyIGNvbnN0cmFpbmVkIGFjY2VzcyB0b2tl bnMgaW4gdGhlIEJDUC4gU28gcmVjb21tZW5kaW5nIGEgZmxvdyB0aGF0IGRvZXMgbm90IHN1cHBv cnQgc2VuZGVyIGNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMgaXMgYSBjb250cmFkaWN0aW9uLg0K DQpXaGF0IGRvIG90aGVyIFdHIG1lbWJlcnMgdGhpbms/DQoNCkFtIDI3LjEyLjIwMTkgdW0gMjE6 Mjggc2NocmllYiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFy Yy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj46DQoNCu+7 vw0KSSBhZ3JlZSB3aXRoIEJyaWFuLiBQbGVhc2UgdXBkYXRlIHRoZSB0ZXh0IHRvIGRlc2NyaWJl IHRoaXMgYWxyZWFkeSBzYWZlIHVzYWdlLg0KDQotLSBNaWtlDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVsbCA8 YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBwaW5n aWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPj4NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMjcs IDIwMTkgMTE6MDM6MzAgQU0NClRvOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRo QGlldGYub3JnPj4NClN1YmplY3Q6IFtFWFRFUk5BTF0gW09BVVRILVdHXSAtc2VjdXJpdHktdG9w aWNzLTEzIGFuZCBPSURDIHJlc3BvbnNlIHR5cGVzICsgZm9ybV9wb3N0IHJlc3BvbnNlIG1vZGUN Cg0KV2UgaGF2ZSBhLXNvbWV0aW1lcyB1c2VkIHNjZW5hcmlvIHdoZXJlIGEgY2xpZW50IG1ha2Vz IGFuIGF1dGhvcml6YXRpb24vYXV0aGVudGljYXRpb24gcmVxdWVzdCB3aXRoIGEgInRva2VuIGlk X3Rva2VuIiByZXNwb25zZSB0eXBlIGFuZCAiZm9ybV9wb3N0IiByZXNwb25zZSBtb2RlIChub25j ZSBpcyBhbHNvIHNlbnQgYW5kIGV4YWN0IHJlZGlyZWN0IFVSSSBtYXRjaGluZyBpcyBkb25lIGF0 IHRoZSBBUykuIFRoZSBhY2Nlc3MgdG9rZW4gaXMgbmV2ZXIgZXhwb3NlZCBpbiBhbnkgVVJMcyBh bmQgYWNjZXNzIHRva2VuIGluamVjdGlvbiBpcyBwcmV2ZW50ZWQgYnkgdGhlIGF0X2hhc2ggY2xh aW0gaW4gdGhlIGlkIHRva2VuLg0KDQpUaGF0IHNlZW1zIHRvIG1lIGxpa2UgYSBsZWdpdGltYXRl IGFuZCByZWFzb25hYmxlIHVzYWdlIHNjZW5hcmlvLiBIb3dldmVyLCBpdCB3b3VsZCBmYWxsIG9u IHRoZSB3cm9uZyBzaWRlIG9mIHRoZSBTSE9VTEQgTk9UIGluIFNlY3Rpb24gMy4xLjIgb2YgdGhl IFNlY3VyaXR5IEJDUC10by1iZTxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFm dC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMyUyM3NlY3Rpb24tMy4uLjEuLjImZGF0YT0w MiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0NmYzI4ZDUxM2IwNGY0ODli MzcxZDA4ZDc4YjlhOTQ4OCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3 QzAlN0M2MzcxMzEzNjgzNDIwOTY5MjMmc2RhdGE9bWZuUXdzR1VaZ3owUGdFWm9xT2wlMkJzc3pQ WXhuY21GYmdCYUpzNHFleDM4JTNEJnJlc2VydmVkPTA+LCB3aGljaCBoYXM6DQoNCiAgIEluIG9y ZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgY2xpZW50cyBTSE9VTEQgTk9UIHVzZSB0aGUgaW1w bGljaXQNCiAgIGdyYW50IChyZXNwb25zZSB0eXBlICJ0b2tlbiIpIG9yIGFueSBvdGhlciByZXNw b25zZSB0eXBlIGlzc3VpbmcNCiAgIGFjY2VzcyB0b2tlbnMgaW4gdGhlIGF1dGhvcml6YXRpb24g cmVzcG9uc2UsIHN1Y2ggYXMgInRva2VuIGlkX3Rva2VuIg0KICAgYW5kICJjb2RlIHRva2VuIGlk X3Rva2VuIiwgdW5sZXNzIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2VucyBhcmUNCiAgIHNlbmRlci1j b25zdHJhaW5lZCBhbmQgYWNjZXNzIHRva2VuIGluamVjdGlvbiBpbiB0aGUgYXV0aG9yaXphdGlv bg0KICAgcmVzcG9uc2UgaXMgcHJldmVudGVkLg0KDQpJIGtub3cgdGhpcyBwYXJ0aWN1bGFyIHRl eHQgaGFzIGJlZW4gZGlzY3Vzc2VkIG92ZXIgYW5kIG92ZXIgYWdhaW4gc28gSSBoYXRlIHRvIHJl dmlzaXQgaXQuIEJ1dCBiYXNlZCBvbiB0aGUgYWZvcmVtZW50aW9uZWQgc2NlbmFyaW8gSSB0aGlu ayBtYXliZSBpdCBzdGlsbCBkb2Vzbid0IHF1aXRlIGhpdCB0aGUgbWFyay4gQWNjZXNzIHRva2Vu IGluamVjdGlvbiBpcyBwcmV2ZW50ZWQuIFRoZSB0b2tlbiBsZWFrYWdlIHNjZW5hcmlvcyBtZW50 aW9uZWQgaW4gdGhhdCBzZWN0aW9uIGFyZSBhbGwgYXZvaWRlZC4gQW5kIHdoaWxlIEkga25vdyBz ZW5kZXItY29uc3RyYWluZWQgaXMgcmVjb21tZW5kZWQgZWxzZXdoZXJlIGluIHRoZSBkcmFmdCwg aXQncyBub3QgcmVhbGx5IGEgcmVhbGlzdGljIG9wdGlvbiBmb3IgdGhlIG1ham9yaXR5IG9mIGRl cGxveW1lbnRzLg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNl IG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0 aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3Nh Z2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91 Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo IG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hbTA2LnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0 Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZvYXV0aCZkYXRhPTAyJTdDMDElN0NNaWNoYWVs LkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3Q2ZjMjhkNTEzYjA0ZjQ4OWIzNzFkMDhkNzhiOWE5NDg4 JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzEzMTM2ODM0 MjEwNjg5MSZzZGF0YT1xTzYlMkJZJTJGTW9lZjBseXg0SHdOTFY4SUQ1RGd1QWUzWGpDUXl4dHZv RnJQbyUzRCZyZXNlcnZlZD0wPg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWls IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhl IHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwg ZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUg dGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4g VGhhbmsgeW91Lg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNl IG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0 aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2Fn ZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3Uu DQo= --_000_BL0PR00MB0836155876E1356943AA669AF5250BL0PR00MB0836namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9ImF1 dG8iIHN0eWxlPSJkaXJlY3Rpb246IGx0cjsgbWFyZ2luOiAwOyBwYWRkaW5nOiAwOyBmb250LWZh bWlseTogc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyBjb2xvcjogYmxhY2s7ICI+DQpJIGFn cmVlIHdpdGggQnJpYW4ncyBzdWdnZXN0ZWQgdGV4dCBjaGFuZ2VzLjxicj4NCjxicj4NCjwvZGl2 Pg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJkaXJlY3Rpb246IGx0cjsgbWFyZ2luOiAwOyBwYWRk aW5nOiAwOyBmb250LWZhbWlseTogc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyBjb2xvcjog YmxhY2s7ICI+DQotLSBNaWtlPGJyPg0KPC9kaXY+DQo8aHIgc3R5bGU9ImRpc3BsYXk6aW5saW5l LWJsb2NrO3dpZHRoOjk4JSIgdGFiaW5kZXg9Ii0xIj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ci IGRpcj0ibHRyIj48Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBzdHlsZT0iZm9udC1z aXplOjExcHQiIGNvbG9yPSIjMDAwMDAwIj48Yj5Gcm9tOjwvYj4gQnJpYW4gQ2FtcGJlbGwgJmx0 O2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRh eSwgRGVjZW1iZXIgMjgsIDIwMTkgNTozMzoyNCBBTTxicj4NCjxiPlRvOjwvYj4gVG9yc3RlbiBM b2RkZXJzdGVkdCAmbHQ7dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZyZn dDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbSZndDs7IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtPQVVUSC1XR10gW0VYVEVSTkFMXSAtc2VjdXJpdHktdG9waWNzLTEzIGFuZCBPSURD IHJlc3BvbnNlIHR5cGVzICYjNDM7IGZvcm1fcG9zdCByZXNwb25zZSBtb2RlPC9mb250Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5UaGUg cmVxdWlyZW1lbnQgZm9yIHJlcGxheS9pbmplY3Rpb24gcHJldmVudGlvbiBhdCByZXNvdXJjZSBz ZXJ2ZXJzIGlzIHN0aWxsIHRoZXJlIGluIHNlY3Rpb24gMy4yLiBUaGlzIGNoYW5nZSBvbmx5IGRy b3BzIGl0IGFzIGEgc3BlY2lmaWMgcXVhbGlmaWNhdGlvbiBvbiB0aGF0IFNIT1VMRCBOT1QgZm9y IGZsb3dzIHRoYXQgc2VuZCBhY2Nlc3MgdG9rZW5zIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3Bv bnNlLiBBbmQgaW5zdGVhZCBmb2N1c2VzDQogdGhhdCBxdWFsaWZpY2F0aW9uIG9uIHRoZSBhZGRp dGlvbmFsIHJpc2tzIHRoYXQgY29tZSB3aXRoIHNlbmRpbmcgYWNjZXNzIHRva2VucyBpbiB0aGUg YXV0aG9yaXphdGlvbiByZXNwb25zZS4gVG8gbWUsIHRoaXMgZmVlbHMgbW9yZSBjb25zaXN0ZW50 LiZuYnNwOw0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Mb29raW5nIGFnYWluIGF0 IHNlY3Rpb24gMywgSSdkIHN1Z2dlc3QgYWxzbyBtb3ZpbmcgdGhlIGZvdXJ0aCBwYXJhZ3JhcGgg b2Ygc2VjdGlvbiAzLjEuMiBpbnRvIHNlY3Rpb24gMy4yIHNvIHRoYXQgdGhlIGRlc2NyaXB0aW9u IG9mIHNlbmRlci1jb25zdHJhaW5lZCBpcyBpbiB0aGUgc3Vic2VjdGlvbiB0aGF0IGlzIGFib3V0 IHNlbmRlci1jb25zdHJhaW5pbmcuJm5ic3A7DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1 dG8iPg0KPGRpdj48YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIj4NCjxkaXYg ZGlyPSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0dHIiPk9uIEZyaSwgRGVjIDI3LCAyMDE5LCA1OjAw IFBNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW49PGEgaHJlZj0ibWFpbHRvOjQwbG9k ZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBsb2RkZXJzdGVk dC5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIGNsYXNzPSJ4X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4 OyBib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTsgcGFkZGluZy1sZWZ0OjFl eCI+DQo8ZGl2IGRpcj0iYXV0byI+DQo8ZGl2IGRpcj0ibHRyIj5Zb3VyIHByb3Bvc2FsIHNvdW5k cyByZWFzb25hYmxlIG9uIGZpcnN0IHNpZ2h0LiBCdXQgdGhpbmtpbmcgYWdhaW4sIGl0IHdvdWxk IG1lYW4gdG8ga2VlcCB0b2tlbiBpbmplY3Rpb24gcHJldmVudGlvbiBpbiBhdXRob3JpemF0aW9u IHJlc3BvbnNlcyBhIHJlcXVpcmVtZW50IHdoaWxlIGRyb3BwaW5nIHRoZSByZXF1aXJlbWVudCBm b3IgcmVwbGF5L2luamVjdGlvbiBwcmV2ZW50aW9uIGF0IHJlc291cmNlIHNlcnZlcnMuDQogVG8g bWUgdGhpcyBmZWVscyBpbmNvbnNpc3RlbnQuPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5BbSAyOC4uMTIuMjAxOSB1bSAwMDowMiBzY2hyaWViIEJy aWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGw9PGEgaHJlZj0ibWFpbHRvOjQwcGluZ2lkZW50aXR5 LmNvbUBkbWFyYy5pZXRmLm9yZyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+NDBw aW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs6PGJyPg0KPGJyPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIi Pu+7vw0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2PkknbSBub3Qgc3VnZ2VzdGluZyB0aGF0IGl0IHNo b3VsZCBiZSBhIHJlY29tbWVuZGVkIGZsb3cuIEJ1dCByZWNvbW1lbmRpbmcgYWdhaW5zdCBpdCwg YXMgdGhlIHRleHQgZG9lcyBub3csIHNlZW1zIG92ZXJyZWFjaGluZyBhbmQgdW5uZWNlc3Nhcnku IEkga25vdyAqY29uc2Vuc3VzKiB3YXMgcHJldmlvdXNseSBmb3VuZCBvbiB0aGUgdGV4dCBpbiAt MTMgYnV0IGJlc3QgSSBjYW4gcmVjYWxsIHRoYXQgZGlzY3Vzc2lvbiB3YXMgbW9zdGx5DQogYXJv dW5kIE5hdCBhZHZvY2F0aW5nIHRvIGFsbG93IHJvb20gZm9yIHNvbWUgZnV0dXJlIHNlbGYtaXNz dWVkIElEUCB0eXBlIGNhc2UgYW5kIHRoZSBjb252ZXJzYXRpb24ga2luZCBvZiBnb3QgaHVuZyB1 cCBvbiB0aGF0Lg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5IZXJlJ3Mg c29tZSBwcm9wb3NlZCB0ZXh0LCB3aGljaCBJIHRoaW5rIHN0aWxsIGxhcmdlbHkgY2FwdHVyZXMg dGhlIGludGVudCBvZiB0aGUgQkNQIHdoaWxlIG5vdCBleHBsaWNpdGx5IHJlY29tbWVuZGluZyBh Z2FpbnN0IGxlZ2l0aW1hdGUgY2FzZXMgbGlrZSB0aGUgb25lIEkgYnJvdWdodCBoZXJlIG9yIE5h dCdzIG9yIHNvbWV0aGluZyBsaWtlIEpBUk0uDQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBJbiBvcmRlciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIGNs aWVudHMgU0hPVUxEIE5PVCB1c2UgdGhlIGltcGxpY2l0PGJyPg0KJm5ic3A7ICZuYnNwO2dyYW50 IChyZXNwb25zZSB0eXBlICZxdW90O3Rva2VuJnF1b3Q7KSBvciBvdGhlciByZXNwb25zZSB0eXBl cyBpc3N1aW5nPGJyPg0KJm5ic3A7ICZuYnNwO2FjY2VzcyB0b2tlbnMgaW4gdGhlIGF1dGhvcml6 YXRpb24gcmVzcG9uc2UsIHVubGVzcyBhY2Nlc3MgdG9rZW4gaW5qZWN0aW9uPC9kaXY+DQo8ZGl2 PiZuYnNwOyZuYnNwOyBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSBpcyBwcmV2ZW50ZWQg YW5kIHRoZSBhZm9yZW1lbnRpb25lZCB0b2tlbiBsZWFrYWdlDQo8YnI+DQo8L2Rpdj4NCjxkaXY+ Jm5ic3A7Jm5ic3A7IHZlY3RvcnMgYXJlIG1pdGlnYXRlZC4gPGJyPg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5UaGUgZHJhZnQgYWxyZWFkeSByZWNvbW1lbmRzIHNlbmRlci1jb25z dHJhaW5lZCBhY2Nlc3MgdG9rZW5zIGVsc2V3aGVyZSBpbiB0aGUgZG9jdW1lbnQuIEl0IGRvZXNu J3QgbmVlZCB0byBiZSByZXBlYXRlZCBhcyBhIHF1YWxpZnlpbmcgY29uZGl0aW9uIGFyb3VuZCB0 aGlzIFNIT1VMRCBOT1QuDQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkkg YW0gYSBwcm9wb25lbnQgb2YgUG9QL0hvSy9zZW5kZXItY29uc3RyYWluZWQgYWNjZXNzIHRva2Vu cyAoYXMgaG9wZWZ1bGx5IGlzIGV2aWRlbnQgZnJvbSBzZXZlcmFsIGF0dGVtcHRzIGF0IGJyaW5n aW5nL2RvaW5nIHJlbGF0ZWQgd29yayBoZXJlKSBidXQgSSBkbyB3b3JyeSB0aGF0IHRoZSByZWNv bW1lbmRhdGlvbiBpbiB0aGUgZHJhZnQgaXMgc3VmZmljaWVudGx5IHVuYWNoaWV2YWJsZSB0byB0 aGUgdmFzdCBtYWpvcml0eSB0aGF0DQogaXQgbWlnaHQgdW5kZXJtaW5lIHRoZSBjcmVkaWJpbGl0 eSBvZiB0aGUgZG9jdW1lbnQuIEJ1dCBJIGdldCB0aGUgYXNwaXJhdGlvbmFsIGFzcGVjdCBvZiBp dCBhbmQsIG90aGVyIHRoYW4NCjxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRm1haWxhcmNoaXZlLmlldGYub3Jn JTJGYXJjaCUyRm1zZyUyRm9hdXRoJTJGUkt1ak9OZWotOTJkVDVscjljTHU2aEhudzhJJmFtcDtk YXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3Q2ZjMjhkNTEzYjA0 ZjQ4OWIzNzFkMDhkNzhiOWE5NDg4JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNzEzMTM2ODM0MjA5NjkyMyZhbXA7c2RhdGE9M2ZDR2pUT0FENDN4WEx6RmF3 M2Q2VkMxa1k0M1F2QmZ6TndkTmZEY2tFMCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgb3JpZ2luYWxzcmM9 Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvUkt1ak9OZWotOTJk VDVscjljTHU2aEhudzhJIiBzaGFzaD0iU0N4UTNkTTI2STVTZ2Y2RDBieVhvSGR6U0FFMVR2L21i bW9zOEV0ekZRZHZBZFd4d0hVdGxGdnRQTHdtWHRNeGx6QnhZa1dPbXFnMnJtUVQyRyYjNDM7RXJN UUgzaG1PUnFwa2swQ0txc2lEaC9QaGNScHJOZHlGR0htTUx6N3RjN092WWQ4dENWbWxXdlZQUC94 c3NyQTlBOW5VQXNFdWovcmhDeUlkOUMyT1EmIzQzO1U9IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIj4NCnNvbWUgc3VnZ2VzdGVkIHR3ZWFrczwvYT4sIGFtIHJlc2lnbmVkIHRvIHNl ZSBpdCBzdGF5IGluIHRoZSBkb2N1bWVudC4gQnV0IGxldCdzIGxldCB0aGF0IHJlY29tbWVuZGF0 aW9uIHN0YW5kIG9uIGl0cyBvd24gaW4gdGhlIGRvY3VtZW50IGFuZCBub3QgYWxzbyB0aWUgaXQg dG8gb3RoZXIgY29uc2lkZXJhdGlvbnMuJm5ic3A7DQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIi IGNsYXNzPSJ4X2dtYWlsX2F0dHIiPk9uIEZyaSwgRGVjIDI3LCAyMDE5IGF0IDE6NDEgUE0gVG9y c3RlbiBMb2RkZXJzdGVkdCAmbHQ7dG9yc3Rlbj08YSBocmVmPSJtYWlsdG86NDBsb2RkZXJzdGVk dC5uZXRAZG1hcmMuaWV0Zi5vcmciIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPjQw bG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBjbGFzcz0ieF9nbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4 IDBweCAwLjhleDsgYm9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7IHBhZGRp bmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9ImF1dG8iPg0KPGRpdiBkaXI9Imx0ciI+QXMgQnJpYW4g c2FpZCwgd2UgaGF2ZSBkaXNjdXNzZWQgdGhpcyBzZXZlcmFsIHRpbWVzIGFuZCB0aGlzIHRleHQg Zm91bmQgY29uc2Vuc3VzLjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2 IGRpcj0ibHRyIj5Vc2luZyBwb3N0IHJlZHVjZXMgdGhlIGF0dGFjayBzdXJmYWNlIGJ1dCBkb2Vz IG5vdCBhbGxvdyB0byBiaW5kIHRoZSBhY2Nlc3MgdG9rZW4gdG8gdGhlIGxlZ2l0aW1hdGUgY2xp ZW50LiBXZSBhcmUgcmVjb21tZW5kaW5nIHNlbmRlciBjb25zdHJhaW5lZCBhY2Nlc3MgdG9rZW5z IGluIHRoZSBCQ1AuIFNvIHJlY29tbWVuZGluZyBhIGZsb3cgdGhhdCBkb2VzIG5vdCBzdXBwb3J0 IHNlbmRlciBjb25zdHJhaW5lZCBhY2Nlc3MNCiB0b2tlbnMgaXMgYSBjb250cmFkaWN0aW9uLjwv ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5XaGF0IGRv IG90aGVyIFdHIG1lbWJlcnMgdGhpbms/PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj5BbSAyNy4xMi4yMDE5IHVtIDIxOjI4IHNjaHJpZWIgTWlrZSBK b25lcyAmbHQ7TWljaGFlbC5Kb25lcz08YSBocmVmPSJtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRt YXJjLmlldGYub3JnIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj40MG1pY3Jvc29m dC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+77u/DQo8ZGl2 IGRpcj0iYXV0byIgc3R5bGU9ImRpcmVjdGlvbjpsdHI7IG1hcmdpbjowcHg7IHBhZGRpbmc6MHB4 OyBmb250LWZhbWlseTpzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgY29sb3I6YmxhY2siPg0K SSBhZ3JlZSB3aXRoIEJyaWFuLiBQbGVhc2UgdXBkYXRlIHRoZSB0ZXh0IHRvIGRlc2NyaWJlIHRo aXMgYWxyZWFkeSBzYWZlIHVzYWdlLjxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8i IHN0eWxlPSJkaXJlY3Rpb246bHRyOyBtYXJnaW46MHB4OyBwYWRkaW5nOjBweDsgZm9udC1mYW1p bHk6c2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGNvbG9yOmJsYWNrIj4NCi0tIE1pa2U8YnI+ DQo8YnI+DQo8L2Rpdj4NCjxociBzdHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7IHdpZHRoOjk4 JSI+DQo8ZGl2IGlkPSJ4X2dtYWlsLW1fMTk2NDMxMzUwMDEzNDEyMTI4M21fMzA3MjM5NTE1NDE0 OTUyOTYyMW1fNTgxNTM5ODQxOTA5NDg3NjgxbV8tOTE0MTg1Mjg1MDQ1NTUzOTUwMG1fMzgzMjMy OTY5NTMwOTk4NTgxNGdtYWlsLW1fMjgzNDc5NTczNjA1NTY2NTEwMGRpdlJwbHlGd2RNc2ciIGRp cj0ibHRyIj4NCjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIGNvbG9yPSIjMDAwMDAw IiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxiPkZyb206PC9iPiBPQXV0aCAmbHQ7PGEgaHJlZj0i bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQnJpYW4g Q2FtcGJlbGwgJmx0O2JjYW1wYmVsbD08YSBocmVmPSJtYWlsdG86NDBwaW5naWRlbnRpdHkuY29t QGRtYXJjLmlldGYub3JnIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj40MHBpbmdp ZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIERlY2VtYmVyIDI3LCAyMDE5IDExOjAzOjMwIEFNPGJyPg0KPGI+VG86PC9iPiBvYXV0aCAm bHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtF WFRFUk5BTF0gW09BVVRILVdHXSAtc2VjdXJpdHktdG9waWNzLTEzIGFuZCBPSURDIHJlc3BvbnNl IHR5cGVzICYjNDM7IGZvcm1fcG9zdCByZXNwb25zZSBtb2RlPC9mb250Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5XZSBoYXZlIGEtc29t ZXRpbWVzIHVzZWQgc2NlbmFyaW8gd2hlcmUgYSBjbGllbnQgbWFrZXMgYW4gYXV0aG9yaXphdGlv bi9hdXRoZW50aWNhdGlvbiByZXF1ZXN0IHdpdGggYSAmcXVvdDt0b2tlbiBpZF90b2tlbiZxdW90 OyByZXNwb25zZSB0eXBlIGFuZCAmcXVvdDtmb3JtX3Bvc3QmcXVvdDsgcmVzcG9uc2UgbW9kZSAo bm9uY2UgaXMgYWxzbyBzZW50IGFuZCBleGFjdCByZWRpcmVjdCBVUkkgbWF0Y2hpbmcgaXMgZG9u ZSBhdCB0aGUgQVMpLiBUaGUgYWNjZXNzIHRva2VuDQogaXMgbmV2ZXIgZXhwb3NlZCBpbiBhbnkg VVJMcyBhbmQgYWNjZXNzIHRva2VuIGluamVjdGlvbiBpcyBwcmV2ZW50ZWQgYnkgdGhlIGF0X2hh c2ggY2xhaW0gaW4gdGhlIGlkIHRva2VuLg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5UaGF0IHNlZW1zIHRvIG1lIGxpa2UgYSBsZWdpdGltYXRlIGFuZCByZWFzb25hYmxl IHVzYWdlIHNjZW5hcmlvLiBIb3dldmVyLCBpdCB3b3VsZCBmYWxsIG9uIHRoZSB3cm9uZyBzaWRl IG9mIHRoZSBTSE9VTEQgTk9UIGluDQo8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUy Rmh0bWwlMkZkcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMyUyM3NlY3Rpb24tMy4u LjEuLjImYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdD ZmMyOGQ1MTNiMDRmNDg5YjM3MWQwOGQ3OGI5YTk0ODglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTMxMzY4MzQyMDk2OTIzJmFtcDtzZGF0YT1tZm5Rd3NH VVpnejBQZ0Vab3FPbCUyQnNzelBZeG5jbUZiZ0JhSnM0cWV4MzglM0QmYW1wO3Jlc2VydmVkPTAi IG9yaWdpbmFsc3JjPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0 aC1zZWN1cml0eS10b3BpY3MtMTMjc2VjdGlvbi0zLi4uMS4uMiIgc2hhc2g9IkdjR2xJS0tjVk1i dE5mcTkmIzQzO3VnaGQ1c29nSWVwWEpNQ1N5TUpnUjlSZlRVYzRVSGFxciYjNDM7dEhSTkM4RG40 YmpncUR3UkdnYWZTeVZNL2Uwd2xoc0w5dGNmU0pSNnp3ZFlEbkFNaVNscXFDQ1UzakMwejNPc0JW WkxqWHgwY3NvTWpjOC9wVlFJZld3dW9oQWlBWnpkUFMxbGt0MHljTVo0dFh2TUpuSVdaRmRrPSIg cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpTZWN0aW9uIDMuMS4yIG9mIHRoZSBT ZWN1cml0eSBCQ1AtdG8tYmU8L2E+LCB3aGljaCBoYXM6PGJyPg0KPC9kaXY+DQo8YnI+DQo8ZGl2 PiZuYnNwOyZuYnNwOyBJbiBvcmRlciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIGNsaWVudHMgU0hP VUxEIE5PVCB1c2UgdGhlIGltcGxpY2l0PGJyPg0KJm5ic3A7ICZuYnNwO2dyYW50IChyZXNwb25z ZSB0eXBlICZxdW90O3Rva2VuJnF1b3Q7KSBvciBhbnkgb3RoZXIgcmVzcG9uc2UgdHlwZSBpc3N1 aW5nPGJyPg0KJm5ic3A7ICZuYnNwO2FjY2VzcyB0b2tlbnMgaW4gdGhlIGF1dGhvcml6YXRpb24g cmVzcG9uc2UsIHN1Y2ggYXMgJnF1b3Q7dG9rZW4gaWRfdG9rZW4mcXVvdDs8YnI+DQombmJzcDsg Jm5ic3A7YW5kICZxdW90O2NvZGUgdG9rZW4gaWRfdG9rZW4mcXVvdDssIHVubGVzcyB0aGUgaXNz dWVkIGFjY2VzcyB0b2tlbnMgYXJlPGJyPg0KJm5ic3A7ICZuYnNwO3NlbmRlci1jb25zdHJhaW5l ZCBhbmQgYWNjZXNzIHRva2VuIGluamVjdGlvbiBpbiB0aGUgYXV0aG9yaXphdGlvbjxicj4NCiZu YnNwOyAmbmJzcDtyZXNwb25zZSBpcyBwcmV2ZW50ZWQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5JIGtub3cgdGhpcyBwYXJ0aWN1bGFyIHRleHQgaGFzIGJlZW4gZGlzY3Vzc2VkIG92 ZXIgYW5kIG92ZXIgYWdhaW4gc28gSSBoYXRlIHRvIHJldmlzaXQgaXQuIEJ1dCBiYXNlZCBvbiB0 aGUgYWZvcmVtZW50aW9uZWQgc2NlbmFyaW8gSSB0aGluayBtYXliZSBpdCBzdGlsbCBkb2Vzbid0 IHF1aXRlIGhpdCB0aGUgbWFyay4gQWNjZXNzIHRva2VuIGluamVjdGlvbiBpcyBwcmV2ZW50ZWQu IFRoZSB0b2tlbiBsZWFrYWdlIHNjZW5hcmlvcyBtZW50aW9uZWQNCiBpbiB0aGF0IHNlY3Rpb24g YXJlIGFsbCBhdm9pZGVkLiBBbmQgd2hpbGUgSSBrbm93IHNlbmRlci1jb25zdHJhaW5lZCBpcyBy ZWNvbW1lbmRlZCBlbHNld2hlcmUgaW4gdGhlIGRyYWZ0LCBpdCdzIG5vdCByZWFsbHkgYSByZWFs aXN0aWMgb3B0aW9uIGZvciB0aGUgbWFqb3JpdHkgb2YgZGVwbG95bWVudHMuDQo8YnI+DQo8L2Rp dj4NCjwvZGl2Pg0KPGJyPg0KPGkgc3R5bGU9Im1hcmdpbjowcHg7IHBhZGRpbmc6MHB4OyBib3Jk ZXI6MHB4IG5vbmU7IG91dGxpbmU6Y3VycmVudGNvbG9yIG5vbmUgMHB4OyB2ZXJ0aWNhbC1hbGln bjpiYXNlbGluZTsgYmFja2dyb3VuZDpyZ2IoMjU1LDI1NSwyNTUpIG5vbmUgcmVwZWF0IHNjcm9s bCAwJSAwJTsgY29sb3I6cmdiKDg1LDg1LDg1KSI+PHNwYW4gc3R5bGU9Im1hcmdpbjowcHg7IHBh ZGRpbmc6MHB4OyBib3JkZXI6MHB4IG5vbmU7IG91dGxpbmU6Y3VycmVudGNvbG9yIG5vbmUgMHB4 OyB2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTsgYmFja2dyb3VuZDp0cmFuc3BhcmVudCBub25lIHJl cGVhdCBzY3JvbGwgMCUgMCU7IGZvbnQtd2VpZ2h0OjYwMCI+PGZvbnQgc2l6ZT0iMiI+Q09ORklE RU5USUFMSVRZDQogTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBh bmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUg Ynkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkNCiB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkg ZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L2ZvbnQ+PC9z cGFuPjwvaT48L2Rpdj4NCjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuPk9BdXRoIG1haWxpbmcgbGlzdDwvc3Bhbj48 YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHJlbD0ibm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48 YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZvYXV0 aCZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0NmYzI4 ZDUxM2IwNGY0ODliMzcxZDA4ZDc4YjlhOTQ4OCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdDMSU3QzAlN0M2MzcxMzEzNjgzNDIxMDY4OTEmYW1wO3NkYXRhPXFPNiUyQlklMkZN b2VmMGx5eDRId05MVjhJRDVEZ3VBZTNYakNReXh0dm9GclBvJTNEJmFtcDtyZXNlcnZlZD0wIiBv cmlnaW5hbHNyYz0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg c2hhc2g9Ik5UbXZhTUt1SzJhdGZkbENoUFkmIzQzO0ptUlhnZWVTaDFIQ3RndmVLSUpNWHVYbm5N T3hjaUcxJiM0Mzt1OVMwL1p4SjhxbFJQTjFlQ1hPdGl1a0RQd01uWG1sU1J2YUhOdmlKRFVYQjFN UCYjNDM7VGFrcXImIzQzO21KN2h4eEtTQlBEU1NxN3dCL01Hd1Q4MDNtaUpPb3dPUzlqVUdjSUdp cyYjNDM7bVE2cXUxS2J1a0c3d1ZSdzMxQkRnPSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3Nw YW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8YnI+DQo8aSBzdHlsZT0ibWFyZ2luOjBweDsgcGFkZGluZzowcHg7IGJv cmRlcjowcHggbm9uZTsgb3V0bGluZTpjdXJyZW50Y29sb3Igbm9uZSAwcHg7IHZlcnRpY2FsLWFs aWduOmJhc2VsaW5lOyBiYWNrZ3JvdW5kOnJnYigyNTUsMjU1LDI1NSkgbm9uZSByZXBlYXQgc2Ny b2xsIDAlIDAlOyBjb2xvcjpyZ2IoODUsODUsODUpIj48c3BhbiBzdHlsZT0ibWFyZ2luOjBweDsg cGFkZGluZzowcHg7IGJvcmRlcjowcHggbm9uZTsgb3V0bGluZTpjdXJyZW50Y29sb3Igbm9uZSAw cHg7IHZlcnRpY2FsLWFsaWduOmJhc2VsaW5lOyBiYWNrZ3JvdW5kOnRyYW5zcGFyZW50IG5vbmUg cmVwZWF0IHNjcm9sbCAwJSAwJTsgZm9udC13ZWlnaHQ6NjAwIj48Zm9udCBzaXplPSIyIj5DT05G SURFTlRJQUxJVFkNCiBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVk IHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3Vy ZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeQ0KIHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFu eSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91LjwvZm9udD48 L3NwYW4+PC9pPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8aSBzdHlsZT0ibWFyZ2luOjBweDsgcGFkZGlu ZzowcHg7IGJvcmRlcjowcHg7IG91dGxpbmU6MHB4OyB2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTsg YmFja2dyb3VuZDpyZ2IoMjU1LDI1NSwyNTUpOyBjb2xvcjpyZ2IoODUsODUsODUpIj48c3BhbiBz dHlsZT0ibWFyZ2luOjBweDsgcGFkZGluZzowcHg7IGJvcmRlcjowcHg7IG91dGxpbmU6MHB4OyB2 ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTsgYmFja2dyb3VuZDp0cmFuc3BhcmVudDsgZm9udC13ZWln aHQ6NjAwIj48Zm9udCBzaXplPSIyIj5DT05GSURFTlRJQUxJVFkNCiBOT1RJQ0U6IFRoaXMgZW1h aWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0 aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNl LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5DQogdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5k IGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNv bXB1dGVyLiBUaGFuayB5b3UuPC9mb250Pjwvc3Bhbj48L2k+PC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_BL0PR00MB0836155876E1356943AA669AF5250BL0PR00MB0836namp_-- From nobody Sun Dec 29 10:14:49 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DA112008D for ; Sun, 29 Dec 2019 10:14:47 -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 Nk2l9MP9gtP5 for ; Sun, 29 Dec 2019 10:14:44 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A6012006E for ; Sun, 29 Dec 2019 10:14:44 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id v69so26259891ili.10 for ; Sun, 29 Dec 2019 10:14:44 -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=q7u+nXvgijtDa8qr+J0zg9g6IoRXHql73Yf7uqwX2SM=; b=THW/54e4YgPWFeBf+AfHP1S/Vk2wHUbPi7BnER/HkSbeBSSt5yD0rSORlv1MrF7SV0 TXHKPKF5xhHNDJr8WvRbAfzpJtd9nqXzK53KP6xlSJRtRQfoOMHBoEU3R4ENelkE6VjE tG6ZKY/IK7QYIG24Ej6nyxpo1Zwdl0HfzXDlGWgzc4zQWH35HnUiqkT3aUdriTQYYJ/w EFSVILTNPaAy1a+pEXLuEloMhjaVKH3zDqMXNJ0EXxSYCZPteg9naA2TQt9tcKq56czW Q+DYuNiZ6Zi+uvbE3f+SH/IrRponDtBbWBGjaF9r3zFEANv/W2PCCKo3xXSSTmteMCus x3Ig== 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=q7u+nXvgijtDa8qr+J0zg9g6IoRXHql73Yf7uqwX2SM=; b=kNpX3MPJWq3Sa41M+jrG+q3ula8mx+0po43zsDb0eAm8QYTxc7Se5M6wPGnztRJK6f /F5C0tQ98pBnyebcqcdFFa08EUv0Zh2n9ZXdFm3IGiaUMVFD9kpdjtTV2f4mZZlvcXIS 9l64OmgndPqN3oaeYocOrE1QlhvbtfV/4HfIFWBaDS35Ojn28+G1UYD/otJpTxYovMv0 M+bbYsNyfAu0GWZrQcb5dUYvf0fbB1h52pgPiGOyOxjqBGsyavOYXW4DmU1y5i1y9KdP b2e3jZd0VifqRuHptYZoRPs4p2shLpbOWrxlUqZig0CROBUvisNOHxrm9y8eQsHwFaJF qkLg== X-Gm-Message-State: APjAAAWucF8WIc3W3SXioeMB0rlXuweqMdn5RxNMrvAQPD4VStLaw/ko ajnh4U2HWu4ZKgLK+1hF5f1q/WJh64v6FSPV4B4= X-Google-Smtp-Source: APXvYqyX1TMOkbR4NFu1tzy8lCUZiVNc1+32JQVgO9Q32EnmNBe+zV7wmqB3BS2v/cctWjw6md/vLS/uDd6deanSYqk= X-Received: by 2002:a92:3984:: with SMTP id h4mr51147408ilf.36.1577643284124; Sun, 29 Dec 2019 10:14:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Sun, 29 Dec 2019 13:14:32 -0500 Message-ID: To: Justin Richer Cc: oauth Content-Type: multipart/alternative; boundary="000000000000885843059adbb31d" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2019 18:14:47 -0000 --000000000000885843059adbb31d Content-Type: text/plain; charset="UTF-8" All, There is a clear support for this document by the WG. Torsten, Please, go ahead and publish a WG version. Regards, Rifaat & Hannes On Wed, Dec 18, 2019 at 4:24 PM Justin Richer wrote: > I support adoption of PAR and have already implemented the draft > specification. > > - Justin > > On Dec 17, 2019, at 7:59 AM, Rifaat Shekh-Yusef > wrote: > > All, > > This is a call for adoption of for the OAuth 2.0 Pushed Authorization > Requests document. > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ > > There was a good support for this document during the Singapore meeting, > and on the mailing list in the Meeting Minutes thread. > > Please, let us know if you support or object to adopting this document as > a working group document by Dec 27th. > > If you have already indicated your support on the Meeting Minutes thread, > you do not need to do it again on this thread. > > Regards, > Rifaat & Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --000000000000885843059adbb31d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

There is a clear support for= this document by the WG.


Torsten,
<= div>
Please, go ahead and publish a WG version.
Regards,
=C2=A0Rifaat & Hannes

=

On Wed, Dec 18, 2019 at 4:24 PM Justin Richer <jricher@mit.edu> wrote:
= I support adoption of PAR and have already implemented the draft specificat= ion.

=C2=A0- Justin

On Dec 17, 2019, at 7:59 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wr= ote:

All,

This is a call = for adoption of for the=C2=A0OAuth 2.0 Pushed Authorization Requests docume= nt.

There was a good suppo= rt for this document during the Singapore meeting, and on the mailing list = in the Meeting Minutes thread.

Please, let us know= if you support or object to adopting this document as a working group docu= ment by Dec 27th.

If you have already indicated yo= ur support on the Meeting Minutes thread, you do not need to do it again on= this thread.

Regards,
=C2=A0Rifaat &= ; Hannes


=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
--000000000000885843059adbb31d-- From nobody Mon Dec 30 08:57:43 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221FE120AF3 for ; Mon, 30 Dec 2019 08:57:41 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=7YBlk+jj; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=TBsxEfYA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T02h00Qbs99C for ; Mon, 30 Dec 2019 08:57:37 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30058.outbound.protection.outlook.com [40.107.3.58]) (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 6D5BD120AEC for ; Mon, 30 Dec 2019 08:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lKKFFfmEV3XZLCALC3pFDLzyCnPErjDA0OpW/f9IuCU=; b=7YBlk+jjnLw/FYKEgFBTxrQnM+noBbgyQUIdst6e93rTMyfI1Jxvb9SaAU7g4Nvh0ULuLG/3WIj9B2O8tUj3Uht9TBubi6sOEOzAtJfxFNDSPL2njsJ+aMuUJWzBeORbw5kToyibgo1dUWNoWlyPJIL+VQBLA2ddNM0Gigrk6Dk= Received: from VI1PR08CA0180.eurprd08.prod.outlook.com (2603:10a6:800:d1::34) by DB6PR0802MB2134.eurprd08.prod.outlook.com (2603:10a6:4:83::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Mon, 30 Dec 2019 16:57:34 +0000 Received: from AM5EUR03FT043.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::201) by VI1PR08CA0180.outlook.office365.com (2603:10a6:800:d1::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.12 via Frontend Transport; Mon, 30 Dec 2019 16:57:34 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT043.mail.protection.outlook.com (10.152.17.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11 via Frontend Transport; Mon, 30 Dec 2019 16:57:34 +0000 Received: ("Tessian outbound ba41a0333779:v40"); Mon, 30 Dec 2019 16:57:34 +0000 X-CR-MTA-TID: 64aa7808 Received: from c89379670002.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 4FC4461B-4E4B-4C55-BA72-A8B68E3FFBE2.1; Mon, 30 Dec 2019 16:57:29 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c89379670002.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 30 Dec 2019 16:57:29 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LE0z3HT0uIXdqE5ihK391y1THbGEc6Hed8CjZORVgBpbuNYKyRfN+kx6AA+i5vqlXn9nCSwhBrpuC066mQKw5rTZNdP17kp1p84G/pRIvgfv+dlyrCjhjVAj5MUsr8XKHP3O6nsq3qbQccqKyub9LZwNIU7b5wXr2lpXQt2ntbWV1mlPf7WtKgzXxyUv5Oc9uHW5Cs0WeJAKCnYSnnEXmPsQ1w5ia/axzqXFqlLASYYIjHPQPeZ6VtPqDtqrthuOkw/gTS/tY9dbnXYc1JYLux5pXCsrI5tkyXvwVPNPfSCZpCFktSXSOP5bXMmZDHtN6iKIxaF5VZTaoLWHWnq1Rg== 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=QaPNIjnaFmb5sCoMSdXNYDiugFHAQpYWAnD+Cwqu0Ek=; b=dZY9KTirJ5efmrQUzR6EL4OwmMgMScq4qasftWrWP1siL+/QXkYmquWzrlUQUlszdnbaIeyF3Dmgyxur5njhN0fnaSn3UD6HGiwADnrIJDV0GgI+6X6aaboLr2zn+ZkDa9clIjd3q+ewJ8YizGj7GSoxsTfV5WY+KATTdVEq7dVXPMogJO6K4Y3pYzzEICxxVmsBUnnZ2e9GWxKujVH7QPcOpvGOKWR1HMpyao043YEDCjCp2f1HSANCXCOg/TJ15pmgVCKmqwivenFDUFBL5PB1/PIDm2fba32Ux3X7kP8LxLlSUXbuICcSNEkShVSxyNcT56XXRxCjaWvDoasaCw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QaPNIjnaFmb5sCoMSdXNYDiugFHAQpYWAnD+Cwqu0Ek=; b=TBsxEfYA/EI4IrEpGjV7OwYiMnoI/u7niqq/6SgBNP7N5rv1HmsNbW68DS7YvwqBeK0L/JjzxunsIC+0t6udD2DSBPs5GUvexJ4w5XLLpTYHJ1fBQheimAtKFx2P04oZiNDgkgY9bDzjrP6ZmJA2RYnAAFheM8KJ7v6obEMwv2s= Received: from AM6PR08MB5285.eurprd08.prod.outlook.com (20.179.0.161) by AM6PR08MB2965.eurprd08.prod.outlook.com (52.135.165.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Mon, 30 Dec 2019 16:57:26 +0000 Received: from AM6PR08MB5285.eurprd08.prod.outlook.com ([fe80::1581:c3da:22ee:41b9]) by AM6PR08MB5285.eurprd08.prod.outlook.com ([fe80::1581:c3da:22ee:41b9%7]) with mapi id 15.20.2581.007; Mon, 30 Dec 2019 16:57:26 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" Thread-Topic: No OAuth Call Today Thread-Index: AdW/Mgm1xGsYaawwQ8WlFnle4p5vJQ== Date: Mon, 30 Dec 2019 16:57:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 23428471-eb30-4eab-b635-974cc7a4928f.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [195.149.223.43] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 694a5928-722f-4f9a-2858-08d78d495dcc X-MS-TrafficTypeDiagnostic: AM6PR08MB2965:|DB6PR0802MB2134: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:813;OLM:813; x-forefront-prvs: 0267E514F9 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(366004)(39860400002)(396003)(189003)(199004)(3480700006)(558084003)(52536014)(6506007)(33656002)(64756008)(66556008)(66446008)(66946007)(66476007)(26005)(186003)(7696005)(6916009)(8936002)(8676002)(478600001)(81166006)(81156014)(71200400001)(86362001)(5660300002)(76116006)(316002)(2906002)(9686003)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB2965; H:AM6PR08MB5285.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: doepLvFL0vcF4/OALn513T26Bae0SU9VtYZgXeEKZXxQ7L/ZtRfGhmLNtS3Tcv2Eul4WQKnM5RqKE2W0U88EVAv0/qh6VU51FUd3JqIEF634Z2DmV+xvuPgr6gC7nivPpwZg50dxKZplAgfG0mQx0q/KJJjajnl3gUZBdYgzUfOYanUaJuxb8cffvf2SlmioloOwmMkko8gbNRJgoflZbyCQXFKbFbz4gQ3m0egukWZk6Cs48GLvh7y0VponcL5kfkqKQaV6Qo7DtIS5Bi0WLD6vhdumrwYPvbifxFHZze9GJMFlHqWjeMqmLPcff3OAaLxgUHYg4nxGScYeLISqAUg9rA/FuV+vffhbFIRHrGnU9I/LmWhihzA8hIKIWr8PHXwkKlb1aZjh4r8Z5jYAxsM1MOnZ2IMgXopUoQDW1KlDCn508YIvTlaqnvxsB5Cw x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB5285BE776D091262CBD09C72FA270AM6PR08MB5285eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB2965 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT043.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(376002)(136003)(346002)(199004)(189003)(40434004)(8936002)(3480700006)(55016002)(2906002)(7696005)(76130400001)(70586007)(5660300002)(70206006)(33656002)(336012)(26826003)(8676002)(9686003)(186003)(81156014)(81166006)(478600001)(26005)(86362001)(6506007)(36906005)(356004)(6916009)(52536014)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0802MB2134; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 36b74bfc-5362-4450-8bdc-08d78d49595b X-Forefront-PRVS: 0267E514F9 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: t+SpdNy0y8Lk5iClvGE+os6nLB8ClWC7sQJp1NO/bVkPyh97z8J9QblU5lfOwZD/HeowsKFR8O6EzQ7ymyDC4NV52Cr7MljfZ6ulEvtOvQdlNLkOCjGPfzdiz0KiQ0KQxUyECMHRSreIvcsGZpHlyOckDzLr4kHkz0sXsBe4S6eizYYDnXceG9j4/rSq+4kOWpq89krwYmQmIShUfcLWyaqOwzRORCFcMg2pH+hosPduNWZH//uvTygydnDEUett+NXh/KNWtRYzv4XhY7rP6+t56+iG1M2bfNKctwhv7I/1o4tFN0Dq6HSp9pwe5htfsyOE5gIUTgb0RwG5vSa072CvFqlUmJNVRWGdna69sPHeGRrvjvJYdAgIQKroH8Atsh6WgL6xlpoSqXZnd3/eGnIRCc98ITMUjpw/NwYJPg5NjYpcy8RCsCMUFpkuc4c6e0fP4yExienR6mxGmZEAlYBpzIzket0WSOO70ZGZXjqcuN1EvyLl0HJlcbyq/khD X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Dec 2019 16:57:34.1353 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 694a5928-722f-4f9a-2858-08d78d495dcc X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2134 Archived-At: Subject: [OAUTH-WG] No OAuth Call Today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2019 16:57:41 -0000 --_000_AM6PR08MB5285BE776D091262CBD09C72FA270AM6PR08MB5285eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Due to vacation there is no OAuth call today. We wish you a Happy New Year! Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM6PR08MB5285BE776D091262CBD09C72FA270AM6PR08MB5285eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Due to vacation there is no OAuth call today.

 

We wish you a Happy New Year!

 

Ciao
Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM6PR08MB5285BE776D091262CBD09C72FA270AM6PR08MB5285eurp_-- From nobody Mon Dec 30 09:30:42 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679D2120B43 for ; Mon, 30 Dec 2019 09:30:40 -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 sKIqW5QeyfSh for ; Mon, 30 Dec 2019 09:30:39 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF7E120B42 for ; Mon, 30 Dec 2019 09:30:38 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id d16so33294179wre.10 for ; Mon, 30 Dec 2019 09:30:38 -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=UOkRiQzVgs5DtzVl8wXHk3a48BLYy9izYpHssevsELI=; b=5AmjoaTlNV412muHwk8Bm6hN42GKd4d8Tv5D15058Ov94JrUhmdqYV0hBtnjo4pcuy r9unVr5vMQgLNd2wXr2Rv/+Qb4H3TZ0hFK4WtVxiZBK+fSwSraj2+EFP5500iHcvCc4l LBRu2Ii0HAdyFWc+F0UOAizUZX0JCvkulZF26ZLj18ghXucmN9+vSuQ9vSLUG/QdEv3v +Jbm/UKa7ysaqNk2omlV1cTYnC00mmfAYaEjUqVs+VRB0QVbd6GeIAklJ9dq2npeegG9 3Z2PCzzzHs8v9oPrfXkxqd4vG2FiGJF81ssiENGhv06ePhi5qey2dM7Fhds2NOAJd9y+ XRSg== 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=UOkRiQzVgs5DtzVl8wXHk3a48BLYy9izYpHssevsELI=; b=nRIFc/NKwYDkUuvKUC5CeVZ5tHoO3SH5K3rNCPotePA3Zz+DcAciyoseopelSUPX+1 hKhSnJ8zU87RWjAAVAD/T+m2nT+Kqk/RNdBR1Veaz/6capDRUpwuNvqEl9jLizryhJ1k acWRd43dQrZeXORzSukVHm58fSXZj/4oRqNGh8UILSUajkIsa1Vibn93wTalnEwNm929 YUoFygbPmuIdEc4z/V5DIj0T8+DW7NGSiGJCF7BJsXN/gHIu3puUZylYPHK9tGR3lUUL 5hBeJVB7q5Q04S2AhL4GzaAtsFM8EzERJMvhmRjXQKxpXLRsot0KWM4TzueSJEYFsqLN 3Buw== X-Gm-Message-State: APjAAAVQROYeIFVMKWAKncucHPEMIkrR67S/EROQKp04/peoNvKNc9Zn EEQMWCHtcDmLoDakDmnQJhqj2A== X-Google-Smtp-Source: APXvYqxJrSW6Kt+RrYlGm+XswMqXggNvmFaYu9L3J+tvecPdDfGxGyOcD30vZWm0nF8bCJEyIZkElQ== X-Received: by 2002:adf:81e3:: with SMTP id 90mr67345435wra.23.1577727037141; Mon, 30 Dec 2019 09:30:37 -0800 (PST) Received: from p200300eb8f1a50b7b098efab20d3faea.dip0.t-ipconnect.de (p200300EB8F1A50B7B098EFAB20D3FAEA.dip0.t-ipconnect.de. [2003:eb:8f1a:50b7:b098:efab:20d3:faea]) by smtp.gmail.com with ESMTPSA id u24sm96882wml.10.2019.12.30.09.30.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Dec 2019 09:30:36 -0800 (PST) From: Torsten Lodderstedt Message-Id: <42BB0246-E87B-4573-847B-CAFC52CCBD25@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_34B09F80-3A4F-484F-BCA8-D62F22F6CACE"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Mon, 30 Dec 2019 18:30:04 +0100 In-Reply-To: Cc: oauth , Hannes Tschofenig To: Rifaat Shekh-Yusef References: X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2019 17:30:41 -0000 --Apple-Mail=_34B09F80-3A4F-484F-BCA8-D62F22F6CACE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Rifaat, thanks. The document was uploaded and is awaiting your approval. best regards, Torsten.=20 > On 29. Dec 2019, at 19:14, Rifaat Shekh-Yusef = wrote: >=20 > All, >=20 > There is a clear support for this document by the WG. >=20 >=20 > Torsten, >=20 > Please, go ahead and publish a WG version. >=20 > Regards, > Rifaat & Hannes >=20 >=20 > On Wed, Dec 18, 2019 at 4:24 PM Justin Richer wrote: > I support adoption of PAR and have already implemented the draft = specification. >=20 > - Justin >=20 >> On Dec 17, 2019, at 7:59 AM, Rifaat Shekh-Yusef = wrote: >>=20 >> All, >>=20 >> This is a call for adoption of for the OAuth 2.0 Pushed Authorization = Requests document. >> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/=20 >>=20 >> There was a good support for this document during the Singapore = meeting, and on the mailing list in the Meeting Minutes thread. >>=20 >> Please, let us know if you support or object to adopting this = document as a working group document by Dec 27th. >>=20 >> If you have already indicated your support on the Meeting Minutes = thread, you do not need to do it again on this thread. >>=20 >> Regards, >> Rifaat & Hannes >>=20 >>=20 >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_34B09F80-3A4F-484F-BCA8-D62F22F6CACE 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 Fw0xOTEyMzAxNzMwMDRaMC8GCSqGSIb3DQEJBDEiBCC+YGHXcfbwOs2j4nZf8BXR5TeKsS0erq1O cCRT8TZdEDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAGW7eVZtQIILUXuZDygF2olkNmcd6hpVMeOfKUlK+nH1diKqG0a+2PnElVGY gaueceXlJSw9shOFBk637LocnCgZtXVvzXgIOyPV1mbdosUD9YDfLYRAULuXgR6cTWsv40Tk5MgQ pJ3xrl7gbNOjk8tjnZlGw3X1uJ5mIW/A0lksuIsae9K2GEzAEn3RIjw3kjEMcExVEPJxOEkWN1bN x7r/uCXevpxVLuP35q2F4nUt3aEWjA3nd12jkfgU5zLYpEWaR5WmR5VWPSmx0X+7HMUm950f17+P A26mUx1XN5uIdnoaliVUIvwpHZvqm39sB7telKcLC/bSdy9YclTrIUIAAAAAAAA= --Apple-Mail=_34B09F80-3A4F-484F-BCA8-D62F22F6CACE-- From nobody Mon Dec 30 09:38:15 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A35120B42; Mon, 30 Dec 2019 09:38:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <157772749376.4497.13603592973852722557@ietfa.amsl.com> Date: Mon, 30 Dec 2019 09:38:13 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2019 17:38:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Pushed Authorization Requests Authors : Torsten Lodderstedt Brian Campbell Nat Sakimura Dave Tonge Filip Skokan Filename : draft-ietf-oauth-par-00.txt Pages : 14 Date : 2019-12-30 Abstract: This document defines the pushed authorization request endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent authorization request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-par-00 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 31 06:39:03 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E707120123 for ; Tue, 31 Dec 2019 06:38:57 -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 hpWgtsse0eQ0 for ; Tue, 31 Dec 2019 06:38:55 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B2C120131 for ; Tue, 31 Dec 2019 06:38:55 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id q10so35321021wrm.11 for ; Tue, 31 Dec 2019 06:38:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:mime-version:subject:message-id:date:cc:to; bh=dSTHEIbc9ShlrTMIayPnR1odvEOgKUC01CfmNJYOo0Y=; b=itar9HUK2JKXwDkUxPcaaa3Dbyx3c/QC75yovdgW6x6T0dB1r8+uOzyi28jBSI+8q5 Igha6EBHffDx/n3VIMZOkdfZSt7kpTpy2zj5kSHVEhABgNEJLTAJxHT+8Gd/nca0Q5gr 9n+cPdtRBA9jC5/B6OHNvN476dlW5s4TbRNlgtewpOGCYaNOlFd+vi2a+R6bQu+9E74g xAyYp6SpR2QI2bSM3mPlRTRAdgr3ZP/BZKiDJe2ALsyueV5ptc5KeCEuDJIZbxydxLXT J/M3SiROaFt8OBnyiJBLqhacyRwvYAdZeeyAJfsPQzeqQnFTKykUcyuHzyspW/WNmwLU Bpvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=dSTHEIbc9ShlrTMIayPnR1odvEOgKUC01CfmNJYOo0Y=; b=KcRH/D4tLNxXE9f+tcb9ITppuHlug4rLtbfeQvxBs4FndvaXxAWAF8t0ruDBerbNew FXFqzHad/9sdkE1BgRkQGOLKtZO7AOmtdtRe2uRq4oquKY5XgeXqT8tu2xffNrtzAVpI bx+FCXhcRx3Ci2RsgDq4hnScKUzFtOdp8JpYpeQLJbkvFy02j3jyhP/01PbRrUBLYRET Qo7N4h81lru6zSI1QSz3GqXOIWlI8mNoAfKPhPyoJpn/yXu7rMJtEbhbxmtOjI/R3vKL SSSgD90+cZiMwR07fmmjx8DNB0wctpBLBz8ywwoM2mxRhCOVwH18l+JKhD8DzL0s1MS+ 3B5w== X-Gm-Message-State: APjAAAXQJ4k1leOHYw5neLcruumXT8CPoqVcf3GPGKaBb0Wd6u7txTi5 eRUsZi85xVqkL57YAgqS2TSPNZNf2aoo+w== X-Google-Smtp-Source: APXvYqzmGBT/WXr6vloEnvTK2UM6Xd6IBBfan/Gt51qBxa20qZaBKvZa7oDxwitHLDYxGwQliwf4GQ== X-Received: by 2002:adf:dfc1:: with SMTP id q1mr71810023wrn.155.1577803133634; Tue, 31 Dec 2019 06:38:53 -0800 (PST) Received: from p200300eb8f1a50e4853495bb51a8296f.dip0.t-ipconnect.de (p200300EB8F1A50E4853495BB51A8296F.dip0.t-ipconnect.de. [2003:eb:8f1a:50e4:8534:95bb:51a8:296f]) by smtp.gmail.com with ESMTPSA id 4sm2639590wmg.22.2019.12.31.06.38.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Dec 2019 06:38:52 -0800 (PST) From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_781C8E12-CDB6-4BDC-B277-76AEA867AEF1"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Message-Id: Date: Tue, 31 Dec 2019 15:38:21 +0100 To: oauth , Filip Skokan , Dave Tonge , Nat Sakimura , Brian Campbell X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: [OAUTH-WG] PAR metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 14:39:02 -0000 --Apple-Mail=_781C8E12-CDB6-4BDC-B277-76AEA867AEF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, Ronald just sent me an email asking whether we will define metadata for=20= pushed_authorization_endpoint_auth_methods_supported and pushed_authorization_endpoint_auth_signing_alg_values_supported. The draft right now utilises the existing token endpoint authentication = methods so there is basically no need to define another parameter. The = same principle could be applied to signing (and encryption) algorithms = as well.=20 What=E2=80=99s your opinion? best regards, Torsten.=20= --Apple-Mail=_781C8E12-CDB6-4BDC-B277-76AEA867AEF1 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 Fw0xOTEyMzExNDM4MjFaMC8GCSqGSIb3DQEJBDEiBCAPF2Pz+YoAMyV/7RWFoGzgJvWkgSvh6dnF WrL5/ciD5jCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAA07yLXVytzCrJL009Cv8OwdM1Kw5RseXYb6UrvT4dLGo3Vv57ldOgqQqZMj buWFCjtHB00i/cZxV74Nh5uisunt9OcCJgtLhXAFg5dGNEyQmHnZGM2wH+NzDkwcG5ya1x0DDlT+ uMtBWcFPfuZfSZ55/Cfj6y3xAnRpID7mTCHli5EEm5+EvtuDlkLW6pQ/An93JQqbgpki7ERgWooO b2vssvtbBdPQlWN75mDHq3DkvFe3fRCAMZ0/UkMDyyCuXSCMWPyewO8c6GyX9F0EolXG6uwOGgu5 GX09wFf4Gbv8/Gt7iQsagWXgYdGaeJaTJmEYlWTFAqk1nQ6DBXy3DjwAAAAAAAA= --Apple-Mail=_781C8E12-CDB6-4BDC-B277-76AEA867AEF1-- From nobody Tue Dec 31 07:22:40 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3022E12003E for ; Tue, 31 Dec 2019 07:22: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 eo4blVx17WHj for ; Tue, 31 Dec 2019 07:22:35 -0800 (PST) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0: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 D212D120013 for ; Tue, 31 Dec 2019 07:22:35 -0800 (PST) Received: by mail-oi1-x230.google.com with SMTP id 18so11178057oin.9 for ; Tue, 31 Dec 2019 07:22:35 -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=/Cma+CzNfACevxmZYe0UTSLsh8d84zJ/nWHrd1q7E9c=; b=t6pY8zu8mMkT0gYm5wI989sxru+8QjDzDzW8U+mDZZddMCy5fYpCkb4cJUk8iQKcsb yHD7Lhno8a6vFNafWfAnc0ZvEuHImq4SxZdzD9GBtIF74WYS/KVbHu/JRRv9fIB9QJE9 vwkUFMOd1m5R2JLIxCgvtuKwGOZqFkxlJEUUoUD0wSpYFBtR4rEdBHej6wpJugaRtbWb 0MCNGzB4TUxehTktbSypQUk/EM5c1DOrRICBaeD3ar6b1o0HMVDiGOUjTUEyWCDCREZQ CQNCrJHhYIL0h3oOQ5Rj+CDkrg+KWs3Y5gQphkxrykSpBMl5qmFjn7Evsn9Ze0NeB9lY dU+Q== 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=/Cma+CzNfACevxmZYe0UTSLsh8d84zJ/nWHrd1q7E9c=; b=jNA7p/Ba2/TkZ7OI+wm5yIAYOEkyxHcQxb1dvAy9a+TYytr19RAkcGSsORat86ryCo HFjXivkkaw1/NoPXtJh5mN1h0PpdDXp/w52Ec3MDIg8FiKDrgYV8zATE8l9pcpiKsH40 u1+IArK02XrN6egXROcguePLXY+DBO5UPDkOfF99OGbVc9gmqiivyoDIVRG3AzZhmBlg oivR6pLRC8utnMEj0e0SibJe1mSp4P/3apkow5YghbsgWYChOzk4wj2tro5HAsdZdm6l bkb+YUrLse2dNCcVexvL2Ge/bXGOSw8btTKG+PmUecMvMuiq4qBHPJ96KBQq4jcSLhGn twhQ== X-Gm-Message-State: APjAAAXNHDTdQT5/MVDCtf1eVymivpgobx3lVk6sFYRzO1wZ2yefSdoU cbpU7XgFozar/zBupXCsBQOBL9gxzobD9naeWw== X-Google-Smtp-Source: APXvYqywHtKL7yQZzNtsKYkaWHF07/xkXegpaysaTD03Y4JjUukbb5Qr7s0w2Ag72BbALGKlrnS6UJIctxqic9fYnzw= X-Received: by 2002:aca:ea46:: with SMTP id i67mr794515oih.149.1577805755023; Tue, 31 Dec 2019 07:22:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Tue, 31 Dec 2019 16:22:23 +0100 Message-ID: To: Torsten Lodderstedt Cc: oauth , Dave Tonge , Nat Sakimura , Brian Campbell , Roland Hedberg Content-Type: multipart/alternative; boundary="0000000000008d854a059b018794" Archived-At: Subject: Re: [OAUTH-WG] PAR metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 15:22:38 -0000 --0000000000008d854a059b018794 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think we need a *_auth_method_* metadata for every endpoint the client calls directly, none of the new specs defined these (e.g. device authorization endpoint or CIBA), meaning they also didn't follow the scheme from RFC 8414 where introspection and revocation got its own metadata. In most cases the unfortunately named `token_endpoint_auth_method` and its related metadata is what's used by clients for all direct calls anyway. The same principle could be applied to signing (and encryption) algorithms > as well. This I do not follow, auth methods and their signing is dealt with by using `token_endpoint_auth_methods_supported` and `token_endpoint_auth_signing_alg_values_supported` - there's no encryption for the `_jwt` client auth methods. Unless it was meant to address the Request Object signing and encryption metadata, which is defined and IANA registered by OIDC. PAR only references JAR section 6.1 and 6.2 for decryption/signature validation and these do not mention the metadata (e.g. request_object_signing_alg) anymore since draft 07. PS: I also found this comment related to the same question about auth metadata but for CIBA. Best, *Filip* On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt wrote: > Hi all, > > Ronald just sent me an email asking whether we will define metadata for > > pushed_authorization_endpoint_auth_methods_supported and > pushed_authorization_endpoint_auth_signing_alg_values_supported. > > The draft right now utilises the existing token endpoint authentication > methods so there is basically no need to define another parameter. The sa= me > principle could be applied to signing (and encryption) algorithms as well= . > > What=E2=80=99s your opinion? > > best regards, > Torsten. --0000000000008d854a059b018794 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think we need a *_auth_method_* metadata = for every endpoint the client calls directly, none of the new specs defined= these (e.g. device authorization endpoint or CIBA), meaning they also didn= 't follow the scheme from=C2=A0RFC 8414 where introspection and revocat= ion got its own metadata. In most cases the unfortunately named `token_endp= oint_auth_method` and its related metadata is what's used by clients fo= r all direct calls anyway.

The same principle could be applied to signing (and e= ncryption) algorithms as well.

This I do no= t follow, auth methods and their signing is dealt with by using `token_endp= oint_auth_methods_supported` and `token_endpoint_auth_signing_alg_values_su= pported` - there's no encryption for the `_jwt` client auth methods.=C2= =A0
Unless it was meant to address the Request Object signing and= encryption metadata, which is defined and IANA=C2=A0registered=C2=A0by OIDC. PAR only references JAR section 6.1 = and 6.2 for decryption/signature validation and these do not mention the me= tadata (e.g. request_object_signing_alg) anymore since draft 07.
=
PS: I also found this comment=C2=A0related to the same = question about auth metadata but for CIBA.

B= est,
Filip


On Tue, 31 Dec 2019 at 15:38, Torsten L= odderstedt <torsten@lodderste= dt.net> wrote:
Hi all,

Ronald just sent me an email asking whether we will define metadata for
pushed_authorization_endpoint_auth_methods_supported and
pushed_authorization_endpoint_auth_signing_alg_values_supported.

The draft right now utilises the existing token endpoint authentication met= hods so there is basically no need to define another parameter. The same pr= inciple could be applied to signing (and encryption) algorithms as well.
What=E2=80=99s your opinion?

best regards,
Torsten.
--0000000000008d854a059b018794-- From nobody Tue Dec 31 07:56:24 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1828E1200E6 for ; Tue, 31 Dec 2019 07:56:23 -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, 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=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 rzsU26HUH-R3 for ; Tue, 31 Dec 2019 07:56:20 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A951200DE for ; Tue, 31 Dec 2019 07:56:20 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id y1so27226314lfb.6 for ; Tue, 31 Dec 2019 07:56:19 -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=Hv6ZXbjkpKY12XUqJTMqnHj4UaVYQ8t9+3vOCZSRdjg=; b=X2mlTaSvcO7E4zDF5f81ivoL1OwR6PW5DHObqo4mQVEXZDnkdPGnOH9+gQW7lW9+7p d2jymnx+TB1tzTUz45M571Oc7WxcCLL/lWub06P0GpszdPQDMARppERoW/3j5H7ihC0J O6dBXILVQ3emfzDn/Af58lKMh+HnTVncpkG7ZiZaEjzx3/72ZF7EHXUaRJr+6PjgenO0 Z+4ufrAqpsbQ7mwLPtNMw16y5uPfmQkamtEPJalWYL+GXtXIhjChZK5j1woIu1utFgDn folDTCkPSKVGVmFb1cKG4rb/6r/aJDt9r9BvJMTX6xs72MU3w3RDD4OAOR0d6F7dG7Hz Imcg== 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=Hv6ZXbjkpKY12XUqJTMqnHj4UaVYQ8t9+3vOCZSRdjg=; b=rKgnK+LXQkoJkDjrB1MNmWjI65thcxFkAhtiUTOCfspj+wkBtavfxZjGKZn4GzAknB czwHose0VU14Pc29dQZDETY/ow1/rmOhIXuY1corpgsI68kUusu3z4niPS4knDcINgqL 06E+pH6gmMs3QHxdyedwXaQXaAwW1DSZzrjx0kEnoXfOKIeoAbALQFCa4ZxrIzDZux8C f6R3OOxqaX8SYR0es1NPyZ33MaUDhdWjoNTlYLxRfoTxVqDNX+cQQV2EOZjeQQsM3amP a+a8RSorrCOz3LbZx5aeA9fJb+a5zIFhVa5MfxwzDXEKl+N9Pb1gj7wshOur23EdSAm6 dFZQ== X-Gm-Message-State: APjAAAVXnqlT/6mFZ+PS2/Z0EkbycstFb4WBnHf2mZF3enYlaJeSNtdB 5pBTePVHO32zItSeAUkcUPLknHrucG5SoefruYXpxbzAeq2U+VON8WsaKzAct+K+1rnhx3kE116 6nweHDCjJKvg7tg== X-Google-Smtp-Source: APXvYqxNWPBV3M+FvmFJ7pWaq+wXR0mlewsTvD8c56e+hPxq46FrvLCtn3Bkv8J+5S/RgtqopJiZNbCKbVvD9CuBCAU= X-Received: by 2002:a19:5057:: with SMTP id z23mr41031108lfj.132.1577807778215; Tue, 31 Dec 2019 07:56:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Tue, 31 Dec 2019 08:55:51 -0700 Message-ID: To: Filip Skokan Cc: Torsten Lodderstedt , oauth , Dave Tonge , Nat Sakimura , Roland Hedberg Content-Type: multipart/alternative; boundary="000000000000251a35059b0200a9" Archived-At: Subject: Re: [OAUTH-WG] PAR metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 15:56:23 -0000 --000000000000251a35059b0200a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, I agree. The insights in that comment Filip referenced (copied below) are very very wise and explain why we should not define pushed_authorization_endpoint_auth_methods_supported and pushed_authorization_endpoint_auth_signing_alg_values_supported metadata. There's some historical weirdness to how client authentication has come to be represented (and named) in metadata. Client registration metadata has only a token_endpoint_auth_method, which despite the name has become the de facto place in the client data model to say how the client will authenticate to the AS when making any direct client -> AS call. The parameter name is a bit unfortunate but I believe it makes sense to have a single (backchannel) authentication method per client. RFC 8414 took a different direction and has revocation_endpoint_auth_methods_supported and introspection_endpoint_auth_methods_supported etc., which I believe was a mistake. I don't see a clear use case for needing or allowing a different set of auth methods for the different endpoints. And having a bunch of _supported parameters for different endpoints seems likely to clutter up the metadata document with a bunch of redundant info. I'd propose that some text be added into CIBA core that says that, for the backchannel authentication endpoint, the AS supports the same client authentication methods as indicated with token_endpoint_auth_methods_supported. And state that, for a client, the token_endpoint_auth_method is the authentication method registered for its client_id regardless of the endpoint being called. On Tue, Dec 31, 2019 at 8:22 AM Filip Skokan wrote: > I don't think we need a *_auth_method_* metadata for every endpoint the > client calls directly, none of the new specs defined these (e.g. device > authorization endpoint or CIBA), meaning they also didn't follow the sche= me > from RFC 8414 where introspection and revocation got its own metadata. In > most cases the unfortunately named `token_endpoint_auth_method` and its > related metadata is what's used by clients for all direct calls anyway. > > The same principle could be applied to signing (and encryption) algorithm= s >> as well. > > > This I do not follow, auth methods and their signing is dealt with by > using `token_endpoint_auth_methods_supported` and > `token_endpoint_auth_signing_alg_values_supported` - there's no encryptio= n > for the `_jwt` client auth methods. > Unless it was meant to address the Request Object signing and encryption > metadata, which is defined and IANA registered > by > OIDC. PAR only references JAR section 6.1 and 6.2 for decryption/signatur= e > validation and these do not mention the metadata (e.g. > request_object_signing_alg) anymore since draft 07. > > PS: I also found this comment > related > to the same question about auth metadata but for CIBA. > > Best, > *Filip* > > > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt > wrote: > >> Hi all, >> >> Ronald just sent me an email asking whether we will define metadata for >> >> pushed_authorization_endpoint_auth_methods_supported and >> pushed_authorization_endpoint_auth_signing_alg_values_supported. >> >> The draft right now utilises the existing token endpoint authentication >> methods so there is basically no need to define another parameter. The s= ame >> principle could be applied to signing (and encryption) algorithms as wel= l. >> >> What=E2=80=99s your opinion? >> >> best regards, >> Torsten. > > --=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._ --000000000000251a35059b0200a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, I agree. The insights in that comment Filip ref= erenced (copied below) are very very wise and explain why we should not def= ine pushed_authorization_endpoint_auth_methods_supported and
pushed_authorization_endpoint_auth_signing_alg_values_supported metadata. <= br>


There's some historical weirdness to how client authentication has co= me to be represented (and named) in metadata. Client registration metadata = has only a token_endpoint_auth_method, which despite the name has become th= e de facto place in the client data model to say how the client will authen= ticate to the AS when making any direct client -> AS call. The parameter= name is a bit unfortunate but I believe it makes sense to have a single (b= ackchannel) authentication method per client. RFC 8414 took a different dir= ection and has revocation_endpoint_auth_methods_supported and introspection= _endpoint_auth_methods_supported etc., which I believe was a mistake. I don= 't see a clear use case for needing or allowing a different set of auth= methods for the different endpoints. And having a bunch of _supported para= meters for different endpoints seems likely to clutter up the metadata docu= ment with a bunch of redundant info.

I'd propose that some text = be added into CIBA core that says that, for the backchannel authentication = endpoint, the AS supports the same client authentication methods as indicat= ed with token_endpoint_auth_methods_supported. And state that, for a client= , the token_endpoint_auth_method is the authentication method registered fo= r its client_id regardless of the endpoint being called.


On Tue, Dec 31, 2019 at 8:22 AM Filip Skokan <panva.ip@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">
I do= n't think we need a *_auth_method_* metadata for every endpoint the cli= ent calls directly, none of the new specs defined these (e.g. device author= ization endpoint or CIBA), meaning they also didn't follow the scheme f= rom=C2=A0RFC 8414 where introspection and revocation got its own metadata. = In most cases the unfortunately named `token_endpoint_auth_method` and its = related metadata is what's used by clients for all direct calls anyway.=

The = same principle could be applied to signing (and encryption) algorithms as w= ell.

This I do not follow, auth methods and= their signing is dealt with by using `token_endpoint_auth_methods_supporte= d` and `token_endpoint_auth_signing_alg_values_supported` - there's no = encryption for the `_jwt` client auth methods.=C2=A0
Unless it wa= s meant to address the Request Object signing and encryption metadata, whic= h is defined and IANA=C2=A0registered=C2=A0by OIDC. PAR only references JAR section 6.1 and 6.2 = for decryption/signature validation and these do not mention the metadata (= e.g. request_object_signing_alg) anymore since draft 07.

PS: I also found this comment=C2=A0related to= the same question about auth metadata but for CIBA.

Best,
Filip


On Tue, 31 Dec = 2019 at 15:38, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

Ronald just sent me an email asking whether we will define metadata for
pushed_authorization_endpoint_auth_methods_supported and
pushed_authorization_endpoint_auth_signing_alg_values_supported.

The draft right now utilises the existing token endpoint authentication met= hods so there is basically no need to define another parameter. The same pr= inciple could be applied to signing (and encryption) algorithms as well.
What=E2=80=99s your opinion?

best regards,
Torsten.

<= 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. --000000000000251a35059b0200a9-- From nobody Tue Dec 31 08:06:44 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC81120043 for ; Tue, 31 Dec 2019 08:06:42 -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 bo8MpdB_1UiP for ; Tue, 31 Dec 2019 08:06:41 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33AE0120013 for ; Tue, 31 Dec 2019 08:06:41 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id t2so35509976wrr.1 for ; Tue, 31 Dec 2019 08:06:41 -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=qYJvoGst3tJpXkyK76xWrIh3h7PntVWfswhUsoaI6Zk=; b=LUet9W0CSTyzweWtgXen95iI/Z3i+ZErSRvcwZsF5sJP1ijIFJoJLo8A4CXG2L129Q bBoFiC9LNFjPVvD8+IGr0atnSIKDaRMaAt5wwR9qsDWkxQOxEI5WO/ZIvhEXJSxNh8XG oOvhoEidn5v3faKLeVA4j68UEYfhER3oWQ0pp8ZZ7GxJ4ntMxwr5TA+SlHVkou9XwreE fBeqPhLML0p1s/pkLaEDGFAXjoeCvlkZrpQIf+gqidNLB1TYJ1RbXI1n9aV3nj+7tQkJ MXOBGvT21ngoU/MDcDqg6NXsyIRig9SZDbiH2Ps3k5xQwXQj6vB9CsKuqOG/LDisJ+Kh 6YSw== 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=qYJvoGst3tJpXkyK76xWrIh3h7PntVWfswhUsoaI6Zk=; b=d5CjZTv++vGUPdEsXsWpZtB0Y1p6bXbZigPaGkT06Hl6Np2CbDB1H870H6ZVTybP0c sxznhX7SGfawKYfp+1gOL/dEEK5gXZaXAzuh+erMdlwkhN0sI+QbToOOw8YFrTyaDZyT Qq6WZOnv/uZeIEfY8RiIhjwoo7e9f/hr6Z1cfVmeygC5086J34gfnM15fyStmXFq9Jho KZ8lCctXuECw3I8kicS40DZ2bRfReZU7jfEu1anVTZWvp/RRZXtMBwqXRFJszXXTSrRT +BKQHGgimAt8SWroaQrI2Kdg0+E6pwNBi7q6C8/S88vdRsDIQdDnqtPILKWPW1EEcf4l Riyw== X-Gm-Message-State: APjAAAXG1tMqWY/YkxWyTvGgknhP6OF4VxpsMNZ+MKVmklhjKzI6aTYs mV7toKGIX6CNoVUZpr1JgCZIqw== X-Google-Smtp-Source: APXvYqwSgoejoOzAPM0EQI9sgRMTJSFvZvZYvf24sEkYOcI+IrYleIEtJ3ipboXCgP4N5KhX1vPCiw== X-Received: by 2002:adf:f288:: with SMTP id k8mr77214909wro.301.1577808399591; Tue, 31 Dec 2019 08:06:39 -0800 (PST) Received: from p200300eb8f1a50e4853495bb51a8296f.dip0.t-ipconnect.de (p200300EB8F1A50E4853495BB51A8296F.dip0.t-ipconnect.de. [2003:eb:8f1a:50e4:8534:95bb:51a8:296f]) by smtp.gmail.com with ESMTPSA id n189sm2975154wme.33.2019.12.31.08.06.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Dec 2019 08:06:38 -0800 (PST) From: Torsten Lodderstedt Message-Id: <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_4F740B29-FD50-4381-AB54-8DCBCD4CA8BD"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Tue, 31 Dec 2019 17:06:06 +0100 In-Reply-To: Cc: oauth , Dave Tonge , Nat Sakimura , Brian Campbell , Roland Hedberg To: Filip Skokan References: X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [OAUTH-WG] PAR metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 16:06:43 -0000 --Apple-Mail=_4F740B29-FD50-4381-AB54-8DCBCD4CA8BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Filip,=20 > On 31. Dec 2019, at 16:22, Filip Skokan wrote: >=20 > I don't think we need a *_auth_method_* metadata for every endpoint = the client calls directly, none of the new specs defined these (e.g. = device authorization endpoint or CIBA), meaning they also didn't follow = the scheme from RFC 8414 where introspection and revocation got its own = metadata. In most cases the unfortunately named = `token_endpoint_auth_method` and its related metadata is what's used by = clients for all direct calls anyway. >=20 > The same principle could be applied to signing (and encryption) = algorithms as well. >=20 > This I do not follow, auth methods and their signing is dealt with by = using `token_endpoint_auth_methods_supported` and = `token_endpoint_auth_signing_alg_values_supported` - there's no = encryption for the `_jwt` client auth methods.=20 > Unless it was meant to address the Request Object signing and = encryption metadata, which is defined and IANA registered by OIDC. PAR = only references JAR section 6.1 and 6.2 for decryption/signature = validation and these do not mention the metadata (e.g. = request_object_signing_alg) anymore since draft 07. Dammed! You are so right. Sorry, I got confused somehow.=20 >=20 > PS: I also found this comment related to the same question about auth = metadata but for CIBA. Thanks for sharing.=20 >=20 > Best, > Filip thanks, Torsten.=20 >=20 >=20 > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt = wrote: > Hi all, >=20 > Ronald just sent me an email asking whether we will define metadata = for=20 >=20 > pushed_authorization_endpoint_auth_methods_supported and > pushed_authorization_endpoint_auth_signing_alg_values_supported. >=20 > The draft right now utilises the existing token endpoint = authentication methods so there is basically no need to define another = parameter. The same principle could be applied to signing (and = encryption) algorithms as well.=20 >=20 > What=E2=80=99s your opinion? >=20 > best regards, > Torsten. --Apple-Mail=_4F740B29-FD50-4381-AB54-8DCBCD4CA8BD 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 Fw0xOTEyMzExNjA2MDZaMC8GCSqGSIb3DQEJBDEiBCBTbi07pZwVlnymo8/p2H5Hui2HD/S8SEU8 5RSqzfEh/TCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAK1MMmxzffErJxIuRKOB7/19yevOuH0imF0FWfGztV1/U13/JiWuKM0qGARZ 7+lBos/fTraevY5GhnyJXCbY0YFIoExQ4YFXkTGx9twxDlBZI6R+7gG1lPkaNAkt7usKSftyzi91 yt+lUlKw/2xgqvAZehkr9TiYE2TxOvG0WW0sXXgNziQIh981eRVbdecXK6kF+fjJNZLi2eh/coTI Bkzj6My9rhR9CJqvvBulQhWpJ8wyUU5IEII7XWHMEvyiLB+mYMTmuD42xQzYB08YnMWOIh2cyFMq ocnI23zz6iY7G9MsCigBQUPLdH+1jXgUK6P8AqBa09+rpj7QoJKEY8YAAAAAAAA= --Apple-Mail=_4F740B29-FD50-4381-AB54-8DCBCD4CA8BD-- From nobody Tue Dec 31 08:07:10 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8B0120043 for ; Tue, 31 Dec 2019 08:07:09 -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 zOrTLU26soUz for ; Tue, 31 Dec 2019 08:07:07 -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 0F3CC120013 for ; Tue, 31 Dec 2019 08:07:07 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id p9so2163412wmc.2 for ; Tue, 31 Dec 2019 08:07:06 -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=ALDhCn/vhUyXP6DLQpN5OyYomFTNjCueSuZjpIt8Mng=; b=nkRPRSIfl0HvB+gPKHy1gxbmT0JbMX+WifKmEodUzI22v4rKeoAzcny1JFfr7J9bBk W7I0jCcoB695X4SSjSAKwcJSXqu2SysHurYYh1slspNd3fk+KtBTzZ7wZ3FTy+uFJJtL 3CTXMUXsIrBOtn4G87SB8p3IuM2+OaaAaDwkvQf6XYPCMKHVqIAdwiE6tXrI9o88UoI3 jLY9uaQTUrI8V6cjKRZg0N4/9H9RKVkcAx7swWxHP96yobB0zJqmpX/QyyjAyx1zsBOK o8y4lgzxyMuFMT2qmYfsQwm6i3JoeaDO9sqzWyWnPT5sjLwCxFk7lMutji1tqIYeqRfk dz6g== 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=ALDhCn/vhUyXP6DLQpN5OyYomFTNjCueSuZjpIt8Mng=; b=irSwDblccohM7EotR937cIyRzrwJdLl0vkHq6S1awbTDW/cmCcxeEK0/jP9QmtRJq8 w15gUm6y5/SB37XKniksE7TkDRZsi6e2ZHU4i5eXrYVoCNmaUZCsgFY/i4sNWC9qU3+h /xCnxaRFohqYK834jqQtj9g+J6eU0Tyifqf7vWX6HhFSgyifzS/isZPNB+KbWRiBBzva +yqAV8FR1ymGl+uRToeBUTcheX5mpKOhqGVsI6e2B1MnwNxjOmHAhiaGWtSED4To24pV m+LITj98agQTmWVdW4zHokVIfJdUjNPoC1SpZX22OhU65wgg4QQu5kaXKy+pEI1qrbLI mXYg== X-Gm-Message-State: APjAAAUIfyN1iP1boPopNH31T7axtx+l0UQ/sjKi5/ESpSo9LVx1GBds j7ZJFa6dN4Z9VEq1TPT6TITL4Q== X-Google-Smtp-Source: APXvYqzWjBA1viO4KSQSy0xxXjypQs4XhR8wrXE/Cdi6G+fQrpl+EL0K2CNIwGmWpVX0vxlp+gAOVg== X-Received: by 2002:a1c:3187:: with SMTP id x129mr4998602wmx.91.1577808425531; Tue, 31 Dec 2019 08:07:05 -0800 (PST) Received: from p200300eb8f1a50e4853495bb51a8296f.dip0.t-ipconnect.de (p200300EB8F1A50E4853495BB51A8296F.dip0.t-ipconnect.de. [2003:eb:8f1a:50e4:8534:95bb:51a8:296f]) by smtp.gmail.com with ESMTPSA id n189sm2975154wme.33.2019.12.31.08.07.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Dec 2019 08:07:04 -0800 (PST) From: Torsten Lodderstedt Message-Id: <876D534C-66FE-41A4-8101-619B0A4915AF@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_C878A8E2-34D7-425E-AB4D-E7A9F7E5D435"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Tue, 31 Dec 2019 17:06:33 +0100 In-Reply-To: Cc: Filip Skokan , oauth , Dave Tonge , Nat Sakimura , Roland Hedberg To: Brian Campbell References: X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [OAUTH-WG] PAR metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 16:07:09 -0000 --Apple-Mail=_C878A8E2-34D7-425E-AB4D-E7A9F7E5D435 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 wfm Have a great new year! > On 31. Dec 2019, at 16:55, Brian Campbell = wrote: >=20 > Yeah, I agree. The insights in that comment Filip referenced (copied = below) are very very wise and explain why we should not define = pushed_authorization_endpoint_auth_methods_supported and > pushed_authorization_endpoint_auth_signing_alg_values_supported = metadata.=20 >=20 >=20 > There's some historical weirdness to how client authentication has = come to be represented (and named) in metadata. Client registration = metadata has only a token_endpoint_auth_method, which despite the name = has become the de facto place in the client data model to say how the = client will authenticate to the AS when making any direct client -> AS = call. The parameter name is a bit unfortunate but I believe it makes = sense to have a single (backchannel) authentication method per client. = RFC 8414 took a different direction and has = revocation_endpoint_auth_methods_supported and = introspection_endpoint_auth_methods_supported etc., which I believe was = a mistake. I don't see a clear use case for needing or allowing a = different set of auth methods for the different endpoints. And having a = bunch of _supported parameters for different endpoints seems likely to = clutter up the metadata document with a bunch of redundant info. >=20 > I'd propose that some text be added into CIBA core that says that, for = the backchannel authentication endpoint, the AS supports the same client = authentication methods as indicated with = token_endpoint_auth_methods_supported. And state that, for a client, the = token_endpoint_auth_method is the authentication method registered for = its client_id regardless of the endpoint being called. >=20 >=20 > On Tue, Dec 31, 2019 at 8:22 AM Filip Skokan = wrote: > I don't think we need a *_auth_method_* metadata for every endpoint = the client calls directly, none of the new specs defined these (e.g. = device authorization endpoint or CIBA), meaning they also didn't follow = the scheme from RFC 8414 where introspection and revocation got its own = metadata. In most cases the unfortunately named = `token_endpoint_auth_method` and its related metadata is what's used by = clients for all direct calls anyway. >=20 > The same principle could be applied to signing (and encryption) = algorithms as well. >=20 > This I do not follow, auth methods and their signing is dealt with by = using `token_endpoint_auth_methods_supported` and = `token_endpoint_auth_signing_alg_values_supported` - there's no = encryption for the `_jwt` client auth methods.=20 > Unless it was meant to address the Request Object signing and = encryption metadata, which is defined and IANA registered by OIDC. PAR = only references JAR section 6.1 and 6.2 for decryption/signature = validation and these do not mention the metadata (e.g. = request_object_signing_alg) anymore since draft 07. >=20 > PS: I also found this comment related to the same question about auth = metadata but for CIBA. >=20 > Best, > Filip >=20 >=20 > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt = wrote: > Hi all, >=20 > Ronald just sent me an email asking whether we will define metadata = for=20 >=20 > pushed_authorization_endpoint_auth_methods_supported and > pushed_authorization_endpoint_auth_signing_alg_values_supported. >=20 > The draft right now utilises the existing token endpoint = authentication methods so there is basically no need to define another = parameter. The same principle could be applied to signing (and = encryption) algorithms as well.=20 >=20 > What=E2=80=99s your opinion? >=20 > best regards, > Torsten. >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. --Apple-Mail=_C878A8E2-34D7-425E-AB4D-E7A9F7E5D435 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 Fw0xOTEyMzExNjA2MzNaMC8GCSqGSIb3DQEJBDEiBCBfl3QCZRJsPWgxilgLhLIO5OcN/GerVYwy QGLJUNs++zCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAMJ+7ClbKUlKkGZOadR8TRG3plGWDSynZJPvpztp7T3VynQyCQCokbDUNbgc w29rcYFi+Zlg6hGSeLf1YParpN73nAYbKTywNMiRX9iM864mer8B74i6c/A6WAknPeX4Kpr5Zjny zM5/z03xukNgeMJPwaAs/3A1PXf++xPTSfX2FzJl1oT52byvrC5vlYFzwscIfhTahBbHNBbdDocn zFVdhydT83hKyd2BZ57qSYh5S+xHkhz5f86EijWyvIg7wZkg6pyKlN20JMVQPO5VyRqwHlcSnHL7 qu7Soe6+HlB6XXAwpP/fehUnQvetWVLheDSVD1SYl90w4lR8YEiq9DAAAAAAAAA= --Apple-Mail=_C878A8E2-34D7-425E-AB4D-E7A9F7E5D435--