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 775A21A904F for ; Thu, 18 Feb 2016 05:55:47 -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 icYdcjYwP713 for ; Thu, 18 Feb 2016 05:55:44 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3EAD1A903D for ; Thu, 18 Feb 2016 05:55:43 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id c3so44585985vkb.3 for ; Thu, 18 Feb 2016 05:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=EiMv8iRKf07K3jgqOugfOBTb9SeOML0GSYTk0EGjevM=; b=I37ytp2JsNhMXhIopWr5fZvL9qucsaBm6Y8nIwEsykELqVeOf8WLKiPDuDijNY2/Ek owwOXP4fI6ChQBSQ05YG6VAFG6Nn+Kv2bdGI3GGVTIAxIRmSIqy0svlRCRRp+6feQEZo LM3EuyTtgDQsPPAyqZ7mFYn28zSeN+C/dfvkg5l485bsTOalMiCP0ra3h+4iA+KKg4a6 JvA3BUmGCC5+2NDoVhP8AQn0+Tg5t5baN5719TM/pP4DEsExVabG0EfkITf93JG06q9v gRh7bolS8JES+xdjHFdbSKI04q6V0CV/SjLapqq1dmOLWjv2LxESqnNwJ/nWFRoubCNN U0Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=EiMv8iRKf07K3jgqOugfOBTb9SeOML0GSYTk0EGjevM=; b=bYkxqbSA7XtCXmsIol8G1HFTvGmSQcTcH/NCUnf64aEHWrdHExSsa+l/rTmjgailbW ZrBcyF/ZdHnSHDvoREMx0hDR3NV39G+rL+UmKGtkMA8fj5N+lUXOW3GpdTyWZbaORQZN CLY16WjVV9ZDv/jHFmr2Oe4FA/ZOUWqpnkwBG/kK4BqulPE68hGHVUWts1p2MKNr2hIM CcuoA+wgyxAEt9ZSLJRyAB1evFx9QCcfrEwmRUVqnGFwXMzxXkwt3aX8JOd1iZgy/ydD pr6hSMugCXrvZdXscNjwzT4q6P+rCVfKTRSZnfkRvItln5MDu3F7HXVG2i5sh6m6XnZa xoyw== X-Gm-Message-State: AG10YOTWF5BIrW2rJ7IIYIhyNdXjt0o4hmlSkLOTKqidNlhj6oyZ8iLuGAqgHiWHZ5RnIw== X-Received: by 10.31.52.133 with SMTP id b127mr6120984vka.77.1455803742739; Thu, 18 Feb 2016 05:55:42 -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 h22sm755071vka.26.2016.02.18.05.55.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Feb 2016 05:55:41 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_840611E4-EA19-45B4-85D6-818A2BA963CF"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> Date: Thu, 18 Feb 2016 08:55:39 -0500 Message-Id: <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.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 13:55:47 -0000 --Apple-Mail=_840611E4-EA19-45B4-85D6-818A2BA963CF Content-Type: multipart/alternative; boundary="Apple-Mail=_7EDD57F4-67C4-4E79-ACAB-878D9106F5DF" --Apple-Mail=_7EDD57F4-67C4-4E79-ACAB-878D9106F5DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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. =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. 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 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 --Apple-Mail=_7EDD57F4-67C4-4E79-ACAB-878D9106F5DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=_7EDD57F4-67C4-4E79-ACAB-878D9106F5DF-- --Apple-Mail=_840611E4-EA19-45B4-85D6-818A2BA963CF 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 SIb3DQEJBTEPFw0xNjAyMTgxMzU1NDBaMCMGCSqGSIb3DQEJBDEWBBRcvVPLAVunnQpKio7PwJPh qZ8N6DCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCoJI3KW/NMhDQ9Rm7fLW+qW67O747MMgUeTcpD7RT/6MRy7cI9fYZA hQV2oQ6QQu67TxmDImPPRhLtkfgCtlAYDbgEFZebE9HwMEyx74ZciOEkeXnvx2VApkudAvpX+iPe CCCDd6gNxJYOWKBewQIQapIID9TEOtcmAsXp0AD9ML0WYxutPar3SN4e+spqHChL2RLsPUn8ylZ/ 26LwgGipeeaLzF2hyUUdLZrYtI6pDfiE4aTRqvZPazjo+vzNfxyotUJIgKUg3QenK6A5B08darSg EhDEpeFFvobPLEtP4bWm1I81Jed/E9Nc6SjtdyQEShK12gqi2cLbbx3Wk4bDAAAAAAAA --Apple-Mail=_840611E4-EA19-45B4-85D6-818A2BA963CF--