- From: Colin Gallagher <colingallagher.rpcv@gmail.com>
- Date: Mon, 13 Oct 2014 23:04:33 -0700
- To: GALINDO Virginie <Virginie.Galindo@gemalto.com>
- Cc: "public-web-security@w3.org" <public-web-security@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Harry Halpin <hhalpin@w3.org>, Jon Matonis <jon@bitcoinfoundation.org>
- Message-ID: <CABghAMgQKzJruOsAOLAzt-VLU_J8moOPS94ygxkek2+_mduQzA@mail.gmail.com>
Copying this to Jon Matonis of Bitcoin Foundation who may be interested in light of some developments at that Foundation. -cg On Thu, Sep 25, 2014 at 8:06 AM, GALINDO Virginie < Virginie.Galindo@gemalto.com> wrote: > Dear all, > > > > FYI > > In case you do not follow the web app conversation, Mike West from google > is looking for a place to develop an interesting API dedicated to manage > credentials. The initial contribution which can be found under > http://mikewest.github.io/credentialmanagement/spec/ offers a credential > manager which allows to play with credential (including in a scheme of > federated identity) and get status of login operations. This API, at the > moment, does not require at the moment any specific security constraint > with respect to credential storage. > > > > Regards, > > virginie > > > > *From:* Mike West [mailto:mkwst@google.com] > *Sent:* mercredi 24 septembre 2014 15:57 > *To:* Brad Hill; Dan Veditz; chaals@yandex-team.ru; GALINDO Virginie; > Webapps WG > *Cc:* Jonas Sicking; plh@w3.org; ylafon@w3.org; xiaoqian@w3.org; Wendy > Seltzer; hhalpin@w3.org > *Subject:* Looking for a home for a proposed Credential Management API. > > > > (I'd originally sent this just to the folks on to: and cc:. Art reminded > me that public is better, so I'm resending to public-webapps@, and BCCing > public-webappsec@ for visibility). > > > > Hello, chairs of the WebApps, WebAppSec, and WebCrypto WGs! > > > > On Friday, I had an encouraging discussion with Jonas Sicking (CC'd) about > the Credential Management API proposed a month or so ago on WebApps ( > http://mikewest.github.io/credentialmanagement/spec/). Chrome has > started experimenting with an implementation, and though we're nowhere near > even considering shipping it, I'd like to make sure that our implementation > doesn't get too far out ahead of the spec process. > > > > I think it's fair to say that Mozilla is interested in continuing the > discussion around the short-term and long-term goals of such an API in an > appropriate venue. I'd like your collective opinion about what that venue > might be. WebApps seems like the right place just in terms of having the > right people involved. It would require a recharter, however, and it's not > clear to me that that would be a worthwhile use of folks' time. > > > > Both WebCrypto and WebAppSec are in the process of rechartering, which > resolves that potential issue, but neither really seems to be appropriate, > as they're concerned with aspects other than credentials and authentication. > > > > There's a credentials community group that has nothing to do with the > proposal, and given the weak IPR protections of a CG, I'd prefer to avoid > them in the long run (though they might be the right place for short-term > incubation). > > > > Brad suggested that an authentication WG might be spun up out of the > conversations in the recent WebCrypto workshop. Are there concrete plans > for such a group? > > > > Thanks! > > > > -mike > > > > -- > Mike West <mkwst@google.com> > > Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 > > Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany > Registergericht und -nummer: Hamburg, HRB 86891 > > Sitz der Gesellschaft: Hamburg > > Geschäftsführer: Graham Law, Christine Elizabeth Flores > > (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) > ------------------------------ > This message and any attachments are intended solely for the addressees > and may contain confidential information. Any unauthorized use or > disclosure, either whole or partial, is prohibited. > E-mails are susceptible to alteration. Our company shall not be liable for > the message if altered, changed or falsified. If you are not the intended > recipient of this message, please delete it and notify the sender. > Although all reasonable efforts have been made to keep this transmission > free from viruses, the sender will not be liable for damages caused by a > transmitted virus. >
Received on Tuesday, 14 October 2014 17:17:56 UTC