Re: Coming back to CREDENTIAL.

On 08/31/2015 10:18 AM, Mike West wrote:
> Thanks Adrian!
> 
> On Mon, Aug 31, 2015 at 3:18 PM, Adrian Hope-Bailie
> <adrian@hopebailie.com <mailto:adrian@hopebailie.com>> wrote:
> 
>     On 31 August 2015 at 11:31, Mike West <mkwst@google.com
>     <mailto:mkwst@google.com>> wrote:
> 
>         1. I see very little debate about password management use cases.
>         Could we agree that the API as defined (perhaps modulo naming)
>         is a reasonable first stab at solving that particular problem?
>         Coincidentally, This is the piece I'm most interested in
>         shipping quickly.
> 
> 
>     +1 - Password management has very few stakeholders that might have
>     an opinion on the API (vendors of password managers are the only
>     ones I can think of) so I see little danger in forging ahead with
>     that recommendation as is.
> 
> 
> Hooray.

+1 - Like you mentioned though, there may be a need to change/narrow the
naming -- as it depends on whether or not the scope of the API ends up
including other kinds of credentials and federated login and so on.

> 
> I have emailed the generic addresses I could find at LastPass and
> 1Password, by the way. If you (or anyone else?) happen to know folks
> there, help me out. :)
> 
>         2. I see agreement that the current `get()` API is robust enough
>         to support extension in another WG with (something like) an
>         IdentityCredential object which could "assert certain properties
>         and values about an identity".
> 
> 
>     I am "taking the 5th" on this. I need to go back to the spec again
>     with fresh eyes. I do think that get() filtered by provider is a
>     dangerous and irreversible step. I can't think of any other browser
>     API which allows the caller to list protocol implementations by
>     vendor as a means of discovering which protocol to use. That feels
>     like anti-standardisation to me.
> 
> 
> You're talking specifically about FederatedCredential, though, right?
> 
> Here, I'm only suggesting (and I think Dave agreed
> in https://lists.w3.org/Archives/Public/public-webappsec/2015Aug/0081.html)
> that a theoretical `IdentityCredential` and `navigator.credentials.get({
> "identity": { "filter-key": "value", "filter-key1": "value1", ... } });`
> pattern could meet the needs of the folks who wish to define those things.

Based on your input, Mike, it seems like the theory is ok. My main
concerns were mentioned in my last email (ie: ensuring the underlying
data model will work with our use cases and be appropriately exposed to
the browser).

> 
> That is, I want to make room for other people to work on the things they
> care about, the core objections from the Credentials CG and Web Payments
> IG were about the API's deficiencies in extensibility, and we've worked
> hard to address those objections. I think the current API model is
> generic enough to do so.

And that work is very appreciated. :)

>   
>         3. I didn't see any discussion about future protocols like FIDO,
>         so I'll simply assume that everyone agrees that the current
>         model is extensible enough. :)
> 
> 
>     Don't know enough about this domain to comment other than to say
>     this probably shouldn't be pushed through in a vacuum. There is work
>     being done at W3C related to hardware-based security and perhaps
>     some cross-pollination of ideas is a good idea.
> 
> 
> Yes. My point wasn't to suggest that we had a solid FIDO-supporting API,
> but instead to suggest that the API as-defined is generic enough to
> support things like FIDO if they choose to use it as a basic framework.
> It would be lovely if FIDO folks would officially hop into the W3C so we
> could openly discuss the proposals that have been floated in more closed
> contexts.

+1 to Adrian's comments; more input from primary stakeholders is a good
idea.

>  
>     If, on the other hand, all of these IdPs were implementing a
>     standardised federated identity protocol it would be possible for
>     RP's to implement a single protocol that benefits their users
>     irrespective of IdP. If those users switch IdP the migration at each
>     RP would be simple and the market becomes more efficient.
> 
> 
> Except insofar as those IdPs you're worried about generally provide
> significant services above and beyond authentication (e.g. graph
> information). It's unclear that offering an authentication protocol in
> the browser will be enough to move RP away from them in anything like
> significant numbers, because they're not simply authentication systems.
> They're ecosystems in and of themselves.

I agree; I don't think merely offering an authentication protocol in the
browser will cause any seismic change. However, it will help remove a
barrier to competition and freedom of choice.

> 
>         3. Do you have a proposal for discovery? That is, how do I know
>         what protocols a particular origin supports? Do all the
>         protocols you care about support something like
>         `https://accounts.google.com/.well-known/openid-configuration`?
>         Would we need to request X files from a server every time we
>         save a password? (Note: I'm a bit concerned about proposals that
>         require the IDP to do some work, as it doesn't appear that
>         there's significant incentive for the IDP to do so.)
> 
> 
>     Shouldn't discovery be part of the get() API? The RP site calls
>     get() providing the list of protocols it supports and the browser
>     looks in it's internal registry of stored identity credentials for
>     those that support this protocol. These are the identities presented
>     to the user for selection and when the user selects one this is
>     returned to the RP site to initiate some protocol specific flow that
>     the RP is then in control of.
> 
>  
> I mean an earlier phase of discovery that enables the protocol-based
> `get()` you've outlined here. How does the browser create an internal
> registry of stored identity credentials that support a protocol?

In the Credential's CG work, your browser can discover a URL to your IdP
(given a user secret) and a JSON-LD document at that URL declares the
IdP's supported services.

For other protocols, one approach could be to have the IdP register
itself with your browser. So, upon visiting your IdP, it could register
a credential in your browser (with your permission) that declares its
supported protocols. That credential could later be used to initiate the
generation of an RP-origin-specific credential. This requires some level
of cross-origin stuff and a prior visit to your IdP.

-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Monday, 31 August 2015 23:09:11 UTC