- From: Arshad Noor <arshad.noor@strongauth.com>
- Date: Wed, 22 Jun 2016 10:43:45 -0700
- To: public-webauthn@w3.org
- Message-ID: <576ACE51.8060604@strongauth.com>
I have made this argument at the FIDO Alliance, but it may be worth repeating here because I see danger in adding extensions to Webauthn - and I speak with nearly 2 decades of architecture, design and deployment PKI experience behind me. Webauthn will be successful only if it sticks to its knitting - which is _strong-authentication_. Extensions are a misguided attempt at embedding business logic into something that does not belong there. Factors such as geo-location, time-of-day, phase-of-moon, etc. in extensions are primarily necessary for RPs to determine whether they should *_authorize_* the user to perform transaction-X - whatever X may be: get cash, buy a widget, access a resource, etc. These are /application-specific/ and /domain-specific/ rules that should be performed by the application - not the authentication device and protocol. For Webauthn to succeed, the WG should focus only on the _authentication_ part of the protocol and eliminate all extensions, leaving it to applications/apps on however they want to validate those business rules. In case you're wondering what is the danger to adding a few extensions, I would encourage those who are not familiar with PKI to read up RFC 5280 and trace its evolution over the last 20+ years - and you'll realize why most RPs will not implement strong-authentication using digital certificates. (And RFC 5280 only deals with /standardized /extensions; take a look at actual implementations of PKI and applications that use digital certificates to see all the private extensions that are created, which break compatibility). Its not often you get a chance to fix a problem that has been around since the dawn of computing (secret-based authentication); lets learn from the industry's failures with ClientAuth over the last two decades and not repeat those mistakes. Arshad Noor StrongAuth, Inc. On 06/22/2016 09:55 AM, Mandyam, Giridhar wrote: > > Excuse me, but a form of the proposed extension is actually in the > specification already as an example – see > https://w3c.github.io/webauthn/#sample-extensions. > > I understand that Mozilla had little to no involvement in the FIDO > efforts, but I think characterizing an extension that has already been > discussed extensively as being a “general networking protocol” is > inaccurate. > > -Giri > > *From:*Richard Barnes [mailto:rbarnes@mozilla.com] > *Sent:* Wednesday, June 22, 2016 9:50 AM > *To:* Mandyam, Giridhar <mandyam@qti.qualcomm.com> > *Cc:* W3C WebAuthn WG <public-webauthn@w3.org> > *Subject:* Re: Proposal for a Location Extension, rev 3 > > <hat type="individual"/> > > > Sorry, I'm late here, and I'm going to be a little glib here because > the call is coming up. But: > > This proposal seems like a huge abuse of the API. We are building an > authentication API, not a general networking protocol. If you want a > general protocol for shuffling data to and from off-board devices, > please charter a new working group. > > Mozilla would probably formally object to such an extension. > > On Wed, Jun 22, 2016 at 12:45 PM, Mandyam, Giridhar > <mandyam@qti.qualcomm.com <mailto:mandyam@qti.qualcomm.com>> wrote: > > Thanks to Jeff H. for comments. Here is a revision. > > *_Location Extension_* > > This extension allows a WebAuthn Relying Party to request an > authenticator to add a location object as extension data to either > the packed attestation or assertion. The authenticator, if it > supports the extension, can add location data to either a packed > attestation or assertion. > > *Extension Identifier* > > webauthn.loc > > *Client argument* > > The argument {“webauthn.loc” : true} MUST be present in the > makeCredential() or getAssertion() method. > > *Client processing* > > This extension can only be used during makeCredential() or > getAssertion(). If the selected authenticator supports location > extension, then the client MUST not prevent the extension > authenticator data from being returned in either the packed > attestation or assertion. > > *Authenticator argument* > > If the authenticator supports extension selection, then the client > MUST pass the client argument encoded as a CBOR string. > > *Authenticator Processing* > > If the authenticator does not support the extension, then the > authenticator MUST ignore the extension request. If the > authenticator accepts the extension, then the authenticator SHOULD > only add this extension data to a packed attestation or assertion. > > *Authenticator data* > > If the authenticator accepts the extension request, then > authenticator data SHOULD provide location data in the form of a > CBOR-encoded type 5 map to be included in the packed attestation > or assertion. Examples of representations of the location object > that can be encoded as a CBOR type 5 map are provided in [1] and [2]. > > [1] A. Popescu, “Geolocation API Specification”, W3C Candidate > Recommendation, > https://www.w3.org/TR/geolocation-API/#position_interface > > [2] J. Peterson, RFC 4119, “A Presence-based GEOPRIV Location > Object Format”, Sec. 2.2. >
Received on Wednesday, 22 June 2016 17:45:27 UTC