Create a SEP to allow user to be approved for auth_required asset without leaving their wallet / exchange frontend

[tomquisel]

Who: SDEX users who want to hold & trade AUTH_REQUIRED assets What: Create a new SEP that defines a client / server protocol allowing users to submit KYC info to an anchor and receive authorization to hold an AUTH_REQUIRED asset without leaving their wallet / exchange frontend. Why: AUTH_REQUIRED assets are becoming more common, and currently the user experience of trying to trade one in an exchange frontend is painful, requiring the user to create an account and manually upload KYC for each new anchor whose assets the user wants to hold.

This SEP would parallel SEP-6 and leverage SEPs 9,10, and 12 to transmit KYC information.

@tomerweller thoughts?

[tomerweller]

@tomquisel I think SEP12's PUT /customer essentially solves that already across the stack. Though we haven't expressed that anywhere.

So (a) we should document it and (b) maybe add something to the HTTP response to indicate authorization status?

[tomquisel]

@tomerweller I think that's partially true, but how does the wallet contact the issuer and discover the KYC fields that must be sent over as a prereq for approval?

I think we need a mechanism similar to the non-interactive KYC response to /deposit in SEP-6.

[tomerweller]

@tomquisel, got it. Yeah this relates to our conversation from a couple of weeks ago regarding whether or not the kyc responses belong in SEP6 or SEP12. I guess there's no escape from having them in both? Why do you think SEP12 should only support the non-interactive flow?

[tomerweller]

Also, this might be a really bad idea but what if we'd have another SEP (always a good idea) for unauthorized responses and then both SEP6 and SEP12 could link to it? .