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

Francis Pouatcha <fpo@adorsys.de> Wed, 27 May 2020 14:09 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 B2B4E3A0B42 for <oauth@ietfa.amsl.com>; Wed, 27 May 2020 07:09:18 -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 l7b-iMjRMNUD for <oauth@ietfa.amsl.com>; Wed, 27 May 2020 07:09:16 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 E129C3A0B41 for <oauth@ietf.org>; Wed, 27 May 2020 07:09:15 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id s8so24086650wrt.9 for <oauth@ietf.org>; Wed, 27 May 2020 07:09:15 -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; bh=mNdC4UDJNDCxZOSS8G9VXuPy5SrPizNcQkftwebqSQo=; b=KnMMizNQHZvoUaeOBPKPwm4HSsl+IdyMGm7LcQ/CEoQd/RNKeHnnHmBsUReXvbmCqc wUy9AH4gvTz/XKXqwqYhp8IFl0+NfzJlAap60v3BwtpoP3cNg11MsxklWq39pVBvldEp F9fLsnjmgjpVo4RPpadMIDXJSxK0C6mR+/xA8=
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; bh=mNdC4UDJNDCxZOSS8G9VXuPy5SrPizNcQkftwebqSQo=; b=eNUu1yY1WlnF0blHdRQSgQaA686RnBngeN5SV5kHblL9Oqjs2GDznAl01boLpxplTe cKM9KoZbq3j58Xt6mLvMF25RowXyM8+zi+2iB9S1enUfaoh/f3Wd600PXzZbPJqoPWMT EGQwoo1EAcKP5jhmakwIFx3JuKyQdlP4kxFhdS3RsnWLMGVsNyq6CPKxljGJ+fp+VjBH VAr7vWc2nwgsOTLOMPggCDbSvGYKx5R+0ObvBozh12KqoObjk+KWdYQ9IuTO31athZZ9 SFhc5h4u2sd+B5jdn9bCBVrV9BUXi46PBZAwgVQfgw0mU3UFELqhlYjdg42KjxQwXeh4 Opjw==
X-Gm-Message-State: AOAM530ovNDZDcFlwUG/EioPWNgyX1kzrTiEcPI13Wyn8pSe+9fULOab 0oDF2RmH9FNkT5Dk6h4PEyDMTtIk0Kmht1lsdLHXdItEf10=
X-Google-Smtp-Source: ABdhPJwn9HTbokE82jc4f6czsy04vTlYP+8chrlRt/BW91YkIbrdpwX4XJwpPqF9/Hmgt1KDXhDSkfzbkLezslvMYeg=
X-Received: by 2002:adf:f28f:: with SMTP id k15mr22198038wro.283.1590588550079; Wed, 27 May 2020 07:09:10 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.1608.1590473008.8861.oauth@ietf.org>
In-Reply-To: <mailman.1608.1590473008.8861.oauth@ietf.org>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Wed, 27 May 2020 10:08:59 -0400
Message-ID: <CAOW4vyONovS7SLPnTpoGVoi5T92M7tMDbQ4N4o3hGodQRssqSQ@mail.gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000082fb2005a6a1c168"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Lus915ZP1oCZ7Xch-FLfS5nKyuw>
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, 27 May 2020 14:09:19 -0000

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