Re: Coming back to CREDENTIAL.

On 09/03/2015 07:11 AM, Mike West wrote:
> Before diving too deeply into the line-by-line, allow me to criticize my
> proposal. :)
> 
> I think the layering is wrong. Putting a `protocols` item on
> `PasswordCredential` basically binds that implementation to
> `FederatedCredential` in a way that I'm not sure makes any sense.

Yes, this was a point of confusion.

> Perhaps a static method on `FederatedCredential`
> (`FederatedCredential::registerAsProvider()`?) would be better from a
> conceptual standpoint.

Or maybe two credentials should be stored at the IdP, one
PasswordCredential and one that conceptually performs the registration
as an IdP.

> 
> On Wed, Sep 2, 2015 at 10:58 PM, Dave Longley
> <dlongley@digitalbazaar.com <mailto:dlongley@digitalbazaar.com>> wrote:
> 
>     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?
> 
> 
> Yes, pretty much. I think we'll need to lock down the protocol names in
> some way (e.g. is "OpenID Connect" the same as "OpenID" and "openid" and
> "openidconnect" and etc?). Maybe an enum backed by a registry?

I don't know if enums and registries are necessary as they can make it
harder to experiment. Other specs do just fine with strings (eg:
WebCrypto uses strings for AlgorithmIdentifier names); I don't think we
need to make it any more complex than that.

> 
>     What if the protocol isn't a cross-origin type of protocol ... or does
>     this API assume that they all are?
> 
> 
> It assumes that anyone claiming to support a protocol is doing so
> cross-origin. Is there a use case for the opposite case?

I don't have a specific use case in mind, but I wasn't ruling one out,
so I didn't assume a cross-origin requirement.

> 
>     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?
> 
> 
> Isn't that what this is?

Only with the above assumption (ie: `protocol` also implies
cross-origin). But as you mentioned above, a different approach than a
"protocols" property on the base credential type is a better design.

> 
>     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 <http://rp.com>.
>     6. rp.com <http://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
>     <http://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
>     <http://rp.com>.
>     11. The UA uses Bob's IdentityCredential (with a credentials
>     property containing his selection) to fulfill rp.com
>     <http://rp.com>'s query. (The Promise returned by the
>     `navigator.credentials.get` call gets resolved to this constructed
>     IdentityCredential instance).
> 
> 
> Assuming that step 8 through 11 take place in another browsing context,
> this sounds superficially similar to what we'd need to do for
> OpenID/OAuth/Whatever.

Agreed, that's the hope anyway.

> Step 9 in particular needs to be worked out, but
> I'm quite explicitly punting that discussion to v2 in this document. :)

I'm not sure if punting here is a good idea. It certainly should be
noted in the document, somewhere, that an important part of any flow
that needs to get user input from another site will need a way to
"complete the flow" and hand control back/notify the original calling
script. My concern with punting on this is that we're missing a key
component required for extensibility that involves third party sites.

> 
>     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
> 
> That polyfill is pretty much limited to accountchooser (and is seriously
> out of date by now, sorry about that).
> 
> I think a polyfill for IdentityCredential would need to do something
> vaguely similar (iframe (or pop up a window if you need user
> interaction) a shim, and communicate with that shim via `postMessage`),
> but I don't have a ton of input about exactly how that ought to work.

Ok. I *think* I have a decent idea of how we (Credentials CG) could
build a preliminary polyfill. Now we just need some free time to magic
itself into existence. :)


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Monday, 7 September 2015 16:42:30 UTC