- From: Neha Narula <narula@csail.mit.edu>
- Date: Sun, 8 May 2016 14:22:29 -0400
- To: Vlad Zamfir <vldzmfr@gmail.com>
- Cc: Daniel Buchner <dabuchne@microsoft.com>, Mountie Lee <mountie@paygate.net>, "public-blockchain-workshop@w3.org" <public-blockchain-workshop@w3.org>, "public-blockchain@w3.org" <public-blockchain@w3.org>
Thanks for clearing that up Vlad! On Sun, May 8, 2016 at 1:02 PM, Vlad Zamfir <vldzmfr@gmail.com> wrote: > Neha, I also felt that this was out of scope, but I suppose that there are > going to be two mailing lists, one for the chairs + program committee and > one public mailing list. > > The workshop is meant to steer a standards process, so any discussion about > standards that doesn't fall under "planning the agenda, soliciting positions > and reviewing positions" would be inappropriate in a forum for planning the > workshop. There's a clear opportunity for conflict of interest, there. I can > spell it out if anyone needs me to, or it ends up being a problem. > > The public mailing list seems to be completely unstructured, on the other > hand, and so far we've only received messages on the public list, as far as > I can tell (list addresses have prefix "public-"). Also, be sure to look at > this list of responsibilities for the program committee, which includes > participating in the public mailing list. > > Doug, could you please ping the planning list so we can start using it? > > Thanks! > <3Vlad > > > On Sun, May 8, 2016 at 8:28 AM Neha Narula <narula@csail.mit.edu> wrote: >> >> I might have misunderstood the purpose of this mailing list, and its >> discussions. I thought it was to discuss topics and coordination >> details for the upcoming workshop happening in late June. Are you >> suggesting this for a topic of the workshop, or am I on the wrong >> mailing list? >> >> I'm new to the W3C, but it sounds like a lot of this is reinventing >> parts of existing systems (DNS and PKIs). I'm happy to discuss >> futuristic identity agent schemes, and have asked questions below. >> >> If we're talking about the workshop, then I think it makes sense to >> talk about user wallets. Wallets (and by that I mean user-specific >> key management for signing blockchain transactions) seem core to any >> of this. >> >> On Sun, May 8, 2016 at 10:53 AM, Daniel Buchner <dabuchne@microsoft.com> >> wrote: >> > >> > How do you propose that this "global blockchain identity" works? For >> > example: >> > >> > - Who signed the transaction creating this "global blockchain identity"? >> > >> > You generate a blockchain transaction that you hold the private/public >> > keys to. That transaction is encoded with a unique name, per a unified hash >> > format. The hash also includes a pointer to off-chain data. What you now >> > have is a recognizable, user-friendly name that a system like Blockstack can >> > index as a globally known name. The data off-chain is signed with the same >> > keys that own the name, thus anyone checking the data can clearly see it is >> > from the name owner. >> > >> > What you now have is provable identity, rooted in the trust of the >> > blockchain, which can have signed data linked to it for use by anyone you >> > allow. >> >> This sounds like DNS. It would be good to understand exactly what the >> specific benefits are of this scheme over DNS. >> >> > - What happens if the entity that signed that is compromised? >> > >> > What happens any other time you give your private keys to someone? Short >> > answer: 1) don't do that 2) there are many mitigations, such as: multi-sig >> > social circle recovery, derivative keys that allow data update but are >> > separate from the actual name ownership keys. >> >> When developing any PKI system, we should plan on keys getting >> compromised. So (1) is not a good answer. (2) should be fleshed out. >> >> > - If no one entity signed it, what keeps anyone from creating a "global >> > blockchain identity" for me against my wishes? >> > >> > The system can prove that they are not you, because you took the name by >> > registering it as a transaction before they did, and you have the private >> > keys to prove it. >> >> This also sounds a lot like the way domain names work on the web >> today. We rely on applications like Google to navigate a reputation >> system of backlinks and figure out how to distinguish between similar >> sounding names. What's the equivalent in this scheme? If you haven't >> seen it, I recommend taking a look at keybase.io. >> >> > - How does my device prove it has been authorized to transact on behalf >> > of this identity? >> > >> > Your off-chain data contains a record of your "Identity Agents", which >> > your identity container uses to check incoming payloads against. When a CRUD >> > op or signature request comes it, this layer makes sure the payload is >> > signed with the identity of someone or thing you have given agency to act on >> > certain fields. >> > >> > - If that device-proof is compromised, how do I revoke those keys? >> > >> > The device only has derivative keys or parts of a multi-factor scheme, >> > so you would lose your identity. You would message your identity container >> > using your private master key and it would then reset your identity data and >> > remove the offending agent/device. >> >> OK, so it sounds like there is still a need for user-wallets. This >> might be a good place to start, independent of the rest of it. >> >> > >> > I would appreciate pointers to information describing the design of such >> > a thing. Barring that, I think user wallets are a much simpler, more >> > reasonable thing to consider. >> > >> > Check this out: https://blockstack.org/docs/how-blockstack-works >> > >> > - Daniel >> > >> >> which the UA will understand >> >> and use in transactions as an identity agent of the user, via its own >> >> unique key. The identity system’s challenge and response loop can be >> >> used to interact with sites, devices, etc., to perform all manner of >> >> actions, such >> >> as: user data storage, messaging, blockchain transactions, etc. >> >> >> >> >> >> >> >> The browser should be extended to do four things: >> >> >> >> >> >> >> >> · Form an agent relationship with a user’s blockchain identity >> >> >> >> · CRUD a user’s blockchain identity data as an allowed agent >> >> >> >> · Sign data on behalf of identity owners it is in agency with >> >> >> >> · Form basic blockchain transactions across chains >> >> >> >> >> >> >> >> With these four capabilities, almost anything you can imagine in the >> >> realm of decentralized identity and app development becomes possible. >> >> >> >> >> >> >> >> - Daniel >> >> >> >> >> >> >> >> From: Mountie Lee [mailto:mountie@paygate.net] >> >> Sent: Sunday, May 8, 2016 12:39 AM >> >> To: public-blockchain-workshop@w3.org >> >> Cc: public-blockchain@w3.org >> >> Subject: Blockchain Private Key and Web Same-origin policy >> >> >> >> >> >> >> >> hi. >> >> >> >> >> >> >> >> let me raise issue for SOP and blockchain private key. >> >> >> >> >> >> >> >> when we expand usage of blockchain private to Web, >> >> >> >> Web SOP will cause some difficult issues. >> >> >> >> >> >> >> >> private key can be generated/stored in secure element of client side. >> >> >> >> user will have ownership of private key and related assets. >> >> >> >> when the usage of key is restricted to specific origin, >> >> >> >> that is different from normal user expectations. >> >> >> >> >> >> >> >> many user will think, "my money can be used on any site when I want" >> >> >> >> but with SOP, "your money can be used on this site only" >> >> >> >> >> >> >> >> SOP is important security policy of Web. >> >> >> >> because the previous thinking are "some resources are from some >> >> origins" >> >> >> >> but now we have more requirements letting user have full control of >> >> assets which user has ownership. >> >> >> >> >> >> >> >> I need opinion for it. >> >> >> >> >> >> >> >> -- >> >> >> >> Mountie Lee >> >> >> >> PayGate >> >> >> >> CTO, CISSP >> >> Tel : +82 2 2140 2700 >> >> E-Mail : mountie@paygate.net >> > >> > >> > >> > -- >> > >> > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnehanaru.la&data=01%7c01%7cdabuchne%40microsoft.com%7cbf7a9d79c597471d68ff08d3774ea7ec%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gtrPWrykDnbwzMZnzSURkS%2fkKmggyqlb6IACd4D0JcE%3d >> > | @neha >> >> >> >> -- >> http://nehanaru.la | @neha >> > -- http://nehanaru.la | @neha
Received on Sunday, 8 May 2016 19:27:22 UTC