<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi all,<div class=""><br class=""></div><div class="">One of the discussions on the FAPI working group:</div><div class=""><br class=""></div><div class=""><a href="https://bitbucket.org/openid/fapi/issues/255/certification-clarification-request" class="">https://bitbucket.org/openid/fapi/issues/255/certification-clarification-request</a></div><div class=""><br class=""></div><div class="">Eventually gave rise to a thread on the OAuth WG:</div><div class=""><br class=""></div><div class=""><a href="https://mailarchive.ietf.org/arch/browse/oauth/?gbt=1&index=RDtr2l-e3CxlXpcHobqiieessG8" class="">https://mailarchive.ietf.org/arch/browse/oauth/?gbt=1&index=RDtr2l-e3CxlXpcHobqiieessG8</a></div><div class=""><br class=""></div><div class="">The FAPI WG thought it’d be a good idea to give the connect working group a heads up as well, as it firmly crosses into the area the OIDC discovery spec covers.</div><div class=""><br class=""></div><div class="">In particular there appears to be a possible consensus forming around adding a sub structure something like this to the discovery document:</div><div class=""><br class=""></div><div class=""><pre class="wordwrap" style="box-sizing: border-box; font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; font-size: 12.25px; margin-top: 0px; margin-bottom: 1rem; overflow: auto; color: rgb(33, 37, 41); white-space: pre-wrap; word-wrap: normal; word-break: normal; padding: 0px; caret-color: rgb(33, 37, 41);">"alternative_authorization_endpoints": {
"banking": {
"authorization_endpoint": "<a href="https://loadsamoney/business/auth" class="">https://loadsamoney/business/auth</a>",
"description": "loadsmoney business banking customers",
"logo_url": "<a href="https://loadsamoney/business/logo.png" class="">https://loadsamoney/business/logo.png</a>"
},
"personal": {
"authorization_endpoint": "<a href="https://loadsamoney/consumer/auth" class="">https://loadsamoney/consumer/auth</a>",
"description": "loadsmoney personal customers",
"logo_url": "<a href="https://loadsamoney/consumer/logo.png" class="">https://loadsamoney/consumer/logo.png</a>"
}
}</pre><div class="">This solves at least two issues:</div></div><div class=""><br class=""></div><div class="">1) Allowing a single authorisation server for companies that have several distinct brands</div><div class=""><br class=""></div><div class="">2) A similar issue where there’s only one brand but there’s segmented user bases that have different mobile apps and app2app is in use, which then requires distinct authorization endpoints for the two apps.</div><div class=""><br class=""></div><div class="">Any thoughts are most welcome.</div><div class=""><br class=""></div><div class="">Thanks</div><div class=""><br class=""></div><div class="">Joseph</div><div class=""><br class=""></div></body></html>