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

On 6/15/16, 5:50 PM, "Mandyam, Giridhar" <mandyam@qti.qualcomm.com> wrote:
> JeffH wrote:
>> 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.

hm. I'm uncertain whether I'd highlight the signing notion in naming a
{registration, authentication} extension because the extension result data
returned via the authenticator is signed as a matter of course.

I suppose I'd term it just a "geolocation extension".


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

ah, well, this is because the UVI data is essentially simply a opaque
binary blob (i.e., a bit string) uniquely associated with the biometric
template it is derived from -- i.e., it (the blob) will be provided each
time the user shows the same biometric characteristic. this could be
better explained in the UVI extension definition.


>I can certainly specify a location object to be included,

perhaps it should accomodate various formats, e.g., Position from
<https://www.w3.org/TR/geolocation-API/#position_interface> and PIDF-LO
<http://tools.ietf.org/html/rfc5491>, e.g. in say a "tag-length-value"
fashion (where the tag identifies the type of the following object, eg
Position, pdif-lo, etc.) ?

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

yes, we need to consider changing that SHOULD to a MUST.  the WebAuthn
security model is based upon underlying secure transport (c.f. S 7.3.1 of
<https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-security-ref
-v1.0-ps-20141208.html>) -- without that the webauthn is insecure, and it
seems AFAICT that requiring a secure context is the web-ish manner to
stipulate such. 

> We should have a way to allow authenticators to send sensitive data via
>encrypted payloads.

that seems to be yet another feature that /could/ be specified in the
future. in any case, there is nothing stopping an extension definition
from declaring that the emitted data is encrypted. the difficult part is
figuring out what key to use for encryption and key management and such
(there is an "easy" answer to that, ie use the authentication private key
to encrypt, however there's cryptographic considerations since that key is
primarily used for signing, etc, and IANAC (i am not a cryptographer))

HTH

=JeffH


>-----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 Friday, 17 June 2016 23:03:23 UTC