Issues 407 and 495 #496
Issues 407 and 495 #496
Conversation
|
✅ Deploy Preview for openpayments-preview ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Two minor things that are not showstoppers:
The badge colors are not the same shade of blue and green as the API docs. We could do custom styling on the badges, but that may be overkill. At least the badges and API docs are better aligned now.
I'm conflicted about whether we should include Identity Provider in the glossary. It's not really part of Open Payments, and in that sense, it's fine that we don't have an entry for it. At the same time, we do delve into the concept on the Grant negotiation and authorization page, and in that regard, I wonder if it warrants an entry.
|
|
||
| ## 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. |
There was a problem hiding this comment.
I don't know if this is overkill. Just a suggestion.
A client is an application or service, such as a mobile or web app, that interacts with an authorization server to obtain grants and tokens. A client uses these tokens to access resources on a resource server to perform actions, such as retrieving transaction history and setting up payments, 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). | ||
|
|
There was a problem hiding this comment.
Can you change this link to use the LinkOut component?
|
|
||
| ## 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. |
There was a problem hiding this comment.
We have an entry for client, so the last sentence may not be necessary.
|
|
||
| ## 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. |
There was a problem hiding this comment.
We say that it represents a payment being received by an entity, but I wonder if we should be more explicit. The resource is created by the recipient's ASE, on their resource server. Also just a suggestion, but I'm going to add a similar comment to the other two resource definitions.
There was a problem hiding this comment.
Can you link this to /introduction/op-concepts/#incoming-payment?
|
|
||
| ## 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. |
There was a problem hiding this comment.
The resource is created by the sender's ASE, on their resource server.
Phrasing suggestion: An outgoing payment resource requires explicit consent from the sender before the resource can be created.
There was a problem hiding this comment.
Also, it's not the outgoing payment resource that serves as a mechanism to separate instruction from execution. All of Open Payments is for that purpose.
There was a problem hiding this comment.
Link to /introduction/op-concepts/#outgoing-payment
|
|
||
| ## 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. |
There was a problem hiding this comment.
Link to /introduction/op-concepts/#quote
The resource is created by the sender's ASE, on their resource server, after the incoming payment resource is created by the recipient's ASE.
|
@hajjimo I see what you mean about the color. If it was something we could easily adjust, I'd say we should change it. But it requires HJ to customize some stuff. |
- Fixed reference to Global Payments APIs with reference to singular Wallet Address API - Glossary fixes
Changes proposed in this pull request
#407 : Added Glossary - removed from draft status, finished definitions, and put into sidebar
#495 : Fixed badge colors, swapping blue and green