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

Hi James, > On 5 Jun 2020, at 03:23, Manger, James > wrote: > If you merely want to trigger a different look-n-feel, define a “brand” > parameter to add the to the authorization request. Unfortunately this doesn’t work when the authorization endpoint is a claimed https url for a mobile app:

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

Wedging support for multiple Authorization Server brands via this "alternative_authorization_endpoints" metadata field is a very kludgy hack. > "alternative_authorization_endpoints": { >"banking": { > "authorization_endpoint": "https://loadsamoney/business/auth";, > "description": "

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

Hi Francis, > On 3 Jun 2020, at 18:07, Francis Pouatcha > wrote: > > Hello Dave, > > I agree that the best deployment option is: 1 brand = 1 issuer = 1 discovery > doc, however that is not always possible. > > I'd like to understand Francis what particular issue you see from allowing an > A

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

t; } > } > This use case is neither multi tenancy nor the disclosure of the client identity in a consent page. Starting with the logo here, we will end up adding css and js code snippets. This type of customizing shall be done in the AS-Deployment without playing around with the public A

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

s://loadsamoney/consumer/auth";, "description": "loadsmoney personal customers", "logo_url": "https://loadsamoney/consumer/logo.png"; } } Dave On Wed, 27 May 2020 at 16:09, Francis Pouatcha wrote: > >> >> Message: 1 >&g

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

> > > > Message: 1 > Date: Tue, 26 May 2020 09:03:16 +0300 > From: Vladimir Dzhuvinov > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands > Message-ID: <2fc4c4ee-8627-936a-baf4-872c0f18e...@connect2id.com> > Content-

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

My understanding of the branding concept was to present different UIs to resource owners during login and authorization, while keeping the OP / AS the same, meaning identical issuer. In a spec it would be helpful to spell out what branding means (and what not). Regarding a token being issued for "

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

- I will go for Option 1 even if we have the same runtime instance producing tokens under different issuer uris. - Option 2 might expose security risk as many clients rely on the issuer to associate the token with authorization context. By no way shall a token issued for "personal" be valid for "b

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

The first case looks better to me as well. It would require a chooser that provides both the issuer url and the brand id. BTW: I would prefer a more generic term in order to facilitate other use cases. I think it could be useful to have a discriminator for selecting a set of endpoints. For exa

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

I just realised that “client chooser” in the below is a very ambiguous term. Please read it to mean “a chooser presented by the client”.. (And in the UK today, that chooser is manually populated by the client developer based on the central directory.) Joseph > On 22 May 2020, at 09:32, Joseph

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

Thanks Vladimir/Torsten. I agree, it would make sense to have some form of static id for each entry. My first attempt started out similar but for some reason I decided to simplify… On the conceptual side for choosers (and biased towards how the UK openbanking ecosystem works as that’s what I kn

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

With that said it makes sense to devise a structure which can accommodate UI driven as well as automatic choice. * The UI driven chooser will need a human readable description and other UI hints. This can work for instance with "classic" OIDC Discovery. * The "auto" chooser will need

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

I think an id or label per endpoint set would be needed to determine the set of endpoints to be used by a certain client. On the conceptual side, I’m asking myself how the complete process is supposed to work. Who is deciding what issuer/endpoint set combination to use. I assume in an open bank

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

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 param

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

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

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

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

[OAUTH-WG] Issuers, Discovery Docs & Brands

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