Re: Harmonizing same-origin and cross-origin credentials

Manu,

  In my experience, there is a considerable history of work that already
embodies the concept you're calling a "cross-origin credential" under the
moniker of "claims based authentication".  See, e.g. SAML, OAuth2, OpenID,
OpenID Connect, WS-Trust, UMA, even Kerberos, with patterns like claims
aggregation and security token services deployed as overlays on top of more
traditional monolithic-identity federation relationships and protocols.

 Since there seems to be a great deal riding on the word "credential" and
its definition, can you explain briefly what are the important differences
between what  you call "cross-origin credentials" and "claims based
authentication" as it has been widely deployed in the last decade?  Are
there specific lessons in privacy and management that we can apply from the
operational experience in deploying claims-based technologies and their
successes and failures?

-Brad

On Mon, May 18, 2015 at 11:52 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

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