diff --git a/index.bs b/index.bs
index 665183e..4ac9707 100644
--- a/index.bs
+++ b/index.bs
@@ -23,6 +23,7 @@ spec:html; type:element; text:link
 spec:fetch; type:dfn; text:name
 spec:fetch; type:dfn; text:value
 spec:infra; type:dfn; text:list
+spec:permissions; type:dfn; text:feature
 </pre>
 <pre class="anchors">
 spec:payment-request; urlPrefix: https://w3c.github.io/payment-request/
@@ -123,7 +124,7 @@ spec: RFC8941; urlPrefix: https://datatracker.ietf.org/doc/html/rfc8941#
     will actually be granted the ability to use that API.</p>
   </div>
   <div class="example">
-    <p>SecureCorp Inc. restructured its domains and now needs to needs to delegate
+    <p>SecureCorp Inc. restructured its domains and now needs to delegate
     use of the Geolocation API to its origin ("<code>https://example.com</code>")
     as well as three subdomains ("<code>https://geo.example.com</code>",
     "<code>https://geo2.example.com</code>", and "<code>https://new.geo2.example.com</code>").
@@ -163,6 +164,51 @@ spec: RFC8941; urlPrefix: https://datatracker.ietf.org/doc/html/rfc8941#
     to use the Geolocation API, but any other ports on "<code>https://example.com</code>"
     could use it too.</p>
   </div>
+  <div class="example">
+    <p>JSPlaygroundCorp Inc. wants to host user-generated web applications, but wants the
+    browser to manage their permissions to use [=powerful features=] in isolation of each other.
+    This can be accomplished by creating discrete subdomains for each piece of web-content
+    or web-content creator, and navigating them as top-level documents (framework and
+    user-content can still be separated using same-origin iframes).
+
+    This is necessary since users grant permissions to the domain they perceive they
+    are interacting with in the browser, which is the top-level domain.
+
+    JSPlaygroundCorp should avoid iframing user-generated web applications using the
+    <{iframe/allow}> attribute from its own domain in this case, as this would grant
+    its domain permissions to all of them.
+  </div>
+  <div class="example">
+    <p>PlatformCorp Inc. wants to offer a marketplace of embeddable third-party
+    components to build from or games to play under its top-level domain. It wants to
+    delegate the use of [=powerful features=] like the {{MediaDevices/getUserMedia()}}
+    API responsibly. It accepts responsibility for tracking which of its component
+    applications need a feature, using bespoke "install" UX to keep end-users in
+    charge.</p>
+    <p>Camera and microphone are disabled by default in all cross-origin frames.
+    Each third-party component has a subdomain, and can be embedded in a
+    cross-origin iframe. PlatformCorp can use the <{iframe/allow}> attribute on
+    the <{iframe}> element to control whether to delegate camera or microphone
+    access or not to each subdomain.
+
+    An iframe where the component "app1" should have camera access, "app2" should
+    have microphone access, and "app3" should have both might look like this:
+    <pre>
+    &lt;iframe
+      allow="camera https://app1.site.com https://app3.site.com;
+             microphone https://app2.site.com https://app3.site.com"
+      src="https://doc1.site.com"
+      sandbox="allow-same-origin allow-scripts"&gt;
+    &lt;/iframe&gt;
+    </pre>
+    <p>Iframe attributes can selectively enable features in certain frames, and
+    not in others, even if those contain documents from the [=same origin=].
+    The list of sandbox tokens might be longer in practice.</p>
+    <p>Since browsers generally ask users to grant permissions to the top-level
+    domain, there might not be any additional permission prompt for the
+    components to request camera or microphone access if the user already
+    trusts PlatformCorp.</p>
+  </div>
 </section>
 <section>
   <h2 id="other-and-related-mechanisms">Other and related mechanisms</h2>