-
Notifications
You must be signed in to change notification settings - Fork 172
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.
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
Acceptable UV caching time affordance extension added #2021
base: main
Are you sure you want to change the base?
Changes from 6 commits
9e58208
d2ce9ce
9b431ce
9074475
c2c3deb
a45a2b6
f342836
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -7580,6 +7580,61 @@ To <dfn abstract-op>Create a new supplemental public key record</dfn>, perform t | |||||
[=set/append=] this [=supplemental public key record=] to |credentialRecord|.[$credential record/supplementalPubKeys$]. | ||||||
|
||||||
|
||||||
### User verification caching extension (<dfn>userVerificationCaching</dfn>) ### {#sctn-user-verification-caching-extension} | ||||||
|
||||||
In some cases it is good enough for the [=[RP]=] to know whether the user was verified by the authenticator "recently". | ||||||
|
||||||
This extension allows the [=[RP]=] to specify such [=user verification=] caching time, i.e. the time for which the [=user verification=] status can be "cached" by the [=authenticator=]. | ||||||
|
||||||
For example: Do not ask the user for a fresh [=user verification=] for sign-in if the user was verified by this authenticator within the past 300 seconds. | ||||||
|
||||||
: Extension identifier | ||||||
:: `userVerificationCaching` | ||||||
|
||||||
: Operation applicability | ||||||
:: [=authentication extension|authentication=] | ||||||
|
||||||
: Client extension input | ||||||
:: The maxTimeSinceLastUV denotes the maximum acceptable number of milliseconds elapsed since the last time the user was successfully verified. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we bound this with a min and max? (#2034 (comment)) |
||||||
<xmp class="idl"> | ||||||
partial dictionary AuthenticationExtensionsClientInputs { | ||||||
unsigned long long maxTimeSinceLastUV; | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This member name needs to be the same as the extension identifier.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. should There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, ...oh, I was about to say we use the same type for |
||||||
}; | ||||||
</xmp> | ||||||
|
||||||
: Client extension processing | ||||||
:: None, except creating the [=authenticator extension input=] from the client extension input. | ||||||
|
||||||
: Client extension output | ||||||
:: Returns the number of milliseconds elapsed since the last time the user was successfully verified as returned by the [=authenticator=]. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. s/verified as/verified, as |
||||||
<xmp class="idl"> | ||||||
partial dictionary AuthenticationExtensionsClientOutputs { | ||||||
unsigned long long timeSinceLastUV; | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This member name needs to be the same as the extension identifier.
Suggested change
|
||||||
}; | ||||||
</xmp> | ||||||
|
||||||
: Authenticator extension input | ||||||
:: The maximum acceptable time in milliseconds elapsed since last user verification, encoded in CBOR. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's missing here is the negative case - if this extension is not present, do not allow caching at all. This needs to be clearly stated in the spec. |
||||||
|
||||||
``` | ||||||
$$extensionInput //= ( | ||||||
mtslUV: uint .size 4 | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This member name needs to be the same as the extension identifier.
Suggested change
|
||||||
) | ||||||
``` | ||||||
|
||||||
: Authenticator extension processing | ||||||
:: When user verification is requested, the [=authenticator=] triggers user verification only if more milliseconds have elapsed since the last time the user was verified than indicated by the maxTimeSinceLastUV value in the extension. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "If more milliseconds have elapsed since the last time the user was verified than indicated by the maxTimeSinceLastUV value in the extension, request [=user verification=]." |
||||||
|
||||||
: Authenticator extension output | ||||||
:: If no fresh user verification needed to be triggered triggered, the authenticator reports the time last last user verification time back to the [=[RP]=] to ensure the [=[RP]=] is aware that no fresh user verification was triggered. It is up to the authenticator to decide whether to return the real elapsed time, or a "rounded" value. If user verification was requested, this value SHALL not exceed the value originally provided in the extension input. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is the extension output if UV is done as part of the current ceremony? I know that the UV bit should be set in authenticatorData, but should the extension output also be set with a value of 0 perhaps? The purpose of returning that is to at least indicate to the RP that the extension was acknowledge and processed. The RP could infer that UV was done, but might otherwise not have been if the maxTimeSinceLastUV had been shorter. This would differentiate it from an authenticator that doesn't support the extension and just did UV because it always does UV when There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To be clear, the suggestion here is that extension output should be set to |
||||||
|
||||||
``` | ||||||
$$extensionOutput //= ( | ||||||
tslUV: uint .size 4 | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This member name needs to be the same as the extension identifier.
Suggested change
|
||||||
) | ||||||
``` | ||||||
|
||||||
|
||||||
# User Agent Automation # {#sctn-automation} | ||||||
|
||||||
For the purposes of user agent automation and [=web application=] testing, this document defines a number of [[WebDriver]] [=extension commands=]. | ||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is where the user verification selection criteria should go IMO.
Also shouldn't this apply to both creation and authentication?
If so, suggest the following: