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

Re: Proposal for a Trusted Location Extension

From: Hodges, Jeff <jeff.hodges@paypal.com>
Date: Fri, 10 Jun 2016 16:48:06 +0000
To: "Mandyam, Giridhar" <mandyam@qti.qualcomm.com>
CC: W3C WebAuthn WG <public-webauthn@w3.org>
Message-ID: <D37F42CD.C4D63%jehodges@paypalcorp.com>
On 6/9/16, 3:31 PM, "Mandyam, Giridhar" <mandyam@qti.qualcomm.com> wrote:
> =JeffH wrote..
>>wouldn't the RP simply add `{ "webauthn.loc": true }` to the invocation
>>of either makeCredential() or getAssertion(), as desired?
>
>Yes that is fine. [...] 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. 

if the extension is specified that way then that's the way it's supposed
to work :)

>   Did you want me to rewrite it as one extension instead of
>request/response?

I would, sure. 


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

yeah, that's a good question -- i suspect that Rolf originally just cooked
it up as an example and no one has yet formally proposed making it, or
something like it, another 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 Friday, 10 June 2016 16:48:49 UTC

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