Re: RPID and web origin scope restrictions

Not an answer to the whole question, but FWIW the U2F spec did include
support for "facets", which is somewhat similar to what you're asking
about. Check out "3.1.2 Determining if a Caller's FacetID is Authorized for
an AppID" in this doc:
https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-appid-and-facets-ps-20141009.html
..

In particular, the idea of a discovery document that lists allowed
domains/URIs was included in the spec.

On Tue, Feb 4, 2020 at 5:18 AM Shane B Weeden <sweeden@au1.ibm.com> wrote:

> Hoping someone who's been involved with WebAuthn spec development longer
> than me can provide some history and describe why the scoping of RPID to
> origin has no cross-origin sharing mechanism (
> https://www.w3.org/TR/webauthn/#scope).
>
> For example let's say I want a page served from b.com to be able to make
> calls to navigator.credentials.[get|create] using RPID a.com. Current
> WebAuthn scoping rules prohibit this.
>
> Why couldn't there be a discovery mechanism (conceptually similar to CORS)
> whereby the browser retrieves a well-known discovery document from a.com
> (obviously ensuring server-authentication at transport level) that lists
> b.com as an allowed origin for the purposes of registering or using
> credentials under the a.com RPID?
>
> Today's alternative is having to use browser-sso protocols to redirect (or
> iframe to) a.com, complete WebAuthn interactions there, and SSO back with
> the result. For domains really under the control of the same entity (proven
> by a hosted discovery document) it would be convenient to be able to use
> WebAuthn with a different RPID directly.
>
> I read and get the comment about "This is done in order to match the
> behavior of pervasively deployed ambient credentials (e.g., cookies,
> [RFC6265]). Please note that this is a greater relaxation of "same-origin"
> restrictions than what document.domain's setter provides."
>
> But is that the whole story? Seems like cross-origin trust could be useful
> for a variety of use cases.
>
> Thanks,
> Shane.
>
>
>

-- 
*Nick Mooney*
/ Senior Research Engineer


nmooney@duo.com

Duo.com <https://duo.com/>

----------
Duo Security is now part of Cisco
<https://duo.com/about/press/releases/cisco-completes-acquisition-of-duo-security>
..