Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

[Vladimir Dzhuvinov <[e-mail]>]

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 <[e-mail]
>> <mailto:[e-mail]>> 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
>>> <https://bitbucket.org/openid/fapi/issues/255/certification-clarification-request>
>>> 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 <mailto:[e-mail]> )
>>>
>>> > 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