RE: 05/24/2016 WebAuthn Summary

> 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.


a)      Encoding does not necessarily have to mean encryption.  It could be that the authenticator is producing a compact form of the location object that is understood by the RP but not necessarily laid out in the specification itself.

b)      The spec requires secure context for API access, but there is no guarantee that the TLS connection is not vulnerable to MITM (e.g. no token binding).  A hostile party could be eavesdropping on the location data being sent by the client.

> 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?

Given that all extensions are optional for the client, it seems that this would be a decision that each browser vendor must make on their own independent of the specification.  I personally don’t think we need to answer these questions for the specification to go forward.  But I look forward to other responses.

-Giri

From: Sampath Srinivas [mailto:samsrinivas@google.com]
Sent: Friday, May 27, 2016 9:47 AM
To: Mandyam, Giridhar <mandyam@qti.qualcomm.com>
Cc: Anthony Nadalin <tonynad@microsoft.com>; public-webauthn@w3.org
Subject: 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<mailto: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<mailto:samsrinivas@google.com>]
Sent: Friday, May 27, 2016 9:28 AM
To: Anthony Nadalin <tonynad@microsoft.com<mailto:tonynad@microsoft.com>>
Cc: Mandyam, Giridhar <mandyam@qti.qualcomm.com<mailto:mandyam@qti.qualcomm.com>>; public-webauthn@w3.org<mailto: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<mailto:tonynad@microsoft.com>> wrote:
That is correct, we look forward to your contribution !

From: Mandyam, Giridhar [mailto:mandyam@qti.qualcomm.com<mailto:mandyam@qti.qualcomm.com>]
Sent: Friday, May 27, 2016 8:56 AM
To: public-webauthn@w3.org<mailto: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]
Sent: Thursday, May 26, 2016 12:14 PM
To: public-webauthn@w3.org<mailto: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)