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": "loadsmoney business banking customers",
> "logo_url": "https://loadsamoney/business/logo.png"
> },
> "personal": {
> "authorization_endpoint": "https://loadsamoney/consumer/auth",
> "description": "loadsmoney personal customers",
> "logo_url": "https://loadsamoney/consumer/logo.png"
> }
> }
It assumes only 1 piece of metadata (authorization_endpoint) is brand-specific,
but none of the other 50 (eg ui_locales_supported, op_tos_uri,
scopes_supported, …) from 4 different specs currently listed in the metadata
registry<https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata>
(not to mention the ones in draft specs not registered yet).
It offers 1 logo (in one size/resolution/format/colour-palette/…) and 1
description (in one language), which is likely to be totally inadequate so the
suggestion is probably only a fraction of the actual complexity required.
If you want to build a “chooser” user-interface allowing a user to, say, pick
between multiple banks & brands then that needs a solution quite distinct from
AS metadata.
If you want to allow a client to reuse 1 dynamic registration across multiple
brands, could you compare the “registration_endpoint” in each brand’s own AS
metadata (being careful a malicious AS cannot trick the client into sharing the
client’s creds from a victim AS). Or how about an “associated_issuer” member
holding an array of issuer identifiers. If issA & issB each list each other in
their “associated_issuer” metadata, then a client registration at either can be
used at the other.
If you merely want to trigger a different look-n-feel, define a “brand”
parameter to add the to the authorization request.
--
James Manger
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth