<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 Francis,<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 3 Jun 2020, at 18:07, Francis Pouatcha <<a href="mailto:fpo=40adorsys.de@dmarc.ietf.org" class="">fpo=40adorsys.de@dmarc.ietf.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hello Dave,</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" class=""><div style="font-family:"trebuchet ms",sans-serif" class=""><br class=""></div><div style="font-family:"trebuchet ms",sans-serif" class="">I agree that the best deployment option is: 1 brand = 1 issuer = 1 discovery doc, however that is not always possible.</div><div style="font-family:"trebuchet ms",sans-serif" class=""><br class=""></div><div style="font-family:"trebuchet ms",sans-serif" class="">I'd like to understand Francis what particular issue you see from allowing an AS to specify multiple authorization_endpoints?</div></div></div></blockquote><div class="">Confusing End User! A user is using the same credentials on a yellow styled "<a href="https://loadsamoney/business/auth" target="_blank" class="">https://loadsamoney/business/auth</a>" and a green styled "<a href="https://loadsamoney/consumer/auth" target="_blank" class="">https://loadsamoney/consumer/auth</a>". A well designed environment will have a centralized page for login and account management like "<a href="https://loadsamoney/consumer/auth" target="_blank" class="">https://loadsamoney/accounts/auth</a>" even better "<a href="https://loadsamoney/consumer/auth" target="_blank" class="">https://accounts.loadsamoney/auth</a>".</div></div></div></div></blockquote><div><br class=""></div>In the cases Dave and I are thinking of, there’s no SSO between the different brands (sorry,I’m struggling to find a better word than brands!), which also have segmented user credentials - there’s no user confusion.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" class=""><div style="font-family:"trebuchet ms",sans-serif" class="">I can see that to avoid user confusion it would be necessary for the Client to record which endpoint they redirected the user to, in case they need the user to re-authorize - but I can't see any particular security issue?</div></div></div></blockquote><div class="">Let assume the "Client-Business" will record the business auth-endpoint and keep sending RO to "<a href="https://loadsamoney/business/auth" target="_blank" class="">https://loadsamoney/business/auth</a>" for reauthentication. If the user opens his personal banking application on another tab, "Client-Consumer" will send the user to "<a href="https://loadsamoney/consumer/auth" target="_blank" class="">https://loadsamoney/consumer/auth</a>". For SSO to work, the AS has to store the SSO-Cookies under "<a href="https://loadsamoney/consumer/auth" target="_blank" class="">https://loadsamoney/</a>". Now your AS SSO Cookies are also accessible to "<a href="https://loadsamoney/consumer/auth" target="_blank" class="">https://loadsamoney/blog</a>"! This problem is even worse if instead of path you use subdomains like "<a href="https://loadsamoney/business/auth" target="_blank" class="">https://business.loadsamoney/auth</a>" and "<a href="https://loadsamoney/consumer/auth" target="_blank" class="">https://consumer.loadsamoney/auth</a>" the the SSO Cookie of your AS has to be set to: ".loadsamoney", providing access to the SSO Cookies to all other subdomain hosted application like "<a href="https://loadsamoney/consumer/auth" target="_blank" class="">https://blog.loadsamoney/</a>".</div><div class="">Most AS I have used in customer projects use cookies to manage SSO?<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>I think this is either mainly an issue with the example urls, or solved by pointing out that you should not do SSO between different authorization endpoints for the reasons you say?</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" class=""><div style="font-family:"trebuchet ms",sans-serif" class=""><br class=""></div><div style="font-family:"trebuchet ms",sans-serif" class="">No matter which authorization_endpoint the user was sent to, after the user is redirected back to the Client's redirect_uri the process is the same as if there had been 1 authorization_endpoint. </div></div></div></blockquote><div class="">AS UI customization is being done today by many AS deployment because of:</div><div class="">- Multitenancy of deployment</div><div class="">- The need to have client identity disclosed to the RO in a consent page</div></div></div></div></blockquote><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" class=""><div style="font-family:"trebuchet ms",sans-serif" class=""></div><div style="font-family:"trebuchet ms",sans-serif" class="">I am in favour of Vladimir's suggestion of:</div><div style="font-family:"trebuchet ms",sans-serif" class=""><br class=""></div><div style="font-family:"trebuchet ms",sans-serif" class="">"alternative_authorization_endpoints": {<br class=""> "banking": {<br class=""> "authorization_endpoint": "<a href="https://loadsamoney/business/auth" target="_blank" class="">https://loadsamoney/business/auth</a>",<br class=""> "description": "loadsmoney business banking customers",<br class=""> "logo_url": "<a href="https://loadsamoney/business/logo.png" target="_blank" class="">https://loadsamoney/business/logo.png</a>"<br class=""> },<br class=""> "personal": {<br class=""> "authorization_endpoint": "<a href="https://loadsamoney/consumer/auth" target="_blank" class="">https://loadsamoney/consumer/auth</a>",<br class=""> "description": "loadsmoney personal customers",<br class=""> "logo_url": "<a href="https://loadsamoney/consumer/logo.png" target="_blank" class="">https://loadsamoney/consumer/logo.png</a>"<br class=""> }<br class=""> }<br class=""></div></div></div></blockquote><div class="">This use case is neither multi tenancy nor the disclosure of the client identity in a consent page. Starting with the logo here, we will end up adding css and js code snippets. This type of customizing shall be done in the AS-Deployment without playing around with the public AS metadata. </div></div></div></div></blockquote><div><br class=""></div><div>I don’t understand why “disclosure of the client identity in a consent page” is relevant here; that already happens, it will continue to happen in the same way and isn’t affected in any way by this suggestion.</div><div><br class=""></div><div>Yes, there are other architectures that don’t require this. I don’t think it is the job of the protocol to disallow or make some architectures difficult just because other architectures are better.</div><div><br class=""></div><div>I don’t think it’s even clear that having a client deal with 16 different issuers for a single bank (a real world example of what would happen if we forced ‘one authorization endpoint per issuer’) is actually “better”. It’s a pain for the client to manage 16 different issuers rather than 1 with 16 authorization endpoints - it means 16 client registrations and 16 issuers to configure, and it obfuscates to the client that these are actually all the same system. I have a hard time saying that one architecture is clearly good and that the other should clearly be disallowed unless you’re willing to go outside of the standards, particularly when switching architectures is a large breaking change that would be close to impossible to coordinate in any real world system with a number of active OAuth clients.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">I am in favor of pushing those changes into target AS-Deployment specific customizing.</div></div></div></div></blockquote><div><br class=""></div><div>Many authorization servers are already running multiple authorization endpoints. They are required in certain architectures, and there are no other security concerns raised so far that are unique to those architectures. (The need to do SSO sensibly and securely applies to all architectures.)</div><div><br class=""></div><div>The suggested new metadata allows authorization servers to publish these multiple authorization endpoints in a standard machine readable format that clients can then use with less need for manual configuration and poking around emails or ‘dev portals’ to find the details. I do not see a downside of allowing this.</div><div><br class=""></div><div>Thanks</div><div><br class=""></div><div>Joseph</div><div><br class=""></div></div></body></html>