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 5CFA61B30A4 for ; Tue, 9 Feb 2016 15:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001] autolearn=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 FzteCd9T_2jT for ; Tue, 9 Feb 2016 15:49:46 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 E9A681B30A6 for ; Tue, 9 Feb 2016 15:49:45 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id b35so2640207qge.0 for ; Tue, 09 Feb 2016 15:49:45 -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=FpvaUHNQTKokPac4USHnMgfbPG++sYcu9SRDK3SOY+E=; b=TJek58FPG3yFuZDqPTHvM5CvK7ArstVAgN6vOjw/3bv2vNBcvFuehmBuKr21zOo29v Vzsd6e4XGfdWo9GbQfxTpOwzS8Eo7gyIOzmzDHCKFfl4UbXkNFPAD45Cyd/S0RAKX33m 7o5r+2cASGVelCGrRp8HUNN8ZVhSgabrLdMvCVpXQdudj9rB9eb63uC8kZguynaIQHDQ RWNzZ1Z9llzqcA0l5jVQFnGRbKzdDsxJbESkqZMVCnwCvtATJGZcmeOmof6P5XGjBG52 iwx2AT/Zt+qg4CXt1PYpx7NuV0JBqP9spcqUqbn5WOxPqmQvynM1nWFAT3KsLbWRlQxe zVwA== 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=FpvaUHNQTKokPac4USHnMgfbPG++sYcu9SRDK3SOY+E=; b=aOlhSiAcsescDCKlbvBt3ihQhx4I/WoDONLp9AxC1Zybdcv04A/nhOvmpAg7ENGCrX elE/zChBrUTPRnE76QFv1n7x4woehX5atTTD+LSYpjVEWLMi3+ZiQE4ZkJY/8yoBDElF R9Vo9ybYVjtlnW2GLqfUcOlfb9PemLw7Nz4QLS5XF/UTRmeG+Ea1TSMzidncYINER5lt DJRBlwgl6wjlDqc9e8FrBIUqzR7cVF33mzK2Q8bCCmVhrfu+EsRnXZnfbFQK1a1DH22e WZgxhExsy8YKg2pcpB15kNghKE8rEVhX1pSvlZPjzbruvpI/R4WXAeKY1UlvEfH6xOSD CpwQ== X-Gm-Message-State: AG10YOT8YnfxpsPjRJW6lN0phAC6kEW4Ltxvulql7e46G2n/XF99U72azsLURwMcjGOY5A== X-Received: by 10.140.220.78 with SMTP id q75mr47160783qhb.77.1455061784765; Tue, 09 Feb 2016 15:49:44 -0800 (PST) Received: from [192.168.8.100] ([181.202.64.23]) by smtp.gmail.com with ESMTPSA id t187sm177872qht.39.2016.02.09.15.49.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Feb 2016 15:49:43 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_1C59C430-D4A2-452B-B5AD-1EA6453ABBA5"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com> Date: Tue, 9 Feb 2016 20:49:39 -0300 Message-Id: References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification 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: Tue, 09 Feb 2016 23:49:49 -0000 --Apple-Mail=_1C59C430-D4A2-452B-B5AD-1EA6453ABBA5 Content-Type: multipart/alternative; boundary="Apple-Mail=_97CB28A2-6543-43E6-B803-9C6090C2E246" --Apple-Mail=_97CB28A2-6543-43E6-B803-9C6090C2E246 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Have a look at https://tools.ietf.org/html/rfc7033 = The way to do what you want would mean having multiple array objects = with the same rel and somehow differentiating them via properties. I think that is going to be more complicated for clients to parse. I think that the difference is how you look at the actors involved. I = think clients look for a service and then go from there, you are = advocating that they would look for a authorization method and then find = services that support that method. =20 So yes we are looking at it from different ends. I don=E2=80=99t know that defining OAuth genericly at the webfinger = level of user discovery makes sense. Perhaps for a enterprise custom = API environment it might. John B. > On Feb 9, 2016, at 8:24 PM, Phil Hunt wrote: >=20 > Huh? >=20 > Our proposals are the opposite of one-another. In your proposal you = have people querying scim to get oauth. I=E2=80=99m saying you query = rel=3Dscim to get information about SCIM. Querying rel=3DSCIM and = receiving OAuth seems bass- ackwards does it not? >=20 > Further, having rel=3Doauth lets us define one RFC for all that covers = all the security concerns for oauth discovery. If we do it your way = then every resource that registers its own discovery also has to have an = oauth section that copies the oauth discovery stuff because there is no = longer an oauth discovery relationship. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Feb 9, 2016, at 3:16 PM, John Bradley > wrote: >>=20 >> Please don=E2=80=99t break the webfinger RFC. >>=20 >> If you search for SCIM you can have additional properties returned as = part of the entry, but you only search for one thing. >> =20 >> Webfinger is designed to be very simple to implement. In general you = just get back the whole document with all the rel.=20 >> The query filter is a optional optimization.=20 >>=20 >> The JSON in the doc is by rel. >>=20 >>> On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) > wrote: >>>=20 >>> The rel for scim returns the endpoint for scim.=20 >>>=20 >>> The rel for oauth returns endpoints for oauth.=20 >>>=20 >>> The query lets the client say i want the endpoint for oauth used for = scim.=20 >>>=20 >>> I suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-) >>>=20 >>> Phil >>>=20 >>> On Feb 9, 2016, at 14:52, John Bradley > wrote: >>>=20 >>>> You would define a rel uri for SCIM. The SCIM entry can have sub = properties if it supported more than one auth type, or you could have a = SCIM discovery document that the URI points to. >>>>=20 >>>> There are probably multiple ways to do it. >>>>=20 >>>> I don=E2=80=99t think trying to have a oauth rel and then sub types = is going to make sense to developers. It is also not a good fit for = Webfinger. >>>>=20 >>>> I also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service. >>>>=20 >>>> Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as. >>>>=20 >>>> Each service will need to be thought through for webfinger as the = account identity may mean different things depending on the protocol, = and not every protocol needs per user discovery. >>>>=20 >>>> John B >>>>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) > wrote: >>>>>=20 >>>>> Another example is to look at scim discovery(in contrast with = connect). >>>>>=20 >>>>> When asked separately the answers may be different.=20 >>>>>=20 >>>>> Asking what is the oauth server for scim is yet another relation. = So may be we need a scheme for oauth where query is rs:someval and = optionally an acnt value to.=20 >>>>>=20 >>>>> For example >>>>> Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com = >>>>>=20 >>>>> Note i probably have the compound query syntax wrong.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On Feb 9, 2016, at 14:03, John Bradley > wrote: >>>>>=20 >>>>>> If we keep webfinger I don=E2=80=99t think that having a generic = OAuth rel makes sense. It should be up to each API/Protocol to define = it=E2=80=99s own rel value like Connect has done. >>>>>>=20 >>>>>> It is not reasonable to think that a persons ID provider is going = to be the same as the one for calendaring or photo sharing. >>>>>>=20 >>>>>> So I could go two ways with webfinger, leave it out completely, = or leave it in but make it up to the application to define a rel value. >>>>>> I expect that some things using UMA in web-finger would point = directly to the resource and the resource would point the client at the = correct UMA server. >>>>>>=20 >>>>>> The config file name in .well-known could stay as = openid-configuration for historical reasons or we could change it. >>>>>>=20 >>>>>> I think we first need to decide if every protocol/API is going to = have its own config file, we are going to get apps to retrieve multiple = files, or everything is going to go into one config-file and = applicatins just add to that? >>>>>>=20 >>>>>> I prefer not to change the file name if we are going for one = config file, but if we do one alias/link is probably not the end of the = world, as I doubt people will ever remove openid-configuration one if = they have it now. >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>> =20 >>>>>>> On Feb 9, 2016, at 2:19 PM, Justin Richer > wrote: >>>>>>>=20 >>>>>>> Mike, thanks for putting this up. >>>>>>>=20 >>>>>>>=20 >>>>>>> I would like to propose for two changes that have been brought = up before: >>>>>>>=20 >>>>>>> 1) The wholesale removal of section 2, Webfinger lookup.=20 >>>>>>>=20 >>>>>>> 2) The changing of "/.well-known/openid-configuration=E2=80=9D = to "/.well-known/oauth-authorization-server=E2=80=9D or something else = not openid-related. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones = > = wrote: >>>>>>>>=20 >>>>>>>> We have created the initial working group version of OAuth = Discovery based on draft-jones-oauth-discovery-01, with no normative = changes. >>>>>>>> =20 >>>>>>>> The specification is available at: >>>>>>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 = >>>>>>>> =20 >>>>>>>> An HTML-formatted version is also available at: >>>>>>>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html = >>>>>>>> =20 >>>>>>>> -- = Mike >>>>>>>> =20 >>>>>>>> P.S. This notice was also posted at = http://self-issued.info/?p=3D1534 = and as @selfissued . >>>>>>>> =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 = >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>=20 >=20 --Apple-Mail=_97CB28A2-6543-43E6-B803-9C6090C2E246 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Have a look at
https://tools.ietf.org/html/rfc7033

The way to do what you want would mean = having multiple array objects with the same rel and somehow = differentiating them via properties.

I think that is going to be more = complicated for clients to parse.

I think that the difference is how you = look at the actors involved.  I think clients look for a service = and then go from there,  you are advocating that they would look = for a authorization method and then find services that support that = method.   

So yes we are looking at it from different ends.

I don=E2=80=99t know = that defining OAuth genericly at the webfinger level of user discovery = makes sense.   Perhaps for a enterprise custom API environment it = might.

John = B.

On Feb 9, 2016, at 8:24 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Huh?

Our proposals are the = opposite of one-another.  In your proposal you have people querying = scim to get oauth.  I=E2=80=99m saying you query rel=3Dscim to get = information about SCIM.  Querying rel=3DSCIM and receiving OAuth = seems bass- ackwards does it not?

Further, having rel=3Doauth lets us = define one RFC for all that covers all the security concerns for oauth = discovery.  If we do it your way then every resource that registers = its own discovery also has to have an oauth section that copies the = oauth discovery stuff because there is no longer an oauth discovery = relationship.





On Feb 9, 2016, at 3:16 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Please don=E2=80= =99t break the webfinger RFC.

If you search for SCIM you can have additional properties = returned as part of the entry, but you only search for one = thing.
 
Webfinger is = designed to be very simple to implement.  In general you just get = back the whole document with all the rel. 
The = query filter is a optional optimization. 

The JSON in the doc is by = rel.

On Feb 9, 2016, at 8:03 PM, = Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

The rel for scim = returns the endpoint for scim. 

The rel for oauth returns endpoints for = oauth. 

The= query lets the client say i want the endpoint for oauth used for = scim. 

I = suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-)

Phil

On Feb 9, 2016, at 14:52, John Bradley <ve7jtb@ve7jtb.com> = wrote:

You would define a rel = uri for SCIM.   The SCIM entry can have sub properties if it = supported more than one auth type,  or you could have a SCIM = discovery document that the URI points to.

There are probably multiple ways to do = it.

I don=E2=80=99= t think trying to have a oauth rel and then sub types is going to make = sense to developers.  It is also not a good fit for = Webfinger.

I = also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service.

Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as.

Each service will need to be thought = through for webfinger as the account identity may mean different things = depending on the protocol, and not every protocol needs per user = discovery.

John = B
On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) = <phil.hunt@oracle.com> wrote:

Another example = is to look at scim discovery(in contrast with connect).

When asked separately = the answers may be different. 

Asking what is the oauth server for = scim is yet another relation.  So may be we need a scheme for oauth = where query is rs:someval and optionally an acnt value = to. 

For = example
Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com

Note i probably have the = compound query syntax wrong. 

Phil

On Feb 9, 2016, at = 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:

If we keep webfinger I don=E2=80=99t think = that having a generic OAuth rel makes sense.   It should be up to = each API/Protocol to define it=E2=80=99s own rel value like Connect has = done.

It is not = reasonable to think that a persons ID provider is going to be the same = as the one for calendaring or photo sharing.

So I could go two ways with webfinger, =  leave it out completely, or leave it in but make it up to the = application to define a rel value.
I expect that = some things using UMA in web-finger would point directly to the resource = and the resource would point the client at the correct UMA = server.

The = config file name in .well-known could stay as openid-configuration for historical reasons or we could = change it.

I think we = first need to decide if every protocol/API is going to have its own = config file, we are going to get apps = to retrieve multiple files,  or everything is going = to go into one config-file and applicatins just add to = that?

I prefer not to = change the file name if we are going for one config file, but if we do = one alias/link is probably not the end of the world, as I doubt people = will ever remove openid-configuration one if they have it = now.

John = B.

 
On Feb 9, 2016, at 2:19 PM, = Justin Richer <jricher@mit.edu> wrote:

Mike, thanks for putting this up.


I would like to propose for two changes = that have been brought up before:

1) The wholesale removal of section 2, = Webfinger lookup. 

2) The = changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related.



 =E2=80=94 = Justin


On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We have = created the initial working group version of OAuth Discovery based on = draft-jones-oauth-discovery-01, with no normative changes.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.htm= l
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
P.S.  = This notice was also posted at http://self-issued.info/?p=3D1534 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

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




= --Apple-Mail=_97CB28A2-6543-43E6-B803-9C6090C2E246-- --Apple-Mail=_1C59C430-D4A2-452B-B5AD-1EA6453ABBA5 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 SIb3DQEJBTEPFw0xNjAyMDkyMzQ5NDBaMCMGCSqGSIb3DQEJBDEWBBRDoFTi6wzW009MiDOMHnN/ /XOihzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBGpJNsGFNetL6Mx/42EGkngIumwp80QBL54RuPkWeWUbyLsM4fDLAn pubHCmKZxqFUkSWU3zv1lt/k4Q50DH9Qr/+2CEw0tCazaLvwZUm+1QNiHcgCfUnBmU/zkHrRoSPN ++39j+/EM17oIAdLRWNTAjD4JdpDAQqQJyBFjI1PSBK+k5uH+CUrVFm2hSf/1nv2yi6tCW/9JZzj FX/Fw7H64q8CGY31EN3gNGCPoEZE6zMo4MPb98YGAF4mkyFCkOjPRWGFKH8c9UgguR1bZL72jlyy VYbR2uT88FzBzsdCyfUcIBAKhhQBWfg2DbJ+sZZ4ANiXKi3+e4bGpRkRvl1aAAAAAAAA --Apple-Mail=_1C59C430-D4A2-452B-B5AD-1EA6453ABBA5--