RE: RPID and web origin scope restrictions

Thanks Nick. I was aware of that. Wondering though why a similar capability is explicitly excluded from WebAuthn. 

Sent from my iPhone

> On 4 Feb 2020, at 9:38 am, Nick Mooney <nmooney@duo.com> wrote:
> 
> 
> 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 
> 
> ----------
> Duo Security is now part of Cisco.