Revise same-origin as ancestor requirements

[apowers313]

Picking up where we left off on w3c/webappsec-credential-management#3 and related to #873 and #911...

There is a need by some relying parties to be able to use WebAuthn in child browsing contexts (e.g. - iframes, child windows, etc.). Currently WebAuthn requires sameOriginWithAncestors which prevents these use cases.

@equalsJeffH had put together an initial proposal on how this might work and presented it during a meeting and we didn't hear anyone complain.

[apowers313]

Not putting this in the spec until L2 means that certain relying party use cases (which seem to be important for adoption) won't be implementable for at least a year.

Any chance we could do this for L1?

[ve7jtb]

Talking to Jeff, there are WebAppSec dependencies to get this to work securely.

While I think we all want this to work, just removing the restriction in WebAutn is not sufficient to have it work securely.

We should try to sort this out so that at least not block it working once the other parts come together. That, however, may be difficult to capture in spec language.

[mikewest]

@equalsJeffH: What are the WebAppSec dependencies? Can y'all not just accept sameOriginWithAncestors == false?

[equalsJeffH]

@mikewest - are arbitrary cross-origin mashups presently secure? If we were to "just accept sameOriginWithAncestors == false", would we not be handing webauthn Relying Parties a footgun? I may be behind the times and need to be educated....

i.e., IIUC, if we accept sameOriginWithAncestors == false, we ought to do the things handwavily listed here:

https://docs.google.com/presentation/d/1sK9hhI0y25iioyLGMKwdhtpe-sVRV7Ln4pMHR2JXApw/edit#slide=id.g3ad57c9b5b_0_13

...Yes?

Is IntersectionObserver2 still just a "proposal"?

It seems to me that RPs would be well served by being able to invoke something like " Compute whether a Target is unoccluded, untransformed, unfiltered, and opaque"...

Do we know what the exact list of things we need to add to the webauthn spec in order to not hand RPs a footgun?

WDYT?

thanks!

[rlin1]

We might want to add a note to the security considerations to point to intersection observer 2 (io2).

[rlin1]

See also #969

[jcjones]

We might want to add a note to the security considerations to point to intersection observer 2 (io2).

Opened #1105

[jcjones]

This is now considered to be effectively a duplicate of #911, which all parties agreed to implement in Level 2, so closing this in favor of #911.