RE: Proposal for a Trusted Location Extension

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

Yes that is fine.  I don't want to get into a debate on this point and just concede.  Just as long as the sequence of events is clear - the location data cannot be added to assertion/attestation without the { "webauthn.loc": true } argument being present in the corresponding methods.    Did you want me to rewrite it as one extension instead of request/response?

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

Almost, but not quite .  (1) The extension as written in the example seems to require client data, and (2) the format of the returned CBOR object from the authenticator in what I proposed does not have to follow what is specified in the example .  In fact, the CBOR Map returned from the authenticator in what I proposed could be encrypted in addition to being signed.  This is because from the authenticator standpoint, the client is untrustworthy - for instance the client could be giving access to the Web Auth API to a webpage operating in an insecure context (see https://w3c.github.io/webauthn/#secure-contexts).  

Maybe you may have more insight as to why the example didn't become a pre-defined extension ...

-----Original Message-----
From: Hodges, Jeff [mailto:jeff.hodges@paypal.com] 
Sent: Thursday, June 09, 2016 3:13 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/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.htm

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

>> l
>>
>>..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:32:43 UTC