feature policy for the various credential types: per-credential? all-included?

[equalsJeffH]

wrt w3c/webauthn#911 "integrate with feature policy..." (see also w3c/webappsec-permissions-policy#168 and w3c/webappsec-permissions-policy#306):

So far, with our fancy webauthn-blinders on, we've been tacitly assuming that we'd just make webauthn a policy-controlled feature, without thinking very much about how it's integrated here with credman and how there's two other extant credential types: password and federated.

So, if we continue on this path, we'll potentially end up with at least three feature identifieers: webauthn, password, federated. Ostensibly, each would have a default allowlist of 'self' (meaning cross-origin feature use is disabled by default). Then, if a webapp's devs wish to allow an embedded (ie framed) webapp to utilize any of the three credential types, they'd have to remember to explicitly authorize the specific credential type(s) to be so allowed, rather than just be able to authorize "credential management and all its credential types" in a single go?

Would we want to provide a main "credman" feature-policy "all-included" on-off switch, as well as individual credential type feature policies (which are overridden by the main switch?), or just former or just the latter?

While we're sorting this out, I will be chipping away at defining webauthn as a individual policy-controlled feature, which appearfs to require credman mods (before the algs go in-parallel), which oughta be at least somewhat re-purposeable regardless how we decide the above questions.

[equalsJeffH]

cc: @mikewest @clelland @agl

[equalsJeffH]

@agl and I feel the answer is per-credential at the least.

Having no main "credman" feature-policy "all-included" on-off switch makes browser impl easier and less complex. Although, then if webdevs wish to turn off all credential processing in a given context, they have to disallow all such individual credential types explicitly. Thoughts on this trade-off?

[equalsJeffH]

see also: w3c/webauthn#1277 ' rename "webauthn" feature policy token to publickey-credentials '

This has been done in features.md in w3c/webappsec-permissions-policy#338

[equalsJeffH]

In terms of current status:

WebAuthn ended up going even more fine-grained regarding the permissions policy (nee' feature policy) for the webauthn "policy controlled feature" and created just publickey-credentials-get within features.md.

The questions above wrt how fine-grained these "policy controlled feature" knobs ought to be, and whether there ought to be an overall credman on-off switch remain relevant.