Map options member identifiers and credential types: public-key vs publicKey

[equalsJeffH]

Please see issue #147 and w3c/webauthn#1004 for full context.

The summary is that this PR introduces a registry mapping credential types to options member identifiers, and updates the magical relevant credential interface objects algorithm to use the latter registry.

This is the "...define a mapping from dictionary member names to [[type]] values or vice versa." solution identified by @bzbarsky in w3c/webauthn#1004 (comment). @jyasskin had also independently suggested using a registry for this mapping.

Additionally, this PR contains some modest editorial updates/changes (that seem appropriate to make in conjunction with this PR's primary mission of mapping cred types to options member identifiers):

• Clarify 2nd sentence of Introduction's first paragraph.
• Clarify definition of "credential type", and note that other specs eg webauthn (can) define other cred types.
• Explicitly delimit the (otherwise sort of hidden) "same-origin with its ancestors" algorithm by creating a "Infrastructure Algorithms" subsection containing it. Motivated in large part by adding the new Registry section after the algorithm. As a reader, I find this makes the spec more clear.
• use the 1. numbering for all steps in algs that I modified.

fixes #147

---

Preview | Diff

[nsatragno]

Thanks for fixing this long standing issue! I like the registry mapping.

You mixed in some editorial changes in this PR. Can you update the PR description to point that out?

[nsatragno]

lgtm pending Jeffrey's comments

[equalsJeffH]

I am thinking that we ought to land PR #182 first, then rebase this PR onto the resultant main branch, before finalizing and landing this PR.

update 6-Jan-2022: PR #182 is now merged.

[jyasskin]

Thanks! LGTM aside from one nit.