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

Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 22 May 2020 06:59 UTC

Return-Path: <torsten@lodderstedt.net>
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 CBAFE3A0F05 for <oauth@ietfa.amsl.com>; Thu, 21 May 2020 23:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 (2048-bit key) header.d=lodderstedt.net
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 KqNVqL6Z8DcF for <oauth@ietfa.amsl.com>; Thu, 21 May 2020 23:59:09 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 9ABD03A0F01 for <oauth@ietf.org>; Thu, 21 May 2020 23:59:09 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id x1so11745126ejd.8 for <oauth@ietf.org>; Thu, 21 May 2020 23:59:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HnpmgqJFoq3NejT2rePXsrbISM76Ue/rtXXEFuCjK8c=; b=DEfPBGWKPZOJG37q9xMALsM5nBl0zxvYRxEGbVoO1ksO9jjTm1kly+bkeMz49smy5G tJVcg/bf+ZjzHDbAelmyRHOFyxt9wbxOp1K4V6loBID1TauK62fqHppZV9xDJsW/a0lU 3NSkWGlfEs3hrkQt05xZcE7rRRifPLcC6iIZTdUgF0+WcuSjZS6x3YPmMUu1zoKOrru4 u0jne1OgFZlVXJljOOqYV1WDaCfUjdRjhtx3Kq1eioUmBVus80yyFzLAD0l6E9Lngtse +0oww29U3pPmgG5APFKLYzhgv+/HhRfe5TYkuQCmf8pYss+zHW7NEtrXsVeXMRMHWeeH 1AMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HnpmgqJFoq3NejT2rePXsrbISM76Ue/rtXXEFuCjK8c=; b=WJjckkTbbkZ28h2gNVSeFe5CqJeRM0EeI5dJZAmlfOu5lW/8uzP9/8+03epzbh4TuL TADk3BxJEI59+dg6xBreRjhaJsM8vwg3fhAOrbVDIHQwwJHR6QcZlIpqmULlME9YS2yq dUn0byng98Bmf3t5i39RmecwHb52LKj+isOs9Que6W7Cfi9TU4SFUxh40yCEHMkRBifj 6nxD3trWPDmXKzlb9LU+P+SH5sifAXfMErNvVuaIHoztEdC25zgGgAZRIQDfNBM2cqxv ctvgTmvJipNWE/H0JvxpBAfzOE2oV4YuohPK/OTV6tOwCZ3u6MhtYCZyN8eigmL9XgmK ALhw==
X-Gm-Message-State: AOAM532zYn6QVJzrTcpgcWY5K7rnIi93lxdB7taQWhnbgvl7V1UwaHNd WRfubg+mRTFLGVXn1TtS5/MbDsz+xY0=
X-Google-Smtp-Source: ABdhPJyjBbKWrxpYQGyZ+GFUmNLe1ftrLuxxWNM2EyOncfDMVEkIqpPxxRA4WZWLpj9rP4IGcPbWIw==
X-Received: by 2002:a17:906:160a:: with SMTP id m10mr7221680ejd.170.1590130745942; Thu, 21 May 2020 23:59:05 -0700 (PDT)
Received: from p200300eb8f3b3fc8904241d200c1eeb6.dip0.t-ipconnect.de (p200300eb8f3b3fc8904241d200c1eeb6.dip0.t-ipconnect.de. [2003:eb:8f3b:3fc8:9042:41d2:c1:eeb6]) by smtp.gmail.com with ESMTPSA id cm26sm6268958edb.87.2020.05.21.23.59.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2020 23:59:05 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <365a545e-cd20-65c7-c7ae-d71c63865fce@connect2id.com>
Date: Fri, 22 May 2020 08:59:03 +0200
Cc: Joseph Heenan <joseph.heenan@fintechlabs.io>, Openid-specs-fapi <openid-specs-fapi@lists.openid.net>, oauth <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <78531853-D0B1-492C-85DA-E140A921B04B@lodderstedt.net>
References: <CAP-T6TTehOT7U_fniZdHsei1C1phOWQfK7o=fHSNciXSTjviPA@mail.gmail.com> <2066e8dd-fac8-db15-6d5c-19b11db050a2@connect2id.com> <72D97116-747B-47FE-A4D7-E729B708E723@fintechlabs.io> <365a545e-cd20-65c7-c7ae-d71c63865fce@connect2id.com>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/0LEh5apLZJsgobqjodfBZuOGLYo>
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: Fri, 22 May 2020 06:59:12 -0000

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> 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> 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
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth