Re: Overlap with Credentials/Web Payments CG (was Re: CfC to publish a FPWD of Credential Management; ending April 17th.)

On 04/14/2015 01:19 PM, Brad Hill wrote:
> But, unfortunately, as a point of order within this group, I'd like to 
> ask that we confine discussion to the shape of the abstract API.  If 
> we can improve it to make it more future-proof, we should of course do 
> so, but providing a direct implementation for the Credential CG and 
> Payment IG's use cases is not what we are chartered to do, members of 
> those groups have not joined the WG or executed contributor's 
> agreements, and we cannot take potentially encumbered technology into 
> our specifications, especially that which is beyond our charter scope.

+1

To quote from Adrian, I think the minimum we need to future proof this 
API is:

"1. Allow the browser to act as an agent between an IdP and RP rather 
than always assuming the role of IdP (although this should also be in 
scope/possible) as suggested previously by Dave Longley in Manu's last email
2. The definition of a credential object could more closely match the 
proposal in the latest Credentials CG spec: 
http://opencreds.org/specs/source/identity-credentials/#a-typical-identity
(i.e Properties such as expiry, id, type, signature should exist on the 
base Credential class)"

To help aid in determining the shape of the abstract API, I've included 
some details about the credentials API we have been working on:

1. Our credentials API entry point is `navigator.credentials.get()`. 
This is the same as the Credentials Management API.

2. The `get()` method is intended to take an object that represents a 
query for the types of credentials (and potentially other information) 
desired by the relying party. Here "types" refers to RDF type (a Linked 
Data attribute). It also takes a callback URL that the credentials will 
be posted to in response. This differs from the Credentials Management 
API which returns a Promise, as it does not contact any third parties.

3. The browser would be responsible for fulfilling the query using any 
previously cached credentials (optional) or contacting the user's third 
party IdP and forwarding the request to it. The browser could optionally 
mask who the relying party is so the IdP is not made aware of this 
information without the user's consent.

4. The user's IdP would authenticate the user, process the request, 
present the credentials to be sent, and request the user's authorization 
to proceed.

5. After the user consents, the result of the request, formatted as a 
Linked Data document (JSON-LD) containing the user's identifier and a 
credentials property with an array of credentials that matched the 
request, would be posted to the callback URL. If the credentials were 
cached, this post could happen immediately without a need to contact the 
IdP.

There are a number of other details, some decided, some TBD, but below 
are some basic ideas that I believe need to be known so that we can work 
together to future proof the Credentials Management API:

1. We use Linked Data for extending credentials.

We don't implement new types of credentials at a browser API level; that 
approach is not scalable to the broad ecosystem this technology serves, 
it requires credential authors to have a greater skill set than 
necessary (just define new vocabulary terms vs. write and manage 
JavaScript code), and it can't leverage existing Linked Data tools to 
help consumers merge credentials from different sources together to 
define a more complete profile of a user's identity. In short, "just 
define a new derived Credential class" is an unattractive and perhaps 
unworkable proposal from the Credentials CG's perspective. I believe we 
would end up having to define a single new class that isn't really a 
Credential itself at all, but it would provide the entire credentials 
API we actually want. This would seem to render 
`navigator.credentials.get()` pointless. If, instead, 
`navigator.credentials.get()` could take a complex query and a callback, 
I believe the API would be better future proofed.

2. We expect credentials to be stored by third party IdPs and the 
mechanism for fetching them to be standardized.

This doesn't preclude browsers from being IdPs themselves or from simply 
caching credentials, but we expect people to want to store their 
credentials in a way that makes them accessible from a number of 
different devices/user agents. These credentials aren't simply "login 
credentials", they may be long-lived pieces of information about them 
(eg: driver's license, work permits, etc.). Such credentials may have 
only been issued after a lengthy verification process. It's a very 
different scenario from "You're using a new browser, so just enter your 
username and password again and we'll store the credential in this one, 
too." That approach is untenable for a whole variety of credentials. We 
can discuss this point further if that's still not obvious, but 
hopefully we can just say: "The API needs to support asking third 
parties for stored credentials".

To be clear, we want communicating with third party IdPs to be integral 
to the API; it's unacceptable for the API to return yet another object 
that is then used to execute this behavior. There might as well be 
another API at that point. Note that we also want to standardize a 
protocol -- which means we want the browser to handle transporting 
credentials so that relying parties have as little code to write as 
possible. Earlier in this thread, there was a suggestion that a 
FederatedCredential could have special methods tacked onto it based on 
whether it came from Facebook, Google, etc. Then the relying party could 
use an SDK and call those methods, and so forth. We're trying to unify 
how credentials are passed around so relying parties don't have to deal 
with that problem at all, rather, there's just one way to receive a set 
of credentials and they arrive in a standard format.

3. Once credentials have been authorized, they are typically authorized 
for use at a particular domain, so we may be able to integrate with the 
Credentials Management API in the sense that each Credential is stored 
with a particular "origin." However, I'm not sure if this is stretching 
the intended use of that property or not. The site that issues the 
Credential has nothing to do with this "origin" property, as the issuing 
site, in our design, has no idea where the Credential may be used and is 
not involved in the credential consumption process.

4. We'll need to consider that "credentials" aren't just "for login".

That means that browsers shouldn't just take a list of credentials and 
throw them up in a UI when someone is attempting to log into a website. 
The browser is going to have to differentiate between credentials that 
are intended for that purpose and those that are not. In the Credentials 
CG work, we don't consider "login" to be a special use case. A relying 
party may ask for whatever credential they want to in order to authorize 
a user to take some action or to simply collect information about that 
user for later review, etc. For example, "login" can be implemented by 
requesting a "Verified Email Credential" from a user. The current 
Credential Management API sees the "login use case" as a special first 
class citizen, which makes perfect sense, considering that it is 
scope-limited to making incremental improvements to "login" via a new 
imperative password manager API. I don't see any conflict with the 
Credentials CG in this respect.

The conflict arises from the fact that the spec aims to do more than 
just provide an API for password managers, it suggests there is "future 
work" and attempts to define an extensible API to try and cover it. 
Again, it makes perfect sense that you'd want such an API to support a 
broader range of credentials if it can. Fortunately, the Credentials CG 
has spent years working on designs and technologies in the "future work" 
space the Credentials Management API refers to. Unfortunately, the 
current design feels a bit inverted to those of us that have spent that 
time. I don't have a quick fix for this particular issue -- but it's 
clear to me that how we want credentials to work in the future doesn't 
quite mesh with the existing "login" paradigm. I don't know what this 
means for future-proofing the API, but I do see that some changes are 
necessary.

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