diff --git a/index.html b/index.html
index a84a291..300507a 100644
--- a/index.html
+++ b/index.html
@@ -62,6 +62,18 @@
           date: "2025-05-28",
           publisher: "W3C"
         },
+        "custom-schemes": {
+          title: "Concerns with custom schemes for identity presentment",
+          href: "https://github.com/w3c-fedid/digital-credentials/blob/main/custom-schemes.md",
+          authors: ["Rick Byers"],
+          date: "2024-05-01",
+          publisher: "W3C"
+        },
+        "presenting-credentials-on-the-web": {
+          title: "Presenting Credentials on the Web",
+          href: "https://docs.google.com/document/d/1Ppaz_EnhzHqPOz5UusRJvbSunh-RXPWgJ3Np_TM2EE0/",
+          authors: ["Simone Onofri"]
+        },
       },
       xref: {
         profile: "web-platform",
@@ -919,6 +931,45 @@ <h2>
         evolving privacy landscape and participate in the corresponding
         evolution of the API.
       </p>
+      <section>
+        <h3>
+          Design Considerations and Alternatives
+        </h3>
+        <p>
+          When reviewing the privacy characteristics of the Digital Credentials
+          API it is important to understand the goals of its design, which is
+          to offer a more secure and private user experience than the existing
+          alternatives.
+        </p>
+        <p>
+          As more [=verifiers=] and [=issuers=] join the rapidly emerging
+          digital credentials space, an important choice for implementation is
+          the connection between [=verifiers=] and [=holders=], i.e. the means
+          by which a [=digital credential/exchange protocol|credential exchange
+          protocol=] is initiated and the user navigates from the website
+          they're browsing to their [=holder=] application.
+        </p>
+        <p>
+          As documented in [[[presenting-credentials-on-the-web]]] and
+          [[[custom-schemes]]], QR codes and custom URL schemes solutions have
+          security, privacy, and accessibility concerns, and offer the user
+          agent very little ability to intermediate on behalf of the user (e.g.
+          in the form of a [=credential chooser=]).
+        </p>
+        <p>
+          With adoption of digital credential technology being driven by
+          consumer demand and regulatory mandates, it is essential for user
+          agents to offer an alternative to these harmful technologies that is
+          easy to use for developers, is compatible with existing credential
+          exchange protocols and, most importantly, significantly increases
+          user privacy, security, and accessibility.
+        </p>
+        <p>
+          This API does not inhibit the development of other APIs that further
+          enhance user privacy. For example, an API that more strictly enforces
+          unlinkability of age verification.
+        </p>
+      </section>
       <section data-cite="vc-data-model#spectrum-of-privacy">
         <h3>
           Spectrum of Privacy
@@ -1005,16 +1056,16 @@ <h5>
         </p>
         <p>
           Note that unlinkability is exclusively a consideration for attributes
-          that can not be linked to a specific user identity. Inherently linkable
-          attributes such as names, driver's license numbers or phone numbers do
-          not benefit from unlinkability.
+          that can not be linked to a specific user identity. Inherently
+          linkable attributes such as names, driver's license numbers or phone
+          numbers do not benefit from unlinkability.
         </p>
         <p>
-          Through the Digital Credentials API, the user agent can help verifiers
-          and wallets exchange unlinkable attributes, but it can not guarantee
-          that no linkable information is passed between verifiers and wallets.
-          It is recommended that user agents account for this fact in their
-          user permission experience.
+          Through the Digital Credentials API, the user agent can help
+          verifiers and wallets exchange unlinkable attributes, but it can not
+          guarantee that no linkable information is passed between verifiers
+          and wallets. It is recommended that user agents account for this fact
+          in their user permission experience.
         </p>
         <p class="issue" data-number="279">
           Which level of unlinkability is the goal for this API? Can we