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