diff --git a/index.html b/index.html index 4b271d9f..8c43a7e8 100644 --- a/index.html +++ b/index.html @@ -143,14 +143,14 @@

  • Require [=transient activation=] to perform [=digital credential/presentation requests=] or [=digital credential/issuance requests=], ensuring that sites cannot silently query for nor issue - digital credentials, nor communicate with wallet providers, without the - user's active participation and confirmation of each action. + digital credentials, nor communicate with [=wallet=] providers, without + the user's active participation and confirmation of each action.
  • Enable platform-provided credential selection UX when multiple wallet applications have credentials that match a [=digital credential/presentation request=].
    • -
  • Enable platform-provided wallet selection UX when multiple wallet +
  • Enable platform-provided [=wallet=] selection UX when multiple wallet applications support an [=digital credential/issuance request=].
  • Enable platforms to provide secure cross-device [=digital @@ -427,9 +427,9 @@

    permission to forward a request to the user-selected wallet.

  • Implementation of credential managers, specifically in the role of - [=holder=] software (commonly known as "digital wallets"), including how - they securely store or manage [=digital credentials=] or advertise - capabilities to [=digital credential/presentation|present=] or [=digital + [=digital wallets=], including how they securely store or manage + [=digital credentials=] or advertise capabilities to [=digital + credential/presentation|present=] or [=digital credential/issuance|issue=] them to the [=user agent=], is out of scope. The only exception is the transmission of [=digital credential/issuance request data=] and [=digital credential/request data|credential request @@ -481,8 +481,8 @@

    "presentation response">Presentation response
    - A format that a [=holder's=] software, such as a digital wallet, uses, - via an [=digital credential/exchange protocol=], to respond to a + A format that a [=holder's=] software, such as a [=digital wallet=], + uses, via an [=digital credential/exchange protocol=], to respond to a [=digital credential/presentation request=] by a [=verifier=].
    @@ -552,6 +552,28 @@

    See [=credential request coordinator=].
    +
    + Digital Wallet +
    +
    +

    + A [=credential manager=] (software or hardware) used by a [=holder=] + to [=digital credential/issuance|receive=], [=credential + store|store=], manage, and [=digital + credential/presentation|present=] [=digital credentials=]. A digital + wallet orchestrates [=digital credential/issuance=] and [=digital + credential/presentation=] flows, such as [=credential + chooser|choosing=] which credential to present in response to a + [=digital credential/credential request=], and mediating the user's + decision to share credentials with a [=verifier=]. +

    + +
    @@ -570,7 +592,7 @@

    A user agent MAY delegate some or all coordinator responsibilities to - external wallet applications, platform components, or other trusted + external [=wallet=] applications, platform components, or other trusted entities according to user or platform policy.

    @@ -739,7 +761,7 @@

    The requests specify an [=digital credential/exchange protocol=] and [=digital credential/request data=], which the user agent MAY match against a - holder's software, such as a digital wallet. + holder's software, such as a [=digital wallet=].

    @@ -751,7 +773,7 @@

    credential/presentation request=]. It is used to specify an [=digital credential/exchange protocol=] and some [=digital credential/request data=], which the user agent MAY match against software used by a holder, - such as a digital wallet. + such as a [=digital wallet=]. 

           dictionary DigitalCredentialGetRequest {
@@ -1390,7 +1412,7 @@ 
    
         
    
         
    
           Explain that authentication (such as a PIN code to unlock) to a
-          particular app, such as a digital wallet, that responds to an API
+          particular app, such as a [=digital wallet=], that responds to an API
           request is crucial in high-risk use cases.
         
    
       
@@ -1610,9 +1632,9 @@ 
    
           presentations to conclude they concern the same user
           (verifier-verifier linkability), or that [=verifiers=] cannot collude
           with [=issuers=] to report the exchange of a credential from a
-          digital wallet to the [=issuer=] (verifier-issuer linkability). The
-          former is a property that can be maintained by the [=holder=] and
-          [=issuer=], e.g. through issuing fresh credentials for individual
+          [=digital wallet=] to the [=issuer=] (verifier-issuer linkability).
+          The former is a property that can be maintained by the [=holder=] and
+          [=issuer=], e.g., through issuing fresh credentials for individual
           [=verifiers=].
         
    
         
    
@@ -1631,7 +1653,7 @@ 
    
         
    
         
    
           Through the Digital Credentials API, the [=user agent=] can help
-          [=verifiers=] and digital wallets exchange unlinkable attributes,
+          [=verifiers=] and [=digital wallets=] exchange unlinkable attributes,
           but, because of response encryption, it cannot guarantee that no
           linkable information is passed between [=verifiers=] and digital
           wallets. It is recommended that [=user agents=] account for this fact
@@ -1657,19 +1679,19 @@ 
    
           ensure that an [=issuer=] isn't actively involved in the creation or
           validation of credential presentations after a user has given
           permission to proceed with a credential request. From that point on,
-          the digital wallet application owns this decision. While some digital
-          wallets can be considered [=user agents=], it is generally
+          the [=digital wallet=] application owns this decision. While some
+          [=digital wallets=] can be considered [=user agents=], it is generally
           recommended that the [=user agent=] implementing the Digital
           Credentials API designs its permission experience to prevent exposure of a request to the
-          digital wallet application before user confirmation (keeping in
-          mind considerations for integrating
-          multiple cooperating user agents).
+          [=digital wallet=] application before user confirmation (keeping
+          in mind considerations for
+          integrating multiple cooperating user agents).
         
    
         
    
           Protocols are required to support mechanisms that allow [=issuers=],
-          digital wallets, and [=verifiers=] to avoid or reduce the dependence
-          on "phone home" mechanisms.
+          [=digital wallets=], and [=verifiers=] to avoid or reduce any
+          dependence on "phone home" mechanisms.
         
    
         
    
           Which level of unlinkability is the goal for this API? To what degree
@@ -1796,7 +1818,7 @@

  • [=issuers=] and lawmakers might decide to restrict use of (particularly government-issued) credentials to specific - [=verifiers=] with purpose attestations. Digital wallets might be + [=verifiers=] with purpose attestations. [=Digital wallets=] might be expected to enforce these restrictions by law or policy.
  • The ultimate decision of whether or not to share their personal @@ -2018,7 +2040,7 @@
    "#multiple-user-agents">different user agents to apply appropriate levels of friction and transparency. For example, a browser might delegate knowledge about credential requests to the - operating system, which might require digital wallets to register + operating system, which might require [=digital wallets=] to register known credential types and reject an exchange request for an unknown credential type.

    @@ -2080,7 +2102,7 @@

    To ensure authenticity of a credential, its presentation to [=verifiers=] generally includes more information than the content the [=verifier=] is requesting access to. It will usually contain at - least a signature of the [=issuer=] and the digital wallet, and + least a signature of the [=issuer=] and the [=digital wallet=], and potentially other metadata.

    @@ -2105,9 +2127,9 @@

    through {{DigitalCredential/userAgentAllowsProtocol()}}. It mitigates browser fingerprinting and revealing information about the user's device configuration by not customizing its response based on, for - example, which digital wallet applications are installed on a user's - device. The returned information is thus, at best, equivalent to a - [=user agent=] version. + example, which [=digital wallet=] applications are installed on a + user's device. The returned information is thus, at best, equivalent + to a [=user agent=] version.

    Avoiding leaks of credential availability @@ -2158,7 +2180,7 @@

  • Whether presenting this information will enable tracking.
    • -
  • Which digital wallets can be used to fulfill the credential +
  • Which [=digital wallets=] can be used to fulfill the credential request.
  • Which credential would be used to share the requested @@ -2212,10 +2234,11 @@

    As part of the user permission flow, the [=user agent=] needs to ensure that users retain the power to choose whether to forward a - credential request to a digital wallet, and which digital wallet to - select. This is due to the information disclosure that happens as - part of the request, and the ability of digital wallets to retain or - share this information at the time of the request. + credential request to a [=digital wallet=], and which [=digital + wallet=] to select. This is due to the information disclosure that + happens as part of the request, and the ability of [=digital + wallets=] to retain or share this information at the time of the + request.

    Permission vs. Consent @@ -2224,8 +2247,8 @@

    The permission mediated by the [=user agent=] is not consent, which has specific legal definitions that can vary among different legal and regulatory environments and may need to be collected by the - digital wallet before sharing information with the [=verifier=], or - by the [=verifier=] itself before initiating the request. With + [=digital wallet=] before sharing information with the [=verifier=], + or by the [=verifier=] itself before initiating the request. With frameworks and regulations for obtaining consent still being developed, this API aims to enable the exchange of the necessary information, which could include the following: