docs: idp, keys, test wallet (#3053)

packages/documentation/src/content/docs/admin/admin-user-guide.mdx

@@ -47,7 +47,15 @@ After running the `invite-user` script, the script generates a recovery link tha
 />
 
 :::note
-The invitation link is single-use for security purposes. Once accessed, it becomes invalid. If sending the link through Slack, ensure you format it as code by placing it inside backticks (\`) to prevent Slack from automatically previewing the link, which would invalidate it. Example: \``http://localhost:4433/self-service/recovery?flow=116250ee-07bd-4b5c-a98e-87406192bb4b&token=miv0yZ7DFKKw8RyBBQvWoOsTRa2TVuZm`\`.
+The invitation link is single-use for security purposes. Once accessed, it becomes invalid.
+
+If sending the link through Slack, ensure you format it as code by placing it inside backticks (\`) to prevent Slack from automatically previewing the link, which would invalidate it. For example:
+
+{/* prettier-ignore */}
+```js wrap
+`http://localhost:4433/self-service/recovery?flow=116250ee-07bd-4b5c-a98e-87406192bb4b&token=miv0yZ7DFKKw8RyBBQvWoOsTRa2TVuZm`
+```
+
 :::
 
 #### Generate a recovery link

packages/documentation/src/content/docs/integration/playground/autopeering.mdx

@@ -4,7 +4,7 @@ title: Auto-Peering with the Test Network
 
 import { LinkOut } from '@interledger/docs-design-system'
 
-You can start one local instance of Rafiki and peer it automatically with the remote <LinkOut href='rafiki.money'>Test Network</LinkOut> by running the following commands:
+You can start one local instance of Rafiki and peer it automatically with the remote <LinkOut href='https://wallet.interledger-test.dev/'>Test Network</LinkOut> by running the following commands:
 
 ```sh
 ## using Tigerbeetle DB
@@ -13,7 +13,7 @@ pnpm localenv:compose:autopeer
 pnpm localenv:compose:psql:autopeer
 ```
 
-The mock account servicing entity, Cloud Nine Wallet, in your local Rafiki instance will automatically peer with the remote <LinkOut href='https://rafiki.money/'>Test Network</LinkOut> instance. The required services will be exposed externally using the <LinkOut href='https://www.npmjs.com/package/localtunnel'>localtunnel package</LinkOut>.
+The mock account servicing entity, Cloud Nine Wallet, in your local Rafiki instance will automatically peer with the remote <LinkOut href='https://wallet.interledger-test.dev/'>Test Network</LinkOut> instance. The required services will be exposed externally using the <LinkOut href='https://www.npmjs.com/package/localtunnel'>localtunnel package</LinkOut>.
 
 The exposed ports are:
 

packages/documentation/src/content/docs/integration/playground/testnet.mdx

@@ -12,8 +12,12 @@ The [Local Playground](/integration/playground/overview/) is not the only way to
 
 The current applications include:
 
-- <LinkOut href='https://rafiki.money'>An Interledger test wallet</LinkOut>
-- <LinkOut href='https://rafiki.boutique'>An e-commerce application</LinkOut>
+- <LinkOut href='https://wallet.interledger-test.dev/'>
+    An Interledger test wallet
+  </LinkOut>
+- <LinkOut href='https://boutique.interledger-test.dev/products'>
+    An e-commerce application
+  </LinkOut>
 
 ## Peering with the Test Network
 

packages/documentation/src/content/docs/integration/requirements/idp.mdx

@@ -6,12 +6,13 @@ import { Badge, Steps } from '@astrojs/starlight/components'
 import {
   Mermaid,
   MermaidWrapper,
-  LinkOut
+  LinkOut,
+  CodeBlock
 } from '@interledger/docs-design-system'
 
 An identity provider (IdP) is a system or service that stores and manages user identity information, authentication, and consent. Examples of IdPs include OpenID Connect and Okta.
 
-Integration with an IdP is required if you plan to support outgoing payments via <LinkOut href="https://openpayments.dev">Open Payments</LinkOut>. Open Payments requires outgoing payment _grant_ requests, which precede outgoing payment requests, be interactive. In an interactive grant request, explicit interaction by an individual (e.g., an account holder) is required to approve the grant. An example of an interaction is an end-user tapping _Approve_ in an app to authorize a payment.
+Integration with an IdP is required if you plan to support outgoing payments via <LinkOut href="https://openpayments.dev">Open Payments</LinkOut>. The Open Payments standard requires interactive outgoing payment _grant_ requests, which precede outgoing payment requests. In an interactive grant request, explicit interaction by an individual (e.g., the client's end-user) is required to approve the grant. An example of an interaction is an end-user tapping _Approve_ in an app to authorize a payment.
 
 Your IdP will:
 
@@ -24,22 +25,28 @@ We provide Ory Kratos, a cloud-based user management system, for the identity an
 
 ### Interactions and consent
 
-Before an outgoing payment is created via Open Payments, an outgoing payment grant must be issued.
+Before an outgoing payment is created via Open Payments, an outgoing payment _grant_ must be issued.
 
-Outgoing payment grant requests must be interactive. This means the request requires explicit interaction, often from the account holder, to gather consent (permission) to create the outgoing payment. The interaction is facilitated by your IdP. Your IdP:
+Outgoing payment grant requests must be interactive. This means the request requires explicit interaction, often from the a client's end-user, to gather consent (permission) before creating the outgoing payment. The interaction is facilitated by your IdP.
+
+Your IdP:
 
 <Steps>
-  1. Provides an interface to gather consent (for example, a consent screen) 2.
-  Sends the interaction choice (accept/deny) to your authorization server 3.
-  Sends a request to your authorization server to finish the interaction 4.
-  Redirects the user after the interaction is complete
+
+1. Provides an interface to gather consent (for example, a consent screen)
+2. Sends the interaction choice (accept/deny) to your authorization server
+3. Sends a request to your authorization server to finish the interaction
+4. Redirects the user after the interaction is complete
+
 </Steps>
 
 ### Authorization server
 
 The purpose of an Open Payments authorization server is to grant permission to clients to access the Open Payments APIs. These APIs are used to create incoming payments, quotes, and outgoing payments against an account holder's account.
 
-Rafiki's [auth service](/integration/services/auth-service) provides you with a reference implementation of an Open Payments authorization server. The server extends an [API](#interaction-endpoints) for your IdP to use to begin and finish an interaction, collect authorization, get information about a particular grant, and communicate that a user has authorized a grant. You can use the service as an alternative to developing your own in-house service.
+Rafiki's [auth service](/integration/services/auth-service) provides you with a reference implementation of an Open Payments authorization server. You can use the service as an alternative to developing your own in-house service.
+
+The authorization server extends an HTTP API for your IdP to use to start and finish interactions, collect authorization, get information about a grant, and communicate whether an end-user has authorized a grant. The API's [endpoints](#interaction-endpoints) are described below.
 
 ## Environment variables
 
@@ -61,11 +68,24 @@ The following `backend` variables must be configured on your authorization serve
 
 ## Manage grants
 
-Your Open Payments authorization server extends an API for your IdP server to use after a pending grant request is created.
+After a pending grant request is created, your IdP server can use the interaction endpoints listed below to:
+
+- Start and finish interactions
+- Collect authorization
+- Get information about a grant
+- Communicate whether an end-user has authorized a grant
+
+Each interaction is identified by an `id` and a `nonce`. Both are provided as query parameters when your authorization server redirects to your IdP server.
+
+The endpoints are appended to the `IDENTITY_SERVER_URL` you defined when configuring your [environment variables](#environment-variables).
+
+<CodeBlock title="Example">
 
-Each interaction with an endpoint is identified by an `id` and a `nonce`. Both are provided as query parameters when your authorization server redirects to your IdP server.
+```http
+https://idp.wallet.example.com/interact/{id}/{nonce}
+```
 
-The endpoints are appended to the `IDENTITY_SERVER_URL` you defined when configuring your [environment variables](#environment-variables). For example: `https://idp.wallet.example.com/interact/{id}/{nonce}`
+</CodeBlock>
 
 ### Interaction endpoints
 

packages/documentation/src/content/docs/integration/services/auth-service.mdx

@@ -32,17 +32,19 @@ When a request comes from a client with an account known to your local instance
 
 When a request comes from a client registered with another instance of Rafiki, the `auth` service resolves the client's key endpoint (e.g., `https://wallet.example.com/alice/jwks.json`) to retrieve the client's public keys, then filters out the correct key using the key id (`kid`) in the client's signature.
 
+Review the <LinkOut href="https://openpayments.dev/introduction/client-keys/">Open Payments documentation</LinkOut> for more information about client keys.
+
 ## Identity provider (IdP)
 
 An identity provider (IdP) is a system or service that manages user authentication, identity information, and consent. When you use your Google account credentials to “Sign in with Google” on an app or website, for example, Google is acting as your identity provider.
 
-Integration with an [IdP](/integration/requirements/idp) is required when using Rafiki’s `auth` service because Open Payments requires interactive outgoing payment grant requests. This means there must be explicit interaction by an individual (typically a client’s end user/your customer) to approve or deny an outgoing payment before a grant is issued.
+Integration with an [IdP](/integration/requirements/idp) is required when using Rafiki’s `auth` service because the Open Payments standard requires interactive outgoing payment _grant_ requests. In an interactive request, there must be explicit interaction by an individual (e.g., a client's end-user) to approve or deny the grant. In this case, the grant must be explicitly approved before an outgoing payment is created.
 
 :::note
-Rafiki’s [`frontend`](/integration/services/frontend-service) service requires an IdP for authentication and user management of your administrators. Out of the box, Rafiki uses Ory Kratos to enable your admins to access the Admin API. Kratos is for internal use and cannot be used for your customer-facing Open Payments authorization server.
+Rafiki’s [`frontend`](/integration/services/frontend-service) service requires an IdP for authentication and user management of your [Rafiki Admin](/admin/admin-user-guide) users. Out of the box, Rafiki uses Ory Kratos, a cloud-based user management system. Kratos is for internal use only and **cannot** be used as your customer-facing Open Payments authorization server.
 :::
 
-For more information about interactive grants and how they work with identity providers, review the <LinkOut href="https://openpayments.dev/introduction/grants/">Grant negotiation and authorization</LinkOut> page in the Open Payments docs.
+For more information about interactive grants and how they work with identity providers, review our [Identity Provider](/integration/requirements/idp) page and the <LinkOut href="https://openpayments.dev/introduction/grants/">Grant negotiation and authorization</LinkOut> page in the Open Payments docs.
 
 ## GraphQL Auth Admin API
 

packages/documentation/src/content/docs/overview/concepts/open-payments.mdx

@@ -35,4 +35,4 @@ Rafiki’s [`backend`](/integration/services/backend-service) service is the mai
 
 ## Rafiki's auth service
 
-Rafiki’s [`auth`](/integration/services/auth-service) service is a reference implementation of an opinionated Open Payments authorization server. The authorization server is responsible for delegating authorization (via grants) to clients to use the Open Payments APIs, resolving clients’ public keys to authenticate and authorize incoming requests, and creating payments and quotes on the backend. Open Payments leverages the Grant Negotiation and Authorization Protocol (GNAP) for delegating authorization. You can learn more about the protocol by reviewing its <LinkOut href="https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol">specification</LinkOut>.
+Rafiki’s [`auth`](/integration/services/auth-service) service is a reference implementation of an opinionated Open Payments authorization server. The authorization server is responsible for delegating authorization (via grants) to clients to use the Open Payments APIs, resolving <LinkOut href="https://openpayments.dev/introduction/client-keys/">clients’ public keys</LinkOut> to authenticate and authorize incoming requests, and creating payments and quotes on the backend. Open Payments leverages the Grant Negotiation and Authorization Protocol (GNAP) for delegating authorization. You can learn more about the protocol by reviewing its <LinkOut href="https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol">specification</LinkOut>.