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 _______________________________________________ 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}