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