Re: API aesthetic updates (PR #142)

All,

Our call today had one more change to this PR: to use underscore characters
as delimiters in the updated extension IDs.  That change is up:

https://github.com/w3c/webauthn/pull/142/commits/eef0149a3c17b69615244f709c06162ae8f4ee5b

If there aren't any further comments by the end of the week, I'll merge
this PR.  The whole PR is available here:

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

Cheers,
J.C.



On Tue, Jul 12, 2016 at 1:08 AM, Hodges, Jeff <jeff.hodges@paypal.com>
wrote:

> 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
>
>
>