trying to make it prettier

docs/astro.config.mjs

@@ -40,8 +40,11 @@ export default defineConfig({
           items: [
             { label: 'Overview', link: '/introduction/overview/' },
             { label: 'Authorization', link: '/introduction/authorization/' },
-            { label: 'Wallet addresses', link: '/introduction/wallet-addresses/' },
-            { label: 'Open Payments flow', link: '/introduction/op-flow/' },
+            {
+              label: 'Wallet addresses',
+              link: '/introduction/wallet-addresses/'
+            },
+            { label: 'Open Payments flow', link: '/introduction/op-flow/' }
           ]
         },
         {

docs/src/content/docs/introduction/authorization.mdx

@@ -9,11 +9,12 @@ title: Authorization
 Existing content mostly covered in overview; expand on GNAP on this page
 
 ## Request Authentication
+
 [Client keys and request signatures]
 
 <hr />
 
-#### Existing content starts here 
+#### Existing content starts here
 
 Security of client requests follows a profile of the mechanisms defined in the GNAP specification.
 
@@ -36,11 +37,11 @@ Request Signatures
 
 The integrity of all requests is protected by a signature, generated according to the HTTP Signatures specification
 
-#### Existing content stops here 
+#### Existing content stops here
 
 <hr />
 
-## Requesting Access Grants 
+## Requesting Access Grants
 
 [Initiating a GNAP interaction with the AS]
 

docs/src/content/docs/introduction/op-flow.mdx

@@ -2,4 +2,4 @@
 title: Open Payments flow
 ---
 
-<mark>TO DO</mark>
+<mark>TO DO</mark>

docs/src/content/docs/introduction/overview.mdx

@@ -10,45 +10,50 @@ For example, an application developer can build payments functionality into thei
 
 ## Payments
 
-Open Payments does not execute payments or touch funds in any way. Instead, its APIs allow clients to issue payment instructions to ASEs. 
+Open Payments does not execute payments or touch funds in any way. Instead, its APIs allow clients to issue payment instructions to ASEs.
 
-For example, a client can instruct an ASE to send a payment of $20.00 USD from its mutual customer’s account to another OP-enabled account at a different ASE. The sending ASE is responsible for executing and settling the payment with the receiving ASE outside of Open Payments. The ability to execute payments between OP-enabled ASEs is predicated on the availability of a common payment rail between the ASEs. 
+For example, a client can instruct an ASE to send a payment of $20.00 USD from its mutual customer’s account to another OP-enabled account at a different ASE. The sending ASE is responsible for executing and settling the payment with the receiving ASE outside of Open Payments. The ability to execute payments between OP-enabled ASEs is predicated on the availability of a common payment rail between the ASEs.
 
-By separating payment instructions from execution/settlement, clients can include payment functionality within their feature sets without, for example, also registering as a licensed money transfer business. 
+By separating payment instructions from execution/settlement, clients can include payment functionality within their feature sets without, for example, also registering as a licensed money transfer business.
 
-<p><mark>Link to secondary page, if applicable</mark></p>
+<p>
+  <mark>Link to secondary page, if applicable</mark>
+</p>
 
 ## Authorization
 
 Part of issuing payment instructions includes requesting and obtaining authorization. The correct levels of authorization must be granted to clients and ASEs for a set of payment instructions to be acted upon. Open Payments leverages the Grant Negotiation and Authorization Protocol (GNAP) to define a standard mechanism by which clients get authorization (via access tokens) to use the Open Payments APIs and retrieve data about an account holder.
 
 Grants give clients the authorization to perform one or more operations. GNAP makes it possible to give account holders specific and fine-grained control over the permissions they grant to the clients that connect to their accounts, including control over the amounts of transactions with time-based and velocity-based limits. This enables powerful use cases such as third-party payment initiation and delegated authorization without compromising the security of the underlying financial accounts and payment instruments.
 
-<p><mark>Link to secondary page, if applicable</mark></p>
+<p>
+  <mark>Link to secondary page, if applicable</mark>
+</p>
 
 ## Roles
 
 GNAP clearly separates the roles of authorization server and resource server.
 
-Access tokens are requested from the **authorization server**. The APIs implemented by the authorization server are a profile of GNAP and are defined in our documentation. 
+Access tokens are requested from the **authorization server**. The APIs implemented by the authorization server are a profile of GNAP and are defined in our documentation.
 
 Access is granted to the **resource server**, where operations are performed. In Open Payments, the ASE is the resource server and the OP-enabled account is the primary resource. APIs implemented by the resource server are defined by the Open Payments API specification. An open-source implementation of an Open Payments resource server, called Rafiki, is currently in development.
 
-The entity accessing either server is the client. An example of a client is a third-party application. 
+The entity accessing either server is the client. An example of a client is a third-party application.
 
-<p><mark>Link to secondary page, if applicable</mark></p>
+<p>
+  <mark>Link to secondary page, if applicable</mark>
+</p>
 
 ## Open Payments account identification
 
 Every OP-enabled account is identified by one or more URLs. These URLs not only identify the account, but are also OP service endpoints that provide the entry point for the APIs. These URLs are called [wallet addresses](/introduction/wallet-addresses) within the context of Open Payments.
 
 ## Open Banking
 
-Open Payments attempts to improve upon existing Open Banking standards as defined in the UK, EU, and other jurisdictions. 
+Open Payments attempts to improve upon existing Open Banking standards as defined in the UK, EU, and other jurisdictions.
 
-Existing Open Banking ecosystems are dominated by aggregators and intermediaries, making it impossible for independent third-parties, such as small merchants, to use payment initiation APIs directly against their customers’ payment accounts. 
+Existing Open Banking ecosystems are dominated by aggregators and intermediaries, making it impossible for independent third-parties, such as small merchants, to use payment initiation APIs directly against their customers’ payment accounts.
 
 The goal of Open Payments is to define a standard that is adopted by all ASEs, creating an application layer for the Internet of Value, allowing applications to integrate payments directly into their products without requiring users to create new accounts for every application.
 
 Open Payments allows for scenarios where clients can dynamically register and engage with the APIs without needing to pre-register with an ASE, resulting in a truly distributed and federated payment ecosystem with global reach and no dependencies on any particular underlying payment account type or settlement system. Open Payments is also a significantly less complicated standard with a small number of resource types and a simpler, yet more powerful, authorization protocol.
-

docs/src/content/docs/introduction/wallet-addresses.mdx

@@ -5,9 +5,10 @@ title: Wallet addresses
 At the heart of all interactions in Open Payments (OP) is an OP-enabled account. Every OP-enabled account is identified by one or more URLs. These URLs are not only account identifiers, but also service endpoints for gaining access to the OP APIs. These URLs are called **wallet addresses**. Not all URLs are wallet addresses, but all wallet addresses are URLs.
 
 A URL is only a wallet address if the:
-* Server handling the HTTP requests to the URL supports the OP protocol
-* URL dereferences a resource defined by the OP APIs, where resource equals client, OP-enabled account, incoming payment, or outgoing payment
-* URL uses the `https` protocol and has no `user-info`, `port`, `query string`, or `fragment` parts
+
+- Server handling the HTTP requests to the URL supports the OP protocol
+- URL dereferences a resource defined by the OP APIs, where resource equals client, OP-enabled account, incoming payment, or outgoing payment
+- URL uses the `https` protocol and has no `user-info`, `port`, `query string`, or `fragment` parts
 
 The quickest way to test if a URL is a wallet address is to make an HTTP `GET` request to the URL with an `Accept` header value of `application/json`.
 
@@ -34,11 +35,11 @@ Content-Type: application/json
 
 ## Privacy and security
 
-A wallet address acts as a proxy identifier (alias) for an underlying financial account. If permitted by an account servicing entity (ASE), a single account can have multiple wallet addresses. Allowing account holders to generate unique wallet addresses for every client they interact with can help prevent a single address from becoming a tracking vector. 
+A wallet address acts as a proxy identifier (alias) for an underlying financial account. If permitted by an account servicing entity (ASE), a single account can have multiple wallet addresses. Allowing account holders to generate unique wallet addresses for every client they interact with can help prevent a single address from becoming a tracking vector.
 
-In addition to the one account-to-one wallet address and one account-to-multiple wallet addresses models, an ASE could allow a single wallet address to represent all of a user’s accounts. For example, imagine a user has three accounts with a digital wallet provider. The provider issues the user a single wallet address. When a payment is sent to the wallet address, the provider determines which one of the three accounts should receive the payment based on any number of criteria. 
+In addition to the one account-to-one wallet address and one account-to-multiple wallet addresses models, an ASE could allow a single wallet address to represent all of a user’s accounts. For example, imagine a user has three accounts with a digital wallet provider. The provider issues the user a single wallet address. When a payment is sent to the wallet address, the provider determines which one of the three accounts should receive the payment based on any number of criteria.
 
-Ultimately, it’s up to the ASE to define the supported configuration of relationships between wallet addresses and user accounts. This loose coupling allows wallet addresses to be disabled or even linked to a new account (although there are considerations that must be made before allowing this) without affecting the underlying account. 
+Ultimately, it’s up to the ASE to define the supported configuration of relationships between wallet addresses and user accounts. This loose coupling allows wallet addresses to be disabled or even linked to a new account (although there are considerations that must be made before allowing this) without affecting the underlying account.
 
 For any client, a wallet address is as good as an account. Any two distinct wallet addresses should be treated as distinct accounts by clients even if the client is aware that they are proxies for the same underlying account. Permissions granted to a client for access to an account via one wallet address are not automatically usable for accessing the same account via another wallet address.