- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Mon, 17 Aug 2015 12:55:28 -0400
- To: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- CC: Manu Sporny <msporny@digitalbazaar.com>, Brad Hill <hillbrad@gmail.com>, timeless <timeless@gmail.com>, Adrian Hope-Bailie <adrian@hopebailie.com>
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