Re: Proposal for a Location Extension, rev 3

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