RE: Technical Review of WebAppSec Credential Management API [2/3] (was Re: Overlap with Credentials/Web Payments CG)

[Keeping this to Web Payments IG only to reduce noise.  But I think the topic is important.]

Dave Longley wrote:
>However, what then is the point of calling `navigator.credentials.get()`? It's just to get back another object that has the actual API we want to use?

+1.  Kicking the proverbial can down the road.

And again:
>I don't expect anyone's first choice for a credentials API to be one where you must ask for a
>"BetterCredential" object that has the real credentials API on it.

+1 again.  It might be that our ideas about APIs are a little too one-dimensional.

The book "RESTful Web APIs" (Richardson, Ammundsen, and Ruby) talks at some length about:
1) Human Driven Clients
2) Automated Clients

And makes some assertions about both of these.  (One very interesting point is the importance of rendering Hypermedia Controls faithfully to allow Accessibility; we need to think about this going forward but it's a digression for now.)  Automated clients "carry out simple preprogrammed rulesets that hopefully help them reach some predefined goal."  They list several kinds of such automated clients (crawler, monitor, script, agent) that can be used to accomplish the goals.

The above is only an example.  The point is that object polymorphism is not the only way to solve a complex API problem.  Properly constructed metadata (hypermedia) can give concrete "hints" about how to proceed, and moves ultimate control from inside the API "event horizon" to the outside.  Smarter people than me will have to figure out how to make this work - exciting to contemplate.

Best regards,
David Ezell

-----Original Message-----
From: Dave Longley [mailto:dlongley@digitalbazaar.com]
Sent: Tuesday, April 14, 2015 10:59 AM
To: Adrian Hope-Bailie; Mike West
Cc: Manu Sporny; Brad Hill; Wendy Seltzer; Dan Veditz; public-webappsec@w3.org; Credentials Community Group; Web Payments IG
Subject: Re: Technical Review of WebAppSec Credential Management API [2/3] (was Re: Overlap with Credentials/Web Payments CG)

On 04/14/2015 06:15 AM, Adrian Hope-Bailie wrote:
> Hi Manu, Mike,
>
> It appears that on the one hand Manu is asserting that the current
> design of the API is restrictive and on the other Mike is asserting
> that it is extensible and therefore future use cases are possible
> through extension of this API.
> You are both looking at the same evidence and drawing directly
> contradictory conclusions.
>
> May I suggest that the best way to resolve this is to test these directly.
> Can the publishing of the spec be held back for an agreed period to
> allow the Credentials CG to attempt to POC it's extensive use case
> list against this API.
> Bugs can be logged via Github and discussed on this list with a view
> to reaching a deadline in the future when all use cases have been
> tested against the API.

+1 to this.

I'd like us to have some time to see if and how we can work with this API to deal with the use cases from the Credentials CG and Web Payments IG. I think that's really what the main issue is -- and there can't be consensus without this. I'd like to see Mike working a bit more closely with us to resolve the potential issues.

Looking at the API, my intuition is that we could possibly implement the use cases we have but in a strange end-around way (an unnatural use of the API as presently designed). I also think that the suggestion that every new type of credential be implemented as a new derived Credential class is somewhat naive and architecture heavy. It seems to me that, in order to work with the proposed API, we'd likely implement a single new derived Credential class and then put an entirely new credentials API on that class that actually supports our use cases. However, what then is the point of calling `navigator.credentials.get()`? It's just to get back another object that has the actual API we want to use? It seems like the integration should be tighter than that -- with the old
username+password style login API being a degenerate case, not the default.

I don't expect anyone's first choice for a credentials API to be one where you must ask for a "BetterCredential" object that has the real credentials API on it. The extra step seems unnecessary. I'd prefer that you can ask rich credential queries with `navigator.credentials.get` and it will either return to you credentials that are cached in the browser or it will direct you to your IdP to obtain them. If your query is for a simple username+password style legacy credential, then that's what you'd get (and directly from the browser's cache). If your query was for the kind of credentials required by the use cases from the Credentials CG/Web Payments IG, then those are the kinds of credentials you'd receive. But note that our use cases may require leaving the page -- and then eventually returning back to the relying party. We also want that to happen without requiring that the relying party use some SDK. We want the standard to eliminate that extra work, not add another thing credential consumers need to implement.

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



________________________________
This electronic message, including attachments, is intended only for the use of the individual or company named above or to which it is addressed. The information contained in this message shall be considered confidential and proprietary, and may include confidential work product. If you are not the intended recipient, please be aware that any unauthorized use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and deleting this email immediately.

Received on Tuesday, 14 April 2015 16:00:20 UTC