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

Vladimir Dzhuvinov <> Wed, 20 May 2020 15:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C11A3A0A81 for <>; Wed, 20 May 2020 08:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WVSuqwaqSwZ7 for <>; Wed, 20 May 2020 08:08:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B55853A093D for <>; Wed, 20 May 2020 08:08:01 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id bQK5j3BGtdUjIbQK7j1Ei5; Wed, 20 May 2020 08:08:01 -0700
X-CMAE-Analysis: v=2.3 cv=V4wDLtvi c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=xtERp6CFAAAA:8 a=uXKtHWO2UFqTaMCM4KwA:9 a=K4+QNa6dn7cCZlPPpztru4orrlc=:19 a=eD4XPYFH_YmTrwKq:21 a=LPvUBouTuPz367Qt:21 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=iwW7FXZmUZ5ra3T_uI4A:9 a=sOIWAApBRbf-zHzR:21 a=rjHpS40FXzfAw-er:21 a=LcEjaFlFgROdAWtY:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22
To: Dave Tonge <>, oauth <>
Cc: Openid-specs Fapi <>, Joseph Heenan <>
References: <>
From: Vladimir Dzhuvinov <>
Autocrypt:; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <>
Date: Wed, 20 May 2020 18:07:57 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000001050600080908000600"
X-CMAE-Envelope: MS4wfAFUYL8gSwL54//Al7lHqmqKsidE7xfhhc6yDZuCc3wg/uNLoklDm9YWExX2XcJjLCsB0fWFJ1m5KXabDKxZfznhCUBknS391ztVWxkh6FGsvyaXZ7f6 HobZ8Ta5kaMuVxyHWvSkWP/eqXSAYCQHis7H1jklgz33luJQfcIzCSCitucnQ8/WH+JhMkCdU9QuvHmYfIbQ0KS2Z0aTMY5tS2v8GQ8Z26Iam2PdWqKGsB1I 15vfN6YdOv4pfux+HdF87+V9qvenfxuV515NkPqfOS1PbLgGleS3tbhZtiQCoJYARlEiz6QDFTo9hVtuH9fwog==
Archived-At: <>
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
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 15:08:05 -0000

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:

One could devise a similar JSON object with mappings "label" -

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.


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