Hello Dave, > > I agree that the best deployment option is: 1 brand = 1 issuer = 1 > discovery doc, however that is not always possible. > > I'd like to understand Francis what particular issue you see from allowing > an AS to specify multiple authorization_endpoints? > Confusing End User! A user is using the same credentials on a yellow styled "https://loadsamoney/business/auth"; and a green styled " https://loadsamoney/consumer/auth";. A well designed environment will have a centralized page for login and account management like " https://loadsamoney/accounts/auth <https://loadsamoney/consumer/auth>" even better "https://accounts.loadsamoney/auth <https://loadsamoney/consumer/auth>".
I can see that to avoid user confusion it would be necessary for the Client > to record which endpoint they redirected the user to, in case they need the > user to re-authorize - but I can't see any particular security issue? > Let assume the "Client-Business" will record the business auth-endpoint and keep sending RO to "https://loadsamoney/business/auth"; for reauthentication. If the user opens his personal banking application on another tab, "Client-Consumer" will send the user to " https://loadsamoney/consumer/auth";. For SSO to work, the AS has to store the SSO-Cookies under "https://loadsamoney/ <https://loadsamoney/consumer/auth>". Now your AS SSO Cookies are also accessible to "https://loadsamoney/blog <https://loadsamoney/consumer/auth>"! This problem is even worse if instead of path you use subdomains like " https://business.loadsamoney/auth <https://loadsamoney/business/auth>" and " https://consumer.loadsamoney/auth <https://loadsamoney/consumer/auth>" the the SSO Cookie of your AS has to be set to: ".loadsamoney", providing access to the SSO Cookies to all other subdomain hosted application like " https://blog.loadsamoney/ <https://loadsamoney/consumer/auth>". Most AS I have used in customer projects use cookies to manage SSO? > > No matter which authorization_endpoint the user was sent to, after the > user is redirected back to the Client's redirect_uri the process is the > same as if there had been 1 authorization_endpoint. > AS UI customization is being done today by many AS deployment because of: - Multitenancy of deployment - The need to have client identity disclosed to the RO in a consent page I am in favour of Vladimir's suggestion of: > > "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"; > } > } > This use case is neither multi tenancy nor the disclosure of the client identity in a consent page. Starting with the logo here, we will end up adding css and js code snippets. This type of customizing shall be done in the AS-Deployment without playing around with the public AS metadata. I am in favor of pushing those changes into target AS-Deployment specific customizing. /Francis > > Dave > > > On Wed, 27 May 2020 at 16:09, Francis Pouatcha <fpo= > [email protected]> wrote: > >> >>> >>> Message: 1 >>> Date: Tue, 26 May 2020 09:03:16 +0300 >>> From: Vladimir Dzhuvinov <[email protected]> >>> To: [email protected] >>> Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands >>> Message-ID: <[email protected]> >>> Content-Type: text/plain; charset="utf-8" >>> >>> My understanding of the branding concept was to present different UIs to >>> resource owners during login and authorization, while keeping the OP / >>> AS the same, meaning identical issuer. In a spec it would be helpful to >>> spell out what branding means (and what not). >>> >> Let us call this varian the AS-Brand. >> As an RO, I sign in for AS-Brand-A and my token is usable under the >> context of AS-Brand-B because both share the same issuer. This kills >> transparency at the RO site. >> >> I support: One AS-Brand <-> One Issuer. >> >> Regards >> /Francis >> >>> >>> Regarding a token being issued for "personal" vs "business" and >>> confusion - the usage of the token is normally defined by its scope and >>> audience (RS) and if this rule is observed (and it's not relied solely >>> on the issuer URI for that) then clients shouldn't get confused here. >>> >>> Vladimir >>> >>> On 23/05/2020 06:26, Francis Pouatcha wrote: >>> > - I will go for Option 1 even if we have the same runtime instance >>> > producing tokens under different?issuer uris. >>> > - Option 2 might expose security risk as many clients rely on >>> > the?issuer to associate the? token with authorization context. By no >>> > way shall a token issued for "personal" be valid for "business". >>> > Therefore considering?the?use of the?same issuer here might lead to >>> > confusion at the?RP. >>> > - In order to avoid confusion, AS must make?sure each "brand" >>> > uses?separated key material to produce the token. >>> > >>> > BTW: >>> > The term brand as used in the context of most Open Banking initiatives >>> > refers to entities consuming the Interface provided by TPPs (Third >>> > Party Providers).. TPPs play the roles of RPs in the oAuth2 context. >>> > >>> > Unless I misunderstood this thread we are using a brand here to refer >>> > to an AS virtual host (issuer-uri). >>> > >>> > Going forward, we need?to?agree on choosing another term to refer to >>> > issuers, and leave the term "Brand" for consumers of TPP-interfaces. >>> > >>> > The core brand problem we will be facing in open banking is for having >>> > the AS display the "consumer-brand" logo to the RO in the consent >>> screen. >>> > >>> > >>> > >> On 22 May 2020, at 08:52, Vladimir Dzhuvinov >>> > <[email protected] <mailto:[email protected]>> wrote: >>> > >> >>> > >> 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] <mailto:[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] <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 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 >>> > >> >> >> -- >> Francis Pouatcha >> Co-Founder and Technical Lead at adorys >> https://adorsys-platform.de/solutions/ >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > > -- Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/
_______________________________________________ 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}