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 9A5D721F8EB5 for ; Thu, 9 May 2013 15:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS57uoZRVQvd for ; Thu, 9 May 2013 15:47:15 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1C82E21F8EB1 for ; Thu, 9 May 2013 15:47:14 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id s9so6753898iec.34 for ; Thu, 09 May 2013 15:47:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=pn5/vFLfblInKYVkKG4FMIJEFelmMBYmpx6B0amOQ28=; b=NYqlZ/fmzpSt8QH+03OMERXckM3Jb0SDytEBqdz4e35ZrqJUcB/6LoqMmI2NKANdRK 9DJVWuSoH83b3tFB/8KKYEhXXi3sS2ARgUlVyRgoHLLxU5L/BybB3ojNFeNUXJhycWhf eek2McoQqA2YQSF5vUi2FwELQUaoguJsMsq7xdTiVYWJoapsXeKifJtoUYvkC215FLSl cBSfvuzdWBvrW589vti7/uGutXqiBgMxagl55wFwykE6yWyAs2oerKpid3CSouUqFpCN 0ETmW6UJgbdnFHy8RpvBaQlPyvhEtKQwtq80lJZXnQMajBkBTxb7IsmlfHbvMasRWhG9 2Yfw== X-Received: by 10.50.60.102 with SMTP id g6mr11386igr.112.1368139633602; Thu, 09 May 2013 15:47:13 -0700 (PDT) Received: from [192.168.51.155] (ip65-46-254-110.z254-46-65.customer.algx.net. [65.46.254.110]) by mx.google.com with ESMTPSA id qs4sm172647igb.10.2013.05.09.15.47.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 15:47:12 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4E614468-7D4B-4B9C-949A-40F1892FB004"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <3B38531B-AED4-459C-9B9F-A57DE04AB467@oracle.com> Date: Thu, 9 May 2013 15:47:09 -0700 Message-Id: <915B3011-AD0E-49C4-B655-707092419A11@ve7jtb.com> References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> <86F7EC4C-DDF3-42B7-8355-A8C684CC2D2F@ve7jtb.com> <3B38531B-AED4-459C-9B9F-A57DE04AB467@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmdYAReJQEYXAg7xd8051pKhKe+F8CtyoXZIJl+MGq+B2TyShwgRean4ex/3b5e7099PM34 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 22:47:16 -0000 --Apple-Mail=_4E614468-7D4B-4B9C-949A-40F1892FB004 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Consider if you will a world where IdP support multiple LoA. This allows a RP to register the method required for there use case. If a Client requires the asymmetrically signed JWT assertions rather = than http basic, it doesn't want the Authorization server accepting = http_basic for it's client_id. The reason a client/RP would want to specify multiple LoA is the same = reason they may wan to in SAML or other protocols. The issue is more that different clients will have different security = requirements and this allows them to dynamic register those. If you allow 2 and 3 the one that need 3 will specify that. John On 2013-05-09, at 3:32 PM, Phil Hunt wrote: > Giving the client the choice lets the client choose lower LoA and = downgrade. Surely it is the server that is taking the risk so the = server has the right to set the requirements. >=20 > Why would a server tolerate multiple levels of LoA from the same = client application? Why is that needed? >=20 > If a server allows 2 and 3, then all clients will choose 2 -- or at = the very least your overall security drops to 2. This is not good. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-09, at 3:17 PM, John Bradley wrote: >=20 >> The client needs to be able to say only use a particular auth method = to disallow the Authorization server from providing a weaker method to = an attacker. =20 >>=20 >> This is a required parameter to allow a Authorization server to = support high and low LoA clients dynamically. >>=20 >> John B. >>=20 >>=20 >> On 2013-05-09, at 2:44 PM, Phil Hunt wrote: >>=20 >>> Justin, >>>=20 >>> Just to progress towards resolving this issue, what I would like to = understand is how specifying authentication type makes things simpler or = more inter-operable. I'm concerned that the logic you proposed early in = the thread is a lot more complexity. I would prefer just having the = server tell the client what authentication it MUST use. >>>=20 >>> As an alternative, the negotiation for credential method/type could = occur during the initial developer registration of the app. As in your = "blue button" health case (did I remember that right), the initial = registration JWT would be used in the dynamic registration and allow the = registration server to observe any previously negotiated client = preferences OOB of this spec. Or, are you saying that individual = instances have some need to change authentication types on a per = deployment basis independent of what the associated authorization server = wants them to use? If so what is it? >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2013-05-06, at 11:56 AM, Phil Hunt wrote: >>>=20 >>>> Justin, >>>>=20 >>>> What you describe, though good intentioned, seems like a lot of = complexity without getting an actual benefit. I would rather not have = token_endpoint_auth_method at all. >>>>=20 >>>> Think about someone writing a general purpose SCIM client or OIDC = client. Site as uses method 1 and 2, site b supports 2,3 and 4. Site c = only 5 and 6. So if each site is willing to negotiate authn, how has = this developer's coding been reduced? The developer will end up having = to implement all popular methods regardless of discovery or the ability = of the client to select. In fact, they have to do all the logic you = describe below AND implement all methods. >>>>=20 >>>> I have also thought through, does it matter since it is optional? = I think it does. If servers just ignore the param most of the time, what = value is there? >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >>>>=20 >>>>> In spite of what John seems to think, that dependency was never = there. The whole discovery process is related, but separate, from = registration. It could happen using OIDC, it could happen with Bill = Mills's LRDD link types, it could happen with Nat's proposed HAL-based = system, it could happen by the developer going to the service provider's = documentation page and reading a bunch of text (which is what happens = with large OAuth providers today) -- it ultimately doesn't matter.=20 >>>>>=20 >>>>> And I think that the Dynamic Registration protocol that we have = here is robust against that kind of diversity. Let's take the = token_endpoint_auth_method parameter as an example. Let's say a client = shows up to a service it's just discovered -- through whatever means, we = don't actually care. This client either has some idea of what auth = methods the server supports (through a discovery mechanism) or it = doesn't. If it does, it will also know which methods it supports and it = can pick one. If it doesn't, it will still know which methods it = supports and will just pick one. The server will then take that = information and do one of three things: >>>>>=20 >>>>> 1) Accept what the client proposes and use that. This is of course = the ideal situation where everybody gets what they want, and this can be = brought about more often by a good discovery process. >>>>> 2) Reject what the client proposes with an error code = (invalid_client_metadata would cover this). The client then has to = re-register with a different value or just give up because the two = systems are using different auth methods that can't be reconciled. >>>>> 3) Ignore what the client proposes and return the server's = preferred method. The client can then, in turn: >>>>> a) Accept what the server returns and use that, if it supports it. = This is also ideal because everybody is happy again. >>>>> b) Reject what the server returns and either try the registration = again with another value or give up. >>>>> c) Ignore what the server returns and fail when doing a token = request. This would be a dumb thing for a dumb client to do.=20 >>>>>=20 >>>>> Alternatively, the client could just not mention it and have the = server dictate what method it will use, and the client will either = accept, reject, or ignore it. This process applies to every parameter in = the system, from something innocuous as the client's TOS uri to = something as security-critical as the redirect_uri (which gets its own = special error message).=20 >>>>>=20 >>>>> I think that the assumption of full automation for all clients to = all servers is a red herring in the OAuth world for the simple fact that = the API that's being accessed/protected isn't going to be universally = compatible anyway. I agree fully that a well-specified service discovery = is important and we should, as a working group, help figure out what = that looks like. As mentioned above, several of us already are. But I = don't think it's helpful to conflate the registration and discovery = processes and turn them into some kind of negotiation system. I think we = can do a good job of making it widely useful without that. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> On May 5, 2013, at 1:05 PM, Phil Hunt >>>>> wrote: >>>>>=20 >>>>>> Justin, >>>>>>=20 >>>>>> Has the assumption of a discovery service defined by OIDC been = removed? >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>>>>=20 >>>>>>> Handful of minor changes in this revision, including tightening = the language around scopes and adding an absolute-URI based mechanism = for extending token_endpoint_auth_method (no registry, still). No = normative changes beyond removing an unreachable error state. (Thanks, = Nov.) Please check the diffs, we welcome feedback. I personally think = this is really getting close to final. >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>> On May 5, 2013, at 3:45 PM, >>>>>>> wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>> This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>>>>>>>=20 >>>>>>>> Title : OAuth 2.0 Dynamic Client Registration = Protocol >>>>>>>> Author(s) : Justin Richer >>>>>>>> John Bradley >>>>>>>> Michael B. Jones >>>>>>>> Maciej Machulak >>>>>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>>>>> Pages : 25 >>>>>>>> Date : 2013-05-05 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> This specification defines an endpoint and protocol for dynamic >>>>>>>> registration of OAuth 2.0 Clients at an Authorization Server = and >>>>>>>> methods for the dynamically registered client to manage its >>>>>>>> registration. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>>>=20 >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>>>>=20 >>>>>>>> A diff from the previous version is available at: >>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>>>>>>=20 >>>>>>>>=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 >>>>>=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 >>=20 >=20 --Apple-Mail=_4E614468-7D4B-4B9C-949A-40F1892FB004 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTA5MjI0NzEwWjAjBgkqhkiG9w0BCQQxFgQU+0/R1Nj0 OWjQ8gKbEitdnJdJnaswgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAYXGH36PtboIgTZfhSU9AdgSCocgUz6nT0COFvFEz JM6TPf8/1sSgpx2Tesks6wcYoSlbrKzQtHiuOIOnYCxSYjBcnSAzrEGPOp+ZqzGh8ouvreFEI3mO 9MgZaGUIcM7M+xvzn3hEKTKhSv80bq5LrcfzejqsWbnHmYUO6XniUMX2HxLqrPnHY6ba3/1mVYeG O+J4QpXx8eV9X8I3Np0bWrT2VuzxJesR9hcZxr3zyQY0rlDj/rouU8njAG7a54ApVTjHq32onJ/8 qXmUtao3yVDFTaBqj/vhnzbjDJpVJhmt3VVQkGFPdmCnmfM+acscd5tr5GwPSEGo+ZIqt08z4gAA AAAAAA== --Apple-Mail=_4E614468-7D4B-4B9C-949A-40F1892FB004--