Re: Proposal for a Trusted Location Extension, rev 2

[ technical review below. i have some meta comments I'll put in a separate
thread ]

On 6/15/16, 7:32 AM, "Mandyam, Giridhar" <mandyam@qti.qualcomm.com> wrote:
>Hello All,
>Enclosed is a revision of the proposed text for a verifiable location
>extension.  The proposed extension is still bi-directional (RP must
>request the extension, and the authenticator should provide the associated
> location data only when requested), but it has been collapsed into one
>extension rather than a separate one for request and one for response.
>
> 
>
> 
>Verifiable Location 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.  The authenticator, if it supports
>the extension and does not reject
> the request, can add location data to either a packed attestation or
>assertion.

authnrs do not reject requests containing unsupported extensions. rather,
they simply ignore them: https://w3c.github.io/webauthn/#extensions 4th
parag.


>Extension Identifier
> 
>  webauthn.loc
>
> 
>Client argument
> 
>  Null.

rather than 'null' here, i think you mean 'N/A'.  however:

actually, per the direction we are headed regarding extensions, the client
argument would be..

  `{"webauthn.loc":true}`

..(i.e., the extension identifier as key, and the JSON literal name 'true'
[1] as value.

[1] per section 3 of <https://tools.ietf.org/html/rfc7159>


> 
> Client processing
> 
>
>This extension can only be used during makeCredential() or
>getAssertion().  If the selected authenticator supports verifiable
>location, then the client MUST not prevent the extension authenticator
>data from being returned in either the
> packed attestation or assertion.

I'm not sure the latter sentence is actually necessary.

Suggested rewrite: 

  This extension may be used as a registration extension or as an
assertion 
  extension. There is no client processing other than mapping the client
  argument into an authenticator argument per "Authenticator argument",
below. 



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

could not the above be written more accurately as..

  The authenticator argument is the above client argument transformed to
  a CBOR map (major type 5) containing a single key-value pair.

  Where: the extension identifier (the key) is transformed to a CBOR text
  string (major type 3), and the the JSON literal name 'true' (the value)
  is transformed into CBOR major type 7 simple type True (results in a
  one byte encoded value of: 0xF5).



just to verify/clarify: {"webauthn.loc":true} transformed to a CBOR map
is..

  a1 6c 77 65 62 61 75 74  68 6e 2e 6c 6f 63 f5
         w  e  b  a  u  t  h  n  .  l  o  c


..which I verified with "json2cbor.rb" and http://cbor.me/ -- the latter
prints the JSON-converted-to-CBOR as..


  a1                           # map(1)
    6c                         # text(12)
      776562617574686e2e6c6f63 # "webauthn.loc"
    f5                         # primitive(21)  [i.e., 'true']




> 
>Authenticator Processing
>
> 
>The authenticator SHOULD accept or reject the extension selection, and
>provide an indication to the client.  This indication SHOULD come in the
>form of 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.

given how we have defined authnr extension processing, i don't think this
will work, nor is it necessary. there's no way for the authnr to return a
result to the client. The authnr either processes that extension and
includes the resulting data in `authenticatorData` or not. also, clients
in general do not examine the internals of the returned attestation
statement or assertion.

i.e., authnrs don't "reject" extensions, rather, they simply ignore them.

suggested rewrite..

  If the authenticator suppports this extension, it adds extension data
  to `authenticatorData` per "Authenticator data", below.


> 
>If the authenticator rejects the extension, then the authenticator SHOULD
>NOT add verifiable location authenticator data to the packed attestation
>or assertion.  If the authenticator accepts the extension, then the
>authenticator SHOULD
> only add this extension to a packed attestation or assertion.

I don't believe the above parag is needed.


> 
>Authenticator data
> 
> 
>If the authenticator accepts the extension request, then authenticator
>data
>SHOULD provide location data in the form of a CBOR-encoded type 5 map to
>be included in the packed attestation or assertion.

suggested rewrite:

In the case of a registration extension, when packed attesation is
employed, the authenticator attaches location data in the form of a CBOR
type 5 map to the packed attestation `rawData` per
<https://w3c.github.io/webauthn/#sec-raw-data-packed>.

In the case of a assertion extension, the authenticator attaches location
data in the form of a CBOR type 5 map to `authenticatorData` per
<https://w3c.github.io/webauthn/#sec-authenticator-data>.
 



end

Received on Wednesday, 15 June 2016 23:13:29 UTC