[Openid-specs-fapi] [OAUTH-WG] Issuers, Discovery Docs & Brands

Vladimir Dzhuvinov vladimir at connect2id.com
Fri May 22 06:10:16 UTC 2020

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.



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 <vladimir at connect2id.com
>> <mailto:vladimir at 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 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:joseph.heenan at fintechlabs.io> )
>>> > 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200522/5847bdcd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200522/5847bdcd/attachment-0001.p7s>

More information about the Openid-specs-fapi mailing list