Re: Account -> Options; ScopedCredentialParameters

On Fri, Sep 23, 2016 at 3:42 PM, Alexei Czeskis <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 .
>
> On Fri, Sep 23, 2016 at 12:30 PM, Richard Barnes <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
>>
>
>