Proposal for SEP-6 and SEP-9 Integration Improvement

[Yusuf Dağ]

Hello,

I'd like to initiate a discussion to enhance the integration experience by addressing two issues related to the SEP-6 and SEP-9 protocols.

Issue 1: Lack of Examples for Non-Organizational Instructions (Under SEP-6):

Currently, there is a notable absence of examples for non-organizational instructions within the SEP-6 protocol, which utilizes the SEP-9 Financial Account Fields. To rectify this, I propose incorporating examples that do not use the organizational prefix in the "instructions" field, ensuring comprehensive coverage.

Example:

```{
  "id": "9421871e-0623-4356-b7b5-5996da122f3e",
  "instructions": {
    "bank_number": {
      "value": "121122676",
      "description": "US bank routing number"
    },
    "bank_account_number": {
      "value": "13719713158835300",
      "description": "US bank account number"
    }
  },
  "how": "Make a payment to Bank: 121122676 Account: 13719713158835300"
}```

Issue 2: Simplifying Organization-related Fields Structure (Under SEP-9):

While SEP-9 suggests using the organization prefix, I propose introducing a dedicated "organization" key for organization-related fields within the "instructions" field to improve clarity and avoid potential parsing challenges.

Example:

```{
  "id": "9421871e-0623-4356-b7b5-5996da122f3e",
  "instructions": {
    "organization": {
      "bank_number": {
        "value": "121122676",
        "description": "US bank routing number"
      },
      "bank_account_number": {
        "value": "13719713158835300",
        "description": "US bank account number"
      }
    }
  },
  "how": "Make a payment to Bank: 121122676 Account: 13719713158835300"
}```

Best,

Yusuf DAG

[Jake Urban]

A memo field for deposits to off-chain accounts is a great idea, can you submit a PR for the change?

As for the suggested 'organization' object key, I think its important to continue using the 'organization.{field}' notation, since that is how organization fields are represented in all instances -- SEP-12's 'PUT /customer', 'GET /customer', and SEP-6/24 URL params.

[Yusuf Dağ]

Hey Jake,

Great, will do that. 

I understand why you prefer to keep the organization prefix notation, but what do you think about (Issue 1 above) adding examples for non-organizational instructions? It's just about adding an example under SEP-6 /deposit because, from what I've observed in anchors' /deposit responses, they only send organization prefix notation instructions, even though they support normal individual person instructions. I feel there might be confusion because the examples provided in SEP-6 /deposit are only for organization instructions.

Best, Yusuf

[Jake Urban]

There may be a misunderstanding of the purpose of organization prefixes in the instructions object, in which case we should probably update the SEP to clarify. Let me know if this matches your understanding.

When we added the instructions object to deposit responses, the thinking was that all fields included should be prefixed with 'organization' because the values provided belonged to the anchor (organization), rather than an individual. For example, if the anchor has a bank account for their organization, they would use 'organization.bank_account', rather than 'bank_account'. It wouldn't make sense for the anchor to include fields that don't have the 'organization' prefix, because all values provided are associated with the business, not any one individual.

When an individual is providing their bank account information to the anchor, they wouldn't use the 'organization' prefix because the bank account belongs to them (an individual) rather than an organization they're associated with. So when would it make sense for the client to provide a field with the 'organization' prefix? It is possible that an anchor needs to know the individual's employer information as a part of their KYC requirements, in which case the individual would provide 'organization.name' or other values related to their employer.

--
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/lZuq7Pj8OTY/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/077d9e98-aa41-4076-afb7-4bd74181c578n%40googlegroups.com.

--

Jake Urban

Partner Engineering Manager

Stellar Development Foundation

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

[Yusuf Dağ]

Ahh, I was the one who confused then, haha. Alright, that makes sense indeed. Thanks for clarifying!