Re: Credentials Management API & multiple-credentials.

Thanks for your questions!

On Tue, Feb 10, 2015 at 8:26 PM,  <rektide@voodoowarez.com> wrote:
> Hi.
>
> Two use cases for Credentials Management API that I would appreciate someone taking up:
>
> 1. As a website, I'd like to permit my user to present me multiple credentials. If they
> want to tie their Altavista, Hotbot, Myspace, and Audioscrobbler accounts to my service,
> that would be fantastic.

Hrm. The spec doesn't intend to give direct, cross-origin access to
credentials. That is, we'd never intentionally offer a user the
ability to provide her MySpace credentials directly to Facebook. Can
you help me understand the use case?

With regard to multiple credentials, the LocalCredential concept in
the spec is more or less mapped to a username and password pair to get
you into a site. You may certainly have more than one account on a
site, but I don't think it's at all common to actually sign into more
than one at once. Even Google's/Netflix's/Whoever's multilogin systems
generally force you to actually _be_ one user at a time.

What would you expect a website to do with multiple credentials? How
would you work out which user the user was trying to act as at the
moment?

> 2. if I'm Yoyodyne Enterprises, a worldwide megacorp, and I have subsidiary corporations
> using my SSO, I might want to issue multiple signin credentials. Kerberos for example
> gets me access to over three different credentials at work.

Can you describe how that works from the user's perspective? Do you
log into a single page somewhere that mints tokens for other services?

> Conflict:
> https://w3c.github.io/webappsec/specs/credentialmanagement/#dom-credentialscontainer-pending
> currently only permits the user-agent to present a single credential to the client code.
>
> Recommendation: turn .pending into an array of PendingCredentials.

The PendingCredential is meant to solve a different use case: when you
log into a site, you're often taken to a landing page as a top-level
navigation. The new page doesn't know the username and password you
used to sign in, so it can't generate a LocalCredential object for the
`notifySignedIn()` call. If the browser noticed that you were signing
in to a site, it does some magic (currently) to store that
username/password pair so that you can hit the "save password" button
even though you've navigated away from the page where that data was
entered.

PendingCredential is, therefore, an opaque object that says "Hey, the
browser has some credentials it could store." You can pass that object
to `notifySignedIn()` in order to be explicit about the action you're
performing.

--
Mike West <mkwst@google.com>, @mikewest

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.)

Received on Thursday, 12 February 2015 08:15:46 UTC