SEP-30 Recoverysigner: multi-party key management of Stellar accounts

瀏覽次數:271 次
跳到第一則未讀訊息

Leigh McCulloch

未讀,
2020年4月24日 下午1:26:302020/4/24
收件者:Stellar Developers

Hi devs,


We’ve been working on a proposal for multi-party key management of Stellar accounts so that an individual could use multiple servers to recover control of a Stellar account where no individual server has control of the account.


The draft exists in SEP-30 Recoverysigner: multi-party key management of Stellar accounts. Howard and I are working on an experimental implementation, and we have a very simple web client that exercises the process of registration and recovery with 1+ servers. We’re planning to experiment with it in Vega, the Latin-America-focused cross-border payment and saving app SDF is working on, when that launches.


This thread is the best place for general discussion regarding the proposal. If you see specific issues or improvements, opening issues, pull requests, or alternative proposals on the stellar-protocol repository is also welcome!


Proposal:

https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0030.md


Experimental Implementation:

Server: https://github.com/stellar/go/tree/master/exp/services/recoverysigner

Issues: https://github.com/stellar/go/issues?q=is%3Aopen+exp%2Fservices%2Frecoverysigner

Demo Client: https://github.com/stellar/recoverysigner-demo-client


Cheers,

Leigh McCulloch

Stellar Development Foundation


Leigh McCulloch

未讀,
2020年5月18日 晚上10:35:512020/5/18
收件者:Stellar Developers
Hi devs,

I am exploring how SEP-30 could be changed to support the rotation of signing keys. The motivation for why is that any system that stores and uses keys may need to support changing those keys for a number reasons including:
  • Routine best practice.
  • In response to a key being leaked.
  • In response to a key being compromised.
  • As a requirement to meet a compliance standard.
I have a draft proposal that builds on the existing protocol outlined at the link below. If you see specific issues or improvements or alternative approaches to achieve this please share here or at the link below.


Thanks,
Leigh McCulloch
Stellar Development Foundation

Leigh McCulloch

未讀,
2020年12月18日 晚上8:22:272020/12/18
收件者:Stellar Developers
Hi devs,

I'm modifying the draft proposal for SEP-30 to remove the urlencoded form data as an acceptable content type for requests. We've been using dual content-types in some SEPs for a while and have discovered that on more complex requests with nested objects and arrays there is no standard or common way to represent these in form data, while it is straight-forward in JSON. This change removes that content-type from requests for SEP-30 and is only being made because the proposal is still in draft state. Given the difficulty to build the form requests for this SEP it is unlikely anyone is using that request format.


Please reply here if this would be a breaking change for an integration you have or are aware. I'll merge the PR on December 23rd.

Thanks,

Anthony BARKER

未讀,
2024年1月11日 中午12:03:461月11日
收件者:Stellar Developers

Hi we put together a demo including SEP-30 with Social Authentication recovery (It doesn't rely on Firebase). 
There are 3 recovery servers you can use to test against for UAT:

A react based demo:
https://sep30-demo.bpventures.us/

Registration Flow diagram


The readme as includes a video overview and swagger docs

Christian Rogobete

未讀,
2024年1月16日 上午10:55:171月16日
收件者:Stellar Developers
Hi Anthony,

thank you for providing the SEP-30 demo. I am the developer of the open source Flutter Wallet SDK and I would like to use your demo servers for an example implementation within the SDK. Would that be okay for you?
The registration defined in SEP-30 requires SEP-10. But unfortunately I can not find the home domains of the demo servers providing stellar.toml. Can you pls. share them?

Thx
Christian

回覆所有人
回覆作者
轉寄
0 則新訊息