Re: Blockchain Private Key and Web Same-origin policy

I know we said this was going off topic here but since these questions and
comments were posed, I just want to respond to them here to clear up any
confusion.

This sounds like DNS. It would be good to understand exactly what the
> specific benefits are of this scheme over DNS.


Here's a writeup of some of the benefits:
https://blockstack.org/docs/blockstack-vs-dns

When developing any PKI system, we should plan on keys getting
> compromised.  So (1) is not a good answer.  (2) should be fleshed out.


Blockstack has support for:

1. multi-key ownership of names & identities
2. revocation certificates
3. the ability to define a set of keys as the authorities that can reset
ownership
4. the ability to derive child keys for day-to-day use, keeping the master
key stored away for infrequent access only

With these options, if you properly set up your account, you should be able
to recover from any theft or loss scenario.

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.
>

It sounds like Daniel is referring to exactly the types of verifications
that are performed by both Keybase and Onename (built on Blockstack).

Thanks! Would love to continue this discussion on the other list or
elsewhere.

Ryan

On Sun, May 8, 2016 at 11:27 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
>
>


-- 

*Ryan Shea*   *blockstack.org* <http://blockstack.org/>

*Cell: 650-564-7432 <650-564-7432>*

*Skype: ryaneshea*

Received on Wednesday, 18 May 2016 15:09:39 UTC