RE: [webappsec] CREDENTIAL: requestAutocomplete can already provide local credentials (#445)

Sorry for the late reply. Holiday season.

I was quite excited when rAc was proposed at Google IO two years ago but then it kind of vanished.
https://www.youtube.com/watch?v=1M50AXPd0Tg


Does Google have some numbers on uptake? How many sites use rAc for CC information? How many sites use rAc for login?

Getting into the topic which web technologies succeed and which fail is a topic on its own. I guess this is bigger than this issue #445 and even bigger than webappsec.
Maybe the time was just not ripe for rAc? Is it now? Maybe the marketing for “use rAc for login” is/was non existing and with a little push from major companies it could be THE thing. I don’t know.

Coming back to this issue: I think that rAc could be used to fill username/password form-fields but browsers do that already. Why should sites use rAc for that then?
So the promise of credentialmanagement API is to pave the way for a time past username/password by making it attractive for sites to use the API. And THEN move forward to more secure options.

I think that a new API is better suited for this promise than rAc. It is true that we could tweak rAc to support federation and all but I feel this is hacky.

-Axel

There is a ton of failed attempts to solve Identity on the web:
Microsoft tried Information Cards in 2005.
There was a W3C Workshop on Identity in the Browser in 2011 http://www.w3.org/2011/identity-ws/report.html . Participants could only agree on that some crypto would be good to have and so WebCrypto was born.
I ;-) suggested a minimal javascript for openid. http://ignisvulpis.blogspot.de/2012/11/javascript-api-for-openid.html

BrowserID
WebID / FOAF+SSL
I thought then and still think that the browser should help users to manage their identities. But it is hard.

From: Mike West [mailto:notifications@github.com]
Sent: Mittwoch, 12. August 2015 10:08
To: w3c/webappsec
Cc: Axel Nennker
Subject: Re: [webappsec] CREDENTIAL: requestAutocomplete can already provide local credentials (#445)


@mnoorenberghe<https://github.com/mnoorenberghe>: Thanks for following up!

One thing I forgot to mention in the previous response: the rAc proposal can only replace get(), right? What do you think about store()? I don't really see an analog for that.

I guess I'm looking for an incremental improvement over the status quo and not as worried about login without user mediation as a first increment.

What use cases are you interested in solving? Registration of new accounts, or sign-in? It seems like rAc might be well-suited to the former, given that it can fill a number of field types at once, rather than being limited to usernames and passwords. I'm less enthused about it for the latter, for reasons I'll get to in a moment.

I thought that this spec also had an API which returned the plaintext password at one point but perhaps I'm mistaken or it was changed.

It did (and I think Chrome's implementation currently does). We dropped that in the hopes of making it less likely that the password would leak in two ways:

1.      The password isn't available to JavaScript via the Credential object. I think you're correct to say that the write-only concept could solve this.

2.      The password can only be submitted to same-origin endpoints, and won't follow redirects while doing so. I suppose we could add more attributes to <form> in order to bring these qualities in as well. but that actually requires more developer effort. I'd like to make it hard for folks to screw this up, as it seems like

3.      The API only works in secure contexts. I don't actually remember whether rAc works over HTTP. I think Chrome's implementation doesn't, but I don't think that's a requirement in the spec (https://html.spec.whatwg.org/#dom-form-requestautocomplete).

I believe your write-only password field proposal addresses this issue and the spec could require that field is write-only, if desired.

I would like to dig that up again, but note that this only solves the JavaScript access; malicious folks can submit write-only fields anywhere they like, which means it doesn't significantly reduce the risk of exfiltration.

I don't know much about FIDO or other future plans but I'm assuming the inputs and outputs can be stringified

I wish the FIDO folks would work out their patent issues so we could talk about a concrete proposal. As-is, I can only suggest that the workflows for these kinds of things are more interactive than I think rAc can easily enable. That is, you get an object back from navigator.credentials.get({ 'fido': 'yes please' }) that then has a number of methods hanging off of it for assertion generation and signing. There's also a registration step that we'd model using store() (which, again, I forgot to mention as a concern in my initial response, apologies!).

/cc @annevk<https://github.com/annevk> @AxelNennker<https://github.com/AxelNennker> @tanvihacks<https://github.com/tanvihacks> @sicking<https://github.com/sicking>

—
Reply to this email directly or view it on GitHub<https://github.com/w3c/webappsec/issues/445#issuecomment-130211668>.