- From: Dr. Nick Lee <nicklee@konkuk.ac.kr>
- Date: Mon, 9 May 2016 08:50:33 +0900
- To: Neha Narula <narula@csail.mit.edu>
- Cc: Vlad Zamfir <vldzmfr@gmail.com>, 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>
- Message-ID: <CAMCAVd8yozSuK2DYf=DA75dcRWey+cUHW67ZzTTs8-FD4_y6sQ@mail.gmail.com>
Hello, As for the additional clarification, there is a community group called "blockchain" in w3c which uses public-blockchain@w3.org. And there is another mailing list with the similar name, public-blockchain-workshop@w3.org. The topic of the thread is perfectly fine for the former. Yet it is not for the latter. Let's keep this only to the former and move on. Cheers, Nick. Youngwhan "Nick" Lee, Ph. D. Blockchain Community Group On Mon, May 9, 2016 at 3:22 AM, Neha Narula <narula@csail.mit.edu> wrote: > 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 Monday, 9 May 2016 01:54:47 UTC