Use case for Holder Binding

index.html

@@ -1631,6 +1631,151 @@ <h4>Threat model</h4>
           </li>
         </ul>
     </section>
+    <section>
+      <h3>Boarding an intercontinental flight — holder binding</h3>
+      <h4>Background</h4>
+      <p>
+        Anna is preparing for her Singapore Airlines flight from Paris to Singapore. To travel to Singapore, Anna needs a valid passport.
+        She has to present her boarding pass along with her passport at the gate. 
+        Anna has heard about the new option at Charles de Gaulle airport to use a digital version of her passport (eID) for boarding and decides to try it out.
+
+      </p>
+      <h4>Distinction</h4>
+      <p>
+This use case is challenging because it has to be compliant with government regulations which require a certain
+assurance that Anna is the rightful holder and subject of the presented eID.
+For this, Anna has to be authenticated as the rightful holder of the eID.
+      </p>
+      <p>
+Establishing trust that a credential is being presented by the rightful holder of that credential 
+can be approached in multiple different ways within an ecosystem. Each has advantages and
+disadvantages. We discuss two ways below.
+      <p>
+In an open wallet ecosystem, a Credential Issuer would not check the security requirements of the wallets that they issue credentials into. 
+The Holder needs to provide the Verifier with a proof that represents a Level of Assurance that the Credential has been issued with,
+as well as attestations that generate trust in the secure storage of the Credential and associated keys during their lifetime.
+      </p>
+
+      <p>
+In a Trusted Wallet ecosystem, the Verifier can trust that the Issuer has performed security checks on the wallets that they issue credentials into. 
+In this case, as the Verifier trusts the Issuer to perform Holder authentication and security checks correctly, the Verifier does not need to perform Holder authentication themselves.
+The Verifier could still be interested in the Level of Assurance associated with the credential and the methods used to establish the Level of Assurance.
+      </p>
+
+      <h4>Scenario</h4>
+
+      <p>Open Wallet ecosystem</p>
+        <p>
+Anna has downloaded a WalletApp to her mobile device and goes to get her eID issued. 
+The French government do not verify the security requirements of WalletApps before issuing credentials to them,
+but do enforce a process to provide a High Level of Assurance in the issuance of an eID. 
+Since the French government does not enforce limitations as to which wallets can receive an eID,
+Singapore Airlines can not implicitly trust that the key that an eID has been issued to has been securely stored during its lifetime.
+As such, Singapore Airlines will need to authenticate the presenting Holder as the rightful credential Holder.
+        </p>
+
+        <p>
+Anna can prove her legitimate ownership of the credential through cryptographic Holder binding, 
+where the credential contains a public key or reference to a public key that matches the private key Anna used to sign the credential. 
+It is Singapore Airlines' responsibility to validate that the public key in the credential indeed matches the credential signature. 
+Alternatively, Anna can provide a claim-based Holder binding by proving some attributes about herself with other verifiable credentials 
+that include the same claims as in her eID, such as her name, date of birth, and/or biometric-based attributes by having a 
+picture-to-person verification by an airline employee as happens with physical identity documents. 
+Additionally, Anna can provide a key attestation and an app attestation to satisfy Singapore Airlines requirements of proving securely kept Credentials and keys.
+Singapore Airlines can verify Anna’s credential and additional attestations and be sufficiently satisfied to let Anna board the airplane.
+        </p>      
+
+        <p>Trusted Wallet ecosystem</p> 
+        <p>
+Anna has downloaded a recommended WalletApp to her mobile device and goes to get her eID issued. 
+In this scenario, the French government has decided that they want to ensure that eIDs are only kept in secure wallets. 
+They can do this by requiring a key attestation and an app attestation to apply for the credential. 
+If the French government is able to properly authenticate Anna through, for example, biometrics, and is satisfied with the key 
+and app attestations the Wallet includes when she requests a credential, they can now go ahead and issue the credential to Anna’s wallet. 
+Knowing the French government’s issuance process, Singapore Airlines can trust Anna’s Verifiable Presentation of 
+an eID without validating Anna’s key and app attestations. Anna can provide the level of assurance and methods along with her Verifiable Presentation as metadata.
+        </p>
+
+      <h4>Verifiable Credentials</h4>
+        <dl class="dl-horizontal">
+          <dt>
+            Governmental eID
+          </dt>
+          <dd>
+            x
+          </dd>
+
+          <dt>
+          </dt>
+          <dd>
+          </dd>
+        </dl>
+
+      <h4>Verifiable Presentation</h4>
+        <p>
+The Verifiable Presentation presented to Singapore Airlines contains the French Governmental eID along
+with information that the digital wallet authenticated Anna, or a verifiable proof generated from the digital
+identity wallet that proves that the Governmental eID is bound to the Holder.
+        </p>
+
+        <h4>Trust Hierarchy</h4>
+        <ul>
+          <li>
+Anna is liable for her eID presentation.
+          </li>
+          <li>
+The French Government and Singapore Airlines are liable for the verification of Anna's proof of possession.
+          </li>
+          <li>
+Singapore Airlines is liable for verification of Anna's eID.
+          </li>
+        </ul>
+
+        <h4>Threat model</h4>
+        <ul>
+          <li>
+            <strong>Threat: Identity Fraud</strong> A bad actor could have somehow acquired control over an eID that is
+            not their own and
+            be holding it in a wallet they control. The bad actor could attempt to board the airplane with the stolen
+            credential.
+            <ul>
+              <li>
+                <strong>Response:</strong>Perform a biometric-based proof-of-possession. Verification of the
+                proof-of-possession will show the
+                Verifiable Credential was not originally issued to the wallet in which the bad actor is holding the 
+                credential.
+              </li>
+            </ul>
+          </li>
+          <li>
+            <strong>Threat: Exposure of private information</strong> Boarding the airplaine only requires Anna
+            to prove she holds a valid passport. The eID she uses to relay that information contains detailed private information that
+            does not need to be presented.
+            <ul>
+              <li>
+                <strong>Response:</strong> Encrypt the <a>claims</a> (once by <a>issuer</a>;
+                every <a>verifier</a> gets the same encrypted blob)
+              </li>
+              <li>
+                <strong>Response:</strong> Encrypt the <a>claims</a> uniquely for each
+                <a>verifier</a>. This may leak usage data to the <a>issuer</a>, assuming the
+                <a>holder</a> must ask for a newly encrypted <a>credential</a> for each
+                <a>verifier</a>.
+              </li>
+              <li>
+                <strong>Response:</strong> Blind the <a>claims</a> uniquely for each
+                <a>verifier</a>.
+              </li>
+              <li>
+                <strong>Response:</strong> Encrypt the <a>presentation</a> uniquely for each
+                <a>verifier</a>. No issuer involved
+              </li>
+            </ul>
+          </li>
+            </ul>
+          </li>
+        </ul>
+    </section>
   </section>
   <section>
     <!-- Editor - @halindrome -->