Re: Fwd: Fwd: Proposal for a credential management API.

cc- www-archive

On Mon, 11 Aug 2014 12:39:38 +0200, Arthur Barstow <art.barstow@gmail.com>  
wrote:

> Hi All - any thoughts on whether Google's Credential Management API  
> would be better suited for WebApps vs. WebAppSec or some other group  
> (f.ex. a CG to get things bootstrapped)?

Oddly enough a credentials CG launched a few days ago (it came from the  
webpayments CG). That may be a more appropriate venue, but otherwise my  
hunch is that this belongs to webappsec. Not that I have a very strong  
feeling about venues.

cheers

> Please feel free to followup on public-webapps (as Robin did in  
> <http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0166.html>).
>
> -Thanks, Art
>
> -------- Original Message --------
> Subject:  Fwd: Proposal for a credential management API.
> Date:  Sun, 03 Aug 2014 11:06:22 -0400
> From:  Arthur Barstow <art.barstow@gmail.com>
> To:  team-webapps@w3.org, Robin Berjon <robin@w3.org>, Wendy Seltzer  
> <wseltzer@w3.org>, Brad Hill <bhill@paypal.com>
> CC:  w3c-archive <w3c-archive@w3.org>
>
>
>
> Hi All - any thoughts on whether Google's Credential Management API
> would be better suited for WebApps vs. WebAppSec or some other group
> (f.ex. a CG to get things bootstrapped)?
>
> Please feel free to followup on public-webapps (as Robin did in
> <http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0166.html>).
>
> -Thanks, Art
>
> -------- Original Message --------
> Subject:  Proposal for a credential management API.
> Resent-Date:  Thu, 31 Jul 2014 07:49:05 +0000
> Resent-From:  public-webapps@w3.org
> Date:  Thu, 31 Jul 2014 09:48:14 +0200
> From:  Mike West <mkwst@google.com>
> To:  Webapps WG <public-webapps@w3.org>
>
>
>
> TL;DR: Strawman spec and usecases at
> https://github.com/mikewest/credentialmanagement
>
> # Use Cases
>
> User agents' password managers are a fragile and proprietary hodgepodge  
> of
> heuristics meant to detect and fill sign-in forms, password change
> forms, etc.
> We can do significantly better if we invite websites' explicit  
> cooperation:
>
> * Federated identity providers are nigh undetectable; I don't know of
> any password managers that try to help users remember that they signed
> into Stack Overflow with Twitter, not Google.
>
> * Signing in without an explicit form submission (via XHR,
> WebSockets(!), etc) is good for user experience, but difficult to
> reliably detect.
>
> * Password change forms are less well-supported than they could be.
>
> * Users are on their own when creating new accounts, faced either with a
> list of identity providers they've mostly never heard of, or with the
> challenge of coming up with a clever new password.
>
> More background and exploration of native equivalents at
> http://projects.mikewest.org/credentialmanagement/usecases/.
>
> # Workarounds
>
> HTML defines a number of `autocomplete` attributes which help explain
> fields'
> purpose to user agents. These make the common case of form submission  
> more
> reliably detectable, but are less helpful for XHR-based sign-in, and  
> don't
> address federated identity providers at all.
>
> # Proposal:
>
> The API I'm outlining here is intentionally small and simple: it does not
> attempt to solve the general authentication problem in itself, but  
> instead
> provides an interface to user agents' existing password managers. That
> functionality is valuable _now_, without significant effort on the part  
> of
> either browser vendors or website authors.
>
> The API quite intentionally winks suggestively in the direction of an
> authentication API that would, for instance, do an OAuth dance on behalf
> of an
> application, but that's not the immediate goal.
>
> ```
> [NoInterfaceObject]
> interface Credential {
>    readonly attribute DOMString id;
>    readonly attribute DOMString name;
>    readonly attribute DOMString avatarURL;
> };
>
> [Constructor(DOMString id, DOMString password, DOMString name, DOMString
> avatarURL)]
> interface LocalCredential : Credential {
>    readonly attribute DOMString password;
> };
>
> [Constructor(DOMString id, DOMString federation, DOMString name,
> DOMString avatarURL)]
> interface FederatedCredential : Credential {
>    readonly attribute DOMString federation;
> };
>
> partial interface Navigator {
>    readonly attribute CredentialsContainer credentials;
> };
>
> interface CredentialsContainer {
>    Promise<Credential?> request(optional CredentialRequestOptions  
> options);
>    Promise<any> notifySignedIn(optional Credential credential);
>    Promise<any> notifyFailedSignIn(optional Credential credential);
>    Promise<any> notifySignedOut();
>    readonly attribute PendingCredential? pending;
> };
> ```
>
> A more detailed specification is up at
> http://projects.mikewest.org/credentialmanagement/spec/.
>
> # Example:
>
> ```
> navigator.credentials.request({
>    'federations': [ 'https://federated-identity-provider.com/' ]
> }).then(function(credential) {
>    if (!credential) {
>      // The user had no credentials, or elected not to provide one to
> this site.
>      // Fall back to an existing login form.
>    }
>
>    var xhr = new XMLHttpRequest();
>    xhr.open("POST", "https://example.com/loginEndpoint");
>    var formData = new FormData();
>    formData.append("username", credential.id <http://credential.id>);
>    formData.append("password", credential.password);
>    xhr.onreadystatechange = function () {
>      if (this.readyState != this.DONE)
>        return;
>      var loginSucceeded = // Process response: if login succeeded, yay!
> If not, boo!;
>      if (loginSucceeded) {
>        navigator.credentials.notifySignedIn(credential);
>        // Notify the user that signin succeeded! Do amazing, signed-in
> things!
>      } else {
>        navigator.credentials.notifyFailedSignIn(credential);
>        // Notify the user that signin failed, and fall back to the usual
> experience.
>      }
>    };
>    xhr.send(formData);
> });
> ```
>
> More examples at
> http://projects.mikewest.org/credentialmanagement/spec/#introduction-examples.
>
> It's not clear to me that WebApps is the right venue from a process
> perspective,
> but this is almost certainly the right group of people to evaluate the
> proposal.
> Thanks in advance for your feedback, suggestions, and time. :)
>
> -mike
>
> --
> Mike West <mkwst@google.com <mailto: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.)
>
>
>
>


-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru         Find more at http://yandex.com

Received on Tuesday, 12 August 2014 10:23:54 UTC