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: Tue, 7 Jun 2016 22:47:33 +0000
To: "Mandyam, Giridhar" <mandyam@qti.qualcomm.com>
CC: W3C WebAuthn WG <public-webauthn@w3.org>
Message-ID: <D37C9661.C36E2%jehodges@paypalcorp.com>
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 Tuesday, 7 June 2016 22:48:03 UTC

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