Re: Blockchain Private Key and Web Same-origin policy

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