Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add User Verification (UV) bit to authenticator data #409

Merged
merged 19 commits into from Apr 24, 2017
Merged

Add User Verification (UV) bit to authenticator data #409

Show file tree
Hide file tree
Changes from 18 commits
Commits
Show all changes
19 commits
Select commit Hold shift + click to select a range
6f2f11a
Renamed timeoutSeconds to timeoutMilliseconds as specified in issue 299
AngeloKai Jan 28, 2017
0338bee
Sync with W3C master
AngeloKai Jan 28, 2017
ad4ace2
keep consistent idl format
AngeloKai Jan 28, 2017
b20d784
Merge branch 'master' into angelo-timeout
AngeloKai Feb 14, 2017
8c4d907
Change timeoutMillisecond to timeout
AngeloKai Feb 14, 2017
8d842cc
Fixed sample code due to changes to timeout
AngeloKai Feb 14, 2017
186b3d9
Merge recent update to the sample code section
AngeloKai Feb 15, 2017
1414c2f
Merged changes from master
AngeloKai Feb 15, 2017
d34178d
Add the member of back to the language in describing timeout
AngeloKai Feb 15, 2017
345b8dc
add verification gesture parameter to makeC and getA
AngeloKai Feb 15, 2017
bb4ad64
Ensure the order of parameters are consistent throughout the spec
AngeloKai Feb 15, 2017
485c430
fixed minor merge issue
AngeloKai Feb 15, 2017
6a6eafe
merged from master
Mar 18, 2017
bc857de
removed user verification from assertion option and authenticator ope…
Mar 18, 2017
5f41fac
Merge based on PR 384
AngeloKai Apr 19, 2017
5e860cd
Remove merge conflicts
AngeloKai Apr 19, 2017
9ba8f8a
Merge newly merged master
AngeloKai Apr 19, 2017
f607343
Changed TUI to UV
AngeloKai Apr 20, 2017
9fca565
Add clarifiation as Jeff requested
AngeloKai Apr 24, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
116 changes: 113 additions & 3 deletions images/fido-signature-formats-figure1.svg
View file
Open in desktop
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
4 changes: 3 additions & 1 deletion index.bs
View file
Open in desktop
Expand Up @@ -1263,6 +1263,7 @@ The [=authenticator data=] structure is a byte array of 37 bytes or more, as fol
<td>
Flags (bit 0 is the least significant bit):
- Bit 0: [=Test of User Presence=] (`TUP`) result.
- Bit 1: [=User Verification=] (`UV`) result.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @AngeloKai considering feedback and migrating this to the "user verification" terminology.

Tho, actually, in thinking about the naming of both TUP and UV bits, I would use a present or past simple statement to name the above bits 0 and 1:

  • Bit 0: User Present Flag. This flag bit is set if the [=authenticator=] obtained a positive [=Test of User Presence=] result during either an [=authenticatorMakeCredential=] or an [=authenticatorGetAssertion=] operation.
  • Bit 1: User Verified Flag. This flag bit is set if the [=authenticator=] is both capable of [=user verification=], and obtained a positive [=user verification=] result during either an [=authenticatorMakeCredential=] or an [=authenticatorGetAssertion=] operation.

- Bits 1-5: Reserved for future use (`RFU`).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/1-5/2-5/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: this needs to be updated [per @jyasskin's earlier comment] to be "Bits 2-5" !

- Bit 6: [=Attestation data=] included (`AT`). Indicates whether the authenticator added [=attestation data=].
- Bit 7: Extension data included (`ED`). Indicates if the [=authenticator data=] has extensions.
Expand Down Expand Up @@ -1294,7 +1295,8 @@ does not change between operations but instead remains the same for the lifetime
by the authenticator during the [=authenticatorGetAssertion=] operation, by verifying that the RP ID associated with the
requested credential exactly matches the RP ID supplied by the client.

The `TUP` flag SHALL be set if and only if the authenticator detected a user through an authenticator specific gesture. The
The `TUP` flag SHALL be set if and only if the authenticator detected a user through an authenticator specific gesture. The
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/TUP/UP/ ? (ie, "User Present")

Also, given the language here, we seem to be saying that if UV has been accomplished, BOTH the UP (nee 'TUP') and UV flags would be set, yes?

I.e., UP is set if the authenticator is able to confirm user presence in any fashion, and UV is also set if that fashion is one able to verify that it is the "same user" as in prior interactions (e.g., credential creation).

Yes?

If so, this language ought to be polished appropriately (in both the above and below lines).

BTW, this is the way the FIDO User Verification Methods flags work -- USER_VERIFY_PRESENCE is always set, and then other flags MAY be set in order to signal finer-grained attributes of the interaction, see: https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fido-registry-v1.1-id-20170202.html#user-verification-methods

`UV` flag SHALL be set if and only if the [=user verification=] process has been performed by the authenticator. The
`RFU` bits in the flags byte SHALL be set to zero.

For attestation signatures, the authenticator MUST set the AT flag and include the [=attestation data=]. For authentication
Expand Down