Re: 05/24/2016 WebAuthn Summary

Thinking aloud...

It seems like the key point is that the client has to have some editorial
judgment before sending an extension to the authenticator (such as, "let me
ask the user" or "this one is ok, I can send it").

It seems like it can pass the reply data through to the RP, perhaps the
most editorial the client can do there is to suppress any "volunteered"
extension information the authenticator puts in without being requested.

Actually, even for the main (non-extension) portion of the API, say an
authenticator returns a faulty signature, the client won't (and maybe even
can't) check it (coz it may no longer know the public key associated with
the signature). So it is doing a pass through here anyway.

Anyways, I'm skating here, so welcome wisdom of the wiser.

Giri, why encode the reply where only the RP can decode it? May be better
to send the location "in the clear" but signed in some way (attested
perhaps) by the authenticator. So it can be easily understood and is
transparent but also verifiable.

But this is a side topic to the main one which is:

If the client has made some editorial judgements on what extensions it will
support and what user permissions it will ask for, does it also have to
examine the reply to that extension from the authenticator in any way? Or
for that matter, *can* it even examine the reply sensibly in all cases?

Sam

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
>
>
>
> *From:* Sampath Srinivas [mailto:samsrinivas@google.com]
> *Sent:* Friday, May 27, 2016 9:28 AM
> *To:* Anthony Nadalin <tonynad@microsoft.com>
> *Cc:* Mandyam, Giridhar <mandyam@qti.qualcomm.com>; public-webauthn@w3.org
> *Subject:* 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)
>
>
>