Re: Blockchain Private Key and Web Same-origin policy

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 <https://www.w3.org/2016/04/blockchain-workshop/program-committee.html>
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
>
>