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 6AE953A0A0B for ; Fri, 22 May 2020 00:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 AtQIlzoVkTwH for ; Fri, 22 May 2020 00:52:12 -0700 (PDT) Received: from p3plsmtpa12-09.prod.phx3.secureserver.net (p3plsmtpa12-09.prod.phx3.secureserver.net [68.178.252.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593BF3A07CE for ; Fri, 22 May 2020 00:52:12 -0700 (PDT) Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id c2TQj99H0UpoQc2TRj0gmn; Fri, 22 May 2020 00:52:11 -0700 x-spam-cmae: v=2.3 cv=C9SXNjH+ c=1 sm=1 tr=0 p=_Y5QVBCcAAAA:8 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=__SxRlIrAAAA:8 a=is3RsFX7AAAA:8 a=48vgC7mUAAAA:8 a=d3zCVR3oQ2Bl2PlXulcA:9 a=K4+QNa6dn7cCZlPPpztru4orrlc=:19 a=cS2Fm5A1SFEntd8t:21 a=XxFVu_QeCrdj8Z_A:21 a=QEXdDO2ut3YA:10 a=jl1lMIPSATsA:10 a=058By5spHmhxsZOHdMEA:9 a=3RP4rZn5U4b9dSmJ:21 a=vPJilCChBJUvBDqY:21 a=MWNR8Cv-JauBcsp_:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=H5r4HjhRfVyZ-DhAOYba:22 a=CvJ-9y_HEmGQg9NJmnFv:22 a=w1C3t2QeGrPiZgrLijVG:22 a=IdGyktwZ2tr74praB_5u:22 x-spam-account: vladimir@connect2id.com x-spam-domain: connect2id.com X-CMAE-Analysis: v=2.3 cv=C9SXNjH+ c=1 sm=1 tr=0 p=_Y5QVBCcAAAA:8 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=__SxRlIrAAAA:8 a=is3RsFX7AAAA:8 a=48vgC7mUAAAA:8 a=d3zCVR3oQ2Bl2PlXulcA:9 a=K4+QNa6dn7cCZlPPpztru4orrlc=:19 a=cS2Fm5A1SFEntd8t:21 a=XxFVu_QeCrdj8Z_A:21 a=QEXdDO2ut3YA:10 a=jl1lMIPSATsA:10 a=058By5spHmhxsZOHdMEA:9 a=3RP4rZn5U4b9dSmJ:21 a=vPJilCChBJUvBDqY:21 a=MWNR8Cv-JauBcsp_:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=H5r4HjhRfVyZ-DhAOYba:22 a=CvJ-9y_HEmGQg9NJmnFv:22 a=w1C3t2QeGrPiZgrLijVG:22 a=IdGyktwZ2tr74praB_5u:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: Torsten Lodderstedt Cc: Joseph Heenan , Openid-specs-fapi , oauth References: <2066e8dd-fac8-db15-6d5c-19b11db050a2@connect2id.com> <72D97116-747B-47FE-A4D7-E729B708E723@fintechlabs.io> <365a545e-cd20-65c7-c7ae-d71c63865fce@connect2id.com> <78531853-D0B1-492C-85DA-E140A921B04B@lodderstedt.net> From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: <99394ea7-4588-5a5e-6997-bb96a19a1196@connect2id.com> Date: Fri, 22 May 2020 10:52:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <78531853-D0B1-492C-85DA-E140A921B04B@lodderstedt.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040607050104010804090001" X-CMAE-Envelope: MS4wfCTCCIvkpcSkg7GaCiRuGKnrJSqGRXlm7p3s3iyuZOPG5Lsx+mXKDEz3+oskWICHOrDvyrNN39GG1m7BK/ZX91f9JqgmyTcXgtU7v0qQyxzR0ThXCGZb ckXaEEHGUnC7QlUxqE0SCneZADVASauOHD+Xg7cNZpFKFqccj0QRRH5IaKeBp7JA7ZmAfMrB8MIAETXGWWoR3amXpnOMxn7EC91Uuds8wzGqP8BxANhUXQ0f 1pFp+MzfRxgQPM5G2dfhBgi3OwJ1/SOujyDzsjUBz7xhxDD8XircPogPrh124eWg Archived-At: Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 07:52:17 -0000 This is a cryptographically signed message in MIME format. --------------ms040607050104010804090001 Content-Type: multipart/alternative; boundary="------------7BEAFDC57463DC52A84464EB" Content-Language: en-US This is a multi-part message in MIME format. --------------7BEAFDC57463DC52A84464EB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable With that said it makes sense to devise a structure which can accommodate UI driven as well as automatic choice. * The UI driven chooser will need a human readable description and other UI hints. This can work for instance with "classic" OIDC Discovery. * The "auto" chooser will need some sort of an ID. For a bank chooser this means providing the issuer URI and an optional brand ID and both must get registered together. Or, one could define a standard brand ID (label) for banking operations and if the "alternative_authorization_endpoints" is present look for it in the structure, else fall back to the default "authorization_endpoint". Here is one possible layout which has IDs and UI hints: { ... "alternative_authorization_endpoints": { "banking": { "authorization_endpoint": "https://loadsamoney/business/auth", "description": "loadsmoney business banking customers", "logo_url": "https://loadsamoney/business/logo.png" }, "personal": { "authorization_endpoint": "https://loadsamoney/consumer/auth", "description": "loadsmoney personal customers", "logo_url": "https://loadsamoney/consumer/logo.png" } } } On 22/05/2020 09:59, Torsten Lodderstedt wrote: > I think an id or label per endpoint set would be needed to determine th= e set of endpoints to be used by a certain client. > > On the conceptual side, I=E2=80=99m asking myself how the complete proc= ess is supposed to work. Who is deciding what issuer/endpoint set combina= tion to use. I assume in an open banking scenario, there will always be s= ome kind of bank chooser. Will this chooser provide the client with issue= r and brand id?=20 > >> On 22. May 2020, at 08:10, Vladimir Dzhuvinov wrote: >> >> A mapping like the one you propose can definitely work. Since the user= will be making the choice which endpoint to take with the client app, ha= ving the logo_uri is a good idea. If the branded endpoints differ somehow= in policy one could also allow inclusion of the op_policy_uri and op_tos= _uri params from Discovery. >> >> https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDisco= very >> >> Vladimir >> >> On 20/05/2020 19:16, Joseph Heenan wrote: >>> Thanks for your thoughts Vladimir! >>> >>> The client_id based solution I wasn=E2=80=99t previously aware of - u= nfortunately it doesn=E2=80=99t solve the problem for app2app, as the mob= ile OS selects the app to use based purely on the URL (and in at least th= e iOS case will not offer the user a choice if multiple apps claim to han= dle the same url). >>> >>> I think some kind of mapping like you suggest will work and fallback,= I wonder about a structure in the authorization server metadata somethin= g like this: >>> >>> { >>> ... >>> "alternative_authorization_endpoints": [ >>> { >>> "authorization_endpoint": "https://loadsamoney/business/auth", >>> "description": "loadsmoney business banking customers", >>> "logo_url": "https://loadsamoney/business/logo.png" >>> }, >>> { >>> "authorization_endpoint": "https://loadsamoney/consumer/auth", >>> "description": "loadsmoney personal customers", >>> "logo_url": "https://loadsamoney/consumer/logo.png" >>> } >>> ] >>> } >>> >>> And as you say, the existing authorization_endpoint can be a fallback= for clients that are unaware of the new spec or prefer the simpler optio= n of just using a single authorization endpoint. Supporting the new spec = would allow a better UX though so there=E2=80=99s advantages to client to= do so. >>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can b= e sensibly combined with the proposed multi-brand spec. >>>> >>> I think that particular part is not really an issue as mtls isn=E2=80= =99t used at the authorization endpoint. >>> >>> Thanks >>> >>> Joseph >>> >>> >>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov wrote: >>>> >>>> Hi Dave, >>>> >>>> In the absence of such a "multi-brand" spec we have tackled this iss= ue in the past by letting the "brand" be encoded in the client_id. An alt= ernative scenario is to do a "brand" lookup by client_id. Then let the AS= render the "branded" authZ endpoint. >>>> >>>> You're probably aware the mTLS spec is allowing for endpoint aliases= , so this is not the first time such as need has occurred: >>>> >>>> https://tools.ietf.org/html/rfc8705#section-5 >>>> >>>> One could devise a similar JSON object with mappings "label" - "auth= orization_endpoint". >>>> >>>> Clients that are aware of the new spec will look it up, those that a= re not will fall back to the std "authorization_endpoint". >>>> >>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can b= e sensibly combined with the proposed multi-brand spec. >>>> >>>> >>>> >>>> Vladimir >>>> >>>> >>>> >>>> On 20/05/2020 15:07, Dave Tonge wrote: >>>>> Dear OAuth WG >>>>> >>>>> We have an issue in the OpenID FAPI Working Group that we believe a= ffects the wider OAuth community. >>>>> >>>>> In summary: what is the recommended approach to discovery (RFC8414)= for Authorization Servers who support multiple "brands" . >>>>> >>>>> If brands are completely separate, then it seems sensible that each= brand must have its own `issuer` and therefore its own discovery documen= t at the correct location (i.e. brand 1 would have an issuer of "https://= as/brand1" and a discovery document available at https://as/.well-known/= oauth-authorization-server/brand1). >>>>> >>>>> However in the real world it is not always so simple. We have many = existing implementations in UK open banking that support multiple authori= zation endpoints. Here is an example (thanks to @Joseph Heenan ) >>>>> >>>>>> Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp and, for internet b= anking, one =E2=80=9Clogin page=E2=80=9D for both business and personal c= ustomers. >>>>>> They have separate mobile apps for business/personal, and are requ= ired to support app2app. This means they will definitely be exposing mult= iple authorization endpoints (as there=E2=80=99s a 1:1 mapping of authori= zation endpoints to mobile apps) - the choice is how they do this. >>>>>> Their choices are: >>>>>> 1. Multiple discovery endpoints (one for business, one for persona= l), each with a different authorization endpoint, multiple issuers (if th= eir vendor allows this) >>>>>> 2. Single discovery endpoint, single issuer, multiple authorizatio= n endpoints listed in one discovery doc (one for business, one for person= al) some of which are hardcoded by the 3rd party >>>>>> 3. Multiple discovery endpoints each with a different authorizatio= n endpoint, same issuer in all cases (breaks RFC8414 and OIDC Discovery) >>>>> Option 3 is invalid and that leaves us with options 1 and 2.=20 >>>>> Option 1 can be problematic as often it is in reality the same `iss= uer` behind the scenes. >>>>> >>>>> We would like to get feedback on this issue and potentially an exte= nsion to RFC8414 to allow the definition of multiple authorization endpoi= nts. >>>>> >>>>> Thanks in advance >>>>> >>>>> Dave Tonge >>>>> Co-Chair FAPI WG >>>>> Open ID Foundation >>>>> >>>>> >> --=20 >> Vladimir Dzhuvinov >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --=20 Vladimir Dzhuvinov --------------7BEAFDC57463DC52A84464EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

With that said it makes sense to devise a structure which can accommodate UI driven as well as automatic choice.

  • The UI driven chooser will need a human readable description and other UI hints. This can work for instance with "classic" OIDC Discovery.

  • The "auto" chooser will need some sort of an ID. For a bank chooser this means providing the issuer URI and an optional brand ID and both must get registered together. Or, one could define a standard brand ID (label) for banking operations and if the "alternative_authorization_endpoints" is present look for it in the structure, else fall back to the default "authorization_endpoint".

Here is one possible layout which has IDs and UI hints:

{
  ...
  "alternative_authorization_endpoints": {
    "banking": {
      "authorization_endpoint": "https://loadsamoney/business/auth",
      "description": "loadsmoney business banking customers",
      "logo_url": "https://loadsamoney/business/logo.png"
    },
    "personal": {
      "authorization_endpoint": "https://loadsamoney/consumer/auth",
      "description": "loadsmoney personal customers",
      "logo_url": "https://loadsamoney/consumer/logo.png"
    }
  }
}


On 22/05/2020 09:59, Torsten Lodderstedt wrote:
I think an id or label per e=
ndpoint set would be needed to determine the set of endpoints to be used =
by a certain client.

On the conceptual side, I=E2=80=99m asking myself how the complete proces=
s is supposed to work. Who is deciding what issuer/endpoint set combinati=
on to use. I assume in an open banking scenario, there will always be som=
e kind of bank chooser. Will this chooser provide the client with issuer =
and brand id?=20


On 22. May 2020, at 08:10,=
 Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

A mapping like the one you propose can definitely work. Since the user wi=
ll be making the choice which endpoint to take with the client app, havin=
g the logo_uri is a good idea. If the branded endpoints differ somehow in=
 policy one could also allow inclusion of the op_policy_uri and op_tos_ur=
i params from Discovery.

https://openid.net/specs/op=
enid-connect-discovery-1_0.html#IssuerDiscovery

Vladimir

On 20/05/2020 19:16, Joseph Heenan wrote:

Thanks for your thoughts=
 Vladimir!

The client_id based solution I wasn=E2=80=99t previously aware of - unfor=
tunately it doesn=E2=80=99t solve the problem for app2app, as the mobile =
OS selects the app to use based purely on the URL (and in at least the iO=
S case will not offer the user a choice if multiple apps claim to handle =
the same url).

I think some kind of mapping like you suggest will work and fallback, I w=
onder about a structure in the authorization server metadata something li=
ke this:

{
  ...
  "alternative_authorization_endpoints": [
    {
      "authorization_endpoint": "https://loadsamoney/business/auth",
      "description": "loadsmoney business banking customers",
      "logo_url": "https://loadsamoney/business/logo.png"
    },
    {
      "authorization_endpoint": "https://loadsamoney/consumer/auth",
      "description": "loadsmoney personal customers",
      "logo_url": "https://loadsamoney/consumer/logo.png"
    }
  ]
}

And as you say, the existing authorization_endpoint can be a fallback for=
 clients that are unaware of the new spec or prefer the simpler option of=
 just using a single authorization endpoint. Supporting the new spec woul=
d allow a better UX though so there=E2=80=99s advantages to client to do =
so.

Speaking of mTLS, I'm =
not sure how the "mtls_endpoint_aliases" can be sensibly combined with th=
e proposed multi-brand spec.


I think that particular =
part is not really an issue as mtls isn=E2=80=99t used at the authorizati=
on endpoint.

Thanks

Joseph



On 20 May 2020, at 16:=
07, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

Hi Dave,

In the absence of such a "multi-brand" spec we have tackled this issue in=
 the past by letting the "brand" be encoded in the client_id. An alternat=
ive scenario is to do a "brand" lookup by client_id. Then let the AS rend=
er the "branded" authZ endpoint.

You're probably aware the mTLS spec is allowing for endpoint aliases, so =
this is not the first time such as need has occurred:

https://tools.ietf.org/html/rfc8705#section-5

One could devise a similar JSON object with mappings "label" - "authoriza=
tion_endpoint".

Clients that are aware of the new spec will look it up, those that are no=
t will fall back to the std "authorization_endpoint".

Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be sen=
sibly combined with the proposed multi-brand spec.



Vladimir



On 20/05/2020 15:07, Dave Tonge wrote:

Dear OAuth WG

We have an issue in the OpenID FAPI Working Group that we believe affects=
 the wider OAuth community.

In summary: what is the recommended approach to discovery (RFC8414) for A=
uthorization Servers who support multiple "brands" .

If brands are completely separate, then it seems sensible that each brand=
 must have its own `issuer` and therefore its own discovery document at t=
he correct location (i.e. brand 1 would have an issuer of "https://as/brand1" an=
d a discovery document available at  https://=
as/.well-known/oauth-authorization-server/brand1).

However in the real world it is not always so simple. We have many existi=
ng implementations in UK open banking that support multiple authorization=
 endpoints. Here is an example (thanks to @Joseph Heenan )


Bank =E2=80=9Cload=
samoney=E2=80=9D has one idp and, for internet banking, one =E2=80=9Clogi=
n page=E2=80=9D for both business and personal customers.


              

                
They have separate=
 mobile apps for business/personal, and are required to support app2app. =
This means they will definitely be exposing multiple authorization endpoi=
nts (as there=E2=80=99s a 1:1 mapping of authorization endpoints to mobil=
e apps) - the choice is how they do this.


              

              

              

                
Their choices are:=



              

              

              

                
1. Multiple discov=
ery endpoints (one for business, one for personal), each with a different=
 authorization endpoint, multiple issuers (if their vendor allows this)
2. Single discovery endpoint, single issuer, multiple authorization endpo=
ints listed in one discovery doc (one for business, one for personal) som=
e of which are hardcoded by the 3rd party
3. Multiple discovery endpoints each with a different authorization endpo=
int, same issuer in all cases (breaks RFC8414 and OIDC Discovery)


              

              
Option 3 is invalid and that leaves us with options 1 and 2.=20
Option 1 can be problematic as often it is in reality the same `issuer` b=
ehind the scenes.

We would like to get feedback on this issue and potentially an extension =
to RFC8414 to allow the definition of multiple authorization endpoints.

Thanks in advance

Dave Tonge
Co-Chair FAPI WG
Open ID Foundation




            

            

          

          

        

        
--=20
Vladimir Dzhuvinov

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


      

      

    

    
--=20
Vladimir Dzhuvinov

  


--------------7BEAFDC57463DC52A84464EB--

--------------ms040607050104010804090001
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw
MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp
ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E
1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w
/GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr
xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ
U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f
/8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8
C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P
AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj
dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v
U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG
CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u
bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq
BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu
wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap
xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM
9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv
cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG
SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE
BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE
AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw
MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx
PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno
1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK
8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k
N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee
1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8
kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU
U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G
A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku
Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu
Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz
cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd
F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7
4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0
sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ
JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH
xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe
roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85
F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU
E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY
dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe
5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1MjIwNzUyMDhaMC8G
CSqGSIb3DQEJBDEiBCBoNFGJErhDNxurUEgS3onarv1ikbFe7uVaLCtppCzRcDBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAAZk0CZtOyeKZcgYtWU7UvrW0O37oDnkolyxAGhPvFo6O78O
Z+diNYdUiDupmjEl15o+7OPOFv2bV6YFDEw9pm3PhP0d2kOD8n8GJVu3MvnTk51oKyByLm+b
TqHVsSXhOTy+zbVXlxrA6qsIX5Z0bXFNbwuJwZvmivD0KW3eEXZhWt1vGin0Vx3WAx4Sl+Px
I8Ez3FeBdvIE2lMThWvXme3iEzRxMfskE0N1FBHiof2MI9G8e9Iv2p3XWegDAl1RTDSweTFX
kFKeFB6PkCCvOVi3AN4gOV9mYMk7NyWmcRp+oVgyOR5k86bgz0el2sawZwU1VQlQJG4Jb+cr
QMn94esAAAAAAAA=
--------------ms040607050104010804090001--