RE: Account -> Options; ScopedCredentialParameters

I commented on the issue. I’m wondering if the added complexity of creating such corner cases is justified in this case.

From: Alexei Czeskis [mailto:aczeskis@google.com]
Sent: Friday, September 23, 2016 1:14 PM
To: Richard Barnes <rbarnes@mozilla.com>
Cc: W3C WebAuthn WG <public-webauthn@w3.org>
Subject: Re: Account -> Options; ScopedCredentialParameters

I'll make a PR.


Thanks!
-Alexei


________________

 . Alexei Czeskis .:. Securineer .:. 317.698.4740 .

On Fri, Sep 23, 2016 at 1:01 PM, Richard Barnes <rbarnes@mozilla.com<mailto:rbarnes@mozilla.com>> wrote:
On Fri, Sep 23, 2016 at 3:42 PM, Alexei Czeskis <aczeskis@google.com<mailto:aczeskis@google.com>> wrote:
I agree wrt 'account' -- sounds like a good idea.

Want to make a PR, or do I have to clone the repo? :)  I think it should just be an IDL change; might have to shift around how we refer to the thing.

I kind of like `cryptoParameters` as a name. it forces our hand into trying to not define a rich policy language.  But `constraints` is fine too.

That's fair enough.  Let's have the conversation about what we want RPs to be able to express, and we can name the parameter to match.
--Richard



Thanks!
-Alexei


________________

 . Alexei Czeskis .:. Securineer .:. 317.698.4740<tel:317.698.4740> .

On Fri, Sep 23, 2016 at 12:30 PM, Richard Barnes <rbarnes@mozilla.com<mailto:rbarnes@mozilla.com>> wrote:
Hey folks,
I can't remember if we talked about this before.  Would it make sense to move the `account` argument to `makeCredential` into the `options` dictionary?  It seems like there are at least some credential types that don't require it (e.g., U2F credentials), and it makes the interface a bit simpler.
I also wonder whether given the discussion this week it might make sense to change the `cryptoParameters` argument to something like `constraints`, as is done in getUserMedia [1], as a general "These are the types of credential I support" field.  Might not be necessary if we don't want to allow the caller to specify anything more than we do now, but might be a way to address some of the concerns about, e.g., attestation types, that were raised this week.

Thanks,
--Richard

[1] https://www.w3.org/TR/mediacapture-streams/#constraints