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

Vladimir Dzhuvinov <vladimir@connect2id.com> Fri, 22 May 2020 06:10 UTC

Return-Path: <vladimir@connect2id.com>
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 612303A0ED6 for <oauth@ietfa.amsl.com>; Thu, 21 May 2020 23:10:22 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 a6nt_9eyNxPO for <oauth@ietfa.amsl.com>; Thu, 21 May 2020 23:10:20 -0700 (PDT)
Received: from p3plsmtpa12-01.prod.phx3.secureserver.net (p3plsmtpa12-01.prod.phx3.secureserver.net [68.178.252.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0643A0ED5 for <oauth@ietf.org>; Thu, 21 May 2020 23:10:20 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id c0sqjBxjVdUjIc0ssj3erX; Thu, 21 May 2020 23:10:19 -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=is3RsFX7AAAA:8 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=xtERp6CFAAAA:8 a=aIV-FTHC-H4Dhrm39lYA:9 a=K4+QNa6dn7cCZlPPpztru4orrlc=:19 a=UmaLIfN2AhQ9ysBL:21 a=JRyh2daJwUtBteVW:21 a=QEXdDO2ut3YA:10 a=jl1lMIPSATsA:10 a=pGLkceISAAAA:8 a=-fURarvJKJOy_1CgWcQA:9 a=ToMOwuxt29NOrO82:21 a=1xyAgr1_yCD1nCmP:21 a=eyPr8bBxdJ_wKJy8:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=CvJ-9y_HEmGQg9NJmnFv:22 a=H5r4HjhRfVyZ-DhAOYba:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: Joseph Heenan <joseph.heenan@fintechlabs.io>
Cc: Dave Tonge <dave.tonge@momentumft.co.uk>, oauth <oauth@ietf.org>, Openid-specs-fapi <openid-specs-fapi@lists.openid.net>
References: <CAP-T6TTehOT7U_fniZdHsei1C1phOWQfK7o=fHSNciXSTjviPA@mail.gmail.com> <2066e8dd-fac8-db15-6d5c-19b11db050a2@connect2id.com> <72D97116-747B-47FE-A4D7-E729B708E723@fintechlabs.io>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Autocrypt: addr=vladimir@connect2id.com; 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: <365a545e-cd20-65c7-c7ae-d71c63865fce@connect2id.com>
Date: Fri, 22 May 2020 09:10:16 +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: <72D97116-747B-47FE-A4D7-E729B708E723@fintechlabs.io>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070006080209000105010900"
X-CMAE-Envelope: MS4wfB6rIq50gKwPxYy84Lgu6k0kT5zB1Q3iYXGq3Fdn1qCbsFRGc7hPHzCPjwncwiA+/CYb7t6zZRooFmn2g9S9oPV8Gsr8EpUTUqN/hZ9XRrJXZBCxwNlh 0xwlltwrzyQ8gBcbpcn/qS4LRMfSYrpPJTFkNNRDTvk4cD22XgvwJICBHEo0LlxOq7X/V7cB61bIztcnM7iKZkS8Mx7PSS1gUWORpHzeB7L2dVN7xLrtiwsW 4TVxk7DmwGQGE3cuPX8XNiFgaYjlxyACQAXRgHcCEP4B9HEH9XVsjm5y+RrMVg5RH6ftT0x7nXDq9Ki2KAlB/w==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/mFpCqcNElkT_KKhNgxtSafRB3fw>
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:10:23 -0000

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
>> <mailto: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
>>> <https://bitbucket.org/openid/fapi/issues/255/certification-clarification-request>
>>> 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 <mailto:joseph.heenan@fintechlabs.io> )
>>>
>>> > 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