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 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 <[email protected]>
>> 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#IssuerDiscovery
>>
>> 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:
>>>
>>> {
>>> ...
>>> "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 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 <[email protected]>
>>>> 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
>>>>> 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
>>
>> _______________________________________________
>> OAuth mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
--
Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
![https://loadsamoney/business/logo.png"](https://loadsamoney/business/logo.png"){kind=link}
![https://loadsamoney/consumer/logo.png"](https://loadsamoney/consumer/logo.png"){kind=link}