Re: Proposal for a Trusted Location Extension

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

hm, I don't understand why one would need to design this as these two
extensions in order for the platform (UA+OS+Authnrs) to be able to apply
user preferences -- might you explain?

thx

=JeffH




>
>> 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 Thursday, 9 June 2016 15:45:11 UTC