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] >> <mailto:[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 >>> <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:[email protected]> ) >>> >>> > 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
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}