On 2016-03-14 2:29 AM, Mike West wrote:
On Thu, Mar 10, 2016 at 9:07 PM, Ben Kelly <bke...@mozilla.com> wrote:
I believe Matthew Noorenberghe had some concerns about the necessity of the
API given requestAutocomplete:
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ
https://github.com/w3c/webappsec-credential-management/issues/2
We should probably come to some consensus there before moving forward.
I agree with MattN that a rAc-style API is a reasonably good fit for
signing up for a new account on a website*. Sign-up forms often encompass a
variety of kinds of information, and layering something on top of existing
forms and autocomplete attributes sounds like a way of providing all of
those bits and pieces at once, rather than having 15 calls to a APIs that
hand them out piecemeal.
Given that, do you think it makes sense to have a separate API for login
when there is overlap with rAc as well?
With some caveats around XSS protection, I think that rAc could work for
signing-in with passwords. I guess it could work for signing in with
federations, though I think it starts to break down pretty rapidly. I don't
think it would work for any other potential uses of the API. `store()`, in
particular, is more or less the opposite of rAc and seems valuable
(especially for federations, but also for passwords), and FIDO is a good
example of a set of proposals that seem to entirely require additional
interaction above and beyond filling a form. I haven't seen a
counter-proposal for those pieces.
You're convinced me that an imperative method for saving (local)
credentials is useful but I don't think we need new interfaces and
objects surrounding it when we have the autocomplete values. See
https://github.com/w3c/webappsec-credential-management/issues/13
I'm inclined to continue pursuing this more imperative proposal, as it
seems flexible enough to support the use cases we know we have today, and
those we'll discover in the future. The developers I've spoken with see the
API as an improvement and have been able to layer it on top of existing
sign-in systems with minimal change to their authentication backends
(which, as probably won't surprise you, are _always_ the oldest,
least-well-understood, and most fragile bits :) )**. I think it's worth
exploring.
-mike
* I also agree with him that sign-up is an important use-case, and that we
should do the work to support it. Anyone interested in working with me on a
draft proposal for what that might look like?
This is already specified in the requestAutocomplete[1] section of the
HTML specification so I think it's probably (close to being?) ready to
implement already. The other part for XSS protection is @writeonly[2]
which can be added to the HTML spec. I'm not sure what else you have in
mind but I can try help.
Matthew
[1] https://html.spec.whatwg.org/#dom-form-requestautocomplete
[2]
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Oct/0181.html
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
