<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">Hi Joseph,</div><div dir="ltr"><br><blockquote type="cite">Am 03.06.2020 um 19:07 schrieb Joseph Heenan via Openid-specs-ab <openid-specs-ab@lists.openid.net>:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8">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></blockquote><div><br></div>How do you envision this use case to work? Assuming the RP has determined the issuer and obtained the metadata document, how does it determine what alternative endpoint (and App) to use? Would the RP check whether any of the respective apps is installed on the device?<div><br></div><div>best regards,</div><div>Torsten.</div><div><div><br><blockquote type="cite"><div dir="ltr"><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><span>_______________________________________________</span><br><span>Openid-specs-ab mailing list</span><br><span>Openid-specs-ab@lists.openid.net</span><br><span>http://lists.openid.net/mailman/listinfo/openid-specs-ab</span><br></div></blockquote></div></div></body></html>