Proposal for Adjusting `dest` Field in SEP-6 Protocol

[Yusuf Dağ]

Hello everyone,

As part of ongoing efforts to enhance the SEP-6 protocol, the dest field in the request object for the GET TRANSFER_SERVER/withdraw endpoint in the SEP-6 protocol has been marked as deprecated. It has come to my attention that certain anchors, especially those not yet supporting SEP-10, still find the dest field crucial for their operations.

Proposal:

I suggest revisiting the deprecation status of the dest field and making it optional instead. This adjustment would offer a middle ground, allowing anchors to continue using the dest field as needed. By making it optional, we can provide a more flexible solution for those who may not be fully integrated with SEP-10.

Looking forward to hear any insight or feedback.

Best,

Yusuf DAG

[Jake Urban]

Hey Yusuf,

The 'dest' field was deprecated because it puts sensitive financial account data in URLs. SEP-6 shouldn't endorse this approach, which is why we moved it to deprecated. 

Anchors that already use the 'dest' field can continue doing so in the short term but they should update to an alternative approach (passing financial account data in request bodies, specifically SEP-12's 'PUT /customer' endpoint) in the medium-to-long term. 

Most importantly, the deprecation serves as a warning for new anchors & wallets to not use the 'dest' parameter. We want the Stellar ecosystem's proposals to be designed and implemented with best practices in mind.

[Marcin Olszowy // Whalestack LLC]

Hey. We are actively using the dest param for /withdraw and have no plans to migrate it. Second the motion to mark it as optional instead of deprecating it. No intentions to involve another SEP into the currently simple withdrawal process.

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/b95a4a6f-bb2e-4cba-80b1-ab653055fa57n%40googlegroups.com.

[Jake Urban]

Whalestack and Beans can continue with the current approach, but it does not make sense to endorse passing financial account data in URLs in the specification. New wallets and ramps, or those who are willing to update their implementations, should use a more secure approach. Whalestack's services already include significant deviations from the SEP-6 protocol as it is defined today so I don't see why the use of 'dest' needs to be standardized.

You received this message because you are subscribed to a topic in the Google Groups "Stellar Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/stellar-dev/1Hlq-CmbRHg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/7e7aa3d1-f2c7-45a0-a59e-90d37af779a4%40whalestack.com.

--

Jake Urban

Partner Engineering Manager

Stellar Development Foundation

w: https://www.stellar.org/

[Marcin Olszowy // Whalestack LLC]

Hey Jake,

The practical consequence of deprecating "dest" in /withdraw is that SEP-6 seizes to exist as a standalone API. That's a pretty extreme step. There are anchors who do not need or want SEP-12 and mandating it forces them to over-engineer an otherwise simple process. 

I feel like keeping "dest" around as an option as suggested by Yusuf is a far better approach than killing it off. This way existing anchors are not burdened with a considerable refactoring of their implementation and SEP-6 continues to offer flexibility to those who want it.

There are situations where exposing public information via a GET param does no harm at all. Anchor operators are probably mature enough to decide for themselves whether it makes sense in their use-case or not. Not all "financial account data" is sensitive and if transmitted via HTTPS it is only visible to the client and anchor anyway.

However, if your main concern is passing data via GET params, wouldn't it be best to simply re-declare /deposit and /withdraw in SEP-6 as POST? This would be the appropriate HTTP method in the REST concept anyway. Wouldn't this address the actual root-problem more precisely and therefore more neatly align with your vision of wanting "the Stellar ecosystem's proposals to be designed and implemented with best practices in mind"?

Changing from GET to POST is trivial to refactor and does not force an expensive SEP-12 implementation/refactoring on everyone who does not need or want it in their SEP-6. During a transitional period anchors could allow both GET and POST.

Marcin

--

You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/7c3cca22-4f03-4efa-a153-2fb38369a0ccn%40googlegroups.com.

[Marcin Olszowy // Whalestack LLC]

Hey Jake,

> but it does not make sense to endorse passing financial account data
> in URLs in the specification.

Then in that case we indeed need to re-declare /deposit and /withdraw as
POST as suggested in my previous email?

There is other "financial account data" in the URLs and forcing "dest"
into SEP-12 (while still "exposing" Stellar accounts, memos, email
addresses etc. etc. in GET /deposit for example) does not solve the
actual root problem.

> Whalestack's services already include significant deviations from the
> SEP-6 protocol as it is defined today

For the record, our implementation is fully compatible with SEP-6 as it
stands and numerous wallets consume it without issues. It addresses the
obvious shortcomings and data structure problems of SEP-6 though which
we discussed in length in the other thread.

[Jake Urban]

I agree adding POST endpoint alternatives definitely addresses the root of the problem, and I'm open to that change. 

I believe that approach was considered some time ago and we opted not to do it because it would require existing implementations to update, but thinking about this again now, I don't think SEP-6 has enough adoption to consider that a strong enough reason not to do it.

You received this message because you are subscribed to a topic in the Google Groups "Stellar Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/stellar-dev/1Hlq-CmbRHg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/57f72379-90c3-4070-8ec0-93a378fbd2e4%40whalestack.com.

[Yusuf Dağ]

Hey Jake and Marcin,

I think POST endpoint sounds like a good solution here for SEP-6 deposit and withdrawal. So we could still make the `dest` optional instead of deprecated in that case, right? 

Best, Yusuf

[Jake Urban]

If we're going to add POST endpoints, I would suggest using the SEP-9 fields for passing financial account information, rather than adding the 'dest' parameter. SEP-24 uses POST, but it doesn't have a 'dest' parameter. Instead, if the client wants to provide the user's bank account info, they include it in the withdrawal request body under the 'bank_account_number' or similar field. See the following line in the withdraw request definition:

Additionally, any SEP-9 parameters may be passed as well to make the onboarding experience simpler.

Example:

POST TRANSFER_SERVER_SEP0024/transactions/withdraw/interactive
Content-Type: application/x-www-form-urlencoded

asset_code=USD&email_address=myac...@gmail.com&account=GACW7NONV43MZIFHCOKCQJAKSJSISSICFVUJ2C6EZIW5773OU3HD64VI

 

In this example the 'email_address' SEP-9 field is used, but it would be the same for financial account fields. 

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/1c368628-375a-4117-ad20-7698fbddbf65n%40googlegroups.com.

[Yusuf Dağ]

I think it is a great idea! If there are no other additions to these, I can create an issue and PR for :

- Using POST instead GET for SEP-6 deposit and withdrawal endpoints.

- Adding "Additionally, any SEP-9 parameters may be passed as well to make the onboarding experience simpler." 

[Marcin Olszowy // Whalestack LLC]

Agreed on SEP-9 fields being better than the generic dest/dest_extra.

I am somehow missing the link between developers wanting to send a SEP-6 /withdraw and them knowing which SEP-9 destination params to include in the request. Do we have a normalized way to fetch which SEP-9 fields clients should include in the /withdraw request for a particular transfer server?

Thanks.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/dd223c5d-4794-4869-9dc3-ac5635235bdcn%40googlegroups.com.

[Jake Urban]

Sounds good Yusuf, and since we're adding new endpoints, let's only add 2 (POST /withdraw and POST /deposit), rather than 4 (including POST /withdraw-exchange and POST deposit-exchange). The 2 endpoints we add can be designed to support transactions involving both equivalent and non-equivalent assets. For example, USD-for-USDC and USDC-for-MXN.

To you question Marcin, the 'fields' object in 'GET /info' can be used if the set of fields is static (i.e. the fields required don't change depending on various factors). If the fields are dynamic, then using /info isn't a great solution because clients won't know whether or not each field is truly necessary for their specific transaction. That is where SEP-12 comes in, since it can return the fields required for a specific transaction by passing the transaction ID to the 'GET /customer' endpoint. Note that this also assumes clients are making requests to initiate every transaction.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/bf73c12d-0496-408c-a06d-12d1987c58f9%40whalestack.com.

[Marcin Olszowy // Whalestack LLC]

the 'fields' object in 'GET /info' can be used

Right. Perfect. Thanks.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CA%2BEqNSxxubHg7nKKyC%2BEyRCAUpx-t2M6pjnOCEVw4g5q24T7OA%40mail.gmail.com.