Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD95A1AC3CA for ; Thu, 18 Feb 2016 06:19:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPtrl99AdVMA for ; Thu, 18 Feb 2016 06:19:14 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F94A1AC3DF for ; Thu, 18 Feb 2016 06:19:12 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id e6so45240428vkh.2 for ; Thu, 18 Feb 2016 06:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=RnM3WYt32y338cvY0ypttvwJyFx9IIIvsCgsvEFTYyU=; b=VsIv4OaAhzvnnx+aMbPW+EU2V3EkDgq12iILxzi8FEGsyXDRL0aoplDRtZjk0FuqOr Wfo+tAFjKyKgsqXwSXBSXQrLB0Pa9izTr5NvV4OFXrtlVVcT5uLZ3pZv64IUv5P3a3Vh YlG0mjf37VN0NEDXgsYhiKxNOVidgZoZW46GfqnoHGj7kcUdG1P5rF1fCYdI2+dKEkp8 yrN1vBaXjto0AWC3x3c4OfFZps5sFg7+w47msE66i6BL+liGY+FGCMIW5IsHpQ29yUv1 VeymPWF1WIpisP2hmF9s7tCAQqJdcuS7ugl2H/kEB1JIDy9AUoZJlEbsTe/tMvboY1Gm +90A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=RnM3WYt32y338cvY0ypttvwJyFx9IIIvsCgsvEFTYyU=; b=WbnmJ1gbu49rZsFW6vvoxkUktWxj3IyUcoLOOMeEQEzmxgAi05oK3tvFv1ndcQGwYx 6AMEfJBO8dsE5vNFYmJEtjZ6PTX32xQtg54NZVU9OYNtGBCadsnu2PSO+Sc5obwfFevL F6IU0seNs32KGAH9SfbwWmy/PQuy95Tk4t3QhE8rLhqrwRFuf9lEZckriHRjfC5A2mkx NlSrsWXlzg6TQ8zUGl/bhBOXi3MjZIGHkhVZQTj4ouzS7Vxh7C7tmOtBv0M2DQx72e+D glVBFe2KYzelU4PnBDK3Xyr94Orjku2tvLJvurddVTRNFJqxMwKFjiFL5t9Z7zO9Oove 8pxA== X-Gm-Message-State: AG10YORBShQhZUu8+R/JhQqDueFfwK9bde3pOP2HJ2GlDmLl+zVeY2AWTjeh4PbzFMxhcA== X-Received: by 10.31.44.77 with SMTP id s74mr6123602vks.4.1455805151892; Thu, 18 Feb 2016 06:19:11 -0800 (PST) Received: from [192.168.12.59] (ip-64-134-184-168.public.wayport.net. [64.134.184.168]) by smtp.gmail.com with ESMTPSA id v19sm757939vkd.22.2016.02.18.06.19.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Feb 2016 06:19:10 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_6ADD2369-3884-4482-859A-CF187414C116"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Thu, 18 Feb 2016 09:19:09 -0500 Message-Id: References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> To: Phil Hunt X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 14:19:18 -0000 --Apple-Mail=_6ADD2369-3884-4482-859A-CF187414C116 Content-Type: multipart/alternative; boundary="Apple-Mail=_AD2AFE33-99A6-41E3-87B0-9135EBE6227C" --Apple-Mail=_AD2AFE33-99A6-41E3-87B0-9135EBE6227C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Can you clarify what you mean by =E2=80=9Cresource service x=E2=80=9D? Is that the RS base URI for the resource, a specific URI that the = client is requesting? That is getting UMA ish.=20 The concept of a base RS URI is a rat hole that I prefer not to go down, = as it is something everyone thinks exists but like SCIM if it exists it = is protocol or deployment specific. The notion that you would send the URI you are planning on requesting to = a Webfinger server to find the OAuth server, is probably going to have = privacy issues. I suspect that you need to hand back a error from the resource to say = where the AS is, or have a .well-known for the RS. RS discovery probably wants to be separate from AS discovery. (Yes I do = think we need something, UMA rpt or something like it might be a way to = go) John B. > On Feb 18, 2016, at 9:06 AM, Phil Hunt wrote: >=20 > Maybe SCIM was a bad example. It functions as a RESTful resource in = the context of OAuth. >=20 > I find the use of OIDC to be confusing as an example (and the default) = because it is both an OAuth resource and a security service. It is a = modification of OAuth. >=20 > Start thinking about every application ever written that uses OAuth. = Are we expecting 100s of thousands of these to each register? >=20 > To me, this specification is a fine specification for OIDC and it = should be published there because the specification defines how to = discovery OAuth and OpenID information. >=20 > Likewise you suggest it is ok for SCIM to do the same.=20 >=20 > How do we expect normal applications to set up and do discovery? >=20 > It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should = have a parameter to ask, I want to discover OAuth configuration for = resource service X. >=20 > That still allows me to have a separate discovery service that says, = tell me about resource service X itself. >=20 > BTW. I think we are FAR from Last Call on this topic. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Feb 18, 2016, at 6:55 AM, John Bradley > wrote: >>=20 >> Diffrent protocols like Connect and SCIM may have different = configurations, endpoints , keys , authentication methods, scopes etc. >>=20 >> It should be posable to have them as one document, but forcing them = to use one document is going to cause a explosion of claim registration = for discovery. >>=20 >> I think it is better for SCIM to register one well known than to have = to register 20 claims with scim prefixes or something silly like that. >>=20 >> Name-spacing the claims by allowing them to be in different well = known files is not unreasonable. >>=20 >> Remember some of these protocols may be hosted on SaaS so there is no = guarantee that all protocols will have the same OAuth Config. >>=20 >> Nothing stops a protocol from doing what it likes with webfinger if = it wants to use that for discovery. >>=20 >> In principal I like the idea of having another protocol as an = example. >>=20 >> My only concern is that I haven=E2=80=99t seen any discussion of your = SCIM discovery document in the SCIM WG. =20 >> I personally think sorting out discovery for SCIM is a good idea, = but OAUTh is but one of several authentication methods for SCIM, and = there are probably other non OAuth things that want to be described. >>=20 >> I would feel better about using it as an example if it were adopted = by the WG and some general interest shown. >>=20 >> I encourage you to do that so we can use it as a example. >>=20 >> John B. >>=20 >>> On Feb 18, 2016, at 8:35 AM, Phil Hunt > wrote: >>>=20 >>> I still find the following text objectionable and confusing=E2=80=A6 >>> By default, for historical reasons, unless an = application-specific >>> well-known URI path suffix is registered and used for an = application, >>> the client for that application SHOULD use the well-known URI = path >>> suffix "openid-configuration" and publish the metadata document = at >>> the path formed by concatenating = "/.well-known/openid-configuration" >>> to the authorization server's issuer identifier. As described in >>> Section 5 = , = despite the identifier >>> "/.well-known/openid-configuration", appearing to be = OpenID-specific, >>> its usage in this specification is actually referring to a = general >>> OAuth 2.0 feature that is not specific to OpenID Connect. >>>=20 >>> Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the = default further gives people the impression that a plain OAuth server = *is* an authentication server and that the normal access token received = is evidence of a successful authentication. >>>=20 >>> It would be better to point out that application may include oauth = discovery in their discovery URI and that OAuth is an example of this. = It might be good to include two examples. E.g. OIDC and SCIM (as = another referenceable example). >>>=20 >>> GET /.well-known/openid-configuration >>> and >>> GET /.well-known/scim >>> Retrieve the OAuth configuration for the application openid and scim = respectively. >>>=20 >>> The use of: >>> GET /.well-known/oauth2/ >>> Should be the default used when there is no known application based = well-known application based URI discovery. >>>=20 >>> Of course, the concern I raised earlier is that this approach of = application specific URIs ends up requiring every application to make an = IANA registration if they don=E2=80=99t want to use the default of = =E2=80=9Coauth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80=9D). = Is that what the authors expect? >>>=20 >>> It seemed better to me to use the webfinger syntax to allow the = client to say =E2=80=9CI want the designated OAuth configuration for the = resource service X=E2=80=9D would be a better design that avoids = extensive IANA registration. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Feb 17, 2016, at 11:48 PM, Mike Jones = > = wrote: >>>>=20 >>>> In response to working group input, this version of the OAuth = Discovery specification has been pared down to its essence =E2=80=93 = leaving only the features that are already widely deployed. = Specifically, all that remains is the definition of the authorization = server discovery metadata document and the metadata values used in it. = The WebFinger discovery logic has been removed. The relationship = between the issuer identifier URL and the well-known URI path relative = to it at which the discovery metadata document is located has also been = clarified. >>>> =20 >>>> Given that this now describes only features that are in widespread = deployment, the editors believe that this version is ready for working = group last call. >>>> =20 >>>> The specification is available at: >>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 = >>>> =20 >>>> An HTML-formatted version is also available at: >>>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html = >>>> =20 >>>> -- Mike & = Nat & John >>>> =20 >>>> P.S. This notice was also posted at = http://self-issued.info/?p=3D1544 = and as @selfissued . >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >=20 --Apple-Mail=_AD2AFE33-99A6-41E3-87B0-9135EBE6227C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Can you clarify what you mean by =E2=80=9Cresource service = x=E2=80=9D?

Is that = the RS base URI for the resource,  a specific URI that the client = is requesting?

That is getting UMA ish. 

The concept of a base RS URI is a rat = hole that I prefer not to go down, as it is something everyone thinks = exists but like SCIM if it exists it is protocol or deployment = specific.

The = notion that you would send the URI you are planning on requesting to a = Webfinger server to find the OAuth server, is probably going to have = privacy issues.

I suspect that you need to hand back a error from the = resource to say where the AS is, or have a .well-known for the = RS.

RS = discovery probably wants to be separate from AS discovery.  (Yes I = do think we need something,  UMA rpt or something like it might be = a way to go)

John B.

On = Feb 18, 2016, at 9:06 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Maybe SCIM was = a bad example.  It functions as a RESTful resource in the context = of OAuth.

I find the = use of OIDC to be confusing as an example (and the default) because it = is both an OAuth resource and a security service.  It is a = modification of OAuth.

Start thinking about every application = ever written that uses OAuth. Are we expecting 100s of thousands of = these to each register?

To me, this specification is a fine specification for OIDC = and it should be published there because the specification defines how = to discovery OAuth and OpenID information.

Likewise you suggest it is ok for SCIM = to do the same. 

How do we expect normal applications to set = up and do discovery?

It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec = should have a parameter to ask, I want to discover OAuth configuration = for resource service X.

That still allows me to have a separate discovery service = that says, tell me about resource service X itself.

BTW. I think we are FAR = from Last Call on this topic.





On Feb 18, 2016, at 6:55 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Diffrent = protocols like Connect and SCIM may have different configurations, = endpoints , keys , authentication methods, scopes etc.

It should be posable to have them as = one document, but forcing them to use one document is going to cause a = explosion of claim registration for discovery.

I think it is better for SCIM to = register one well known than to have to register 20 claims with scim = prefixes or something silly like that.

Name-spacing the claims by allowing = them to be in different well known files is not unreasonable.

Remember some of these = protocols may be hosted on SaaS so there is no guarantee that all = protocols will have the same OAuth Config.

Nothing stops a protocol from doing = what it likes with webfinger if it wants to use that for = discovery.

In = principal I like the idea of having another protocol as an = example.

My = only concern is that I haven=E2=80=99t seen any discussion of your SCIM = discovery document in the SCIM WG.  
I = personally think sorting out discovery for SCIM is a good idea, =  but OAUTh is but one of several authentication methods for SCIM, = and there are probably other non OAuth things that want to be = described.

I = would feel better about using it as an example if it were adopted by the = WG and some general interest shown.

I encourage you to do that so we can = use it as a example.

John B.

On Feb = 18, 2016, at 8:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

I still find the following text objectionable and = confusing=E2=80=A6
   By default, for historical reasons, =
unless an application-specific
   well-known URI path suffix is registered and used for an application,
   the client for that application SHOULD use the well-known URI path
   suffix "openid-configuration" and publish the metadata document at
   the path formed by concatenating "/.well-known/openid-configuration"
   to the authorization server's issuer identifier.  As described in
   Section 5, despite the identifier
   "/.well-known/openid-configuration", appearing to be OpenID-specific,
   its usage in this specification is actually referring to a general
   OAuth 2.0 feature that is not specific to OpenID Connect.

Further, = as a default =E2=80=9Copenid-configuration=E2=80=9D as the default = further gives people the impression that a plain OAuth server *is* an = authentication server and that the normal access token received is = evidence of a successful authentication.

It would be better to point out that = application may include oauth discovery in their discovery URI and that = OAuth is an example of this. It might be good to include two examples. =  E.g. OIDC and SCIM (as another referenceable example).

 GET =
/.well-known/openid-configuration
and
 GET =
/.well-known/scim
Retrieve = the OAuth configuration for the application openid and scim = respectively.

The use of:
 GET /.well-known/oauth2/
Should be the default used when there is no known application = based well-known application based URI discovery.

Of course, the concern I = raised earlier is that this approach of application specific URIs ends = up requiring every application to make an IANA registration if they = don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80=9D (or = =E2=80=9Copenid-configuration=E2=80=9D).  Is that what the authors = expect?

It = seemed better to me to use the webfinger syntax to allow the client to = say =E2=80=9CI want the designated OAuth configuration for the resource = service X=E2=80=9D would be a better design that avoids extensive IANA = registration.





On Feb 17, 2016, at 11:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

In response to working group input, = this version of the OAuth Discovery specification has been pared down to = its essence =E2=80=93 leaving only the features that are already widely = deployed.  Specifically, all that remains is the definition of the = authorization server discovery metadata document and the metadata values = used in it.  The WebFinger discovery logic has been removed.  = The relationship between the issuer identifier URL and the well-known = URI path relative to it at which the discovery metadata document is = located has also been clarified.
 
Given that this now describes only = features that are in widespread deployment, the editors believe that = this version is ready for working group last call.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-01
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html=
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike & = Nat & John
 
P.S.  This notice was also posted at http://self-issued.info/?p=3D1544 and as @selfissued.
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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



= --Apple-Mail=_AD2AFE33-99A6-41E3-87B0-9135EBE6227C-- --Apple-Mail=_6ADD2369-3884-4482-859A-CF187414C116 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMTgxNDE5MDlaMCMGCSqGSIb3DQEJBDEWBBQGGCudZzlBUW2f+8iI3CPe lq1NdjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCSQQT+PXdQSgyOf17lnGFzmZwGCYOCnQE9TnEKPrWFc2+z2Qa0aS28 JcUOFNBz+Q6jeH9dh56v263KBTmXGdeABuwBy5c74jUdXEYWa5QVHPwGPkpx7dwMQvpvQgPCNGHy ovWVT9yr25QJhanU6fGcfBUdWJX8nNNG4ZI81uKsQqVxZ9YtwEWujQzRrfCHw8ENhUwXp5Pal60v 6vTaPPRUX0dF1gBItkwkrf4+M9l/oww0OwmqOOWnxxz2rKASepxCGd6awjeSKCkuy1L5TOyvS9mk Ehe+tmSXo8dZYhQWz5XNpIREq7tYTHXpC6JidlncQJEOsv0Kbsu9wGH+hpziAAAAAAAA --Apple-Mail=_6ADD2369-3884-4482-859A-CF187414C116--