Re: New security fetaure : Looking for a home for a proposed Credential Management API.

Hey Virginie,

I had a chat with Jonas about this, and it seems like this would be better
for WebAppSec than WebCrypto.

--Richard

On Thu, Sep 25, 2014 at 11: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.
>