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 9A0C21A9073 for ; Tue, 24 Feb 2015 18:04:06 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 PURgwCli-S9t for ; Tue, 24 Feb 2015 18:04:02 -0800 (PST) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (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 487EF1A039F for ; Tue, 24 Feb 2015 18:04:02 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id a108so775351qge.7 for ; Tue, 24 Feb 2015 18:04:01 -0800 (PST) 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=snJPUANi14XnphyE8GamMoE4hIZUqy8A4qm79QcYFww=; b=VPhObGD0Pt8MUaPMam0LKbBVVWSQSHZFgvHMPAY5rQkZAWH+ulXNinSwCirZo8dVt1 /QsLZMUYxYjCJIIWdpN6fOPYpGjQvd+pbaDULtv2NsseBupyAvDimi6L7HN9CHDpzs8F U6YcCV0sS7W1mDEKqrd13AM0N8R9yUCy+woUugLI/EeICjRdBIGB7K13xHgXUnxjcI7d OaT72sFmldSE7M9OzI+KgdYxR4VEk2jAWziEqfme+1QJ4IshsgE88fDvqXB2pmyg7Qg2 C0awkneivbTrPupqG7qILh/vHUUu4Z+DvrN5kkMjiZs1TmdsZkJvDqONYSy/d5ZwtlSo vk5A== X-Gm-Message-State: ALoCoQliVyyj+UVSnn0yD9px6avQHptiGcraka5G7FuUW8n//S+8aIGH32Y6mYacios894wLc2XL X-Received: by 10.140.192.15 with SMTP id n15mr2165145qha.28.1424829841344; Tue, 24 Feb 2015 18:04:01 -0800 (PST) Received: from [192.168.4.129] (ip-64-134-240-44.public.wayport.net. [64.134.240.44]) by mx.google.com with ESMTPSA id 201sm20687545qhb.32.2015.02.24.18.03.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 18:04:00 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_4E15337C-1843-4560-ACE8-5340F49A130A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <3AAFF7CB-1C84-4BD5-B8BF-9162660BD57D@gmail.com> Date: Tue, 24 Feb 2015 21:03:27 -0500 Message-Id: <8C0D57C9-3E4C-4384-A10B-8A0D57F2F75B@ve7jtb.com> References: <54DC2CB1.8090400@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com> <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com> <54E4D2A5.5030705@gmx.net> <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com> <3AAFF7CB-1C84-4BD5-B8BF-9162660BD57D@gmail.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg 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: Wed, 25 Feb 2015 02:04:06 -0000 --Apple-Mail=_4E15337C-1843-4560-ACE8-5340F49A130A Content-Type: multipart/alternative; boundary="Apple-Mail=_03BAF2AC-421A-4A9D-82DD-15FBF635CAEA" --Apple-Mail=_03BAF2AC-421A-4A9D-82DD-15FBF635CAEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes as one of the Authors and a officer of the OpenID Foundation the = text was contributed in accordance with the OIDF copyright, allowing = derivative works. The OIDF is well aware of this specification and is pleased to = contribute parts of the connect specification that have broader = applicability in the OAuth community for inclusion in IETF = specifications. John B. > On Feb 24, 2015, at 8:02 PM, Kathleen Moriarty = wrote: >=20 > I was able to get a response, I'm guessing the question got too buried = in the thread over the past few days. >=20 > Essentially, it is the contributors responsibility to ensure it's ok = to include text. If this was Mike or someone else that believe it is = fine, then we can proceed. >=20 > Hannes may need to update the shepherd report and I'll read through = the updated version tomorrow. I'll try to get a review out if the = accompanying management draft tomorrow too. >=20 > Thanks, > Kathleen=20 >=20 > Sent from my iPhone >=20 > On Feb 24, 2015, at 6:47 PM, Mike Jones > wrote: >=20 >> Thanks, Kathleen. This had been discussed on the OAuth list before, = but just in case you or the IETF legal counsel weren=E2=80=99t aware of = it =E2=80=93 the reason that it=E2=80=99s OK to produce derivative works = from OpenID specs, as draft-ietf-oauth-dyn-reg did, is that it=E2=80=99s = explicitly allowed by the OpenID Foundation. See this text = athttp://openid.net/specs/openid-connect-registration-1_0.html#Notices = = =E2=80=93 the spec from which text was copied: >> =20 >> The OpenID Foundation (OIDF) grants to any Contributor, developer, = implementer, or other interested party a non-exclusive, royalty free, = worldwide copyright license to reproduce, prepare derivative works from, = distribute, perform and display, this Implementers Draft or Final = Specification solely for the purposes of (i) developing specifications, = and (ii) implementing Implementers Drafts and Final Specifications based = on such documents, provided that attribution be made to the OIDF as the = source of the material, but that such attribution does not indicate an = endorsement by the OIDF. >> =20 >> You could pass that on to the appropriate IETF legal counsel if = they=E2=80=99re not already aware of it. >> =20 >> -- = Mike >> =20 >> From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Kathleen Moriarty >> Sent: Tuesday, February 24, 2015 3:08 PM >> To: Hannes Tschofenig >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg >> =20 >> Hello, >> =20 >> Thanks for updating the draft. I just want to confirm that Hannes is = okay with the updated definitions and updates the shepherd report to = reflect that. >> =20 >> This is getting held up a bit while we sort through copyright of text = from UMA and OpenID. The text from UMA went into an IETF draft, so that = should be the reference as it clears up any possible issues as they = provided that text in an IETF draft. =20 >> =20 >> The chairs will be helping to sort out the requirements with OpenID, = per our discussions the IETF trustees. I'm not sure how long this will = take, but wanted to provide a status so no one thought this had been = dropped. >> =20 >> Thanks. >> =20 >> On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig = > wrote: >> Hi Justin, Hi John, >>=20 >> I believe that provisioning a client with a unique id (which is what = a >> client id/client secret is) allows some form of linkability. While it >> may be possible to associate the client to a specific user I could = very >> well imagine that the correlation between activities from a user and >> those from the client (particularly when the client is running on the >> user's device) is quite possible. >>=20 >> Ciao >> Hannes >>=20 >> On 02/18/2015 06:37 PM, Justin Richer wrote: >> > I=E2=80=99ll incorporate this feedback into another draft, to be = posted by the >> > end of the week. Thanks everyone! >> > >> > =E2=80=94 Justin >> > >> >> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty >> >> >> >> >> wrote: >> >> >> >> >> >> >> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley >> >> >> wrote: >> >> >> >> snip >> >>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty >> >>> >> >>> >> wrote: >> >>> >> >>> > The client_id *could* be short lived, but they usually = aren't. I don't see any particular logging or tracking concerns using a = dynamic OAuth client above using any other piece of software, ever. As = such, I don't think it requires special calling out here. >> >>> >> >>> >> >>> Help me understand why there should not be text that shows = this >> >>> is not an issue or please propose some text. This is bound = to >> >>> come up in IESG reviews if not addressed up front. >> >>> >> >>> >> >> >> >> The client_id is used to communicate to the Authorization = server >> >> to get a code or refresh token. Those tokens uniquely = identify >> >> the user from a privacy perspective. >> >> It is the access tokens that are sent to the RS and those can = and >> >> should be rotated, but the client)id is not sent to the RS in >> >> OAuth as part of the spec. >> >> >> >> If you did rotate the client_id then the AS would track it = across >> >> rotations, so it wouldn=E2=80=99t really achieve anything. >> >> >> >> One thing we don=E2=80=99t do is allow the client to specify = the >> >> client_id, that could allow correlation of the client across >> >> multiple AS and that might be a privacy issue, but we don=E2=80=99= t allow it. >> >> >> >> >> >> Thanks, John. It may be helpful to add in this explanation unless >> >> there is some reason not to? >> >> >> >> >> >> John B. >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Best regards, >> >> Kathleen >> >> _______________________________________________ >> >> 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 >> =20 >> --=20 >> =20 >> Best regards, >> Kathleen > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_03BAF2AC-421A-4A9D-82DD-15FBF635CAEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes as one of the Authors and a officer of the OpenID = Foundation the text was contributed in accordance with the OIDF = copyright, allowing derivative works.

The OIDF is well aware of this = specification and is pleased to contribute parts of the connect = specification that have broader applicability in the OAuth community for = inclusion in IETF specifications.

John B.

On = Feb 24, 2015, at 8:02 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

I was able to get a = response, I'm guessing the question got too buried in the thread over = the past few days.

Essentially, it is the contributors responsibility to = ensure it's ok to include text.  If this was Mike or someone else = that believe it is fine, then we can proceed.

Hannes may need to = update the shepherd report and I'll read through the updated version = tomorrow.  I'll try to get a review out if the accompanying = management draft tomorrow too.

Thanks,
Kathleen 

Sent from my iPhone

On Feb = 24, 2015, at 6:47 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks, Kathleen.  = This had been discussed on the OAuth list before, but just in case you = or the IETF legal counsel weren=E2=80=99t aware of it =E2=80=93 the = reason that it=E2=80=99s OK to produce derivative works from OpenID = specs, as draft-ietf-oauth-dyn-reg did, is that it=E2=80=99s explicitly = allowed by the OpenID Foundation.  See this text athttp://openid.net/specs/openid-connect-registration-1_0.html#No= tices =E2=80=93 = the spec from which text was copied:
 
The OpenID Foundation = (OIDF) grants to any Contributor, developer, implementer, or other = interested party a non-exclusive, royalty free, worldwide copyright = license to reproduce, prepare derivative works from, distribute, perform = and display, this Implementers Draft or Final Specification solely for = the purposes of (i) developing specifications, and (ii) implementing = Implementers Drafts and Final Specifications based on such documents, = provided that attribution be made to the OIDF as the source of the = material, but that such attribution does not indicate an endorsement by = the OIDF.
 
You could pass that on = to the appropriate IETF legal counsel if they=E2=80=99re not already = aware of it.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = Of Kathleen = Moriarty
Sent: Tuesday, February 24, 2015 = 3:08 PM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] AD review of = Draft-ietf-dyn-reg
 
Hello,
 
Thanks for updating the draft.  I just want to = confirm that Hannes is okay with the updated definitions and updates the = shepherd report to reflect that.
 
This is getting held up a bit while we sort through = copyright of text from UMA and OpenID.  The text from UMA went into = an IETF draft, so that should be the reference as it clears up any = possible issues as they provided that text in an IETF draft.  
 
The chairs will be helping to sort out = the requirements with OpenID, per our discussions the IETF = trustees.  I'm not sure how long this will take, but wanted to = provide a status so no one thought this had been dropped.
 
Thanks.
 
On Wed, Feb 18, 2015 at 12:57 PM, Hannes = Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi = Justin, Hi John,

I believe that = provisioning a client with a unique id (which is what a
client id/client secret is) allows some form of linkability. = While it
may be possible to associate the client to a = specific user I could very
well imagine that the = correlation between activities from a user and
those from = the client (particularly when the client is running on the
user's device) is quite possible.

Ciao
Hannes

On = 02/18/2015 06:37 PM, Justin Richer wrote:
> I=E2=80=99ll = incorporate this feedback into another draft, to be posted by the
> end of the week. Thanks everyone!
>
>  =E2=80=94 Justin
>
>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>> <kathleen.moriarty.ietf@gmail.com
>> = <mailto:kathleen.moriarty.ietf@gmail.com>> wrote:
>>
>>
>>
>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley = <ve7jtb@ve7jtb.com
>> <mailto:ve7jtb@ve7jtb.com>> wrote:
>>
>>     snip
>>>     On Feb 18, 2015, at 6:46 AM, = Kathleen Moriarty
>>>     <kathleen.moriarty.ietf@gmail.com
>>>     <mailto:kathleen.moriarty.ietf@gmail.com>> wrote:
>>>
>>>      =    > The client_id *could* be short lived, but they usually = aren't. I don't see any particular logging or tracking concerns using a = dynamic OAuth client above using any other piece of software, ever. As = such, I don't think it requires special calling out here.
>>>
>>>
>>>     Help me understand why there = should not be text that shows this
>>>  =    is not an issue or please propose some text.  This is = bound to
>>>     come up in IESG = reviews if not addressed up front.
>>>
>>>
>>
>>     The client_id is used to = communicate to the Authorization server
>>  =    to get a code or refresh token.  Those tokens uniquely = identify
>>     the user from a = privacy perspective.
>>     It is the = access tokens that are sent to the RS and those can and
>>     should be rotated, but the = client)id is not sent to the RS in
>>    =  OAuth as part of the spec.
>>
>>     If you did rotate the client_id = then the AS would track it across
>>    =  rotations, so it wouldn=E2=80=99t really achieve anything.
>>
>>     One thing = we don=E2=80=99t do is allow the client to specify the
>>     client_id, that could allow = correlation of the client across
>>    =  multiple AS and that might be a privacy issue, but we don=E2=80=99t = allow it.
>>
>>
>> Thanks, John.  It may be helpful to add in this = explanation unless
>> there is some reason not = to?
>>
>>
>>     John B.
>>
>>
>>
>>
>> --
>>
>> = Best regards,
>> Kathleen
>> = _______________________________________________
>> = OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth

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



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

= --Apple-Mail=_03BAF2AC-421A-4A9D-82DD-15FBF635CAEA-- --Apple-Mail=_4E15337C-1843-4560-ACE8-5340F49A130A 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 SIb3DQEJBTEPFw0xNTAyMjUwMjAzMjhaMCMGCSqGSIb3DQEJBDEWBBSvDwStRNdMI+H153yeAR4l c6oxbTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAU/nxhp/h6MWAmmPLyolDL/QlXjNwBBhnxEueVGwLXUCAH3S9JmGV7 Ac6nBRy5hWzkmvZAUPqmP/mYgFCPGgXA7jL+/gXr7OyHSvk7Roe9qMrnlCsE+NswYdgAWwyxuUiE ul/lk932OjNj0ar4iiaEod5bAypgoBkNFGQEA49h8fNhhqK4mnKWG4JIartZGcQz7TzAKbVMnEsH ziFkLrNKm4vGwrYUsCVuPwcOlc4QdU8xFl65zSdwTvO1o2d/usLoX8aLl6BS7q6DOuZUtTu5Osxt Mvbi0k3J96kSVVmLoVuBW02HHbIpXnBKzNMZqvYoSav4uyHCKjBz1wiaj8IJAAAAAAAA --Apple-Mail=_4E15337C-1843-4560-ACE8-5340F49A130A--