W3C home > Mailing lists > Public > public-webauthn@w3.org > May 2016

RE: 05/24/2016 WebAuthn Summary

From: Mandyam, Giridhar <mandyam@qti.qualcomm.com>
Date: Fri, 27 May 2016 16:34:04 +0000
To: Sampath Srinivas <samsrinivas@google.com>, Anthony Nadalin <tonynad@microsoft.com>
CC: "public-webauthn@w3.org" <public-webauthn@w3.org>
Message-ID: <0abeae46bc664d59ab3e565c088fddac@NASANEXM01C.na.qualcomm.com>
> 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<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)

Received on Friday, 27 May 2016 16:34:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:18 UTC