Re: Proposal for a Trusted Location Extension

On 6/9/16, 10:54 AM, "Mandyam, Giridhar" <mandyam@qti.qualcomm.com> wrote:
> JeffH had asked..
>> 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?
>
>I can collapse the request and response into one extension, if the group
>agrees that this can be a pre-defined extension.

hm, I don't understand why collapsing the request and response into one
extension depends upon it being a pre-defined extension ?

pre-defined extensions are simply "the extensions we have cooked-up so
far"...



> This would be consistent with the transaction authorization extension
>definition (https://w3c.github.io/webauthn/#extension-txauth), which in
>my interpretation is an example of a "prompted" extension.

yes, it is a "RP-requested extension" (to coin yet another term)


> I am perfectly OK with that.  I personally don't find the text on the
>transaction confirmation so easy to ready, in that it does not clearly
>outline the sequence of steps that should occur.

issue submission and suggested prose gladly solicited :)


>My interpretation of the proposal in
>https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0049.html

>was that an extension should not be added by the authenticator without a
>corresponding request from the RP.  I took this to mean that RP must add
>an extension request to the makeCredential() method for a prompted
>extension. 

sure.

> My intention in separating the request and response was to make clear
>that the request extension must first appear in makeCredential() before
>the response extension can be added to attestation/assertion.  But maybe
>this sequence would be obvious to anyone who reads the spec.

wouldn't the RP simply add `{ "webauthn.loc": true }` to the invocation of
either makeCredential() or getAssertion(), as desired?

Also, is not the proposed webauthn.loc extension essentially the same as
the example webauthn.geo extension
<https://w3c.github.io/webauthn/#sample-extensions>?  (just curious...)


HTH,

=JeffH



>-----Original Message-----
>From: Hodges, Jeff [mailto:jeff.hodges@paypal.com]
>Sent: Thursday, June 09, 2016 8:45 AM
>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, 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 22:13:13 UTC