Re: 05/24/2016 WebAuthn Summary

I think it would be OK, but --

My position to implementers is that extension data *should* be marked as
what it actually is: That empowers the user agent and the user to make an
informed decision, even if the user agent chooses not to, or cannot process
the extension data itself.

I'm imagining an authenticator that records audio and attaches it in the
opaque extension. There may be reasonable purposes to include audio in a
WebAuthn attestation: perhaps ensuring the user is not under duress, or
explicitly capture an extra voiceprint. But the user should know it's
there, and assent to its use.

It's common today for banks to give away branded attestation tokens; I
imagine getting one that is specially branded for my bank. I don't know the
hardware specifications on it as I wasn't the equipment purchaser.  Perhaps
this token, when plugged in, starts recording audio secretly, with no
indications that it's obtaining a voiceprint. I see the user agent's
responsibility here as to inform the user and obtain consent.

If it's a totally opaque extension, the user agent's consent request would
then be something generic and cautionary, perhaps: "Would you like to share
your authenticator's full capabilities with this webpage? It could
compromise your privacy, send its movement history, photos, video, audio,
or anything else."

The RP would always retain the authority to reject attestations that don't
contain the extensions they're looking for.

More transparency as to what's included could promote better user
experiences, with fewer consent clicks. That said, as long as there exists
an extension ecosystem, this balance should happen outside the scope of the
WG.

J.C.



On Fri, May 27, 2016 at 9:34 AM, Mandyam, Giridhar <mandyam@qti.qualcomm.com
> wrote:

> > If the extension you want, Giri, can be worded specifically such as
> "request for location, the web browser will ask the user for permission and
> then pass on to authenticator" (I believe this was one of your intents)
> that's cool.
>
>
>
> To clarify for this example, if the location data created by the
> authenticator is encoded in such a way that only the RP can decode it (not
> necessarily the UA) – then this would be OK?
>
>
>
> -Giri
>
>
>