Re: Proposal for a Location Extension, rev 3

On Wed, Jun 22, 2016 at 12:55 PM, Mandyam, Giridhar <
mandyam@qti.qualcomm.com> 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.
>

Of course, examples are explicitly non-normative.



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

Like I said, I acknowledge that I'm late.  Sorry, I was on vacation for a
few weeks :)  Also, to be honest, I don't really count anything in FIDO as
"discussed extensively", since that's a closed forum.

I do have a general concern about abuse of this extension mechanism, and to
some degree I'm just catching on this as an example.  I guess we can
discuss on the call why you think this is not an issue.

--Richard



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