Issues 407 and 495

#407 : Added Glossary - removed from draft status, finished definitions, and put into sidebar
#495 : Fixed badge colors, swapping blue and green

docs/astro.config.mjs

@@ -213,10 +213,10 @@ export default defineConfig({
           label: 'Resources',
           collapsed: true,
           items: [
-            // {
-            //   label: 'Glossary',
-            //   link: '/resources/glossary/'
-            // },
+            {
+              label: 'Glossary',
+              link: '/resources/glossary/'
+            },
             {
               label: 'Open Payments-enabled wallets',
               link: '/resources/op-wallets/'
@@ -242,12 +242,12 @@ export default defineConfig({
                 {
                   label: 'Get wallet address',
                   link: '/apis/wallet-address-server/operations/get-wallet-address',
-                  badge: { text: 'GET', variant: 'success' }
+                  badge: { text: 'GET', variant: 'note' }
                 },
                 {
                   label: 'Get keys bound to wallet address',
                   link: '/apis/wallet-address-server/operations/get-wallet-address-keys',
-                  badge: { text: 'GET', variant: 'success' }
+                  badge: { text: 'GET', variant: 'note' }
                 }
               ]
             },
@@ -262,22 +262,22 @@ export default defineConfig({
                     {
                       label: 'Create incoming payment',
                       link: '/apis/resource-server/operations/create-incoming-payment',
-                      badge: { text: 'POST', variant: 'note' }
+                      badge: { text: 'POST', variant: 'success' }
                     },
                     {
                       label: 'List incoming payments',
                       link: '/apis/resource-server/operations/list-incoming-payments',
-                      badge: { text: 'GET', variant: 'success' }
+                      badge: { text: 'GET', variant: 'note' }
                     },
                     {
                       label: 'Get an incoming payment',
                       link: '/apis/resource-server/operations/get-incoming-payment',
-                      badge: { text: 'GET', variant: 'success' }
+                      badge: { text: 'GET', variant: 'note' }
                     },
                     {
                       label: 'Complete an incoming payment',
                       link: '/apis/resource-server/operations/complete-incoming-payment',
-                      badge: { text: 'POST', variant: 'note' }
+                      badge: { text: 'POST', variant: 'success' }
                     }
                   ]
                 },
@@ -288,17 +288,17 @@ export default defineConfig({
                     {
                       label: 'Create outgoing payment',
                       link: '/apis/resource-server/operations/create-outgoing-payment',
-                      badge: { text: 'POST', variant: 'note' }
+                      badge: { text: 'POST', variant: 'success' }
                     },
                     {
                       label: 'List outgoing payments',
                       link: '/apis/resource-server/operations/list-outgoing-payments',
-                      badge: { text: 'GET', variant: 'success' }
+                      badge: { text: 'GET', variant: 'note' }
                     },
                     {
                       label: 'Get an outgoing payment',
                       link: '/apis/resource-server/operations/get-outgoing-payment',
-                      badge: { text: 'GET', variant: 'success' }
+                      badge: { text: 'GET', variant: 'note' }
                     }
                   ]
                 },
@@ -309,12 +309,12 @@ export default defineConfig({
                     {
                       label: 'Create quote',
                       link: '/apis/resource-server/operations/create-quote',
-                      badge: { text: 'POST', variant: 'note' }
+                      badge: { text: 'POST', variant: 'success' }
                     },
                     {
                       label: 'Get a quote',
                       link: '/apis/resource-server/operations/get-quote',
-                      badge: { text: 'GET', variant: 'success' }
+                      badge: { text: 'GET', variant: 'note' }
                     }
                   ]
                 }
@@ -331,12 +331,12 @@ export default defineConfig({
                     {
                       label: 'Grant request',
                       link: '/apis/auth-server/operations/post-request',
-                      badge: { text: 'POST', variant: 'note' }
+                      badge: { text: 'POST', variant: 'success' }
                     },
                     {
                       label: 'Grant continuation request',
                       link: '/apis/auth-server/operations/post-continue',
-                      badge: { text: 'POST', variant: 'note' }
+                      badge: { text: 'POST', variant: 'success' }
                     },
                     {
                       label: 'Cancel grant',
@@ -352,7 +352,7 @@ export default defineConfig({
                     {
                       label: 'Rotate access token',
                       link: '/apis/auth-server/operations/post-token',
-                      badge: { text: 'POST', variant: 'note' }
+                      badge: { text: 'POST', variant: 'success' }
                     },
                     {
                       label: 'Revoke access token',

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

@@ -6,13 +6,13 @@ import { LinkOut } from '@interledger/docs-design-system'
 
 Handling payments is a crucial part of many online applications. Whether it's an eCommerce site selling products, a fundraising platform accepting donations, a streaming service charging for content, or a subscription service with monthly fees, digital payments are central to their operations. Many application developers rely on third-party payment gateways to handle these transactions, which can introduce additional expenses and limit control over the user experience.
 
-Open Payments is an open RESTful API and API standard that enables clients to interface with Open Payments-enabled accounts. In this context, a client is an application, such as a mobile or web app, that consumes one or more Open Payments resources, typically requiring access privileges from one or several authorization servers.
+Open Payments is an open RESTful API and an API standard that enables clients to interface with Open Payments-enabled accounts. In this context, a client is an application, such as a mobile or web app, that consumes one or more Open Payments resources, typically requiring access privileges from one or several authorization servers.
 
 The Open Payments standard is meant to be implemented by account servicing entities (ASEs). ASEs provide and maintain payment accounts for payers and payees, and are regulated entities within the countries they operate. Examples of ASEs include banks, digital wallet providers, and mobile money providers.
 
 ## Benefits of Open Payments
 
-When an ASE implements Open Payments, their customers’ financial accounts become Open Payments-enabled. Clients can then call the Open Payments API to view an Open Payments-enabled account’s transaction history and certain account details, as well as issue instructions for receiving payments into and sending payments from the account.
+When an ASE implements Open Payments, their customers’ financial accounts become Open Payments-enabled. Clients can then call the Open Payments APIs to view an Open Payments-enabled account’s transaction history and certain account details, as well as issue instructions for receiving payments into and sending payments from the account.
 
 For example, an application developer can build payments functionality into their app without the need for custom integrations with each ASE. Users with Open Payments-enabled accounts can use the app to send funds to another Open Payments-enabled account, regardless of whether the recipient uses the same ASE. This app should be able to connect to any ASE that implements the Open Payments standard without the need for custom integrations.
 
@@ -26,7 +26,7 @@ With Open Payments, users remain in full control of their financial transactions
 
 ## Payments
 
-Open Payments does not execute payments or touch funds in any way. Instead, the API allows clients to issue payment instructions to ASEs.
+Open Payments does not execute payments or touch funds in any way. Instead, the 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 customer’s account to another Open Payments-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 Open Payments-enabled ASEs is predicated on the availability of a common payment rail between the ASEs.
 
@@ -42,7 +42,7 @@ Wallet addresses in Open Payments are designed to be user-friendly and publicly
 
 Clients must receive grants before issuing payment instructions. Grants give clients the authorization, via access tokens, to perform one or more operations. Grants represent the rights that are given to the client, such as the right to create an incoming payment request.
 
-Open Payments leverages the <LinkOut href='https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol'>Grant Negotiation and Authorization Protocol (GNAP)</LinkOut> to define a standard mechanism for clients to request and receive the grants necessary to use the Open Payments API. All requests require signatures, which protect the integrity of the requests. Signatures are generated according to the <LinkOut href='https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/'>HTTP Signatures specification</LinkOut>.
+Open Payments leverages the <LinkOut href='https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol'>Grant Negotiation and Authorization Protocol (GNAP)</LinkOut> to define a standard mechanism for clients to request and receive the grants necessary to use the Open Payments APIs. All requests require signatures, which protect the integrity of the requests. Signatures are generated according to the <LinkOut href='https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/'>HTTP Signatures specification</LinkOut>.
 
 GNAP allows account holders to have 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.
 
@@ -52,7 +52,7 @@ Review the [Grant negotiation and authorization](/introduction/grants) page for
 
 Open Payments aims 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. Open Payments allows for scenarios where clients can dynamically register and engage with the API without needing to pre-register with the ASE. This allows for a truly distributed and federated payment ecosystem with global reach and no dependence on any particular underlying account type or settlement system.
+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. Open Payments allows for scenarios where clients can dynamically register and engage with the APIs without needing to pre-register with the ASE. This allows for a truly distributed and federated payment ecosystem with global reach and no dependence on any particular underlying account type or settlement system.
 
 Open Payments is also a significantly simpler standard with a small number of resource types and a more secure and powerful authorization protocol.
 

docs/src/content/docs/resources/glossary.mdx

@@ -0,0 +1,45 @@
+---
+title: Glossary
+---
+
+import { LinkOut } from '@interledger/docs-design-system'
+
+## Account servicing entity (ASE)
+
+An account servicing entity provides and maintains a payment account for a payer and payee, and is a regulated entity in the country/countries it operates.
+
+## Authorization server (AS)
+
+An authorization server issues tokens to clients, which can then be used to perform authorized actions on resource servers. In the context of Open Payments, the authorization server grants permission for a client to access the Open Payments APIs and the `incoming-payment`, `quote`, and `outgoing-payment` resources. Open Payments leverages GNAP as the mechanism for delegating authorization.
+
+## Client
+
+A client is an application or service that interacts with the authorization server to obtain grants and tokens. A client uses these tokens to access resources or perform transactions on behalf of a user or system.
+
+## Grant Negotiation and Authorization Protocol (GNAP)
+
+The Grant Negotiation Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software, and conveying the results and artifacts of that delegation to the software. This delegation can include access to a set of APIs as well as subject information passed directly to the software. For more information, see the [specification](https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol-12).
+
+## Incoming payment resource
+
+An incoming payment resource is an object that represents a payment being received by an entity. This resource contains information about the incoming payment, such as the amount, currency, receiver's wallet address, and payment status. It is used to track and manage payments that are expected to or have been received.
+
+## Interactive grant
+
+An interactive grant requires direct user interaction with the authorization server in order to grant permissions to a client. This ensures that the user is aware of and approves the level of access being requested.
+
+## Open Payments (OP)
+
+Open Payments is an open RESTful API and an API standard that enables clients to interface with Open Payments-enabled accounts. In this context, a client is an application, such as a mobile or web app, that consumes one or more Open Payments resources, typically requiring access privileges from one or several authorization servers.
+
+## Outgoing payment resource
+
+An outgoing payment resource is an object that represents a payment being sent by an entity. This resource contains information about the outgoing payment, such as the amount, currency, receiver's wallet address, and payment status. Outgoing payment resources require explicit consent from the sender, obtained through an interactive grant, and serves as a mechanism to separate payment instructions from payment execution.
+
+## Quote resource
+
+A quote resource is an object that represents a potential payment being received by an entity. This resource contains information about the potential payment, but is mainly used to indicate the total cost, including any applicable fees, to make the payment. The quote resource also serves as a commitment from the sender's ASE to deliver a particular amount to the receiver's ASE and it only valid for a limited time.
+
+## Resource server (RS)
+
+A resource server hosts protected resources and enforces access controls based on the tokens provided by the authorization server. In the context of Open Payments, the resource server manages access to three payment-related resources (`incoming-payment`, `quote`, and `outgoing-payment`), ensuring that only authorized clients can perform actions through the Open Payments APIs.

docs/src/content/docs/snippets/wallet-get-info.mdx

@@ -11,7 +11,7 @@ import Js from '/src/partials/js-prerequisites.mdx'
 
 For a client to request a grant from an authorization server, the client must first verify the validity of the wallet address and get the URL of the wallet's authorization server.
 
-These code snippets enable an authenticated client to verify a wallet address, get the basic information required to construct a new transaction, and discover the auth server’s URL. Note that unauthenticated clients can also call the Open Payments API to get wallet address information.
+These code snippets enable an authenticated client to verify a wallet address, get the basic information required to construct a new transaction, and discover the auth server’s URL. Note that unauthenticated clients can also call the Open Payments APIs to get wallet address information.
 
 ## Before you begin
 

docs/src/partials/before-you-begin.mdx

@@ -1 +1 @@
-We recommend creating a wallet account on [Rafiki.Money](/snippets/before-you-begin), a test wallet provider that's part of the Interledger testnet. Creating an account allows you to test your client against the Open Payments API using an ILP-enabled wallet funded with play money.
+We recommend creating a wallet account on [Rafiki.Money](/snippets/before-you-begin), a test wallet provider that's part of the Interledger testnet. Creating an account allows you to test your client against the Open Payments APIs by using an ILP-enabled wallet funded with play money.