Re: 05/24/2016 WebAuthn Summary

If we have in the main spec, an extension which baldly says 'This is about
passing data which is completely opaque to the client to the authenticator
and just passing the reply through", I as an external reader would have
this reaction:

*"Wait a minute, this means relying parties and particular models of
authenticators can set up private contracts to pass through anything via
the web browser, including stuff which violates privacy. So as an example,
we could pass through a unique identifier of the authenticator and relying
parties can use this as a way to cross correlate users."*

This is not the reaction we would want on privacy from anybody regarding
WebAuth. We should be sensitive to privacy constraints to beyond a fault.

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.

However, it is hard to see how one have a general definition which
reconciles these two seeming irreconcilables:

- The user agent should pass through extensions un-understood to
authenticator and pass back replies un-understood
- The user agent should make editorial judgements to protect user privacy.

Sam


On Fri, May 27, 2016 at 9:02 AM, Anthony Nadalin <tonynad@microsoft.com>
wrote:

> That is correct, we look forward to your contribution !
>
>
>
> *From:* Mandyam, Giridhar [mailto:mandyam@qti.qualcomm.com]
> *Sent:* Friday, May 27, 2016 8:56 AM
> *To:* public-webauthn@w3.org
> *Subject:* RE: 05/24/2016 WebAuthn Summary
>
>
>
> If that is the case, then there should be no issues with adding one more
> pre-defined extension to the spec to cover opaque data – correct?
>
>
>
> -Giri
>
>
>
> *From:* Anthony Nadalin [mailto:tonynad@microsoft.com
> <tonynad@microsoft.com>]
> *Sent:* Thursday, May 26, 2016 12:14 PM
> *To:* public-webauthn@w3.org
> *Subject:* 05/24/2016 WebAuthn Summary
>
>
>
> Since not everyone was on the call this week, I wanted to post what I
> believe the consensus was on the call regarding the “extensions” issue was
> and wanted to makes sure that we also have consensus on the list.
>
>
>
> 1.      Agreement that all extensions should be optional, and agreement
> to leave pre-defined extensions in the spec as they are currently defined.
>
> 2.      Start and IETF RFC for the creations of a IANA Registry for the
> extensions (Jeff took this action item)
>
> 3.      Add clarifying text around the extensions (Jeff took the action
> item)
>