Re: Coming back to CREDENTIAL.

On 09/02/2015 02:15 PM, Mike West wrote:
> On Wed, Sep 2, 2015 at 4:27 PM, Dave Longley
> <dlongley@digitalbazaar.com <mailto:dlongley@digitalbazaar.com>>
> wrote:
>
> I agree with that goal. I was only speaking to the situation where
> others may push for the API to be limited to passwords (and to defer
> the extensibility features for a later date). If that's where it ends
> up, then I think the "credentials" terminology should not be used and
> terminology like "passwordManager" should be instead. Again, that's
> not my preference, however, as I'd like to see a common, extensible,
> credential API created.
>
>
> Right now you and Adrian are the only ones I see pushing back on
> things outside the password functionality, so I'm happy to hear that
> you're not concerned about the scope, just the implementation. :) Do
> you more or less agree with the direction that discussion's going
> (that is, with the suggestion at the bottom of
> https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0011.html)?

Yes, I do agree with the direction, though I've got some comments:

> 1. Bob signs into IDP.com. 2. IDP calls
> `navigator.credentials.store(new PasswordCredential({ id:  'Bob', password: 'hunter2', protocols: ['X', 'Y', 'Z'] }));`
> 3. Bob accepts the user agent's kind offer to store this credential  for him.
>
> Then:
>
> 4. Bob visits every-idp.com.
 > 5. every-idp.com calls `navigator.credentials.get({ 'federated': { 
'protocols': [ 'X' ] } } )`
> 6. The UA helpfully offers Bob IDP.com.

I don't understand how the browser knows to offer "IDP.com" to Bob.

What piece of information does the browser use to determine that? Does
the use of "protocols" imply that a credential can be used to
fulfill credential requests at other domains? Does the browser simply
look for a matching protocol string and then allow the selection of any
credential that happens to list that protocol?

What if the protocol isn't a cross-origin type of protocol ... or does
this API assume that they all are? Or does the browser have implicit
knowledge about particular protocols that enables to look at a
PasswordCredential from one origin (IDP.com) and infer that it could, in
some way, be used to fulfill a request by another origin (every-idp.com)?

Should, instead, IDP.com be required to specify an additional flag that
their credential should be made available to fulfill queries for
matching protocols at other sites?

Don't get me wrong, I'm all for something like this approach. With 
respect to the Credentials CG work, we have been asking for something 
just like this type of "cross origin" credential. We'd like RPs to be 
able to ask for credentials that aren't from the RP origin. Instead, 
they'd be obtained from an IdP (with the browser blinding the request).

The Credentials CG flow could look like this:

1. Bob creates an account at IDP.com.
2. IDP calls `navigator.credentials.store(new IdentityCredential({ ... }))`.
3. Bob's UA guides him through a UI for registering a
decentralized identity associated with IDP.com (and a keypair for his 
device).
4. Bob accepts the user agent's offer to store this credential.

Then:

5. Bob visits rp.com.
6. rp.com calls `navigator.credentials.get({ 'identity': { query:
{email: '', favoriteCat: '', ...} });`
7. The UA offers Bob his decentralized identity, linked to IDP.com, 
which he selects.
8. The UA takes Bob to IDP.com, in a secure context, where Bob selects
credentials that assert property values to fulfill the rp.com's query.
9. IDP.com calls `navigator.credentials.transmit({ Bob's selection })`.
10. The UA asks Bob to confirm sending his selection to rp.com.
11. The UA uses Bob's IdentityCredential (with a credentials property 
containing his selection) to fulfill rp.com's query. (The Promise 
returned by the `navigator.credentials.get` call gets resolved to this 
constructed IdentityCredential instance).

Does this seem like it would work to you? How do you suggest we go about
building a polyfill for this on top of the polyfill you've got here?:

https://github.com/mikewest/credentialmanagement/tree/master/polyfill

We have an *extremely rough* (and slightly different) demo version of 
this running at https://authorization.io. It currently uses source from 
here:

https://github.com/digitalbazaar/credentials-polyfill
https://github.com/digitalbazaar/authorization.io

Note that our polyfill's `registerDid` method would be replaced by 
storing an `IdentityCredential` in the flow above.


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

Received on Wednesday, 2 September 2015 20:59:17 UTC