chore(spec/flows): editorial changes

specification/flows/section/algorithms.html

@@ -76,7 +76,7 @@ <h4>Wallet address request</h4>
     <h3>Authorization server (AS)</h3>
     <section>
       <h4>Outgoing payment and quote grant request</h4>
-      <p>The send an outgoing payment and quote grant requests refers to the <a data-cite="opas/operations/post-continue#">Open Payments grant request</a></p>
+      <p>The send an outgoing payment and quote grant requests refers to the <a data-cite="opas/operations/post-continue#">Open Payments grant request</a>.</p>
       <div class="algorithm">
         When asked to <dfn>send an outgoing payment and quote grant request</dfn>,
         given <a>|walletAddressDetails:WalletAddressDetails|</a>, |budget:number|
@@ -374,7 +374,7 @@ <h4>Incoming payment grant request</h4>
 
     <section>
       <h4>Continue grant request</h4>
-      <p>The send a continue grant request, refers to the <a data-cite="opas/operations/post-continue#">Open Payments grant request</a></p>
+      <p>The send a continue grant request, refers to the <a data-cite="opas/operations/post-continue#">Open Payments grant request</a>.</p>
       <div class="algorithm">
         When asked to <dfn>send a continue grant request</dfn>, given |continueUri:DOMString|, |accessToken:DOMString|, perform the following steps.
         <ol>
@@ -441,7 +441,7 @@ <h4>Continue grant request</h4>
       <h4>Cancel grant request</h4>
       <p>The cancel grant request, refers to the <a data-cite="opas/operations/delete-continue#">Open Payments cancel grant request</a>.</p>
       <div class="algorithm">
-        When asked to <dfn>send a cancel grant request</dfn>, given |continueUri|, |accessToken| perform the following steps.
+        When asked to <dfn>send a cancel grant request</dfn>, given |continueUri|, |accessToken|, perform the following steps.
         <ol>
           <li>
             Let |uri| be the result of running [=URL parser=] with |continueUri|.
@@ -500,7 +500,7 @@ <h4>Cancel grant request</h4>
       <h4>Rotate access token</h4>
       <p>The rotate access token request refers to the <a data-cite="opas/operations/post-token#">Open Payments rotate access token</a>.</p>
       <div class="algorithm">
-        When asked to <dfn>send a rotate access token request</dfn>, given {{Grant}} |userWalletGrant:Grant| perform the following steps.
+        When asked to <dfn>send a rotate access token request</dfn>, given {{Grant}} |userWalletGrant:Grant|, perform the following steps.
         <ol>
           <li>
             Let |manageUrl:URL| be the result of running [=URL parser=] with
@@ -807,7 +807,7 @@ <h3>Helper algorithms</h3>
     <section>
       <h4>Fetch request</h4>
       <div class="algorithm">
-        To perform a <dfn>fetch request</dfn> given a [=request=] request and
+        To perform a <dfn>fetch request</dfn> given a [=request=] |request| and
         an algorithm |processResponseConsumeBody|, execute the following steps:
         <ol>
           <li>

specification/flows/section/authentication.html

@@ -8,7 +8,7 @@ <h2>Authentication</h2>
     (e.g. grant requests, quote creation, outgoing payment creation) MUST be signed.</p>
 
   <p>The validity of signatures is established because the user, during setup or an authorization procedure,
-    registers the [=encoded public key JWK=] with their wallet provider. The wallet provider then uses
+    registers the [=encoded public key JWK=] (JSON Web Key) with their wallet provider. The wallet provider then uses
     that public key to verify subsequent signed requests (for example, grant creation, quote requests,
     and outgoing payment creation).</p>
 
@@ -119,8 +119,8 @@ <h3>Constructing the encoded public key JWK</h3>
             <li>Set |jwk|.kid to |keyId|.</li>
           </ol>
         </li>
-        <li>Let |json:DOMString| be the UTF-8 JSON serialization of |jwk|.</li>
-        <li>Let |encodedPublicKeyJwk:DOMString| be |json| base64 encoded per [[RFC4648]].</li>
+        <li>Let |jsonJwk:DOMString| be the UTF-8 JSON serialization of |jwk|.</li>
+        <li>Let |encodedPublicKeyJwk:DOMString| be |jsonJwk| base64 encoded per [[RFC4648]].</li>
         <li>Return |encodedPublicKeyJwk|.</li>
       </ol>
     </div>
@@ -324,7 +324,7 @@ <h3>HTTP message signatures</h3>
       </ol>
 
       <aside class="example" title="Set as structured header">
-        With |headerName|=`Content-Digest`, |key|=`sha-512`, |value|=`aByteSequence`:
+        With |headerName|=`Content-Digest`, |key|=`sha-512`, |value|=:`aByteSequence`:
         <pre class="http">Content-Digest: sha-512=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:</pre>
         Note that |value| is <a data-cite="RFC9651#name-serializing-a-byte-sequence">serialized as a byte sequence</a> (base64-encoded) and wrapped between `:` (colon).
       </aside>

specification/flows/section/dictionaries.html

@@ -23,25 +23,25 @@ <h4>The `WalletAddressDetails` dictionary</h4>
             <dl>
                 <dt><dfn>`url`</dfn></dt>
                 <dd>
-                    The original URL that the wallet address information was
-                    requested at. <span class="note">Keeping a reference to this URL
+                    The original URL used to request the wallet address.
+                    <span class="note">Keeping a reference to this URL
                     is useful as users may use proxied wallet addresses.</span>
                 </dd>
 
                 <dt><dfn>`id`</dfn></dt>
                 <dd>The wallet address identifier.</dd>
 
                 <dt><dfn>`authServer`</dfn></dt>
-                <dd>corresponds to the endpoint for the [=AS=] APIs.</dd>
+                <dd>Corresponds to the endpoint for the [=AS=] APIs.</dd>
 
                 <dt><dfn>`resourceServer`</dfn></dt>
-                <dd>corresponds to the endpoint for the [=RS=] APIs.</dd>
+                <dd>Corresponds to the endpoint for the [=RS=] APIs.</dd>
 
                 <dt><dfn>`assetCode`</dfn></dt>
-                <dd>corresponds to [=asset code=].</dd>
+                <dd>Corresponds to [=asset code=].</dd>
 
                 <dt><dfn>`assetScale`</dfn></dt>
-                <dd>corresponds to [=asset scale=].</dd>
+                <dd>Corresponds to [=asset scale=].</dd>
 
                 <dt><dfn>`publicName`</dfn></dt>
                 <dd>The public name associated with the wallet address, if available.</dd>

specification/flows/section/status.html

@@ -23,7 +23,7 @@ <h2>Monetization status</h2>
     <h3>Document monetization restrictions</h3>
 
     <p>
-      <dfn data-lt="document monetization disabled">Document monetization disabled</dfn>
+      <dfn data-lt="document monetization disabled">Document monetization disabled</dfn> happens
       given a |document:Document| if either of the following conditions apply:
     </p>
 
@@ -44,7 +44,7 @@ <h3>Document monetization restrictions</h3>
     <h3>Wallet address restrictions</h3>
 
     <p>
-      <dfn data-lt="wallet monetization restricted">Wallet monetization restricted</dfn>
+      <dfn data-lt="wallet monetization restricted">Wallet monetization restricted</dfn> happens
       given a |document:Document| and a [=wallet address=] |walletAddress:DOMString|
       if the <a href="https://webmonetization.org/developers/csp-monetization-src/">`monetization-src`</a> directive
       in the [=content security policy=] of the |document| restricts the |walletAddress|'s [=origin=].

specification/flows/section/storage.html

@@ -83,7 +83,7 @@ <h3>Storage operations</h3>
             <p>To <dfn>get storage</dfn>:</p>
             <ol>
                 <li>Let |storage| be the {{Storage}} instance from secure browser storage.</li>
-                <li>If no stored storage exists, return a new {{Storage}} with all properties set to null.</li>
+                <li>If no stored {{Storage}} exists, return a new {{Storage}} with all properties set to null.</li>
                 <li>Return |storage|.</li>
             </ol>
         </div>

specification/flows/section/terms.html

@@ -17,7 +17,7 @@ <h2>Terms</h2>
 
         <dt><dfn>Grants</dfn></dt>
         <dd>
-            A delegation of authorization from a resource owner to a client, allowing the client to access protected resources or perform actions on the owner’s behalf. In Rafiki, this process is managed by the authorization server, which issues grants as access tokens. These grants permit clients to interact with Open Payments APIs to, for example, create payments and retrieve account information, based on the permissions granted by the resource owner.
+            As per GNAP, a delegation of authorization from a resource owner to a client, allowing the client to access protected resources or perform actions on the owner’s behalf. In Rafiki, this process is managed by the authorization server, which issues grants as access tokens. These grants permit clients to interact with Open Payments APIs to, for example, create payments and retrieve account information, based on the permissions granted by the resource owner.
         </dd>
         <dt><dfn>Web monetized website</dfn></dt>
         <dd>Describes a page/site that has implemented Web Monetization.</dd>
@@ -44,7 +44,7 @@ <h2>Terms</h2>
         </dd>
 
         <dt><dfn>Wallet</dfn></dt>
-        <dd>An account within the [=web monetization provider=] or [=web monetization receiver=].</dd>
+        <dd>An account within a [=web monetization provider=] or [=web monetization receiver=].</dd>
 
         <dt><dfn>Wallet address</dfn></dt>
         <dd>

specification/flows/section/wallet-setup.html

@@ -8,7 +8,7 @@ <h3>Terms</h3>
     <dt><dfn>Web Monetization page</dfn></dt>
     <dd>
       Refers to the browser's UI for managing Web Monetization settings, accessible via a browser specific URI.
-      <span class="note">In Chromium based browser the page can be located at `chrome://webmonetization`.</span>
+      <span class="note">In Chromium based browsers, the page can be located at `chrome://webmonetization`.</span>
     </dd>
     <dt><dfn data-lt="setup page">Web Monetization setup page</dfn></dt>
     <dd>
@@ -44,7 +44,7 @@ <h3>Connecting a wallet</h3>
   running the [=generate an Ed25519 key pair=] algorithm, replacing any previously stored key pair, and MUST display
   the newly generated [=encoded public key JWK=] (representing the [=Ed25519 public key=]) so the user can copy or
   upload it to their wallet provider. This key generation and public key
-  exposure happen before invoking the algorithm below; if no key pair exists at invocation time the algorithm fails.</p>
+  exposure happen before invoking the algorithm below; if no key pair exists at invocation time, the algorithm fails.</p>
 
   <p>To <b><em>process the wallet setup</em></b>, given a string |walletAddress:DOMString|
     (the [=wallet address=] provided by the user),
@@ -70,7 +70,7 @@ <h3>Connecting a wallet</h3>
       Let |interval:DOMString| be an <a href="https://en.wikipedia.org/wiki/ISO_8601#Repeating_intervals">ISO 8601 repeating interval</a>
       if |renewMonthly| is `true`.
       <span class="note">
-        The starting date for the repeating interval needs to be the users current date (ISO String).
+        The starting date for the repeating interval needs to be the user's current date (ISO String).
       </span>
       <aside class="example" title="ISO 8601 Repeating interval - monthly renewal">
         <pre class="text">

specification/index.html

@@ -582,10 +582,20 @@ <h2>
           <dfn>currency</dfn> member
         </h2>
         <p>
-          The currency of the MonetizationCurrencyAmount. See the definition of
-          the `currency` member of {{PaymentCurrencyAmount}} in
+          The currency of the MonetizationCurrencyAmount. The default is an
+          ISO 4217 three-letter alphabetic code; see the definition of the
+          `currency` member of {{PaymentCurrencyAmount}} in
           [[payment-request]] for details.
         </p>
+        <aside class="note" title="Divergence from the Payment Request API">
+          <p>
+            This member’s definition is left as a generic string to maximize
+            flexibility; for example, if a new currency representation
+            standard emerges to supplement or replace ISO 4217. This also
+            permits Web Monetization implementors to support the numeric
+            ISO 4217 codes (as string equivalents) where needed.
+          </p>
+        </aside>
       </section>
       <section>
         <h2>