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

Reply via email to