Re: Coming back to CREDENTIAL.

On Tue, Sep 1, 2015 at 1:08 AM, Dave Longley <dlongley@digitalbazaar.com>
wrote:

> >     +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 think the goal is to be able to include other kinds of credentials,
regardless of whether the initial thing shipped in UAs does so.

How narrow would you like the naming to be?

> 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).
>

I believe that you'll be able to define storage mechanisms for the kinds of
credentials that you care about which have the properties you want. I don't
think that any mechanism with the combinational properties that you're
interested in exists at the moment, but I don't think the API that's
proposed here makes it any harder (or easier) to define them.

> 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.
>

I've poked people.

> 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.
>

I'd really like to come up with a scheme that doesn't require Google (to
pick a random example) to add JavaScript to `accounts.google.com`, because
selling that to the login and security teams is going to be difficult at
best.

That said, we've apparently adopted the discovery mechanism defined at
https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig.
Do other protocols define similar discovery mechanisms?

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)