Return-Path: 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 E1A1D3A0F14 for ; Wed, 3 Jun 2020 06:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk 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 qSEDgk9wqW71 for ; Wed, 3 Jun 2020 06:32:30 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 1A10C3A0EE4 for ; Wed, 3 Jun 2020 06:32:30 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id e5so1829510ote.11 for ; Wed, 03 Jun 2020 06:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2UtASniKMcM/z7PC1EO6R3tebRK5gXpurKtrfWc3Qfo=; b=Bfw5Do7seI5As5CVbGXF/X7V9FTYbBSs19xrLZmDnUWyCjX4aICPipScIrSNtHC3mm DvfTGcD78rnhVKH71te2w4Cog4bE9DBvcO/40lsgyPvhzJNYZZhvwjkieoYOxn+H0/Oz 92vSl80ct6ZtKJWlspl7SLrZyMbkaRsBbX0AQ= 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=2UtASniKMcM/z7PC1EO6R3tebRK5gXpurKtrfWc3Qfo=; b=ByFxwUdM7HYg1k8WrhrkFfe4FVBasXQZEIsCY5rnJypofh94EGYDYlBSG507t1twMj nM7oX11kWhuf7Mpj/Cf4bO7RQUiWn9Oa5NRKBfS+2vv1ZfH7ci9DEd9CMFQvdqwlfBGx H5woWRWzLGcAK7fKlQow21ArBQ42tumB75HYyF67gFuJVjF3SvIAuikdQRQvMykQK2hQ WqVCAamPp+3OOkQaHYz7q0O31oAoXpvW8XshwU3bqhUp6HnnFhaSu8YOfJfusaPV/4xG Sx9ROrfoc1i7NLkDN++2J5yGSRN7ncNU64PLj0TmC4eNRIEJIHTbmIajqSvMkUCnWyVk 25Yw== X-Gm-Message-State: AOAM530TAu9n+P22/Zt3eEQoKWRRWmXvdblYewdmQot2WiulEfCyKxBw BjbCefbYwomsb/8HwP76DlpuYW4Q6LCIaW4d2XjDlKemCuKoFNpw X-Google-Smtp-Source: ABdhPJy00/bX8qULXSJ6lbg37V+m3Z81Che7gIIqxJ6yjJ7qwLmt67muzftBRAV89vXE4C+ASQqq1XypYGsS5kximCA= X-Received: by 2002:a9d:6349:: with SMTP id y9mr17484otk.260.1591191149076; Wed, 03 Jun 2020 06:32:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Tonge Date: Wed, 3 Jun 2020 15:32:17 +0200 Message-ID: To: Francis Pouatcha Cc: OAuth WG , Openid-specs Fapi Content-Type: multipart/alternative; boundary="00000000000035f71e05a72e0f2b" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 13:32:33 -0000 --00000000000035f71e05a72e0f2b Content-Type: text/plain; charset="UTF-8" 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 wrote: > >> >> Message: 1 >> Date: Tue, 26 May 2020 09:03:16 +0300 >> From: Vladimir Dzhuvinov >> 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 >> > > 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 >> > > >> > >>>>? 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 >> > > >> > >>>>>>? 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 > -- --00000000000035f71e05a72e0f2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the replies to this message= .

I agree that the best deployment option is: 1 brand =3D 1 = issuer =3D 1 discovery doc, however that is not always possible.

<= /div>
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=C2=A0for the Client to r= ecord which endpoint they redirected the user to, in case they need the use= r to re-authorize - but I can't see any particular security issue?

No matter which authorization_endpoint the user was sent to, aft= er the user is redirected back to the Client's redirect_uri the process= is the same as if there had been 1 authorization_endpoint.=C2=A0

=
I am in favour of Vladimir's suggestion of:

"= alternative_authorization_endpoints": {
=C2=A0 =C2=A0 "banking= ": {
=C2=A0 =C2=A0 =C2=A0 "authorization_endpoint": "= ;https://loadsamoney/business= /auth",
=C2=A0 =C2=A0 =C2=A0 "description": "loa= dsmoney business banking customers",
=C2=A0 =C2=A0 =C2=A0 "log= o_url": "https:= //loadsamoney/business/logo.png"
=C2=A0 =C2=A0 },
=C2=A0 =C2= =A0 "personal": {
=C2=A0 =C2=A0 =C2=A0 "authorization_end= point": "https://lo= adsamoney/consumer/auth",
=C2=A0 =C2=A0 =C2=A0 "descriptio= n": "loadsmoney personal customers",
=C2=A0 =C2=A0 =C2=A0= "logo_url": "https://loadsamoney/consumer/logo.png"
=C2=A0 =C2=A0 }
= =C2=A0 }

Dave


On Wed, 27 May 2020 at 16:0= 9, Francis Pouatcha <fpo=3D40adorsys.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<= br> Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
Message-ID: <2fc4c4ee-8627-936a-baf4-872c0f18eca6@connect2= id.com>
Content-Type: text/plain; charset=3D"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 c= all this varian the AS-Brand.=C2=A0
As an RO, I sign=C2=A0in for = AS-Brand-A and my token is usable under the context of AS-Brand-B because b= oth share the same issuer.=C2=A0 This kills transparency=C2=A0at the RO sit= e.

I support: One AS-Brand <-> One Issuer.

Regards
/Francis

Regarding a token being issued for "personal" vs "business&q= uot; 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<= br> 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 "b= usiness".
> 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<= br> > 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-int= erfaces.
>
> 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 co= nsent screen.
>
>
>=C2=A0 =C2=A0 =C2=A0>> On 22 May 2020, at 08:52, Vladimir Dzhuvin= ov
>=C2=A0 =C2=A0 =C2=A0<vladimir@connect2id.com <mailto:vladimir@connect2id.com>> = wrote:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> With that said it makes sense to devise a = structure which can
>=C2=A0 =C2=A0 =C2=A0accommodate UI driven as well as automatic choice.<= br> >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ? The UI driven chooser will need a h= uman readable
>=C2=A0 =C2=A0 =C2=A0description and other UI hints. This can work for i= nstance with
>=C2=A0 =C2=A0 =C2=A0"classic" OIDC Discovery.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ? The "auto" chooser will n= eed some sort of an ID. For a
>=C2=A0 =C2=A0 =C2=A0bank chooser this means providing the issuer URI an= d an optional
>=C2=A0 =C2=A0 =C2=A0brand ID and both must get registered together. Or,= one could
>=C2=A0 =C2=A0 =C2=A0define a standard brand ID (label) for banking oper= ations and if
>=C2=A0 =C2=A0 =C2=A0the "alternative_authorization_endpoints"= is present look for it
>=C2=A0 =C2=A0 =C2=A0in the structure, else fall back to the default
>=C2=A0 =C2=A0 =C2=A0"authorization_endpoint".
>=C2=A0 =C2=A0 =C2=A0>> Here is one possible layout which has IDs = and UI hints:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> {
>=C2=A0 =C2=A0 =C2=A0>>? ?...
>=C2=A0 =C2=A0 =C2=A0>>? ?"alternative_authorization_endpoint= s": {
>=C2=A0 =C2=A0 =C2=A0>>? ? ?"banking": {
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"authorization_endpoint":<= br> >=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/business= /auth"
>=C2=A0 =C2=A0 =C2=A0>> ,
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"description": "loads= money business banking customers",
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"logo_url":
>=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/busi= ness/logo.png"
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>? ? ?},
>=C2=A0 =C2=A0 =C2=A0>>? ? ?"personal": {
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"authorization_endpoint":<= br> >=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/consumer= /auth"
>=C2=A0 =C2=A0 =C2=A0>> ,
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"description": "loads= money personal customers",
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"logo_url":
>=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/cons= umer/logo.png"
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>? ? ?}
>=C2=A0 =C2=A0 =C2=A0>>? ?}
>=C2=A0 =C2=A0 =C2=A0>> }
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On 22/05/2020 09:59, Torsten Lodderstedt w= rote:
>=C2=A0 =C2=A0 =C2=A0>>> I think an id or label per endpoint se= t would be needed to
>=C2=A0 =C2=A0 =C2=A0determine the set of endpoints to be used by a cert= ain client.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> On the conceptual side, I?m asking mys= elf how the complete
>=C2=A0 =C2=A0 =C2=A0process is supposed to work. Who is deciding what i= ssuer/endpoint
>=C2=A0 =C2=A0 =C2=A0set combination to use. I assume in an open banking= scenario,
>=C2=A0 =C2=A0 =C2=A0there will always be some kind of bank chooser. Wil= l this chooser
>=C2=A0 =C2=A0 =C2=A0provide the client with issuer and brand id?
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>> On 22. May 2020, at 08:10, Vladimi= r Dzhuvinov
>=C2=A0 =C2=A0 =C2=A0<vladimir@connect2id.com <mailto:vladimir@connect2id.com>><= br> >=C2=A0 =C2=A0 =C2=A0>>>>? wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> A mapping like the one you propose= can definitely work. Since
>=C2=A0 =C2=A0 =C2=A0the user will be making the choice which endpoint t= o take with the
>=C2=A0 =C2=A0 =C2=A0client app, having the logo_uri is a good idea. If = the branded
>=C2=A0 =C2=A0 =C2=A0endpoints differ somehow in policy one could also a= llow inclusion
>=C2=A0 =C2=A0 =C2=A0of the op_policy_uri and op_tos_uri params from Dis= covery.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0ht= tps://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Vladimir
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> On 20/05/2020 19:16, Joseph Heenan= wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Thanks for your thoughts Vladi= mir!
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> The client_id based solution I= wasn?t previously aware of -
>=C2=A0 =C2=A0 =C2=A0unfortunately it doesn?t solve the problem for app2= app, as the
>=C2=A0 =C2=A0 =C2=A0mobile OS selects the app to use based purely on th= e URL (and in
>=C2=A0 =C2=A0 =C2=A0at least the iOS case will not offer the user a cho= ice if multiple
>=C2=A0 =C2=A0 =C2=A0apps claim to handle the same url).
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> I think some kind of mapping l= ike you suggest will work and
>=C2=A0 =C2=A0 =C2=A0fallback, I wonder about a structure in the authori= zation server
>=C2=A0 =C2=A0 =C2=A0metadata something like this:
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> {
>=C2=A0 =C2=A0 =C2=A0>>>>>? ?...
>=C2=A0 =C2=A0 =C2=A0>>>>>? ?"alternative_authorizat= ion_endpoints": [
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?{
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"authorization_endp= oint":
>=C2=A0 =C2=A0 =C2=A0>>>>> "https://loadsamo= ney/business/auth"
>=C2=A0 =C2=A0 =C2=A0>>>>> ,
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"description":= "loadsmoney business banking customers",
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"logo_url": >=C2=A0 =C2=A0 =C2=A0>>>>> "https://load= samoney/business/logo.png"
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?},
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?{
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"authorization_endp= oint":
>=C2=A0 =C2=A0 =C2=A0>>>>> "https://loadsamo= ney/consumer/auth"
>=C2=A0 =C2=A0 =C2=A0>>>>> ,
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"description":= "loadsmoney personal customers",
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"logo_url": >=C2=A0 =C2=A0 =C2=A0>>>>> "https://load= samoney/consumer/logo.png"
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?}
>=C2=A0 =C2=A0 =C2=A0>>>>>? ?]
>=C2=A0 =C2=A0 =C2=A0>>>>> }
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> And as you say, the existing a= uthorization_endpoint can be a
>=C2=A0 =C2=A0 =C2=A0fallback for clients that are unaware of the new sp= ec or prefer
>=C2=A0 =C2=A0 =C2=A0the simpler option of just using a single authoriza= tion endpoint.
>=C2=A0 =C2=A0 =C2=A0Supporting the new spec would allow a better UX tho= ugh so there?s
>=C2=A0 =C2=A0 =C2=A0advantages to client to do so.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Speaking of mTLS, I'm = not sure how the
>=C2=A0 =C2=A0 =C2=A0"mtls_endpoint_aliases" can be sensibly c= ombined with the proposed
>=C2=A0 =C2=A0 =C2=A0multi-brand spec.
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> I think that particular part i= s not really an issue as mtls
>=C2=A0 =C2=A0 =C2=A0isn?t used at the authorization endpoint.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Thanks
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Joseph
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> On 20 May 2020, at 16:07, = Vladimir Dzhuvinov
>=C2=A0 =C2=A0 =C2=A0<vladimir@connect2id.com <mailto:vladimir@connect2id.com>><= br> >=C2=A0 =C2=A0 =C2=A0>>>>>>? wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Hi Dave,
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> In the absence of such a &= quot;multi-brand" spec we have tackled
>=C2=A0 =C2=A0 =C2=A0this issue in the past by letting the "brand&q= uot; be encoded in the
>=C2=A0 =C2=A0 =C2=A0client_id. An alternative scenario is to do a "= ;brand" lookup by
>=C2=A0 =C2=A0 =C2=A0client_id. Then let the AS render the "branded= " authZ endpoint.
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> You're probably aware = the mTLS spec is allowing for
>=C2=A0 =C2=A0 =C2=A0endpoint aliases, so this is not the first time suc= h as need has
>=C2=A0 =C2=A0 =C2=A0occurred:
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> https:= //tools.ietf.org/html/rfc8705#section-5
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> One could devise a similar= JSON object with mappings
>=C2=A0 =C2=A0 =C2=A0"label" - "authorization_endpoint&qu= ot;.
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Clients that are aware of = the new spec will look it up,
>=C2=A0 =C2=A0 =C2=A0those that are not will fall back to the std "= authorization_endpoint".
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Speaking of mTLS, I'm = not sure how the
>=C2=A0 =C2=A0 =C2=A0"mtls_endpoint_aliases" can be sensibly c= ombined with the proposed
>=C2=A0 =C2=A0 =C2=A0multi-brand spec.
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Vladimir
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> On 20/05/2020 15:07, Dave = Tonge wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Dear OAuth WG
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> We have an issue in th= e OpenID FAPI Working Group that we
>=C2=A0 =C2=A0 =C2=A0believe affects the wider OAuth community.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> In summary: what is th= e recommended approach to discovery
>=C2=A0 =C2=A0 =C2=A0(RFC8414) for Authorization Servers who support mul= tiple "brands" .
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> If brands are complete= ly separate, then it seems sensible
>=C2=A0 =C2=A0 =C2=A0that each brand must have its own `issuer` and ther= efore its own
>=C2=A0 =C2=A0 =C2=A0discovery document at the correct location (i.e. br= and 1 would
>=C2=A0 =C2=A0 =C2=A0have an issuer of
>=C2=A0 =C2=A0 =C2=A0>>>>>>> "https://as/brand1&qu= ot; and a discovery document available at?
>=C2=A0 =C2=A0 =C2=A0https://as/.well-kno= wn/oauth-authorization-server/brand1
>=C2=A0 =C2=A0 =C2=A0>>>>>>> ).
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> However in the real wo= rld it is not always so simple. We
>=C2=A0 =C2=A0 =C2=A0have many existing implementations in UK open banki= ng that support
>=C2=A0 =C2=A0 =C2=A0multiple authorization endpoints. Here is an exampl= e (thanks to
>=C2=A0 =C2=A0 =C2=A0@Joseph Heenan )
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> Bank ?loadsamoney?= has one idp and, for internet banking,
>=C2=A0 =C2=A0 =C2=A0one ?login page? for both business and personal cus= tomers.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> They have separate= mobile apps for business/personal, and
>=C2=A0 =C2=A0 =C2=A0are required to support app2app. This means they wi= ll definitely
>=C2=A0 =C2=A0 =C2=A0be exposing multiple authorization endpoints (as th= ere?s a 1:1
>=C2=A0 =C2=A0 =C2=A0mapping of authorization endpoints to mobile apps) = - the choice is
>=C2=A0 =C2=A0 =C2=A0how they do this.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> Their choices are:=
>=C2=A0 =C2=A0 =C2=A0>>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> 1. Multiple discov= ery endpoints (one for business, one
>=C2=A0 =C2=A0 =C2=A0for personal), each with a different authorization = endpoint,
>=C2=A0 =C2=A0 =C2=A0multiple issuers (if their vendor allows this)
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> 2. Single discover= y endpoint, single issuer, multiple
>=C2=A0 =C2=A0 =C2=A0authorization endpoints listed in one discovery doc= (one for
>=C2=A0 =C2=A0 =C2=A0business, one for personal) some of which are hardc= oded by the 3rd
>=C2=A0 =C2=A0 =C2=A0party
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> 3. Multiple discov= ery endpoints each with a different
>=C2=A0 =C2=A0 =C2=A0authorization endpoint, same issuer in all cases (b= reaks RFC8414
>=C2=A0 =C2=A0 =C2=A0and OIDC Discovery)
>=C2=A0 =C2=A0 =C2=A0>>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Option 3 is invalid an= d that leaves us with options 1 and 2.
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Option 1 can be proble= matic as often it is in reality the
>=C2=A0 =C2=A0 =C2=A0same `issuer` behind the scenes.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> We would like to get f= eedback on this issue and
>=C2=A0 =C2=A0 =C2=A0potentially an extension to RFC8414 to allow the de= finition of
>=C2=A0 =C2=A0 =C2=A0multiple authorization endpoints.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Thanks in advance
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Dave Tonge
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Co-Chair FAPI WG
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Open ID Foundation
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> --
>=C2=A0 =C2=A0 =C2=A0>>>> Vladimir Dzhuvinov
>

--
=
Francis Pouatcha
Co-Founder and Technical Lead at adorys
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--

=
--00000000000035f71e05a72e0f2b--