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

Francis Pouatcha <fpo@adorsys.de> Wed, 03 June 2020 17:07 UTC

Return-Path: <fpo@adorsys.de>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE903A0B21 for <oauth@ietfa.amsl.com>; Wed, 3 Jun 2020 10:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Pf_G2F-tV79 for <oauth@ietfa.amsl.com>; Wed, 3 Jun 2020 10:07:45 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F030D3A0B1C for <oauth@ietf.org>; Wed, 3 Jun 2020 10:07:44 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id t18so3188380wru.6 for <oauth@ietf.org>; Wed, 03 Jun 2020 10:07:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jwgw8773A6UFpTlOY7pHTOfaiYwDJhz9Gejtm1FzhGA=; b=CuyxZzK7HZoGxO+aWGPeRPide8fO5c0v1QaFbGFpv3KE8nQhJBQDhRie+0kV8vpax7 C3boK1hCf4k6C8VkHSeIAhTlEHZUPXUi5Wzzuc/f/fflNxpL4seJhCT1FU8s6vTlQuL2 XHTjVwBIJ97i0OuYbnO/nF7Te4I+KDhdvXXd8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jwgw8773A6UFpTlOY7pHTOfaiYwDJhz9Gejtm1FzhGA=; b=BFkkGULWAE9k2U0QPdqSN+p/JUIA7v/Y3Yi8htsGw+qjlBstWPJd0/ViB6O8YayuR8 vsI9qrdyNWWMo1wvlc4fI0cRqyfsYkgCIOXR/cLuE2DHDJ2KwX2noQLu5Z42u7+qZ93+ WdM6JXRDQS1jEAkE3C/TSJHIinFGx41WRnNoOxk0W8kLbeZ41ryWZb+CzqUklTCwUWxO hdjpkMg2PRFml80dvgQK4tQGUhkO02eY7RzBNOErLbMs5xhQDtiaCf2IKhdv6AO3qQiO RM/QGRkg3rYAxB9O+Oq45fNxrcuRw+Eq+o8Ja3CglzAe6w5X90qJOuE8AkHBy20bv1ha ClJQ==
X-Gm-Message-State: AOAM530UUApFbK5yrMMErDZALhUQgJyW8ymmqNMuLA1MHLclxBPqvc1k 8MCBmLKHAfCx9CvEaWZciNl7cUcVhHZwerzeI6RTTA==
X-Google-Smtp-Source: ABdhPJzCavH8sdDoK/uImeSrBltMO8a85jcbWzvbUKd9GCB4mANMQ8kbqwrNmvl/M/qR3SMmE4zvyxOx78fpCDRoVNo=
X-Received: by 2002:adf:e545:: with SMTP id z5mr398721wrm.89.1591204063067; Wed, 03 Jun 2020 10:07:43 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.1608.1590473008.8861.oauth@ietf.org> <CAOW4vyONovS7SLPnTpoGVoi5T92M7tMDbQ4N4o3hGodQRssqSQ@mail.gmail.com> <CAP-T6TT3yo8NhLOGhk3XmPDJJaR6nccjigGSM=VuauysekhV2g@mail.gmail.com>
In-Reply-To: <CAP-T6TT3yo8NhLOGhk3XmPDJJaR6nccjigGSM=VuauysekhV2g@mail.gmail.com>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Wed, 3 Jun 2020 13:07:32 -0400
Message-ID: <CAOW4vyNfwRLuNDXg2fVDPVRov_REKYR+KirgDPUq-AdwW4s+mw@mail.gmail.com>
To: Dave Tonge <dave.tonge@momentumft.co.uk>
Cc: OAuth WG <oauth@ietf.org>, Openid-specs Fapi <openid-specs-fapi@lists.openid.net>
Content-Type: multipart/alternative; boundary="000000000000f1d4cf05a7311099"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/npnKaP_VO5uvTrHynVj6is6lDv8>
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 17:07:48 -0000

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"quot;. 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"quot;. 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=
> 40adorsys.de@dmarc.ietf.org> wrote:
>
>>
>>>
>>> Message: 1
>>> Date: Tue, 26 May 2020 09:03:16 +0300
>>> From: Vladimir Dzhuvinov <vladimir@connect2id.com>
>>> To: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
>>> Message-ID: <2fc4c4ee-8627-936a-baf4-872c0f18eca6@connect2id.com>
>>> 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
>>> >     <vladimir@connect2id.com <mailto:vladimir@connect2id.com>> 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
>>> >     <vladimir@connect2id.com <mailto:vladimir@connect2id.com>>
>>> >     >>>>? 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
>>> >     <vladimir@connect2id.com <mailto:vladimir@connect2id.com>>
>>> >     >>>>>>? 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
>
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/