[OAUTH-WG] Questions about oauth-browser-based-apps-06

[Jared L Jennings]

I'm surprised that this is OK. Why is this safe or a best practice?

   /The Application Server can store the access token either server-side, /
   /or in the cookie itself./


What are appropriate browser APIs? (Maybe providing some guidance or a 
hint regarding this?)


   /The JavaScript app is then responsible for storing the access token /
   /(and optional refresh token) securely using appropriate browser APIs./


Can the access token be included the various (all) available transport 
methods? Query string, Header, Post, etc.


/When the JavaScript application in the browser wants to make a request 
to the Resource Server, it can include the access token in the request 
(D) and make the request directly./



Thanks,

--
-
Jared L Jennings
816.678.4152
Skype: jaredljennings

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [EXTERNAL] Re: proposed resolution for PKCE in OAuth 2.1

[Mike Jones]

I disagree with the language below.  It’s perfectly legal to switch, as the 
same client may do both OpenID Connect and pure OAuth interactions, depending 
upon whether the “openid” scope is included.  Both can be secure.

If the OpenID Connect `nonce` is used to mitigate authorization code
injection instead of `code_challenge`, client and authorization server
MUST ensure that the mitigation is applied to every interaction with
the client and that the client cannot switch between `code_challenge`
and `nonce`. For example, the presence of a `nonce` parameter in the
authorization request is not sufficient to determine that the
`code_verifier` check can be skipped.

I’d rather that the onus be put on new code, than existing code.  For instance 
new code wanting to require PKCE on all interactions could use something like a 
“require_pkce” dynamic client registration parameter (or corresponding static 
registration).  Otherwise, it should be up to the client which of the 
mechanisms to use.

-- Mike

From: Aaron Parecki 
Sent: Wednesday, May 20, 2020 3:48 PM
To: Nov Matake 
Cc: Mike Jones ; oauth@ietf.org
Subject: [EXTERNAL] Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

So if I'm understanding this correctly, it sounds like the AS needs to reject a 
token request with code_verifier if the authorization code was issued in 
response to a request that did not contain a code_challenge. This to me sounds 
like it would be simpler to just say the code_challenge and code_verifier are 
always required.

That said, I do understand the previously discussed concerns around existing 
OpenID Connect clients.

I believe the text that Daniel proposed is the best of both worlds, and I 
support making this change in both OAuth 2.1 and the Security BCP.

Aaron Parecki



On Tue, May 19, 2020 at 9:29 AM Nov Matake 
mailto:mat...@gmail.com>> wrote:
Yes.

The root problem isn’t the mix-use of PKCE and nonce, it’s PKCE implementation 
bug.
Yeah, all PKCE implementation MUST reject such requests, regardless it’s OAuth 
2.1 or 2.0.

(and it’s probably because of PKCE spec’s ambiguity..)


2020/05/20 1:13、Mike Jones 
mailto:michael.jo...@microsoft.com>>のメール:

So it sounds me like the fix is to have servers reject PKCE requests with 
incomplete parameter sets: requests that only contains one of code_challenge 
and code_verified.  Will that eliminate the attack, Nov?

   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Nov Matake
Sent: Monday, May 18, 2020 11:50 PM
To: Daniel Fett mailto:f...@danielfett.de>>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

Sure, feel free to add the senario to your post.

FYI:
my OAuth2 server ruby gem rejects such token requests,
https://github.com/nov/rack-oauth2/blob/master/lib/rack/oauth2/server/extension/pkce.rb#L28
and Google also does the same.
https://gist.github.com/nov/9feba86685bd3b18b4bf7bfb88022046

So I'm guessing such behavior is relatively rare-case, hopefully.

iPadから送信

2020/05/19 15:43、Daniel Fett 
mailto:f...@danielfett.de>>のメール:

Hi,

Am 19.05.20 um 04:55 schrieb Nov Matake:
I thought the server MUST reject such token requests, but I couldn’t find such 
definition in RFC7636...

> The client will send the code, along with a (now not matching) code_verifier 
> to the server. The server will ignore the code_verifier (as it was not 
> expected) and send back an access token and ID token to the client.
https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepkce-sidestep-attack

If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep Attack” would be 
possible.

I *think* that there is nothing preventing servers from sometimes using PKCE 
and sometimes using Nonce. I assume that this is out of the scope of the 
existing specifications.

I would be interested to hear how actual implementations handle this in 
practice.

Plus, with such AS behavior, CSRF protection using PKCE can also be bypassed as 
below.
1. The attacker removes code_challenge from his/her own AuthZ Req, receives a 
non-code_challenge-bound code, and sends it to the victim.
2. The client receives the attacker’s code from the victim, and sends it to the 
AS w/ the valid code_verifier bound to the victim’s browser session.
3. The AS ignores the code_verifier and returns tokens.

If that’s the case, current OAuth 2.0 PKCE implementation can be weaker than 
expected..

Excellent point!

Would it be okay if I add that attack to the original post (with credits, of 
course)?

-Daniel

nov

2020/05/19 1:54、Daniel Fett mailto:f...@danielfett.de>>のメール:

Hi all,

Talking to Torsten, we realized that providing a generic extension point here 
is probably not a good idea. It is really hard to tell what protects you from 
code injection and what does not, and people might come up with all sorts of 

Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

[Aaron Parecki]

So if I'm understanding this correctly, it sounds like the AS needs to
reject a token request with code_verifier if the authorization code was
issued in response to a request that did not contain a code_challenge. This
to me sounds like it would be simpler to just say the code_challenge and
code_verifier are always required.

That said, I do understand the previously discussed concerns around
existing OpenID Connect clients.

I believe the text that Daniel proposed is the best of both worlds, and I
support making this change in both OAuth 2.1 and the Security BCP.

Aaron Parecki



On Tue, May 19, 2020 at 9:29 AM Nov Matake  wrote:

> Yes.
>
> The root problem isn’t the mix-use of PKCE and nonce, it’s PKCE
> implementation bug.
> Yeah, all PKCE implementation MUST reject such requests, regardless it’s
> OAuth 2.1 or 2.0.
>
> (and it’s probably because of PKCE spec’s ambiguity..)
>
> 2020/05/20 1:13、Mike Jones のメール:
>
> So it sounds me like the fix is to have servers reject PKCE requests with
> incomplete parameter sets: requests that only contains one of
> code_challenge and code_verified.  Will that eliminate the attack, Nov?
>
>-- Mike
>
> *From:* OAuth  *On Behalf Of *Nov Matake
> *Sent:* Monday, May 18, 2020 11:50 PM
> *To:* Daniel Fett 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>
> Sure, feel free to add the senario to your post.
>
> FYI:
> my OAuth2 server ruby gem rejects such token requests,
>
> https://github.com/nov/rack-oauth2/blob/master/lib/rack/oauth2/server/extension/pkce.rb#L28
> and Google also does the same.
> https://gist.github.com/nov/9feba86685bd3b18b4bf7bfb88022046
>
> So I'm guessing such behavior is relatively rare-case, hopefully.
>
> iPadから送信
>
>
> 2020/05/19 15:43、Daniel Fett のメール:
>
> 
> Hi,
>
> Am 19.05.20 um 04:55 schrieb Nov Matake:
>
> I thought the server MUST reject such token requests, but I couldn’t find
> such definition in RFC7636...
>
> > The client will send the code, along with a (now not matching)
> code_verifier to the server. The server will ignore the code_verifier (as
> it was not expected) and send back an access token and ID token to the
> client.
>
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepkce-sidestep-attack
>
> If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep Attack”
> would be possible.
>
> I *think* that there is nothing preventing servers from sometimes using
> PKCE and sometimes using Nonce. I assume that this is out of the scope of
> the existing specifications.
>
> I would be interested to hear how actual implementations handle this in
> practice.
>
>
> Plus, with such AS behavior, CSRF protection using PKCE can also be
> bypassed as below.
> 1. The attacker removes code_challenge from his/her own AuthZ
> Req, receives a non-code_challenge-bound code, and sends it to the victim..
> 2. The client receives the attacker’s code from the victim, and sends it
> to the AS w/ the valid code_verifier bound to the victim’s browser session.
> 3. The AS ignores the code_verifier and returns tokens.
>
> If that’s the case, current OAuth 2.0 PKCE implementation can be weaker
> than expected..
>
> Excellent point!
>
> Would it be okay if I add that attack to the original post (with credits,
> of course)?
>
> -Daniel
>
>
> nov
>
>
> 2020/05/19 1:54、Daniel Fett のメール:
>
> Hi all,
>
> Talking to Torsten, we realized that providing a generic extension point
> here is probably not a good idea. It is really hard to tell what protects
> you from code injection and what does not, and people might come up with
> all sorts of non-standard and potentially insecure solutions.
>
> Even just for PKCE vs. Nonce, it is not obvious if they provide the same
> level of protection. In an attempt to answer this question, I tried to come
> up with a more systematic analysis of "PKCE vs Nonce". I wrote up my
> results here:
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
>
> Although this is not a formal analysis, I hope that I have covered all
> interesting cases. Please review the text and let me know if I have missed
> something or if there are any mistakes.
>
> The main results are:
>
>1. In terms of protection against CSRF and code misuse, PKCE and Nonce
>provide similar levels of security, with a slight advantage for PKCE.
>2. In practice, a circumvention of both mechanisms, however, is
>possible if an AS allows a client to choose between PKCE and Nonce and the
>client makes use of this freedom. I propose to call this attack the
>Nonce/PKCE Sidestep Attack. → Please review the attack description in the
>analysis.
>3. To avoid the Nonce/PKCE Sidestep Attack, clients must not switch
>between using only PKCE and only Nonce (but may use both in parallel, or
>switch between using only PKCE and PKCE+Nonce). Authorization servers must
>enforce PKCE unless they know that the 

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

[Joseph Heenan]

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  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
>> 
>> 
> 

___
OAuth mailing list

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

[Vladimir Dzhuvinov]

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
>
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-18

[Rifaat Shekh-Yusef]

Hi Janak,

All interim meetings are posted on the IETF Youtube channel.
Here is the link to the latest meeting:
https://www.youtube.com/watch?v=txkRiIiHEbE

Regards,
 Rifaat


On Wed, May 20, 2020 at 10:17 AM Janak Amarasena 
wrote:

> Hi Rifaat,
>
> Any chance of getting the recording of the meeting?
>
> Best Regards,
> Janak Amarasena
>
> On Tue, May 19, 2020 at 3:40 PM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> Hi Filip,
>>
>> I have uploaded the slides to the materials page here:
>>
>> https://datatracker.ietf.org/meeting/interim-2020-oauth-09/materials/slides-interim-2020-oauth-09-sessa-dpop
>> 
>>
>>
>> Regards,
>>  Rifaat
>>
>>
>> On Tue, May 19, 2020 at 5:39 AM Filip Skokan  wrote:
>>
>>> Hello Brian,
>>>
>>> can you share the slide deck from yesterday so that we may continue
>>> the discussion on the mentioned open questions here on the list?
>>>
>>> Thank you,
>>>
>>> Best,
>>> *Filip*
>>>
>>>
>>> On Wed, 13 May 2020 at 20:43, Brian Campbell >> 40pingidentity@dmarc.ietf.org> wrote:
>>>
 Just wanted to note that there is a newer -01 revision of the document
 on the agenda https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html

 On Wed, May 13, 2020 at 6:16 AM IESG Secretary 
 wrote:

> The Web Authorization Protocol (oauth) Working Group will hold
> a virtual interim meeting on 2020-05-18 from 18:00 to 19:00
> Europe/Vienna (16:00 to 17:00 UTC).
>
> Agenda:
> DPOP
> https://tools.ietf.org/html/draft-ietf-oauth-dpop-00
>
> Information about remote participation:
>
> https://ietf.webex.com/ietf/j.php?MTID=m2655406e74aa2b4e129a1b91a076f70b
>
>
> https://mailarchive.ietf.org/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/
>
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

 *CONFIDENTIALITY NOTICE: This email may contain confidential and
 privileged material for the sole use of the intended recipient(s). Any
 review, use, distribution or disclosure by others is strictly
 prohibited  If you have received this communication in error, please
 notify the sender immediately by e-mail and delete the message and any file
 attachments from your computer. Thank you.*
 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth

>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-18

[Janak Amarasena]

Hi Rifaat,

Any chance of getting the recording of the meeting?

Best Regards,
Janak Amarasena

On Tue, May 19, 2020 at 3:40 PM Rifaat Shekh-Yusef 
wrote:

> Hi Filip,
>
> I have uploaded the slides to the materials page here:
>
> https://datatracker.ietf.org/meeting/interim-2020-oauth-09/materials/slides-interim-2020-oauth-09-sessa-dpop
> 
>
>
> Regards,
>  Rifaat
>
>
> On Tue, May 19, 2020 at 5:39 AM Filip Skokan  wrote:
>
>> Hello Brian,
>>
>> can you share the slide deck from yesterday so that we may continue
>> the discussion on the mentioned open questions here on the list?
>>
>> Thank you,
>>
>> Best,
>> *Filip*
>>
>>
>> On Wed, 13 May 2020 at 20:43, Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote:
>>
>>> Just wanted to note that there is a newer -01 revision of the document
>>> on the agenda https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html
>>>
>>> On Wed, May 13, 2020 at 6:16 AM IESG Secretary 
>>> wrote:
>>>
 The Web Authorization Protocol (oauth) Working Group will hold
 a virtual interim meeting on 2020-05-18 from 18:00 to 19:00
 Europe/Vienna (16:00 to 17:00 UTC).

 Agenda:
 DPOP
 https://tools.ietf.org/html/draft-ietf-oauth-dpop-00

 Information about remote participation:
 https://ietf.webex.com/ietf/j.php?MTID=m2655406e74aa2b4e129a1b91a076f70b

 https://mailarchive.ietf.org/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/

 ___
 IETF-Announce mailing list
 ietf-annou...@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf-announce

>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly
>>> prohibited  If you have received this communication in error, please
>>> notify the sender immediately by e-mail and delete the message and any file
>>> attachments from your computer. Thank you.*
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Issuers, Discovery Docs & Brands

[Dave Tonge]

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