user verification caching etension added - to model behavior of some …

…passkey providers

index.bs

@@ -322,7 +322,7 @@ created and stored by a <em>[=[WAA]=]</em> at the behest of a <em>[=[WRP]=]</em>
 consent=]</em>. Subsequently, the [=public key credential=] can only be accessed by [=origins=] belonging to that [=[RP]=].
 This scoping is enforced jointly by <em>[=conforming User Agents=]</em> and <em>[=authenticators=]</em>.
 Additionally, privacy across [=[RPS]=] is maintained; [=[RPS]=] are not able to detect any properties, or even
-the existence, of credentials [=scoped=] to other [=[RPS]=].
+the existence, of credentials [=scoped=] to other [=[RPS]=]. 
 
 [=[RPS]=] employ the [=Web Authentication API=] during two distinct, but related, [=ceremonies=] involving a user. The first
 is [=Registration=], where a [=public key credential=] is created on an [=authenticator=], and [=scoped=] to a [=[RP]=]
@@ -365,7 +365,7 @@ Beyond that, the intended audiences for this document are the following main gro
         [[#sctn-attestation]] and [[#sctn-defined-attestation-formats]] will also be relevant.
         [[#sctn-extensions]], and [[#sctn-defined-extensions]] will be of interest if they wish to make use of extensions.
         Finally, they should read [[#sctn-security-considerations-rp]] and [[#sctn-privacy-considerations-rp]]
-        and consider which challenges apply to their application and users.
+        and consider which challenges apply to their application and users. 
 
 - User agent developers
 - OS platform developers, responsible for OS platform API design and implementation in regards to platform-specific
@@ -7580,6 +7580,68 @@ 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 Definition #### {#sctn-user-verification-cacing-extension-definition}
+
+: Extension identifier
+:: `userVerificationCaching`
+
+: Operation applicability
+:: [=authentication extension|authentication=]
+
+: Client extension input
+:: The maximum [=user verification=] caching time denotes the maximum acceptable number of seconds elapsed since the last time the user was successfully verified.
+    <xmp class="idl">
+    partial dictionary AuthenticationExtensionsClientInputs {
+      unsigned short maxUVC;
+    };
+    </xmp>
+
+: Client extension processing
+:: None, except creating the [=authenticator extension input=] from the client extension input.
+
+: Client extension output
+:: Returns a JSON object denoting the maximum acceptable number of seconds elapsed since the last time the user was successfully verified as returned by the [=authenticator=].
+    <xmp class="idl">
+    partial dictionary AuthenticationExtensionsClientOutputs {
+      unsigned short maxUVC;
+    };
+    </xmp>
+
+: Authenticator extension input
+:: The maxUVC time in seconds, encoded in CBOR.
+
+    ```
+    $$extensionInput //= (
+      maxUVC: uint .size 2
+    )
+    ```
+
+: Authenticator extension processing
+:: When user verification is requested, the [=authenticator=] triggers user verification only if more seconds have elapsed since the last time the user was verified 
+    than indicated by the maxUVC extension.
+
+: Authenticator extension output
+:: If no fresh user verification needed to be triggered triggered, the authenticator reports the maxUVC time back to the [=RP=] to ensure the [=RP=] is aware
+    that no fresh user verification was triggered.
+
+    ```
+    $$extensionOutput //= (
+      maxUVC: uint .size 2
+    )
+    ```
+
+
 # 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=].
@@ -8375,7 +8437,6 @@ or where [=client=] and [=authenticator=] do not communicate directly,
 designers SHOULD consider how this affects the enforcement of [=scope=] restrictions
 and the strength of the [=authenticator=] as a [=something you have=] authentication factor.
 
-
 ## Security considerations for [=authenticators=] <span id="sctn-attestation-security-considerations"></span> ## {#sctn-security-considerations-authenticator}
 <!-- Note: the above <span> is there to preserve the #sctn-attestation-security-considerations anchor although the section it was
 tied to has been removed. The section had no text of its own and served only to group the following two subsections together. -->
@@ -8413,6 +8474,7 @@ See also the related security consideration for [=[RPS]=] in [[#sctn-revoked-att
 
 ## Security considerations for [=[RPS]=] ## {#sctn-security-considerations-rp}
 
+
 ### Security Benefits for [WRPS] ### {#sctn-rp-benefits}
 
 The main benefits offered to [=[WRPS]=] by this specification include:
@@ -8786,6 +8848,7 @@ These recommendations serve to prevent an adversary with physical access to an [
 
 ## Privacy considerations for [=clients=] ## {#sctn-privacy-considerations-client}
 
+
 ### Registration Ceremony Privacy ### {#sctn-make-credential-privacy}
 
 In order to protect users from being identified without [=user consent|consent=], implementations of the
@@ -9189,6 +9252,22 @@ for their contributions as our W3C Team Contacts.
     "date": "June 2019"
   },
 
+  "RFC9052": {
+    "authors": ["Jim Schaad"],
+    "title": "CBOR Object Signing and Encryption (COSE): Structures and Process",
+    "href": "https://datatracker.ietf.org/doc/rfc9052/",
+    "status": "IETF Internet Standard",
+    "date": "August 2022"
+  },
+
+  "RFC9053": {
+    "authors": ["Jim Schaad"],
+    "title": "CBOR Object Signing and Encryption (COSE): Initial Algorithms",
+    "href": "https://datatracker.ietf.org/doc/rfc9053/",
+    "status": "RFC Informational",
+    "date": "August 2022"
+  },
+
   "ISOBiometricVocabulary": {
     "authors": ["ISO/IEC JTC1/SC37"],
     "title": "Information technology — Vocabulary — Biometrics",