Re: Harmonizing same-origin and cross-origin credentials

On 2015-05-18 20:49, Manu Sporny 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.

Although an extension mechanism is cool, a remaining issue is how to get
an extensions in place.

IF you come to the point that the Credential Management API won't work
right out-of-the-box, I encourage you evaluating the Web2Native Bridge
which was designed to address a wide range of browser extension applications
including Credential Management.

As a reference, the Estonian e-government have settled on using the
Web2Native Bridge "predecessor and inspiration" (Chrome Native Messaging),
for their eID program: https://github.com/open-eid

Anders


>
> -- manu
>

Received on Monday, 18 May 2015 19:40:32 UTC