Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <66FD701A-6036-4D6E-A2AB-E206A0043BBF@authlete.com>
Date: Fri, 22 May 2020 10:38:40 +0200
Cc: Vladimir Dzhuvinov <vladimir@connect2id.com>,
 Openid-specs-fapi <openid-specs-fapi@lists.openid.net>,
 oauth <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <11B2194A-0C5F-4D5D-BD82-2B070EA05622@lodderstedt.net>
References: <CAP-T6TTehOT7U_fniZdHsei1C1phOWQfK7o=fHSNciXSTjviPA@mail.gmail.com>
 <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>
 <99394ea7-4588-5a5e-6997-bb96a19a1196@connect2id.com>
 <66FD701A-6036-4D6E-A2AB-E206A0043BBF@authlete.com>
To: Joseph Heenan <joseph@authlete.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/4TUZPHEKqL7AnpABztSO71DGMtw>
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
Precedence: list

The first case looks better to me as well. It would require a chooser =
that provides both the issuer url and the brand id.=20

BTW: I would prefer a more generic term in order to facilitate other use =
cases. I think it could be useful to have a discriminator for selecting =
a set of endpoints. For example, an AS could then support different =
versions or flavours of OAuth/OpenID in the same deployment. Just =
thinking aloud :-)

> On 22. May 2020, at 10:32, Joseph Heenan <joseph@authlete.com> wrote:
>=20
> Thanks Vladimir/Torsten.
>=20
> I agree, it would make sense to have some form of static id for each =
entry. My first attempt started out similar but for some reason I =
decided to simplify=E2=80=A6
>=20
> On the conceptual side for choosers (and biased towards how the UK =
openbanking ecosystem works as that=E2=80=99s what I know best), what =
this allows for is:
>=20
> client chooser -> authorisation endpoint
>=20
> Where the list is:
>=20
> =E2=80=9CBank a=E2=80=9D
> =E2=80=9CLoadsamoney personal=E2=80=9D
> =E2=80=9CLoadsamoney business=E2=80=9D
> =E2=80=9CBank c"
>=20
>=20
> Instead of the only =E2=80=99standards compliant=E2=80=99 way to do =
app2app in this case today of:
>=20
> client chooser -> AS interstitial chooser on authorization endpoint -> =
real authorization endpoint
>=20
> Where the first chooser is:
>=20
> =E2=80=9CBank a=E2=80=9D
> =E2=80=9CLoadsamoney=E2=80=9D
> =E2=80=9CBank c=E2=80=9D
>=20
> And the second:
>=20
> =E2=80=9CPersonal"
> =E2=80=9CBusiness"
>=20
> The first case is much better, particularly for the real multi-brand =
case where the end user might not even associate the two bank brandnames =
with each other.
>=20
> What actually happens today is the first case (single RP chooser), but =
based on banks emailing around lists of alternative authorization =
endpoints to the RP, or publishing the details on obscure developer =
portals - which destroys much of the convenience / agility / security =
the server metadata RFC was trying achieve.
>=20
> The issue of how the RP finds the server metadata document is =
unchanged from today. (In the UK, we have a centralised directory that =
lists them.)
>=20
> Joseph
>=20
>=20
>=20
>> On 22 May 2020, at 08:52, Vladimir Dzhuvinov =
<vladimir@connect2id.com> wrote:
>>=20
>> With that said it makes sense to devise a structure which can =
accommodate UI driven as well as automatic choice.
>>=20
>> 	=E2=80=A2 The UI driven chooser will need a human readable =
description and other UI hints. This can work for instance with =
"classic" OIDC Discovery.
>>=20
>> 	=E2=80=A2 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:
>>=20
>> {
>>   ...
>>   "alternative_authorization_endpoints": {
>>     "banking": {
>>       "authorization_endpoint":=20
>> "https://loadsamoney/business/auth"
>> ,
>>       "description": "loadsmoney business banking customers",
>>       "logo_url":=20
>> "https://loadsamoney/business/logo.png"
>>=20
>>     },
>>     "personal": {
>>       "authorization_endpoint":=20
>> "https://loadsamoney/consumer/auth"
>> ,
>>       "description": "loadsmoney personal customers",
>>       "logo_url":=20
>> "https://loadsamoney/consumer/logo.png"
>>=20
>>     }
>>   }
>> }
>>=20
>>=20
>>=20
>> 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.
>>>=20
>>> On the conceptual side, I=E2=80=99m 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?=20
>>>=20
>>>=20
>>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov =
<vladimir@connect2id.com>
>>>>  wrote:
>>>>=20
>>>> 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.
>>>>=20
>>>>=20
>>>> =
https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery=

>>>>=20
>>>>=20
>>>> Vladimir
>>>>=20
>>>> On 20/05/2020 19:16, Joseph Heenan wrote:
>>>>=20
>>>>> Thanks for your thoughts Vladimir!
>>>>>=20
>>>>> The client_id based solution I wasn=E2=80=99t previously aware of =
- unfortunately 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 iOS case will not offer the user a choice if multiple apps =
claim to handle the same url).
>>>>>=20
>>>>> 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:
>>>>>=20
>>>>> {
>>>>>   ...
>>>>>   "alternative_authorization_endpoints": [
>>>>>     {
>>>>>       "authorization_endpoint":=20
>>>>> "https://loadsamoney/business/auth"
>>>>> ,
>>>>>       "description": "loadsmoney business banking customers",
>>>>>       "logo_url":=20
>>>>> "https://loadsamoney/business/logo.png"
>>>>>=20
>>>>>     },
>>>>>     {
>>>>>       "authorization_endpoint":=20
>>>>> "https://loadsamoney/consumer/auth"
>>>>> ,
>>>>>       "description": "loadsmoney personal customers",
>>>>>       "logo_url":=20
>>>>> "https://loadsamoney/consumer/logo.png"
>>>>>=20
>>>>>     }
>>>>>   ]
>>>>> }
>>>>>=20
>>>>> 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=E2=80=99s =
advantages to client to do so.
>>>>>=20
>>>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" =
can be sensibly combined with the proposed multi-brand spec.
>>>>>>=20
>>>>>>=20
>>>>> I think that particular part is not really an issue as mtls =
isn=E2=80=99t used at the authorization endpoint.
>>>>>=20
>>>>> Thanks
>>>>>=20
>>>>> Joseph
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov =
<vladimir@connect2id.com>
>>>>>>  wrote:
>>>>>>=20
>>>>>> Hi Dave,
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> You're probably aware the mTLS spec is allowing for endpoint =
aliases, so this is not the first time such as need has occurred:
>>>>>>=20
>>>>>>=20
>>>>>> https://tools.ietf.org/html/rfc8705#section-5
>>>>>>=20
>>>>>>=20
>>>>>> One could devise a similar JSON object with mappings "label" - =
"authorization_endpoint".
>>>>>>=20
>>>>>> Clients that are aware of the new spec will look it up, those =
that are not will fall back to the std "authorization_endpoint".
>>>>>>=20
>>>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" =
can be sensibly combined with the proposed multi-brand spec.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Vladimir
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 20/05/2020 15:07, Dave Tonge wrote:
>>>>>>=20
>>>>>>> Dear OAuth WG
>>>>>>>=20
>>>>>>> We have an issue in the OpenID FAPI Working Group that we =
believe affects the wider OAuth community.
>>>>>>>=20
>>>>>>> In summary: what is the recommended approach to discovery =
(RFC8414) for Authorization Servers who support multiple "brands" .
>>>>>>>=20
>>>>>>> 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=20=

>>>>>>> "https://as/brand1" and a discovery document available at  =
https://as/.well-known/oauth-authorization-server/brand1
>>>>>>> ).
>>>>>>>=20
>>>>>>> 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 )
>>>>>>>=20
>>>>>>>=20
>>>>>>>> Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp and, for =
internet banking, one =E2=80=9Clogin page=E2=80=9D for both business and =
personal customers.
>>>>>>>>=20
>>>>>>>> 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=E2=80=99s a 1:1 mapping of =
authorization endpoints to mobile apps) - the choice is how they do =
this.
>>>>>>>>=20
>>>>>>>> Their choices are:
>>>>>>>>=20
>>>>>>>> 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)
>>>>>>>>=20
>>>>>>> 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` behind the scenes.
>>>>>>>=20
>>>>>>> We would like to get feedback on this issue and potentially an =
extension to RFC8414 to allow the definition of multiple authorization =
endpoints.
>>>>>>>=20
>>>>>>> Thanks in advance
>>>>>>>=20
>>>>>>> Dave Tonge
>>>>>>> Co-Chair FAPI WG
>>>>>>> Open ID Foundation
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>> --=20
>>>> Vladimir Dzhuvinov
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>>=20
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>> --=20
>> Vladimir Dzhuvinov
>>=20
>=20