> > > > 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
![https://loadsamoney/business/logo.png"](https://loadsamoney/business/logo.png"){kind=link}
![https://loadsamoney/consumer/logo.png"](https://loadsamoney/consumer/logo.png"){kind=link}