Coming back to CREDENTIAL.

I've let the credential management API discussion go fallow over the last
month or so; let's pick it back up.

timeless provided some excellent feedback at [1] that I really appreciate.
I'll work through that in the near future. Likewise, I owe the Credentials
CG more detailed responses to the thread that I let die at [2]. Let me pick
that back up in the hopes of coming to something like resolution. I'll go
through the "discussion points" from [3] line-by-line below, but first I'll
back up a second to discuss the problems I actually want to solve, as I
think that will help reframe the discussion:

1. I want to make it easy for users to use password managers, as they have
significant advantage over other methods. Likewise, I want it to be easy
for password managers to help users sign in.

2. I want to encourage usage of federated sign in mechanisms, as they have
interesting properties in relation to passwords. They're certainly not
perfect, but in various cases they can be a big step up in terms of
security. The first baby step is giving the browser an understanding of
what's going on by allowing a site to store federated credentials. The next
obvious step would be to natively support some set of protocols (OpenID,
etc).

3. I want to provide a framework which is extensible enough to support
device-level (but origin-bound) things like FIDO in the future. That is,
you could imagine a `FidoCredential` subclass of `Credential`, with methods
allowing a website to ask for assertions of various kinds.

I'm certainly interested in cooperating with the Credentials CG and others
where possible, insofar as those use cases overlap with these use cases I
care about. As I'll note in #5 below, I think there's some amount of
overlap with #2 above that's worth exploring. That said, I'm also very
interested in deferring a detailed specification of grabbing data from
third parties until after we've determined whether there's
implementer/developer interest in the core functionality.

In short, I'd like to ship the kinds of improvements to Chrome's password
manager that we've been talking about for almost a year now. I hope we can
reach agreement on that portion of the API relatively quickly, even if
questions about future extensibility remain open.

With that in mind, let's look at the discussion points from [3]:

## 1. Composability of Credentials:

This seems like an aesthetic problem more than anything else, and I think
the current document does a pretty good job addressing it. That is,
something like the following seems like a fairly reasonable way of
presenting an "Identity" credential to developers:

    navigator.credentials.get({
      "identity": {
        "filter-key": "value",
        "filter-key1": "value1",
        ...
      }
    });

That might return an IdentityCredential object with a number of properties
hanging off of it, based on the various filters that were passed in.
Technically, this gives you what you need, though I understand that you'd
rather call the properties "credentials".

I don't really understand the caching concern you're expressing here.
Perhaps you could elaborate?

## 2. Remote Storage of Credentials

I don't honestly know how the kinds of credentials that the Credentials CG
wants to represent would be stored in the browser. Structured data is
simpler to work with than free-form data, but we certainly have free-form
storage mechanisms like IndexedDB whose backends we could repurpose. What
data do you need to store? Does the browser need to store it, or can the
requesting origin simply rely on its own Indexed DB or localStorage to
persist the data it requires while offline?

Let's push the workflow questions to #5 below, as I think they all fold in
there.

## 3. Using our definitions, an IdentityCredential is just an identity that
is composed of credentials. It is not a credential itself

I think this is addressed in #1. This sounds like an aesthetic problem
rather than a technical one: assuming you had a set of credentials bundled
up in an object, storing that object (and therefore the credentials it
contains) seems quite possible.

As Brad noted in an earlier email, renaming things might be the right way
to address these concerns. Suggestions for words other than "credential"
for the top-level concept are welcome.

## 4. IdentityCredential can be locally or remotely stored, does that mean
it has to inherit from LocallyStoredCredential?

LocallyStoredCredential is probably unnecessary. I had hoped it would
simplify the query process, but it probably introduces more complexity than
it needs to. I'll drop it, and just move its properties to the subclasses.


## 5. Promises that resolve to navigations:

I don't think we need this.

In particular, if I strip away most of the detail regarding signatures and
queries, it seems to me that the workflow discussed in [3] is very similar
to the three-legged auth flows in OAuth: the user begins on A, is taken to
B to perform some ceremony, and is brought back to A with additional data.
I imagine this taking place in some sort of auxiliary browser UI, as
opposed to navigating the current browsing context.

That has a number of advantages, actually, as it would be quite possible to
treat this kind of authorization window in a way that would make it more
clear to users what was being asked of them. In an ideal world, this could
also mitigate some kinds of phishing attacks, as something like
SafeBrowsing would have more context when examining the page's content
(e.g. "This page is declaring itself to be an auth endpoint. Why does it
look so much like Facebook when it's being served from evil.com?")

Doing the auth work in a separate context means that we can keep a simple,
async, promise-based API for the relying party; it will simply wait until
the user has walked through the auth steps in the auxiliary context, and
the browser will hand it back some data.

This certainly requires either that the browser understand the protocol
(which is possible in the case of OpenID/OAuth), or that we provide an API
which would allow the third-party to pass data back to the initial browsing
context to resolve the Promise.

Either way, this mechanism seems more reasonable than persisting or
recreating data after/during navigation.

## 6. How does query matching work?
https://github.com/w3c/webappsec/pull/292

I think we're closer to resolution in the current document, as I've adopted
most of what Adrian proposed for `get()`.

## 7. Can the origin property for an IdentityCredential refer to the origin
that you have authorized its transmission to rather than where it
originated?

This worries me for reasons I've expressed in other threads. You'd be free,
of course, to define your extension however you like, so if that ends up
making sense for the use cases you care about, you can certainly specify it
that way.

---

This got long. Thanks for reading this far. Hopefully we can get this
conversation spun up again quickly, and resolved equally quickly. :)

[1]: https://lists.w3.org/Archives/Public/public-webappsec/2015Jun/0066.html
[2]: https://lists.w3.org/Archives/Public/public-webappsec/2015Jun/0001.html
[3]:
https://docs.google.com/document/d/1tI0CJ4wAKKPQacrxOmTtl_GQUBeVtbg8e1ZSXs2SWag/edit?usp=sharing

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