Re: API aesthetic updates (PR #142)

note to everyone -- there's on-going line-level comments on PR#142 (that
do not seem to be propogated to the mailing list), see..

https://github.com/w3c/webauthn/pull/142/files

also, i have some comments inline here...

On 7/11/16, 2:40 PM, "J.C. Jones" <jc@mozilla.com> wrote:
>I've produced another pull request in line with the last one, still from
>reviewing as a Web API consumer. The PR is here:
>
>https://github.com/w3c/webauthn/pull/142
>
>These changes are also aesthetic, similar to PR #135, but in this case
>they are all related to API aesthetics. They are still, for the most
>part, editorial in nature. It'd be good to get some care in the review of
>the `makeCredential()` updates per the removal
> of `ScopedCredentialParameters`, though.
>
>First, per Vijay's comment on issue 60[1], moving the interface from the
>global window namespace to the navigator namespace to reduce pollution of
>the global namespace. This also makes semantic sense, as the HTML5
>`window` object represents an open window in
> the browser, whereas the `navigator` object represents the browser
>itself. Since authenticators belong to the whole system, not one window,
>the object model makes more sense to be a property attached to
>`navigator`.

ok

>Second, I've renamed the factory object from `navigator.webauthn` to
>`navigator.authentication`. [...]

ok


>Third, I changed the type of `ScopedCredentialInfo.publicKey` from `any`
>to `CryptoKey`, referencing the WebCryptoAPI for the type information.
>This feels like a fairly substantial change, but it really isn't:
>javascript gets flexibility to ask for the pubkey
> in a variety of formats (including JsonWebKey), and we get a tighter
>(and more expected) type.

see also Vijay's comments on this at
https://github.com/w3c/webauthn/pull/142/files

I personally can see both sides of this and am undecided -- RP developers
should perhaps weigh in.


>Fourth, I've removed the `ScopedCredentialParameters` tuple by unpairing
>the `type` and `algorithm` fields. `ScopedCredentialParameters` is used
>in the procedure for normalizing algorithms and types, but said procedure
>doesn't actually use the types! This changes
> the makeCredential() method to instead have a list of supported types
>and a list of supported algorithms, and perform its procedure that way.
>
>Keeping these together in an object gives a kind of flexibility, but
>after consideration, I don't see much actual purpose in said flexibility.
>A RP can either handle an algorithm or not, and is either willing to
>handle an authenticator type or not -- particular
> combinations seem an unnecessary burden.

see also Vijay's comments on this at
https://github.com/w3c/webauthn/pull/142/files

perhaps that discussion should be brought to the mailing list?  offhand, I
can see both sides with this one also.



>Fifth, in response to Vijay's note about extension names[2], I've renamed
>the example extensions (correcting a CBOR mismatch in the process). I
>also noted in section 7.1, Extension identifiers, that  "Use of
>dot-separated notation here does not imply an object
> hierarchy.", and provided a counterexample of a differently- separated,
>versioned id: `mycompany-myextension_v01`. None of the pre-defined
>extensions were modified.

Note also..

draft-hodges-webauthn-registries-00
  https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0097.html


..and that extension names may have similar name construction requirements
as attstn type names (see my prior msg to the list on that topic)


>As before, comments here or on the PR are both welcome.
>
>1) https://github.com/w3c/webauthn/issues/60#issuecomment-230693738
>2) https://lists.w3.org/Archives/Public/public- webauthn/2016Jul/0046.html

hth,

=JeffH

Received on Tuesday, 12 July 2016 08:09:28 UTC