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

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

"Verifiable" meaning that it is signed.  The location object returned by the W3C geoloc API is not signed.  I'm not hung up on nomenclature, so feel free to suggest something different.

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

Sort of like UVI, huh?  The current text seems to place no hard requirement on the UVI format beyond "The UVI is encoded as CBOR byte string (type 0x58). "

I can certainly specify a location object to be included, but as I mentioned before there is a huge problem with sending this kind of data in the clear.  The specification only places a SHOULD requirement for secure contexts, meaning that an unauthenticated origin could potentially be provided access to the API from the user agent.  We should have a way to allow authenticators to send sensitive data via encrypted payloads.

-Giri 

-----Original Message-----
From: Hodges, Jeff [mailto:jeff.hodges@paypal.com] 
Sent: Wednesday, June 15, 2016 4:38 PM
To: Mandyam, Giridhar <mandyam@qti.qualcomm.com>
Cc: W3C WebAuthn WG <public-webauthn@w3.org>
Subject: 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 Thursday, 16 June 2016 00:50:58 UTC