- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Tue, 14 Apr 2015 18:04:11 -0400
- To: public-webappsec@w3.org
- CC: Mike West <mkwst@google.com>
- Message-ID: <552D8EDB.1070800@digitalbazaar.com>
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
Received on Tuesday, 14 April 2015 22:04:37 UTC