W3C home > Mailing lists > Public > public-webauthn@w3.org > June 2016

RE: Proposal for a Trusted Location Extension

From: Mandyam, Giridhar <mandyam@qti.qualcomm.com>
Date: Wed, 8 Jun 2016 00:26:07 +0000
To: "Hodges, Jeff" <jeff.hodges@paypal.com>
CC: W3C WebAuthn WG <public-webauthn@w3.org>
Message-ID: <32409131cf1e47fea90c2fcaed337044@NASANEXM01C.na.qualcomm.com>
Thanks for the feedback.

>does this replace the proposed "Opaque data" extension in https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0001.html ..or is it in addition to the above?

Consider it an addition.  I am still trying to work on an opaque data extension that can satisfy some of the (valid) concerns raised regarding user privacy.  

> So this is actually two extensions, where the first allows an RP to determine whether an authnr supports the second extension, yes?

Yes.  I wrote it this way in order to indicate at which point the client could filter out any request from the RP that was not consistent with user privacy preferences.  I personally am not convinced that browsers implementing the Web Auth API will actually query permissions from the user on a per-extension basis, but this extension was designed to enable such fine-grained permission management.

> Actually, I believe (IIUC) you can define this as a single extension -- the RP would simply request it, the indication of such a request would be sent down to the authnr by the UA+OS (if the UA+OS deigns to honor this extension request), and if the authnr supports it, the authnr includes the resultant extension data in its emitted `authenticatorData`. If the authnr does not support the extension, it ignores the authnr argument requesting it. The RP can tell whether the extension was honored by examining the returned attestation object or webauthn assertion.

Agreed.  I can revise accordingly if the group agrees to adopt.  

-----Original Message-----
From: Hodges, Jeff [mailto:jeff.hodges@paypal.com] 
Sent: Tuesday, June 07, 2016 3:48 PM
To: Mandyam, Giridhar <mandyam@qti.qualcomm.com>
Cc: W3C WebAuthn WG <public-webauthn@w3.org>
Subject: Re: Proposal for a Trusted Location Extension

On 6/7/16, 1:40 PM, "Mandyam, Giridhar" <mandyam@qti.qualcomm.com> wrote:
>Hello All,
>Enclosed is proposed text for a verifiable location extension.  Note 
>that this is bi-directional ­ the RP must request the extension, and 
>the authenticator should provide the associated location data only when  
>requested (i.e. it is not ³unprompted² data). I can discuss this on the 
>next conf. call on June 8.

does this replace the proposed "Opaque data" extension in..

  https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0001.html

..or is it in addition to the above?

So this is actually two extensions, where the first allows an RP to determine whether an authnr supports the second extension, yes?

Actually, I believe (IIUC) you can define this as a single extension -- the RP would simply request it, the indication of such a request would be sent down to the authnr by the UA+OS (if the UA+OS deigns to honor this extension request), and if the authnr supports it, the authnr includes the resultant extension data in its emitted `authenticatorData`. If the authnr does not support the extension, it ignores the authnr argument requesting it. The RP can tell whether the extension was honored by examining the returned attestation object or webauthn assertion.

Does that make sense?

HTH,

=JeffH


> 
>Verifiable Location Request 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.
>
> 
>Extension Identifier
>
> 
>  webauthn.loc-request
>
> 
>Client argument
>
> 
>  Null
>
> 
>Client processing
>
> 
>  This extension can only be used during makeCredential().  If the 
>selected authenticator supports verifiable location, then the client 
>MUST not prevent the extension from being returned in either the packed 
>attestation or assertion.
>
> 
>Authenticator argument
>
> 
>  If the authenticator supports extension selection AND supports the 
>verifiable location, then the client MUST pass as an argument the 
>extension identifier encoded as a CBOR text string.
>
> 
>Authenticator Processing
> 
> 
>  The authenticator SHOULD accept or reject the extension selection, 
>and provide an indication to the client.  If the authenticator rejects 
>the extension, then the authenticator SHOULD NOT add verifiable 
>location to the packed attestation  or assertion.
>
> 
>Authenticator data
>
> 
>  The authenticator SHOULD provide an indication of acceptance or 
>rejection with a CBOR encoded integer value of Œ1¹ (indicating 
>acceptance of the requested extension) or Œ0¹ (indicating rejection).  
>Any returned values other than Œ1¹ or  Œ0¹ would constitute rejection.





> 
>Verifiable Location Extension
> 
> 
>  This extension allows an authenticator to add a verifiable location 
>as extension data to either the packed attestation or assertion.
>
> 
>Extension Identifier
> 
> 
>  webauthn.loc
> 
> 
>Client argument
> 
> 
>  No client argument required.
> 
> 
>Client processing
> 
> 
>  No client processing required.
> 
> 
>Authenticator argument
> 
> 
>  No authenticator argument required.
> 
> 
>Authenticator Processing
> 
> 
>  The authenticator SHOULD only add this extension to a packed 
>attestation or assertion if the relying party has requested it via the 
>webauthn.loc-request extension.
> 
> 
>Authenticator data
> 
> 
>  The authenticator data SHOULD be a CBOR-encoded type 5 map.
> 
> 
> 
>
>
>
Received on Wednesday, 8 June 2016 00:26:40 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:21 UTC