Re: RPID and web origin scope restrictions

There was a attempt to simplify the spec and browsers didn't like having
to process the facit list.

I could name the person responsible, but in penance they are now working
on a proposal to add back similar functionality.

Currently we are close to having the ability to open b.com in a iframe
from a.com.  You will still need to pass some sort of federation back
from b.com to a.com but it should address most use cases without
compromising correlation.

There will be a discussion on this at the Fido meeting this week.

John B.


On 2/4/2020 9:45 AM, Shane B Weeden wrote:
> 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
>> <mailto: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
>>     <http://b.com> to be able to make calls to
>>     navigator.credentials.[get|create] using RPID a.com
>>     <http://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 <http://a.com> (obviously ensuring
>>     server-authentication at transport level) that lists b.com
>>     <http://b.com> as an allowed origin for the purposes of
>>     registering or using credentials under the a.com <http://a.com> RPID?
>>
>>     Today's alternative is having to use browser-sso protocols to
>>     redirect (or iframe to) a.com <http://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 <mailto: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>.
>>
>

Received on Tuesday, 4 February 2020 10:22:42 UTC