Conversation
- Updated payer/payee references to sender/recipient where contextually appropriate - Fix typos picked up by Vale
|
✅ Deploy Preview for openpayments-preview ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| This request requires an interactive grant as the sender will need to consent before an `outgoingPayment` is made against their wallet. | ||
|
|
||
| For details on how to facilitate an interactive grant please see the <LinkOut href='https://openpayments.dev/guides/create-interactive-grant/'> | ||
| For details on how to facilitate an interactive grant refer the <LinkOut href='https://openpayments.dev/guides/create-interactive-grant/'> |
There was a problem hiding this comment.
Missing "to". "...refer to the..."
| An authorization server (AS) grants delegated privileges to a client in the form of access tokens. Access tokens represent a set of access rights and/or attributes granted to the client. With the requisite access token(s), the client can access a resource server’s (RS) Open Payments APIs and perform allowed operations, such as creating incoming payments and listing outgoing payments, on behalf of the resource owner. | ||
| An authorization server grants delegated privileges to a client in the form of access tokens. Access tokens represent a set of access rights and/or attributes granted to the client. With the requisite access token(s), the client can access a resource server’s Open Payments APIs and perform allowed operations, such as creating incoming payments and listing outgoing payments, on behalf of the resource owner. | ||
|
|
||
| An AS is uniquely identified by its grant endpoint URI, which is an absolute URI that a client calls to initiate a grant request. |
| import { CodeBlock, LinkOut, Tooltip } from '@interledger/docs-design-system' | ||
|
|
||
| Once a resource owner (RO) authorizes a client software, the authorization server (AS) will redirect the RO's [identity provider (IdP)](/introduction/idp/) to the finish URI if the client had provided an `interact.finish` object in the intial request. In order to secure this communication and verify that the redirect indeed emanated from the AS, the AS will provide a hash parameter in the request to the client's callback URI. The client **_must_** verify this hash. | ||
| Once a resource owner authorizes a client software, the authorization server will redirect the resource owner's [identity provider (IdP)](/introduction/idp/) to the finish URI if the client had provided an `interact.finish` object in the initial request. In order to secure this communication and verify that the redirect indeed emanated from the authorization server, the authorization server will provide a hash parameter in the request to the client's callback URI. The client **_must_** verify this hash. |
There was a problem hiding this comment.
There's a merge conflict on this because I just recently changed this paragraph. I think you can resolve the conflict by either undoing your changes or just copy/paste from the live doc.
There was a problem hiding this comment.
Can you move this so that the summary is the first thing on the page?
| ## Hashing method | ||
|
|
||
| The hash base is generated by concatentating the following values in sequence using a single newline `(/n)` character to separate them: | ||
| The hash base is generated by concatenating the following values in sequence using a single newline `(/n)` character to separate them: |
There was a problem hiding this comment.
I also caught this, but it's the same change I made, so it's probably not causing a conflict.
| #### outgoing-payment | ||
|
|
||
| After a quote resource is created, it’s almost time to create the outgoing-payment resource on the payer’s account. The purpose of the outgoing-payment resource is to serve as an instruction to make a payment from the payer’s account. | ||
| After a quote resource is created, it’s almost time to create the outgoing-payment resource on the sender's account. The purpose of the outgoing-payment resource is to serve as an instruction to make a payment from the sender's account. |
There was a problem hiding this comment.
Add code format to outgoing-payment x2
There's a number of instances in this section where the resource name needs to be code
|
|
||
| <Mermaid | ||
| graph={`sequenceDiagram | ||
| participant C as Client instance |
There was a problem hiding this comment.
We use both Client and Client instance as a participant in the diagrams. I'm pretty sure the inconsistency is my fault 😕 Can you change them all to just Client?
|
|
||
| :::note | ||
| When setting up a payment, the client first requests a grant from the recipient's (payee's) authorization server to create an `incoming-payment` resource. The client then requests grants to create the `quote` and `outgoing-payment` resources from the sender's (payer's) authorization server. | ||
| When setting up a payment, the client first requests a grant from the authorization server of the recipient's <Tooltip content="Account servicing entity" client: load><span>ASE</span></Tooltip> to create an `incoming-payment` resource. The client then requests grants to create the `quote` and `outgoing-payment` resources from the authorization server of the sender's ASE. |
There was a problem hiding this comment.
Given that the sentence above the note specifies incoming-payment, quote, and outgoing-payment resource types, what do you think about this:
When setting up a payment, the client first requests an incoming payment grant from the authorization server of the recipient's ASE. Then, the client requests quote and outgoing payment grants from the authorization server of the sender's ASE.
Just a suggestion.
| 4. Send request to create a quote resource to the payer's RS | ||
| 5. Request an interactive `outgoing-payment` grant from the payer's AS | ||
| 6. Send request to create an outgoing payment resource to the payer's RS | ||
| 1. Request an `incoming-payment` grant from the authorization server of recipient's <Tooltip content="Account servicing entity" client: load><span>ASE</span></Tooltip> |
There was a problem hiding this comment.
I've spent some time looking at this path and path 2. By spelling out authorization server and resource server, and by better indicating who the server belongs to, I think it makes the sentences too complex. In these specific instances, it's a case of something sounding good in theory but ending up not so good after execution.
What do you think about this format for the paths?
- Request an incoming-payment grant from the recipient-side authorization server.
- Send request to create an incoming-payment resource to the recipient-side resource server.
- Request a quote grant from the sender-side authorization server.
- Etc...
melissahenderson
left a comment
melissahenderson
left a comment
There was a problem hiding this comment.
Looks really good overall, just a few final minor comments
|
|
||
| In Open Payments, a grant indicates a transfer, or delegation, of authorization from a Resource Owner (RO) to a piece of software. An RO can be a physical person, such as the software’s end user, or a process, such as predefined organizational rules. By delegating authorization, the RO allows the software to access and perform operations on protected resources on the RO’s behalf. | ||
|
|
||
| :::tip[Summary] |
There was a problem hiding this comment.
The summary should be the first thing on the page. Can you move the paragraph back under the summary?
| import { CodeBlock, LinkOut, Tooltip } from '@interledger/docs-design-system' | ||
|
|
||
| Once a resource owner (RO) authorizes a client software, the authorization server (AS) will redirect the RO's [identity provider (IdP)](/introduction/idp/) to the finish URI if the client had provided an `interact.finish` object in the intial request. In order to secure this communication and verify that the redirect indeed emanated from the AS, the AS will provide a hash parameter in the request to the client's callback URI. The client **_must_** verify this hash. | ||
| Once a resource owner authorizes a client software, the authorization server will redirect the resource owner's [identity provider (IdP)](/introduction/idp/) to the finish URI if the client had provided an `interact.finish` object in the initial request. In order to secure this communication and verify that the redirect indeed emanated from the authorization server, the authorization server will provide a hash parameter in the request to the client's callback URI. The client **_must_** verify this hash. |
There was a problem hiding this comment.
Can you move this so that the summary is the first thing on the page?
| The first resource to be created when setting up a payment is the `incoming-payment` resource, created on the recipient's account. When created, the recipient's ASE returns unique payment details to the client that can be used to address payments to the account. Any payments received using these details are then associated with the `incoming-payment` resource. | ||
|
|
||
| A client can issue requests to get an incoming payment’s specific details, as well as list all incoming payments in order to, for example, provide the end-user with transaction details and history. | ||
| A client can issue requests to get an incoming payment’s specific details, as well as list all incoming payments in order to, for example, provide the sender with transaction details and history. |
There was a problem hiding this comment.
I think for this example, it's the recipient that would be provided transaction details and history.
| ::: | ||
|
|
||
| In Open Payments, a grant indicates a transfer, or delegation, of authorization from a resource owner (RO) to a piece of software. An RO can be a physical person, such as the software’s end user, or a process, such as predefined organizational rules. By delegating authorization, the RO allows the software to access and perform operations on protected resources on the RO’s behalf. | ||
| In Open Payments, a grant indicates a transfer, or delegation, of authorization from a Resource Owner (RO) to a piece of software. An RO can be a physical person, such as the software’s end user, or a process, such as predefined organizational rules. By delegating authorization, the RO allows the software to access and perform operations on protected resources on the RO’s behalf. |
There was a problem hiding this comment.
Resource Owner doesn't need to be capitalized, but something like this shouldn't hold up a merge. We can adjust it later.
2 participants
Updated payer/payee references to sender/recipient where contextually appropriate
Fix typos picked up by Vale