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

From: Dave Tonge <[email-masked]>
Date: Wed, 3 Jun 2020 15:32:17 +0200

Thank you for the replies to this message.

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?
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?

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.

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

Dave

On Wed, 27 May 2020 at 16:09, Francis Pouatcha <fpo=
[email-masked]> wrote:

>
>>
>> Message: 1
>> Date: Tue, 26 May 2020 09:03:16 +0300
>> From: Vladimir Dzhuvinov <[email-masked]>
>> To: [email-masked]
>> Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
>> Message-ID: <[email-masked]>
>> 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-masked] <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>>
>> >     >>>>? 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-masked] <mailto:[email-masked]>>
>> >     >>>>>>? 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

--

---

From: Francis Pouatcha <[email-masked]>
Date: Wed, 3 Jun 2020 13:07:32 -0400

Hello Dave,

> 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>".

> 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

>       "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

---

From: Joseph Heenan <[email-masked]>
Date: Thu, 4 Jun 2020 14:52:14 +0100

Hi Francis,

> On 3 Jun 2020, at 18:07, Francis Pouatcha <fpo=[email-masked]> wrote:
> 
> 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 <https://loadsamoney/business/auth>" and a green styled "https://loadsamoney/consumer/auth <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>".

In the cases Dave and I are thinking of, there’s no SSO between the different brands (sorry,I’m struggling to find a better word than brands!), which also have segmented user credentials - there’s no user confusion.

> 
> 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 <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 <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>".

I think this is either mainly an issue with the example urls, or solved by pointing out that you should not do SSO between different authorization endpoints for the reasons you say?

>  
> 
> 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. 

>       "authorization_endpoint": "https://loadsamoney/business/auth <https://loadsamoney/business/auth>",
>       "logo_url": "https://loadsamoney/business/logo.png <https://loadsamoney/business/logo.png>"
>     },
>     "personal": {
>       "authorization_endpoint": "https://loadsamoney/consumer/auth <https://loadsamoney/consumer/auth>",
>       "logo_url": "https://loadsamoney/consumer/logo.png <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 don’t understand why “disclosure of the client identity in a consent page” is relevant here; that already happens, it will continue to happen in the same way and isn’t affected in any way by this suggestion.

Yes, there are other architectures that don’t require this. I don’t think it is the job of the protocol to disallow or make some architectures difficult just because other architectures are better.

I don’t think it’s even clear that having a client deal with 16 different issuers for a single bank (a real world example of what would happen if we forced ‘one authorization endpoint per issuer’) is actually “better”. It’s a pain for the client to manage 16 different issuers rather than 1 with 16 authorization endpoints - it means 16 client registrations and 16 issuers to configure, and it obfuscates to the client that these are actually all the same system. I have a hard time saying that one architecture is clearly good and that the other should clearly be disallowed unless you’re willing to go outside of the standards, particularly when switching architectures is a large breaking change that would be close to impossible to coordinate in any real world system with a number of active OAuth clients.

> I am in favor of pushing those changes into target AS-Deployment specific customizing.

Many authorization servers are already running multiple authorization endpoints. They are required in certain architectures, and there are no other security concerns raised so far that are unique to those architectures. (The need to do SSO sensibly and securely applies to all architectures.)

The suggested new metadata allows authorization servers to publish these multiple authorization endpoints in a standard machine readable format that clients can then use with less need for manual configuration and poking around emails or ‘dev portals’ to find the details. I do not see a downside of allowing this.

Thanks

Joseph

---

From: "Manger, James" <[email-masked]>
Date: Fri, 5 Jun 2020 02:23:15 +0000

Wedging support for multiple Authorization Server brands via this "alternative_authorization_endpoints" metadata field is a very kludgy hack.

>      "logo_url": "https://loadsamoney/consumer/logo.png"

It assumes only 1 piece of metadata (authorization_endpoint) is brand-specific, but none of the other 50 (eg ui_locales_supported, op_tos_uri, scopes_supported, …) from 4 different specs currently listed in the metadata registry<https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata> (not to mention the ones in draft specs not registered yet).
It offers 1 logo (in one size/resolution/format/colour-palette/…) and 1 description (in one language), which is likely to be totally inadequate so the suggestion is probably only a fraction of the actual complexity required.

If you want to build a “chooser” user-interface allowing a user to, say, pick between multiple banks & brands then that needs a solution quite distinct from AS metadata.

If you want to allow a client to reuse 1 dynamic registration across multiple brands, could you compare the “registration_endpoint” in each brand’s own AS metadata (being careful a malicious AS cannot trick the client into sharing the client’s creds from a victim AS). Or how about an “associated_issuer” member holding an array of issuer identifiers. If issA & issB each list each other in their “associated_issuer” metadata, then a client registration at either can be used at the other.

If you merely want to trigger a different look-n-feel, define a “brand” parameter to add the to the authorization request.

--
James Manger

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 6 Jun 2020 10:45:17 +0200

> Am 04.06.2020 um 15:52 schrieb Joseph Heenan via Openid-specs-fapi <[email-masked]>:
> 

Segmented user credentials to me indicate that different issuers should be used. I don’t see the advantage of using the same issuer if the user realms are different.

---

From: Joseph Heenan <[email-masked]>
Date: Mon, 8 Jun 2020 12:52:10 +0100

Hi James,

> On 5 Jun 2020, at 03:23, Manger, James <[email-masked]> wrote:

Unfortunately this doesn’t work when the authorization endpoint is a claimed https url for a mobile app: the mobile app to be used is selected purely based on the host/path segment.

Joseph