Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

[Francis Pouatcha <[e-mail]>]

>
>
>
> Message: 1
> Date: Tue, 26 May 2020 09:03:16 +0300
> From: Vladimir Dzhuvinov <[e-mail]>
> To: [e-mail]
> Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
> Message-ID: <[e-mail]>
> 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
> >     <[e-mail] <mailto:[e-mail]>> 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
> >     <[e-mail] <mailto:[e-mail]>>
> >     >>>>? 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
> >     <[e-mail] <mailto:[e-mail]>>
> >     >>>>>>? 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/