Re: Coming back to CREDENTIAL.

On 07/31/2015 05:00 AM, Mike West wrote:
> I've let the credential management API discussion go fallow over the
> last month or so; let's pick it back up.

My apologies for doing the same since you sent this email!

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

Ok. Thank you for articulating these as your primary goals. We're
definitely interested in the future of #2 and potentially #3. I think
some of our use cases should help inform us on how to go about #2. The
Credentials CG work is all about issuing and consuming third party
credentials.

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

Great and thank you for your time! :)

>
> ## 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".

This sounds ok to me. Btw, the properties aren't "credentials", rather,
credentials assert certain properties and values about an identity.

A credential can be thought of as a partial view of an identity. It
contains N assertions (properties + values) about that identity. Those
assertions are made and digitally-signed by the issuer of the
credential. By combining the assertions from a number of different
credentials together, you get a fuller view of an identity; this
combination we've been calling an "IdentityCredential".

So what we'd likely want an IdentityCredential to look like would be a
collection of properties + values from some set of credentials, and a
special property "credentials" that includes the set of credentials
themselves, to allow the consumer to check their digital signatures and
other meta data.

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

It has to do with how the data is modeled. We "link" credentials
together via a common "identity" identifier. We want to ensure that the
browser knows about this information and can therefore assist the user
when they are making credential selections.

For example, the browser may have cached, for the same website, a number
of different credentials for two different identities: an email address,
a shipping address, and a loyalty card.

Note that these credentials may have been cached following a variety of
different interactions. For example, a website might have asked for an
email address on a separate occasion from a shipping address and loyalty
card.

Now suppose a user is visiting the website and it requests their email
address, a shipping address, and a loyalty card. We want the browser to
*only* present two different "bundles" for the user to select from
(we're calling these "bundles" IdentityCredentials). In this particular
case, the semantics are essentially: "Do you want to take this action as
identity A or identity B?". The user should not be able to mistakenly
present an email address for identity A and a loyalty card for identity B.

We want to ensure that the way in which credentials are stored and the
understanding the browser has of the way credentials are modeled is
sufficient to create appropriate UIs for these scenarios.

>
> ## 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?

JSON documents. They could have a number of properties that should be
understood by storage mechanism, but also some that needn't be (they can
just be ignored).

> 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?

This is a general problem for websites working with credentials, these
credentials and the protocols for requesting and receiving them are
intended to be standardized. If it's not implemented in the browser then
every interested site will just need to reimplement the same thing.
Furthermore, in that scenario, there would be no way for a user to
specify global configuration options for the storage of their
credentials. The browser may also be able to perform certain
optimizations, such as storing some credentials only once if they are
used across multiple origins.

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

This may be the way to go. We'll try to brainstorm a bit more on naming
the top-level concept. So far, we've been referring to it as an
"Identity" or "View of an Identity" but that's problematic for another
set of reasons. In our credential selection flow, a website requests a
number of properties about you and then you "compose a view of an
identity" by picking the credentials you'd like to share to provide the
values for those properties.

>
> ## 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 sounds ideal once it's in the browser, but how would you recommend
that we go about implementing a polyfill for that?

>
> 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 <http://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.

+1

>
> ## 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()`.

Ok, we'll have to take some time to review and follow up on #292.

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

Understood. Our argument is essentially that some things are easily
modeled such that they work with a simplified security model. But some
things are not. We shouldn't say that there's no place for standardizing
those things on the Web just because it's a harder
problem to solve.

Credentials are used in a particular way in the real world. If you could
pass them around the same way on the Web then...

* The state government that issues you a driver's license doesn't run
the federal government website that you give it to to obtain a
passport.

* The university that issues you a degree doesn't run the website where
you're applying for a job.

* The community college that issues you a certification for course
completion doesn't run the state university website where you present
the certification to get credit for course work already completed.

* The organization that issues you a recent background check
certification doesn't run the website where you present it to authorize
you to fill prescriptions or order a firearm.

* The government that issues you a citizenship identifier doesn't run
the website where you present it to authorize a high-value financial
transaction.

These use cases (and many more) all follow a generalized pattern.
There's no standard in place right now to unify these types of
credentials, but we believe there should be. We shouldn't limit the
usefulness of standards on the Web by saying they must be restricted to
origin-user relationships. Certainly those are the parties that are
communicating with one another, but sometimes their common trust comes
from a third party.

Instead, the same origin policy should be viewed as a very useful tool
for simplifying the security model for the vast majority of interactions
on the Web. The same origin policy is a really useful hammer, but not
every problem is a nail.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Received on Monday, 17 August 2015 16:55:55 UTC