CAIP-358: Introducing Transfer Types #381
Conversation
| - `types` - this field **MUST** be an array of strings defining different transfer authorization types. | ||
|
|
||
| The `acceptedPayments` field **MUST** be an array of `PaymentOption` objects. Each element in the array represents a payment option that the wallet can choose from to complete the payment. | ||
| The exclusive list of Transfer Types supported in `version=1` are the following: |
There was a problem hiding this comment.
We could make this non-exclusive and extensible easily with a defined "private types" approach. Right now we're effectively locking this to the types of today rather than the types of what's possible.
A good example of what this might look like is: https://datatracker.ietf.org/doc/html/rfc7519#section-4.3
There was a problem hiding this comment.
Honestly I would say that is the best long-term solution but historically in crypto we have seen this go very bad very quickly
The lack of governance where these "identifiers" can cause a lot of issues and this is very apparent on Ethereum with capabilities which is a melting pot of functionality that barely qualifies as a capability
In this scenario we are locking a narrow scope of accepted payment types that cover 95% of use-cases if not more
That being said this PR is still in Draft status so we can still make a follow-up PR to attempt a "private types" approach
There was a problem hiding this comment.
Yeah I was thinking the same thing when considering this. Technically, someone could just build a “non compliant” version and achieve this anyways in a one off case. If they’re a large enough payment processor everyone would just accept it anyways. So it’s probably better to keep it to only declared values and then have some way to document new declared values too via an errata CAIP or something. We can cross that bridge whenever it happens though. I’m good intentionally closing this extension point off for now for higher interop.
Facebook’s first implementation of OIDC did this where they weren’t a fully compliant implementation for years and sites still intercropped with it.
kdenhartog
left a comment
kdenhartog
left a comment
There was a problem hiding this comment.
few additional comments, to improve intent but this LGTM
Co-authored-by: Kyle Den Hartog <kdenhartog@users.noreply.github.com>
This PR introduces Transfer Types which allows a payment option to be completed either through a transaction hash or a message signature for gasless standards (eg. erc2612 or erc3009)