Cross origin and Conditional UI

[akshayku]

Background:
We at Microsoft have web pages for authentication at different origins. For consumers (MSA), it lives at login.live.com and for enterprises (AAD), it lives at login.microsoftonline.com. When we adopted webauthn, we consolidated all webauthn related operations at single login.microsoft.com. But the initial landing pages are still at login.live.com/login.microsoftonline.com where we have a link like "Sign in with Windows Hello or Security Key" which redirects to login.microsoft.com to do the webauthn operation.

Our intention was to move everything to login.microsoft.com, but there are non-WebAuthn related challenges in doing so. These challenges are technical and we are trying to figure out what we want to do here.

Issue:
When we redirected to the login.microsoft.com for webauthn operation, things all work. However, conditional UI is supposed to work on the webpage that you are on. And for our case, these pages are not at webauthn origin at the moment. Hence, browser will see two different origins and will not allow conditional UI in that scenario. Meaning, browser cannot query credentials for login.microsoft.com from login.live.com webpage.

We think this is not a one off instance for our RP. It may be an issue for a many RPs.

Solution:
One obvious solution is to move everything to login.microsoft.com. But as I said above, there are non-webauthn related challenges in doing so.

Another solution, I was thinking was similar to Cross-origin solution I was thinking for payment/general case as I mentioned at #1667. Potentially, an RP can define policy at well-known location at an origin where it can specify a set of RPs which can ask for WebAuthn operation on behalf of. Like we can define login.live.com to be one of such RPs at login.microsoft.com? And browser in conditional UI can check for these policies when origins in the request don't match the top level origin.

Thoughts?

[sbweeden]

Isn't this really a description of facets as was originally supported in U2F and has been previously discussed in issues such as #1372

[arshadnoor]

Its appid and facets all over again.
Wonder who decided to kill this somewhat useful feature during the early WebAuthn discussions?

[equalsJeffH]

on 2021-11-03 call:
@ve7jtb brings up a webkit bug# where there is a thread where they are discussing whether to allow get() in cross-origin iframes.

John Pascoe from webkit notes that they are imagining adding another user-visible prompt in this case letting user know that this might be used for trackoing and asking for user consent. this somehow leverages the StorageAccess API ....? ( they are imagining safari would request the StorageAccess api permission on behalf of the caller )
(much discussion ensued...see webauthn minutes for more detail)

[akshayku]

Closing now. We most probably will be moving to the final webpage. and Bringing appid/facets seems like complex.