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 1E2773A0C1A for ; Wed, 20 May 2020 09:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=fintechlabs-io.20150623.gappssmtp.com 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 b67Xx4YpXbqp for ; Wed, 20 May 2020 09:16:49 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 ED8F13A0BBA for ; Wed, 20 May 2020 09:16:48 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id u188so3526679wmu.1 for ; Wed, 20 May 2020 09:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fintechlabs-io.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YFjtzaSPXZzpKhnINPKLwG8nZSqk8i1PNhxU0gkTj7M=; b=owfrijxlqyZXdRWSaV8v/ogEgCu5vVWPUkcwjgYvY0i6Yzf9iU/5bFPf67j6yz7Aef mIu8ZY2kLbs8XhRZFGk31sZP5y5/OSqGBcKBk2gXWowSz5h9Zr/qEHFA/+IEXXPmLuQp zW5u/m/RETZfwh6AN9CjlD8X/yUbIcwEe16nyFQWeI+xe4Kx5w1u2DJ3rdc7TQ72D6Kb IO6EBBU1gNbFpSHSfACHMLqECKc9arHA3kqxNSf665OJdrVJOis/hiBmgjq5WgxEyAos CQNDo2UrdNi+b6Y3W0lIxAV3VG+h3ZGZyP3K8FZHd3tyD0Hz2Y0FB5eAYrKDQ0X9AfmY 1iGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YFjtzaSPXZzpKhnINPKLwG8nZSqk8i1PNhxU0gkTj7M=; b=kDmxt6Eu6vWTCFSNalZqFqn92IXLBXwr4JOgvsiMwnhiMOhWWP2KoozOIRloX9xnWs CTDnUjFqlf4Ivtdj8MQW8nuIWZlBikkn/C8l/sBTbQfcdRc7Wu5xgZGgO93cyHPKiPGD i1BKVM7simXOMD9AOtbxHPaai5K3DjmNsu5Gm2tSkukFdlRlVkVDIWaBaiYU1rC1i9A/ n/3vfqRArl7J/Sc68hD7IVUJjqtmVwil0uuA4igw3cVBv1W4cHo214KnXsiHMK/jLoYw thlcu/X1zK+QLIVvSq+Su0XN/b/TLVuhvrt/bQgA1f0NrSZbVeLAru2uFw1hgbnks20+ hZ9A== X-Gm-Message-State: AOAM531SJTtbl/mC/T0n9roovYY7aNVLnkmdIriQpgxCle2+YO+GxMXy jl3jkYgg50lmBfDO7UqhUyC0gw== X-Google-Smtp-Source: ABdhPJwpvNB/MGaEw5n5QStNwQ9a6r14g5zVHM8RPzw8zlVmihgg5D8CBZd68Ozp+gUcvixbDN17iw== X-Received: by 2002:a1c:2302:: with SMTP id j2mr5140658wmj.18.1589991407246; Wed, 20 May 2020 09:16:47 -0700 (PDT) Received: from [192.168.1.112] (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id g140sm3205259wmg.47.2020.05.20.09.16.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2020 09:16:46 -0700 (PDT) From: Joseph Heenan Message-Id: <72D97116-747B-47FE-A4D7-E729B708E723@fintechlabs.io> Content-Type: multipart/alternative; boundary="Apple-Mail=_C614FCF7-910B-4FD5-AA12-15C582357414" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 20 May 2020 17:16:44 +0100 In-Reply-To: <2066e8dd-fac8-db15-6d5c-19b11db050a2@connect2id.com> Cc: Dave Tonge , oauth , Openid-specs-fapi To: Vladimir Dzhuvinov References: <2066e8dd-fac8-db15-6d5c-19b11db050a2@connect2id.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) 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, 20 May 2020 16:16:52 -0000 --Apple-Mail=_C614FCF7-910B-4FD5-AA12-15C582357414 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for your thoughts Vladimir! The client_id based solution I wasn=E2=80=99t previously aware of - = unfortunately it doesn=E2=80=99t 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=E2=80=99s 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. >=20 I think that particular part is not really an issue as mtls isn=E2=80=99t = used at the authorization endpoint. Thanks Joseph > On 20 May 2020, at 16:07, Vladimir Dzhuvinov = wrote: >=20 > Hi Dave, >=20 > 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. >=20 > You're probably aware the mTLS spec is allowing for endpoint aliases, = so this is not the first time such as need has occurred: >=20 > https://tools.ietf.org/html/rfc8705#section-5 = > One could devise a similar JSON object with mappings "label" - = "authorization_endpoint". >=20 > Clients that are aware of the new spec will look it up, those that are = not will fall back to the std "authorization_endpoint". >=20 > Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be = sensibly combined with the proposed multi-brand spec. >=20 >=20 >=20 > Vladimir >=20 >=20 >=20 > On 20/05/2020 15:07, Dave Tonge wrote: >> Dear OAuth WG >>=20 >> We have an issue = in the OpenID FAPI Working Group that we believe affects the = wider OAuth community. >>=20 >> In summary: what is the recommended approach to discovery (RFC8414) = for Authorization Servers who support multiple "brands" . >>=20 >> 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). >>=20 >> 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 = ) >>=20 >> > Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp and, for internet = banking, one =E2=80=9Clogin page=E2=80=9D for both business and personal = customers. >>=20 >> > 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=E2=80=99s a 1:1 mapping of = authorization endpoints to mobile apps) - the choice is how they do = this. >>=20 >> > Their choices are: >>=20 >> > 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) >>=20 >> Option 3 is invalid and that leaves us with options 1 and 2.=20 >> Option 1 can be problematic as often it is in reality the same = `issuer` behind the scenes. >>=20 >> We would like to get feedback on this issue and potentially an = extension to RFC8414 to allow the definition of multiple authorization = endpoints. >>=20 >> Thanks in advance >>=20 >> Dave Tonge >> Co-Chair FAPI WG >> Open ID Foundation >>=20 >>=20 >=20 --Apple-Mail=_C614FCF7-910B-4FD5-AA12-15C582357414 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for your thoughts Vladimir!

The client_id based solution I wasn=E2=80= =99t previously aware of - unfortunately it doesn=E2=80=99t 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=E2=80=99s = 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=E2=80=99t used at the authorization = endpoint.

Thanks

Joseph


On 20 May 2020, at 16:07, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

=20 =20

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 =E2=80=9Cloadsamoney=E2=80=9D has one = idp and, for internet banking, one =E2=80=9Clogin page=E2=80=9D 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=E2=80=99s 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




= --Apple-Mail=_C614FCF7-910B-4FD5-AA12-15C582357414--