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

RE: regarding "opaque pass-thru extensions"

From: Mandyam, Giridhar <mandyam@qti.qualcomm.com>
Date: Wed, 25 May 2016 02:43:56 +0000
To: W3C WebAuthn WG <public-webauthn@w3.org>
Message-ID: <ff1dc0e820a649b2970ce135e80a2329@NASANEXM01C.na.qualcomm.com>
Hi Jeff,

a) The text as provided in your email below seems to allow for such an extension, but the issue was a request for a pre-defined extension type (https://w3c.github.io/webauthn/#extension-standard).  If there was agreement, I would've created a PR to define this extension.  

b) As per https://w3c.github.io/webauthn/#extensions:

"For extensions that the client platform does not support, it passes the request parameters on to the authenticator when possible (criteria defined below). This allows one to define extensions that affect the authenticator only."
...
"All WebAuthn extensions are optional for both clients and authenticators. Thus, any extensions requested by a WebAuthn Relying Party may be ignored by the client browser or OS and not passed to the authenticator at all, or they may be ignored by the authenticator. Ignoring an extension is never considered a failure in the WebAuthn API, so when WebAuthn Relying Parties include extensions with any API calls, they must be prepared to handle cases where some or all of those extensions are ignored."

The paragraph you have cited below only refers to platform processing, which I assume to encompass the native OS.  The text I cite above seems to clearly allow a user agent to drop extensions for any reason.  There is not even a "SHOULD" level requirement for the browser to pass unknown extension data to the authenticator.  Ideally, my organization would like to see opaque data passed forward to the authenticator from the client but I believe the text above places no such obligation on browser vendors.

Ideally the spec language would look like what is in the FIDO UAF Protocol Specification Version 1.0 "The FIDO UAF Client might (a) process an extension or (b) pass the extension through to the ASM. Unknown extensions must be passed through.".  

-Giri

-----Original Message-----
From: jeff.hodges@kingsmountain.com [mailto:jeff.hodges@kingsmountain.com] 
Sent: Tuesday, May 24, 2016 6:38 PM
To: Mandyam, Giridhar <mandyam@qti.qualcomm.com>; Vijay Bharadwaj <vijaybh@microsoft.com>
Cc: W3C WebAuthn WG <public-webauthn@w3.org>
Subject: regarding "opaque pass-thru extensions"


[ please disregard (and delete) prior empty msg with the same subject line as this msg, sorry, thx ]

For sake of discussion, let's call the sort of extension you Giri mention in..

   https://github.com/w3c/webauthn/issues/98


.."opaque pass-thru extensions".

The text of the #98 is..

   An RP may send opaque data to an authenticator via an extension
   that requires no client processing. This should be a pre-registered
   extension type and would be passed directly to the authenticator from
   the client.

I assume by "pre-registered" you mean "pre-defined".  In any case, I note in reading the spec - https://w3c.github.io/webauthn/ - that the above use case seems to be presently addressed per the present editors' copy of the spec...

   https://github.com/w3c/webauthn/issues/98#issuecomment-221449654


   Does this last paragraph of the current section 5 {#extension-request-parameters} address this use case?

   "For extensions that specify additional authenticator processing only, it
   is desirable that the platform need not know the extension. To
   support this, platforms SHOULD pass the client argument of unknown
   extension as the
   authenticator argument unchanged, under the same extension identifier. The
   authenticator argument should be the CBOR encoding of the client argument, as
   specified in Section 4.2 of [RFC7049]. Clients SHOULD silently drop unknown
   extensions whose client argument cannot be encoded as a CBOR structure."


HTH,

=JeffH


Received on Wednesday, 25 May 2016 02:44:29 UTC

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