Harmonizing same-origin and cross-origin credentials

This is an attempt to try and start documenting the concerns and the
path forward for the Credential Management API wrt. cross-origin
credentials.

Specifically, this is not a request that this group take on something
that is outside the scope of their current charter.

This is meant to frame the discussion regarding whether or not the
extensibility of the Credential Management API is capable of supporting
a set of use cases envisioned around credentials in the Credential CG
and Web Payments IG. Mike West already knows most of this stuff, I'm
documenting these points so that the larger WG can understand where the
discussion is currently.

Definitions
-----------

It's important to note that the definition of 'credential' that this
group is using is a subset of the definition of 'credential' that the
Credentials CG and Web Payments CG has defined over the past several
years (personal opinion: the Web Payments IG is likely to adopt the
broader definition for a variety of reasons):

https://docs.google.com/document/d/1Nq543-Am1hQUIZ2hhzAFl8KexvIEBwDDc_f3Ikz1opQ/edit

It's important that we don't get tripped up over the mismatch in the
definition of 'credential'.

Same-origin vs. Cross-origin
----------------------------

Same-origin credentials are ones that are created and consumed on the
same website. Example: username/password login credential

Cross-origin credentials are ones that may be created on one website and
consumed on another website. Example: driver's license

The WebAppSec WG is chartered to consider same-origin credentials and
not cross-origin credentials.

It is likely that cross-origin credentials are going to be a hard
requirement when the Web Payments WGs are created as well as a potential
future Credentials WG.

The Problem
-----------

The Credential Management API provides a section on extensibility,
however we've been following section 8.2 (extension points) and trying
to map the current API and model to figure out if it's possible to
support cross-origin credentials with the current API.

Based on our use cases, we've found that we need a mechanism for
websites to request a subset of properties about an entity (e.g.: name,
proof of age, proof of shipping address) and get back trusted values for
those properties. In order to establish trust, the set of
digitally-signed credentials that asserted those values is included.
These credentials may have been issued by a number of different
cross-origin sites, but they will been aggregated at a single site (a
"credential curator") for the entity.

Here's the key modeling difference between the Credential Management API
and cross-origin credentials:

The Credential Management API assumes that a credential /has/ a unique
identifier and the credential and the entity it's for are one and the same.

The Credentials CG's cross-origin credentials assume that a credential
is /associated/ with a unique identifier. The identifier is an
identifier for some entity, not the credential itself.

We are currently doing the analysis if this modeling difference is
problematic, or if it's just fine.  We have not completed the work yet.
We hope to have something done by the end of this week. We specifically
want to avoid creating an API where browsers will have to implement two
very different designs to support both approaches.

Current Concerns
-----------------

The concerns revolve around what browser implementers are going to be
comfortable with. We can't answer those questions, only browser vendors can:

1. This may deviate from the existing
   LocalCredential/FederatedCredential model and storage system. Is
   remote storage of credentials at a 3rd party ok?
2. We need to store remote credentials and also cache them locally.
   How will/should browsers implement remote retrieval? Create their
   own dialogs or let the browser redirect normally? How would a
   polyfill work?
3. How will/should browsers treat locally cached "IdentityCredentials"?
4. Will the way they are identified not fit with how the other simpler,
   eg: password, credentials work? Is that problematic?
   To extend the existing API according to section 8.2, we'd create an
   "IdentityCredential" that provides a "view" into a particular entity.
   A view is a subset of the entity's properties. That view would also
   come with our own "linked data" credentials (note these aren't
   subclasses of Credential in the API) that assert the values for those
   properties.
5. A site may want two or more different "views" of an entity. For
   example the site may want your email address to log in, but will
   want your shipping address and a proof of age when they want to send
   you a package. This requires two or more "IdentityCredentials", but
   each one would be associated with the same identifier. Is this
   problematic for browser implementations?
6. Should we specify in the spec that browsers should essentially
   generate their own opaque IDs for credentials and not rely on
   Credential.id?

To summarize:

1. We don't want WebAppSec to take on work they're not chartered to do.
2. The Credentials Management API has an extensibility mechanism, and
   we assert that the future Web Payments IG/WG and Credentials CG/WG
   work would like to use it.
3. We don't know if this extensibility mechanism will work for
   cross-origin credentials, which will more than likely be a hard
   requirement for the future Web Payments IG/WG and Credentials CG/WG.
4. We don't want the future Web Payments IG/WG and Credentials CG/WG
   to effectively duplicate the work done in this group because the
   extensibility mechanism doesn't work for them.
5. We're working on getting a concrete but drafty cross-origin
   extension done in the Credentials CG by the end of this week.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: High-Stakes Credentials and Web Login
http://manu.sporny.org/2014/identity-credentials/

Received on Monday, 18 May 2015 18:50:12 UTC