- From: Doug Schepers <schepers@w3.org>
- Date: Mon, 9 May 2016 12:20:18 -0400
- To: Harry Halpin <hhalpin@w3.org>, Neha Narula <narula@csail.mit.edu>, Daniel Buchner <dabuchne@microsoft.com>
- Cc: Mountie Lee <mountie@paygate.net>, "public-blockchain@w3.org" <public-blockchain@w3.org>
Hi, folks– Please, respect the purpose of the public-blockchain-workshop list (which I've now moved to BCC), and the time and attention of the people on that list. The public-blockchain-workshop list is only for planning the workshop, not for technical discussion. If you want to continue this technical conversation, you can continue to use the Blockchain Community Group's list, public-blockchain. (In general, it's a bad idea to cross-post messages across lists.) To close the loop on this topic regarding workshop planning, Harry has agreed to give a short presentation on W3C's current work on security, privacy, and crypto, to provide context to the attendees. I'll start another thread on public-blockchain-workshop to discuss that. Regards– Doug On 5/9/16 8:46 AM, Harry Halpin wrote: > > > On 05/08/2016 02:25 PM, Doug Schepers wrote: >> Hi, folks– >> >> Neha is right, this list isn't for discussing technical issues, it's >> for organizing the workshop. >> >> The technical discussion should take place at the workshop itself. >> >> Of course, it's reasonable to raise the SOP as a topic for >> consideration at the workshop, but I don't want to distract the >> workshop planning discussion. > > It's fine to discuss at the workshop. However, I would prefer to have > the discussion have some chance of providing a useful output for future > work. Currently SOP is the only reasonable security boundary that makes > sense in terms of privilege separation for the Web, which is why W3C > WebCrypto and Web Authentication (The Working Groups I started at W3C > after their own workshops and currently maintain) follow SOP. Everything > Neha said is right, and I highly doubt a discussion of removing > privilege separation from the Web would make sense, much less be > implemented by browser vendors. With Bitcoin, we're seeing wallets work > hard to retro-fit forms of privilege separation (i.e. key derivation). > Thus, if anything Bitcoin and blockchain technologies (and the Web) > would probably benefit from increased privilege separation for key > material, not less. Thus, a more productive way to think about this is > not to press for "one keypair = one person with unlimited scope", but > instead try to figure out how the existing Web Security Model can work > in a sensible way with Bitcoin or blockchain technologies. For example, > per-origin key derivation is what Web Authentication does and it works > quite well, with multi-origin authorization enabled with user consent > via OAuth. There's also Content Security Policy and CORS to be taken > into consideration Videos from CSAIL MIT's Security course on priviledge > separation and the Web Same Origin Policy [2] could be useful background. > > cheers, > harry > > > [1] https://www.youtube.com/watch?v=XnBJc3-N2BU > [2] https://www.youtube.com/watch?v=_1C62Twf0vs > > > >> >> Thanks– >> Doug >> >> On 5/8/16 11:27 AM, Neha Narula 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 >>> >>> >>> >> > > >
Received on Monday, 9 May 2016 16:20:26 UTC