RE: Qualcomm position- Extensions

Hello Arshad,

I have come to the conclusion that the interoperability challenge that Webauthn extensions present currently to the W3C is unprecedented, which is why I believe a waiver is appropriate.

The closest comparable situation (in my opinion) is what occurred with the Encrypted Media Extensions (EME) API, which allowed for an in-band protocol between Content Decryption Modules (external to the browser) and License Servers through the webpage.  In that specification, all messages are opaque to the browser.  In the deck I sent out, slides 7-9 provide a comparison between Webauthn and EME.  In many ways, EME presents a greater challenge for interoperability when it comes to DRM-system specific entitlement messaging.  This is why certification of DRM-system specific implementations are handled within their own ecosystems (Widevine, Playready, ATSC).

Early on in the Working Group, a decision was made not to support opaque extensions - see https://github.com/w3c/webauthn/issues/98.  As a result, all extension data may be inspected by the browser and unexpected authenticator behavior can therefore be managed.  In this regards, I believe Webauthn in its current form could be considered a step forward from EME regarding exposure of potentially identifying information from the device (which is unavoidable for DRM).

I know that you have many years of experience with extensions in the context of PKI and more specifically x.509-based infrastructure and have seen the difficulties in verifying interoperability.  Ironically, Webauthn will not escape these issues due to the entrenchment of x.509 in the acceptable attestation formats.  But by keeping the extensions as normative coupled with a widely-accepted certification scheme (FIDO), hopefully we will be able to leverage the lessons learned from PKI.

-Giri

From: Arshad Noor <arshad.noor@strongkey.com>
Sent: Wednesday, December 5, 2018 9:24 AM
To: public-webauthn@w3.org
Subject: Re: Qualcomm position- Extensions


Out of curiosity, Giri, how does the W3C deal with interoperability issues if:

  *   Extensions are optional (even if they are normative text); and
  *   The W3C Directorate issues a waiver on the specification without any confirmation/validation of interoperability of the optional extensions?

Is there some other process the W3C uses to confirm that there are interoperable implementations of extensions long after the waiver has been granted and the specification has been published?  Is this just carried over to a new version of the specification?  Something else?

Thanks.
--
[https://lh3.googleusercontent.com/kzP27HpzWiG_tv9tbccrvO3hR-gKs5gos7Xx-L7doe1hv8jTi_o3Ca0bFz4addIV9Ocadcmw0ScPNYDFfzGjFCRJd5SxQRMynMWvXxPuAeWjqZOpr5QgL5s6MqP9_whohw]<https://strongkey.com/>


Arshad Noor | CTO
S T R O N G K E Y
408.331.2000
strongkey.com<https://strongkey.com/>
Cupertino, CA


On 12/05/2018 08:16 AM, Giridhar Mandyam wrote:
Qualcomm does not recommend changing the current position of the group.  I realize the request below only sought a response if a member company wanted to change the position of the group, but I felt it was important to re-iterate Qualcomm's position.

This is consistent with the presentation I made to the W3C Directorate in October - see enclosed.  The recommendations are summarized on slide 10 and reproduced here:


  *   Continue to keep normative guidance in spec that all extensions are optional
  *   Follow Sam's suggestion to specify AAID extension as RECOMMENDED  {"Sam" = Sam Weiler}
  *   Keep all extension text as normative
  *   Overall:  as per Process 2018, request Directorate for a waiver on Implementation Experience for extensions

Note that as a previous W3C Working Group chair myself, I understand the quandaries that a feature like extensions presents when trying to follow W3C process and associated interoperability requirements.  I believe all WG member companies were aware of the challenges.  This is why I recommended that the Directorate provide a waiver of the group (which is also consistent with process).

I also think that this issue and the eventual WG decision is sufficiently substantial that it would be better if any call-for-consensus be on a company basis, not on an individual one.  Therefore I would request that "WG member" be clarified as "WG member company", so that company positions be recorded rather than individual opinions.

-Giri Mandyam, Qualcomm Advisory Committee Representative to the W3C

From: Anthony Nadalin <tonynad@microsoft.com><mailto:tonynad@microsoft.com>
Sent: Sunday, December 2, 2018 11:05 PM
To: W3C Web Authn WG <public-webauthn@w3.org><mailto:public-webauthn@w3.org>
Subject: IMPORTANT READ - Extensions

The current consensus position within the working group was to continue to push to keep the "extensions" as optional and normative, due to delays on meeting the ongoing requirements of the W3C for extensions an option was proposed at the last WG call to mark the extensions as optional and non-normative, but still publish the extensions as part of the specification. I would estimate that we would be 2-3 weeks more of discussions with the W3C staff to complete the answers they are looking for if we wanted to continue to make the extensions as optional and normative.

If WG member would like to change the current position from as optional and normative to optional and non-normative please respond to this message, or if you have other suggestions please also respond.