RE: Proposal for a Location Extension, rev 3

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.