Intent to Implement and Ship: `CredentialsContainer::create` in Credential Management API

[Jan Wilken]

Contact emails jdoe...@chromium.org Spec https://w3c.github.io/webappsec-credential-management/#dom-credentialscontainer-create Summary This feature introduces the `CredentialsContainer::create` method to the Credential Management API. This method allows for asynchronous creation of Credential objects. Motivation

The WebAuthn API was rewritten in https://github.com/w3c/webauthn/pull/384 to extend the Credential Management API. There were several minor changes required for the CM API to make this integration possible, this is one of them. Interoperability and Compatibility risk

No risk, the feature is purely additive and no other browser has implemented the Credential Management API yet. Ongoing technical constraints

None

Is this feature fully tested by web-platform-tests?

Yes, existing tests are here: https://github.com/w3c/web-platform-tests/tree/master/credential-management These will be updated accordingly in the implementation CL.

OWP launch tracking bug http://crbug.com/722242 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/5451971465052160 Requesting approval to ship?

Yes

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3557fbb6-6cb1-4a2b-97ee-ce209eb4d3a7%40chromium.org.

[TAMURA, Kent]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8jX1FZk-GFZGtJAK2%2Bj7GHFw-kK-P5NoAVbTG1TaUWhg%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[Rick Byers]

It looks like there hasn't been any feedback from other implementors (eg. on the spec PR).  In general this means interop risk can't be "no risk" (there's some risk that, for some reason, one of the browsers hates this API and will never implement it).  That said, this case seems pretty trivial and consistent with TAG design principle that the platform shouldn't be magic in it's ability to create objects.  So I think the risk is low enough that we shouldn't block on feedback from other implementors.  LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqGZH2bWvsOv64DSTdG7YQPxXJt_G3-_yQxYd6msZU4a2w%40mail.gmail.com.

[Mike West]

On Thu, May 18, 2017 at 11:03 PM, Rick Byers <rby...@chromium.org> wrote:

It looks like there hasn't been any feedback from other implementors (eg. on the spec PR).  In general this means interop risk can't be "no risk" (there's some risk that, for some reason, one of the browsers hates this API and will never implement it).  That said, this case seems pretty trivial and consistent with TAG design principle that the platform shouldn't be magic in it's ability to create objects.  So I think the risk is low enough that we shouldn't block on feedback from other implementors.  LGTM3

It might not have been clear from the initial intent, but the reason this seems particularly low-risk is that it's a hard requirement for the `PublicKeyCredential` interface specified in WebAuthn. Those objects can only be constructed asynchronously due to the intricacies of interacting with hardware and users, so a `Promise<>`-based constructor is essential. Mozilla and Microsoft have both made it fairly clear that they plan to implement that API.

It is indeed possible that WebKit will have fundamental objections, but I do think that's unlikely on this point.

-mike

[PhistucK]

In general, it would be great if you did not use the double colon notation in a ChromeStatus entry (or in the intent subject), because that implies C++ features rather than web features (which, at the moment, does not have such syntax in JavaScript. It might get one for automatically binding members in the future, which would make it even more confusing). Use a period notation instead.

So -

CredentialsContainer::create

Should be -

CredentialsContainer.create

I updated the recent entries already, but do keep that in mind.

(There seems to be a duplicate entry. You can contact Eric Bidelman to remove one of them.)

Thank you!

☆PhistucK

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcTKi%2BT3G98vUTxOPF82aXiqPJSZeUaxnqsRV3Q57RTBg%40mail.gmail.com.

[Domenic Denicola]

I strongly disagree with Phistuck here. CredentialsContainer.create implies a static method in JavaScript, which this is not. Please do not make such changes to other people's work in the future, Phistuck.

---

From: PhistucK <phis...@gmail.com>
Sent: May 19, 2017 1:27 PM
To: Mike West
Cc: Rick Byers; TAMURA, Kent; Chris Harrelson; Jan Wilken; blink-dev; Vasilii Sukhanov; Dominic Battré; Zach Koch; Jochen Eisinger
Subject: Re: [blink-dev] Intent to Implement and Ship: `CredentialsContainer::create` in Credential Management API

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BhUDymVZCGY7ChZW%3Djtg8vpj7haOFdUjSV6xBoKBoMZg%40mail.gmail.com.

[Rick Byers]

We have MANY chromestatus entries already that use '.' in this way - it's certainly pretty close to a consistent pattern across all our intents, so please don't be too tough on Phistuck ;-).

That said I know using Interface.property as a shorthand for Interface.prototype.property is considered by some to be sloppy.  I wouldn't object to someone doing a bulk update to either add the .prototype. or to the Interface#property syntax.  But given that what matters most here is that web developers can find what they're looking for, I'd argue using whatever convention is most used by developers is probably best.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BhUDymVZCGY7ChZW%3Djtg8vpj7haOFdUjSV6xBoKBoMZg%40mail.gmail.com.

[PhistucK]

Well, for what it is worth, I strongly disagree with ::, which makes no sense to a web developer and can lead to unnecessary trial and error. You can come up with another idea, though.

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BhUDymVZCGY7ChZW%3Djtg8vpj7haOFdUjSV6xBoKBoMZg%40mail.gmail.com.

[PhistucK]

Also, to be clear, I am not so keen on omitting "prototype", it does bother me, but, unfortunately, I also know that most of the JavaScript developers have no idea what it means and that can also cause confusion (which is why I still opted into omitting it). I am also fine with keeping "prototype", I just do not think it serves the intended goal.

(I do not like # as well, it is not common)

☆PhistucK