-
Notifications
You must be signed in to change notification settings - Fork 303
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SEP-0010: Revert home domain verification and relax manage data operation constraints (v2.1.0) #740
Conversation
@nebolsin Can we get your thoughts here? Thanks for being patient with us as we develop a plan for these changes. The Ruby SDK already has this functionality correct? It was good intuition on your part. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple suggestions but looks good
…the manage data ops Co-authored-by: Jake Urban <10968980+JakeUrban@users.noreply.github.com>
@JakeUrban Thanks. I made those changes to the protocol. |
I'm slightly curious/concerned that allowing N Manage Data Ops will give room for anchors-client pairs to start using that functionality to pass non-standardized key-value pairs. I don't know how to feel about that, what do you think? @leighmcculloch |
@JakeUrban That's possible. It's not clear to me that it'd be a problem if that happened. As long as a server doesn't include operations that are intended for the client to sign/authorize for, which is prevented by the requirement that the source accounts of any additional ops be the server account. An anchor-client pair could do this today without this change too. And in both cases they need to modify the SDKs since the challenge transaction build functions don't allow adding arbitrary manage data ops. An alternative would be to add the |
But that won't be the case with this change. A specific client-server pair could have 2 additional manage data ops to store account data, say. They expect the home domain op first as specified by the standard, then the 2 custom ops. With SEP-10 3.0, the order changes. The second Manage Data op will be something different than it used to be, which would likely require them to adjust the expectations in their code. |
In v3.0.0 the order of additional ops after the first op isn't intended to matter. Let's discuss on #741 how we can clarify that in v3.0.0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look good – I left a few suggestions to reduce ambiguity 👇
Hi everybody. Let me describe why.
This approach will give the possibility to extend resulting JWT with any data the parties agreed on. |
What
Revert home domain verification and relax manage data operation constraints allowing additional manage data operations as long as their source account is the server account.
Why
There's been some ambiguity about the intended contents of home domain and in the interest of encouraging compatibility between servers and clients I think we need to consider reverting verification the SEP and SDKs are requiring on that field.
The relaxing of the manage data operations so that we can add a new manage data operation in that adds a new hostname for verification. Allowing additional manage data operations with the server account as the source account will allow future releases to add additional fields of data without breaking older clients. Requiring the source account to be the server account ensures that if there is a need in the future to add new fields that the client should confirm and sign for, that older clients won't blindly sign those challenge transactions.
This change is backwards compatible with v2.0.0.
Example Implementations
stellar/go#3108
stellar/js-stellar-sdk#580