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 9158B3A082E for ; Wed, 20 May 2020 05:07:23 -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 UARxBvjyQUXB for ; Wed, 20 May 2020 05:07:21 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 C0B7F3A081F for ; Wed, 20 May 2020 05:07:21 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id d26so2212875otc.7 for ; Wed, 20 May 2020 05:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=zx3SkSH1eOdFwyuPC162SmQcoZ6m8PiRkcvkqitlHRg=; b=TK3Rt+Sr6Va0gY9zy6/T0hDjXCjb6n9uX2HYktmGvNJ1lH0nBXnaWsVlYIl4aDTiHB KDibHHtbi8F6JB/Ji7IZGjwZjZuxXQQ0UUaAc2eEFUy1UN4zpfXc3LkVGWdVCnw453Ky 8BJiz4tXZ8rELt2QOI/re2Ai30BAwUv6f6fvc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=zx3SkSH1eOdFwyuPC162SmQcoZ6m8PiRkcvkqitlHRg=; b=BeBQ7lCQUAEUkZFuu1V1xMPYqTZA6azv9kQvunJbXje8uMP2Y9n7ZUDlUUVqxuEeIn Jv0BgF5cHeamHuEe71PEu/pNlWINs9HMqbkQuM1RHvJKhefammVlMDCr66XsWpS6HiIr pz42Ohz+K0tYDm7M8YgzXQe0ZhOt7/xhUN83jfTZrmhKK7rpSD4UoMTuzchyxvWKQZZi mwVxBeqIZ3LAt1EJdYPU+PwFuDdA2VsDe5J/1319rpaaglVykYmpTaWZsnDObrXVrNHu e3bi8s86OOgoXreNzzOsY5FEUuH5oW28RyBreJQJHGwrFZkPVV4CNfkUxmHC4zHoNoJy 2biQ== X-Gm-Message-State: AOAM533wO8gQxv7GAhxNr3yBjUpCn8DgPB7SRLfLzlmn/zqUPhlt0dW4 yRAdW3UGjQ0x1oi4oh7wMSGBgtTf1JlI+OoULLZ3hzbqOcwMZYqa X-Google-Smtp-Source: ABdhPJy7+LnKFeb1QR21PTlu3UXZfPPsFTUUNR4aQIptfdvg2xdRbGgRuqRCjpNjqeK4MBGA0Ra5QkIj4DVG9Z8bkk8= X-Received: by 2002:a9d:20e7:: with SMTP id x94mr3106958ota.260.1589976440496; Wed, 20 May 2020 05:07:20 -0700 (PDT) MIME-Version: 1.0 From: Dave Tonge Date: Wed, 20 May 2020 14:07:09 +0200 Message-ID: To: oauth Cc: Joseph Heenan , Openid-specs Fapi Content-Type: multipart/alternative; boundary="000000000000f00f8005a6133cea" Archived-At: Subject: [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 12:07:24 -0000 --000000000000f00f8005a6133cea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 --000000000000f00f8005a6133cea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear OAuth WG

We have an = issue in the OpenID FAPI Working Group that we believe affects the wide= r OAuth community.

In summary: what is the recommended ap= proach to discovery (RFC8414) for Authorization Servers=C2=A0who support mu= ltiple "brands" .

If brands are completely sep= arate, then it seems sensible that each brand must have its own `issuer` an= d therefore its own discovery document at the correct location (i.e. brand = 1 would have an issuer of "https://as/br= and1" and a discovery document available at=C2=A0 https://as/.well-known/oauth-autho= rization-server/brand1).

However in the real world it is not always so simple. We have = many existing implementations in UK open banking that support=C2=A0multiple= authorization endpoints. Here is an example (thanks to=C2=A0@Joseph Heenan=C2=A0)

> Bank =E2=80=9Cloadsamoney=E2=80=9D has one idp = and, for internet banking, one =E2=80=9Clogin page=E2=80=9D for both busine= ss and personal customers.

> They have separate mobile apps for b= usiness/personal, and are required to support app2app. This means they will= definitely be exposing multiple authorization endpoints (as there=E2=80=99= s a 1:1 mapping of authorization endpoints to mobile apps) - the choice is = how they do this.

> Their choices are:

> 1. Multiple di= scovery endpoints (one for business, one for personal), each with a differe= nt 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.=C2=A0<= /div>
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 RF= C8414 to allow the definition of multiple authorization endpoints.

Thanks in advance

Dave Tonge
Co-Chair FAPI WG

--000000000000f00f8005a6133cea--