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

Received on Tuesday, 14 April 2015 14:59:41 UTC