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 02E3E3A0B26 for ; Mon, 25 May 2020 23:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 86-vz96qHrqE for ; Mon, 25 May 2020 23:03:21 -0700 (PDT) Received: from p3plsmtpa12-07.prod.phx3.secureserver.net (p3plsmtpa12-07.prod.phx3.secureserver.net [68.178.252.236]) (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 2EAC23A0B24 for ; Mon, 25 May 2020 23:03:19 -0700 (PDT) Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id dSgGj74CM0xLkdSgHjgSGo; Mon, 25 May 2020 23:03:18 -0700 X-CMAE-Analysis: v=2.3 cv=D7M51cZj c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=__SxRlIrAAAA:8 a=is3RsFX7AAAA:8 a=48vgC7mUAAAA:8 a=xdqwTLYnAAAA:8 a=-u-YU2za4N9UWmFB5zEA:9 a=K4+QNa6dn7cCZlPPpztru4orrlc=:19 a=JkxfWD9QpNFVG-6c:21 a=-68rJ_tc1RoGImx6:21 a=QEXdDO2ut3YA:10 a=jl1lMIPSATsA:10 a=pGLkceISAAAA:8 a=0lhL6yGjzcYyPZIURakA:9 a=EVILO4TRa6uCCJAI:21 a=Ec08Onk6jMp4x0RA:21 a=9OfL4BNMrbms6Q34: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=I3GVSKNlf5WA1x-hengb:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: oauth@ietf.org References: 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: <2fc4c4ee-8627-936a-baf4-872c0f18eca6@connect2id.com> Date: Tue, 26 May 2020 09:03:16 +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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000308010705070301060701" X-CMAE-Envelope: MS4wfETxXU+wONL5iS+3Wap6bSD4c42RvOPWafXekh7MqRCivaUmqOFvyjskeEZ8z1S0L/IbFIxI7JSArIbdVr9H7wTU6BxnnNHxbT2Uf4i2yu/SoVXYkOkG gZsGkjPE610esALbZBT+8NnsOXqTEj/wA67L3VaunQdi5xAIv25q7Kr+ 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: Tue, 26 May 2020 06:03:27 -0000 This is a cryptographically signed message in MIME format. --------------ms000308010705070301060701 Content-Type: multipart/alternative; boundary="------------07F764E670E63573430F64D7" Content-Language: en-US This is a multi-part message in MIME format. --------------07F764E670E63573430F64D7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable My understanding of the branding concept was to present different UIs to resource owners during login and authorization, while keeping the OP / AS the same, meaning identical issuer. In a spec it would be helpful to spell out what branding means (and what not). Regarding a token being issued for "personal" vs "business" and confusion - the usage of the token is normally defined by its scope and audience (RS) and if this rule is observed (and it's not relied solely on the issuer URI for that) then clients shouldn't get confused here. Vladimir On 23/05/2020 06:26, Francis Pouatcha wrote: > - I will go for Option 1 even if we have the same runtime instance > producing tokens under different=C2=A0issuer uris. > - Option 2 might expose security risk as many clients rely on > the=C2=A0issuer to associate the=C2=A0 token with authorization context= =2E By no > way shall a token issued for "personal" be valid for "business". > Therefore considering=C2=A0the=C2=A0use of the=C2=A0same issuer here mi= ght lead to > confusion at the=C2=A0RP. > - In order to avoid confusion, AS must make=C2=A0sure each "brand" > uses=C2=A0separated key material to produce the token. > > BTW: > The term brand as used in the context of most Open Banking initiatives > refers to entities consuming the Interface provided by TPPs (Third > Party Providers).. TPPs play the roles of RPs in the oAuth2 context. > > Unless I misunderstood this thread we are using a brand here to refer > to an AS virtual host (issuer-uri). > > Going forward, we need=C2=A0to=C2=A0agree on choosing another term to r= efer to > issuers, and leave the term "Brand" for consumers of TPP-interfaces. > > The core brand problem we will be facing in open banking is for having > the AS display the "consumer-brand" logo to the RO in the consent scree= n. > > > >> On 22 May 2020, at 08:52, Vladimir Dzhuvinov > > wrote: > >> > >> With that said it makes sense to devise a structure which can > accommodate UI driven as well as automatic choice. > >> > >>=C2=A0 =C2=A0 =C2=A0 ? The UI driven chooser will need a human re= adable > description and other UI hints. This can work for instance with > "classic" OIDC Discovery. > >> > >>=C2=A0 =C2=A0 =C2=A0 ? 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: > >> > >> { > >>=C2=A0 =C2=A0... > >>=C2=A0 =C2=A0"alternative_authorization_endpoints": { > >>=C2=A0 =C2=A0 =C2=A0"banking": { > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint": > >> "https://loadsamoney/business/auth" > >> , > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "loadsmoney business ba= nking customers", > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url": > >> "https://loadsamoney/business/logo.png" > >> > >>=C2=A0 =C2=A0 =C2=A0}, > >>=C2=A0 =C2=A0 =C2=A0"personal": { > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint": > >> "https://loadsamoney/consumer/auth" > >> , > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "loadsmoney personal cu= stomers", > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url": > >> "https://loadsamoney/consumer/logo.png" > >> > >>=C2=A0 =C2=A0 =C2=A0} > >>=C2=A0 =C2=A0} > >> } > >> > >> > >> > >> On 22/05/2020 09:59, Torsten Lodderstedt wrote: > >>> I think an id or label per endpoint set would be needed to > determine the set of endpoints to be used by a certain client. > >>> > >>> On the conceptual side, I?m asking myself how the complete > process is supposed to work. Who is deciding what issuer/endpoint > set combination to use. I assume in an open banking scenario, > there will always be some kind of bank chooser. Will this chooser > provide the client with issuer and brand id? > >>> > >>> > >>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov > > > >>>>=C2=A0 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, having 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#IssuerDi= scovery > >>>> > >>>> > >>>> Vladimir > >>>> > >>>> On 20/05/2020 19:16, Joseph Heenan wrote: > >>>> > >>>>> Thanks for your thoughts Vladimir! > >>>>> > >>>>> The client_id based solution I wasn?t previously aware of - > unfortunately it doesn?t solve the problem for app2app, as the > mobile OS selects the app to use based purely on the URL (and in > at least the iOS 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 wonder about a structure in the authorization server > metadata something like this: > >>>>> > >>>>> { > >>>>>=C2=A0 =C2=A0... > >>>>>=C2=A0 =C2=A0"alternative_authorization_endpoints": [ > >>>>>=C2=A0 =C2=A0 =C2=A0{ > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint": > >>>>> "https://loadsamoney/business/auth" > >>>>> , > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "loadsmoney business= banking customers", > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url": > >>>>> "https://loadsamoney/business/logo.png" > >>>>> > >>>>>=C2=A0 =C2=A0 =C2=A0}, > >>>>>=C2=A0 =C2=A0 =C2=A0{ > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint": > >>>>> "https://loadsamoney/consumer/auth" > >>>>> , > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "loadsmoney personal= customers", > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url": > >>>>> "https://loadsamoney/consumer/logo.png" > >>>>> > >>>>>=C2=A0 =C2=A0 =C2=A0} > >>>>>=C2=A0 =C2=A0] > >>>>> } > >>>>> > >>>>> 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 would allow a better UX though so there?s > advantages to client to do so. > >>>>> > >>>>>> Speaking of mTLS, I'm not sure how the > "mtls_endpoint_aliases" can be sensibly combined with the proposed > multi-brand spec. > >>>>>> > >>>>>> > >>>>> I think that particular part is not really an issue as mtls > isn?t used at the authorization endpoint. > >>>>> > >>>>> Thanks > >>>>> > >>>>> Joseph > >>>>> > >>>>> > >>>>> > >>>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov > > > >>>>>>=C2=A0 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 alternative 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" - "authorization_endpoint". > >>>>>> > >>>>>> Clients that are aware of the new spec will look it up, > those that are not will fall back to the std "authorization_endpoin= t". > >>>>>> > >>>>>> Speaking of mTLS, I'm not sure how the > "mtls_endpoint_aliases" can be 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 affects 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 document at the correct location (i.e. brand 1 would > have an issuer of > >>>>>>> "https://as/brand1" and a discovery document available at=C2= =A0 > 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 authorization endpoints. Here is an example (thanks to > @Joseph Heenan ) > >>>>>>> > >>>>>>> > >>>>>>>> Bank ?loadsamoney? has one idp and, for internet banking, > one ?login page? 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 endpoints (as there?s a 1:1 > mapping of authorization endpoints to mobile apps) - the choice is > how they do this. > >>>>>>>> > >>>>>>>> Their choices are: > >>>>>>>> > >>>>>>>> 1. Multiple discovery 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 endpoints listed in one discovery doc (one for > business, one for personal) some of which are hardcoded by the 3rd > party > >>>>>>>> 3. Multiple discovery endpoints each with a different > authorization endpoint, same issuer in all cases (breaks RFC8414 > and OIDC Discovery) > >>>>>>>> > >>>>>>> Option 3 is invalid and that leaves us with options 1 and 2= =2E > >>>>>>> Option 1 can be problematic as often it is in reality the > same `issuer` behind 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 > >>>>>>> > >>>>>>> > >>>>>>> > >>>> -- > >>>> Vladimir Dzhuvinov > > --=20 > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Vladimir Dzhuvinov --------------07F764E670E63573430F64D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

My understanding of the branding concept was to present different UIs to resource owners during login and authorization, while keeping the OP / AS the same, meaning identical issuer. In a spec it would be helpful to spell out what branding means (and what not).

Regarding a token being issued for "personal" vs "business" and confusion - the usage of the token is normally defined by its scope and audience (RS) and if this rule is observed (and it's not relied solely on the issuer URI for that) then clients shouldn't get confused here.

Vladimir

On 23/05/2020 06:26, Francis Pouatcha wrote:
- I will go for Option 1 even if we have the same runtime instance producing tokens under different=C2=A0issuer uris.
- Option 2 might expose security risk as many clients rely on the=C2=A0issuer to associate the=C2=A0 token with authorizat= ion context. By no way shall a token issued for "personal" be valid for "business". Therefore considering=C2=A0the=C2=A0use o= f the=C2=A0same issuer here might lead to confusion at the=C2=A0R= P.
- In order to avoid confusion, AS must make=C2=A0sure each "brand" uses=C2=A0separated key material to produce the token.<= br>

BTW:
The term brand as used in the context of most Open Banking initiatives refers to entities consuming the Interface provided by TPPs (Third Party Providers).. TPPs play the roles of RPs in the oAuth2 context.

Unless I misunderstood this thread we are using a brand here to refer to an AS virtual host (issuer-uri).

Going forward, we need=C2=A0to=C2=A0agree on choosing anothe= r term to refer to issuers, and leave the term "Brand" for consumers of TPP-interfaces.

The core brand problem we will be facing in open banking is for having the AS display the "consumer-brand" logo to the RO in the consent screen.

>> On 22 May 2020, at 08:52, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
>>
>> With that said it makes sense to devise a structure which can accommodate UI driven as well as automatic choice.<= br> >>
>>=C2=A0 =C2=A0 =C2=A0 ? The UI driven chooser will nee= d a human readable description and other UI hints. This can work for instance with "classic" OIDC Discovery.
>>
>>=C2=A0 =C2=A0 =C2=A0 ? The "auto" chooser will need s= ome 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:
>>
>> {
>>=C2=A0 =C2=A0...
>>=C2=A0 =C2=A0"alternative_authorization_endpoints": {=
>>=C2=A0 =C2=A0 =C2=A0"banking": {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint": =
>> "https://loadsamoney/business/auth"
>> ,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "loadsmoney= business banking customers",
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url":
>> "https://loadsamoney/business/logo.png"
>>
>>=C2=A0 =C2=A0 =C2=A0},
>>=C2=A0 =C2=A0 =C2=A0"personal": {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization_endpoint": =
>> "https://loadsamoney/consumer/auth"
>> ,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "loadsmoney= personal customers",
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url":
>> "https://loadsamoney/consumer/logo.png"
>>
>>=C2=A0 =C2=A0 =C2=A0}
>>=C2=A0 =C2=A0}
>> }
>>
>>
>>
>> On 22/05/2020 09:59, Torsten Lodderstedt wrote:
>>> I think an id or label per endpoint set would be needed to determine the set of endpoints to be used by a certain client.
>>>
>>> On the conceptual side, I?m asking myself how the complete process is supposed to work. Who is deciding what issuer/endpoint set combination to use. I assume in an open banking scenario, there will always be some kind of bank chooser. Will this chooser provide the client with issuer and brand id?
>>>
>>>
>>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov <vladimir@connect= 2id.com>
>>>>=C2=A0 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, having 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?t previously aware of - unfortunately it doesn?t solve the problem for app2app, as the mobile OS selects the app to use based purely on the URL (and in at least the iOS 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 wonder about a structure in the authorization server metadata something like this:
= >>>>>
>>>>> {
>>>>>=C2=A0 =C2=A0...
>>>>>=C2=A0 =C2=A0"alternative_authorization_endpoints": [
>>>>>=C2=A0 =C2=A0 =C2=A0{
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization= _endpoint":
>>>>> "https://loadsamo= ney/business/auth"
>>>>> ,
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description":= "loadsmoney business banking customers",
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url": >>>>> "https://loadsamoney/business/logo.png"
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0},
>>>>>=C2=A0 =C2=A0 =C2=A0{
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"authorization= _endpoint":
>>>>> "https://loadsamo= ney/consumer/auth"
>>>>> ,
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"description":= "loadsmoney personal customers",
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logo_url": >>>>> "https://loadsamoney/consumer/logo.png"
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0}
>>>>>=C2=A0 =C2=A0]
>>>>> }
>>>>>
>>>>> 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 would allow a better UX though so there?s advantages to client to do so.
>>>>>
>>>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be sensibly combined with the proposed multi-brand spec.
>>>>>>
>>>>>>
>>>>> I think that particular part is not really an issue as mtls isn?t used at the authorization endpoint.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Joseph
>>>>>
>>>>>
>>>>>
>>>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov <vladimir@connect= 2id.com>
>>>>>>=C2=A0 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 alternative 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" - "authorization_endpoint".
>>>>>>
>>>>>> Clients that are aware of the new spec will look it up, those that are not will fall back to the std "authorization_endpoint".
>>>>>>
>>>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be 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 affects 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 document at the correct location (i.e. brand 1 would have an issuer of >>>>>>> "https://as/brand1" and a discovery document available at=C2=A0 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 authorization endpoints. Here is an example (thanks to @Joseph Heenan )
= >>>>>>>
>>>>>>>
>>>>>>>> Bank ?loadsamoney? has one idp and, for internet banking, one ?login page? 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 endpoints (as there?s a 1:1 mapping of authorization endpoints to mobile apps) - the choice is how they do this.
>>>>>>>>
>>>>>>>> Their choices are:
>>>>>>>>
>>>>>>>> 1. Multiple discovery 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 endpoints listed in one discovery doc (one for business, one for personal) some of which are hardcoded by the 3rd party
>>>>>>>> 3. Multiple discovery endpoints each with a different authorization endpoint, same issuer in all cases (breaks RFC8414 and OIDC Discovery)
>>>>>>>>
>>>>>>> Option 3 is invalid and that leaves us with options 1 and 2.
>>>>>>> Option 1 can be problematic as often it is in reality the same `issuer` behind 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>> --
>>>> Vladimir Dzhuvinov
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys 

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

--=20
Vladimir Dzhuvinov
--------------07F764E670E63573430F64D7-- --------------ms000308010705070301060701 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1MjYwNjAzMTZaMC8G CSqGSIb3DQEJBDEiBCAGKIqQxTMePpjkfqk7kGkq3WIrg1EPuvhYKmAUPD4iszBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAGbFjdsBxmu90I2ZHnNlRe5/XJg2EbuSDUSvXTPj/wG1Oxpj YwiMkmlDw59U670+2yHDKBiMTL3PV3RzNzkwtPCrdpzmc/CV4Vldvwk27i+ZoW3IxR4o96Qw GdSSUBfGQ0J3HbQ2RHrEJKYyZBb/nVwEBipccD8teRyUh93WWHCbrSWywRm6W9SwdHhpTjKh jCeoOKwdmjuPClicWxQTWxDP7JUmzzGv7Egydn1+8NWJo8rRSi21qrUrntF8w7WR28JzG2l9 FfMuj3pBoLAb/eSG9II8IhyitE7mtBCaPxtKRVrkaBhudSvoz0JbKB6PxCwzhekGN2bmkRhT KkcoGAoAAAAAAAA= --------------ms000308010705070301060701--