Re: meta comments on Proposal for a Trusted Location Extension, rev 2

On 6/15/16, 7:32 AM, "Mandyam, Giridhar" <mandyam@qti.qualcomm.com> wrote:
>
>Enclosed is a revision of the proposed text for a verifiable location
>extension.  The proposed extension is still bi-directional (RP must
>request the extension, and the authenticator should provide the associated
> location data only when requested), but it has been collapsed into one
>extension rather than a separate one for request and one for response.

why are you characterizing this as "verifiable location" ?  are not all
returned geo coordinates "verifiable" in the sense they can be looked up
on a map?  (I haven't been following geoloc work so this is likely a noob
questions..)

also, is the format of the returned location data openly specified
somewhere? If not, then this is essentially a "propriatary" extension in
that the authnr vendor would choose the location data format (given that
it is unspec'd), and either inform the public or perhaps just
partners/customers of the format, and this format may be different than
what other authnr vendors may choose.

hence I wonder whether this proposed extension ought to be a pre-defined
extension if the returned geoloc data format is to remain unspecified.

I.e. a plausible alternative approach could be for Qualcomm to specify the
extension (either publicly or privately), and register its extension
identifer with the IANA WebAuthn Extensions Identifiers registry. (though
we'd need to alter the proposed rules for the registry to allow for
identified-but-not-publicly-available proprietary extension specs (we may
want/need to do this in any case))

HTH,

=JeffH 


>Verifiable Location Extension
>
> 
>This extension allows a WebAuthn Relying Party to request an
>authenticator to add a verifiable location as extension data to either
>the packed attestation or assertion.  [...]
>
>[...]
>
> 
>Authenticator data
>
> 
>In the case of a registration extension, when packed attesation is
>employed, the authenticator attaches location data in the form of a CBOR
>type 5 map to the packed attestation `rawData` per
><https://w3c.github.io/webauthn/#sec-raw-data-packed>.
>
>In the case of a assertion extension, the authenticator attaches location
>data in the form of a CBOR type 5 map to `authenticatorData` per
><https://w3c.github.io/webauthn/#sec-authenticator-data>.

Received on Wednesday, 15 June 2016 23:39:00 UTC