Once the above two PRs have landed, the Request a Credential algorithm can be future-proofed with respect to creation of future per-credential-type "policy-controlled feature tokens" (related: "named Feature Policy", "features named", feature-name) by adding a column to the registry listing the "policy controlled feature token(s)" relevant for that credential type (as suggested by @nsatragno in https://github.com/w3c/webappsec-credential-management/pull/182#discussion_r765181739)
For example, for the public-key credential type, the policy-controlled feature token publickey-credentials-get ought to be listed in the "Credential Types Registry".
Also, the same ought to be done for the otp credential type's otp-credentials.
PR #181 creates a "Credential Types Registry" collecting various facets of each listed credential type.
PR #182 adds a permissions policy check to the Request a Credential algorithm.
Once the above two PRs have landed, the Request a Credential algorithm can be future-proofed with respect to creation of future per-credential-type "policy-controlled feature tokens" (related: "named Feature Policy", "features named",
feature-name) by adding a column to the registry listing the "policy controlled feature token(s)" relevant for that credential type (as suggested by @nsatragno in https://github.com/w3c/webappsec-credential-management/pull/182#discussion_r765181739)For example, for the
public-keycredential type, the policy-controlled feature tokenpublickey-credentials-getought to be listed in the "Credential Types Registry".Also, the same ought to be done for the
otpcredential type'sotp-credentials.