Add Feature Policy support for WebAuthn

[equalsJeffH]

update 21-Aug-2019: this is a work-in-progress. It is not ready to re-review as yet. I'm pushing WIP commits to this branch in my fork as I go along... I'll add another update above this one when it's ready for review. thanks.

---

nominally fixes #136 improves #135

cc: @agl

---

Preview | Diff

[mikewest]

I don't understand why this approach is right. I would have expected a feature policy to disable/enable the feature generally, not control whether the feature believes itself to be same-origin with its ancestors. Can you help me understand how you chose this mechanism?

[equalsJeffH]

HI @mikewest, thanks for taking a look at this!

I would have expected a feature policy to disable/enable the feature generally, not control whether the feature believes itself to be same-origin with its ancestors.

yes, we may not wish to conflate those two things.

Basically, a feature policy can be defined that disables/enables a feature generally, even in cross-origin situations.

So I took a stab at it this way first because it obviates adding a parameter (to convey the result of feature policy evaluation) to the credman internal methods, and I naively thought that "hey, maybe if the 'allowed to use' alg returns true in some given context, that'll be good enough for the embedded webapp to use the feature?"

So, yeah, it may be that even though an embedder feels its ok for the embeddee to use a given credential internal method for a given credential type, maybe the embeddee will not agree and so providing the explicit SameOriginWithAncestors signal (in addition to the "enabled/disabled-by-policy" signal) is the way to go. It seems we have to add a param to the internal methods to convey that.

---

background details wrt FP's cross-origin-ness:

Yes, the cross-origin aspects of Feature Policy (FP) are a tad mind-bending-sorta-unexpected, however, it appears that FP does have implicit cross-origin permission properties according to @clelland, as explained in this recent relevant discussion on the public-webappsec@ list ("characterizing framing security needs for webappsec consideration").

Note his opening statement..

PaymentRequest was actually one of the very first features to utilize Feature Policy in Chrome -- by design, it should be able to handle allowing and restricting that API in same- and cross-origin embedding scenarios.

..and also that PaymentRequest's detault allowlist is 'self', which is what is proposed for WebAuthn in w3c/webauthn#1214.

Thus, given @clelland's explanation, along with how HTML's "allowed to use" alg calls FP's is feature enabled in document for origin alg, the use case of an embedder selectively enabling cross-origin feature use is enabled, e.g. see FP's Example 4.

[equalsJeffH]

Hi @mikewest -- this is ready to re-review.

Some notes to get you primed:

1. The background above in Add Feature Policy support for WebAuthn #138 (comment) regarding feature policy and how it works wrt cross-origin-ness still holds.

2. I moved a couple of algs out of where they were "hidden" in the "Credential" section down to the Core API's Algorithms section. the hope is that they are easier to find for the uninitiated reader.

3. It turns out that HTML's "allowed to use" alg needs access to the responsible document and thus AFAIK cannot run in the in-parallel portions of the "create a credential" and "request a credential" credman algs, so the checking of feature policy is done here in credman and we can leave the sameOriginWithAncestors argument as-is (webauthn needs the latter signal to include in "collected client data" (the hash of which gets signed over for security checks).

4. there is a modest asymmetry between "create a credential" and "request a credential" in that the former collects relevant interface objects but the latter does not -- AFAIK this was the case before I began mucking about in those algs and making changes. Should we persist this asymmetry (there's an issue in the text wrt this)?

5. I did not make password and federated cred-types subject to feature policy checks. Thus they continue to work as before wrt same-origin-with-ancestor-ness. We can add feature policy checking to them (and thus enable them for cross-origin iframe usage) if we think it through and end up thinking it is ok.

[mikewest]

LGTM with a few nits. Sorry this took forever.

[mikewest]

I don't think we do, because we explicitly wanted to support picking one of several kinds of credentials. We haven't actually done that yet, and maybe it turns out not to make sense to do so, but for the moment, I'd leave this out.

[mikewest]

Is webauthn just going to ignore this flag, and rely on FP to block access to requests instead?

[equalsJeffH]

webauthn uses this flag for a couple of things:

1. webauthn's create() checks sameOriginWithAncestors and returns an error if cross-origin, because a permissions policy (nee Feature Policy) is presently instantiated only for webauthn's get()(i.e., [DiscoverFromExternalSource]).
2. whether or not a webauthn get() operation occurred cross-origin is recorded in webauthn's CollectedClientData.

[mikewest]

For this kind of thing, Assert: might be more appropriate than Note:.

[mikewest]

Why change from `...` to <code>...</code> here? It seems to run counter to

[equalsJeffH]

Not sure what I was thinking there, please ignore.

[equalsJeffH]

@mikewest -- thanks for your review of this from eons ago. Working on this Credman spec was on the far back burner for quite a while given more urgent priorities. Though priorities have since evolved and Credman is being put back on a front burner.

All: I'm abandoning this PR because it encompasses too many incongruent concurrent changes (both editorial and technical), and would be a pain to rebase onto the current state of the "main" branch. It is superseded by PR #182 (which is much more succinct).