RE: Blockchain Private Key and Web Same-origin policy

Woops, I misunderstood when I saw the other technical talk going on - sorry Doug!

-----Original Message-----
From: Doug Schepers [mailto:schepers@w3.org] 
Sent: Sunday, May 8, 2016 11:26 AM
To: Neha Narula <narula@csail.mit.edu>; Daniel Buchner <dabuchne@microsoft.com>
Cc: Mountie Lee <mountie@paygate.net>; public-blockchain-workshop@w3.org; public-blockchain@w3.org
Subject: Re: Blockchain Private Key and Web Same-origin policy

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.

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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbloc

>> kstack.org%2fdocs%2fhow-blockstack-works&data=01%7c01%7cdabuchne%40mi
>> crosoft.com%7c7c0bc3237a1647a8a64608d3776e3793%7c72f988bf86f141af91ab
>> 2d7cd011db47%7c1&sdata=xigKYkiJna3JVpF%2fOA5dnhxJHw2XwiDNs2VOEF8Pwh4%
>> 3d
>>
>> - 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%2fnehan

>> aru.la&data=01%7c01%7cdabuchne%40microsoft.com%7cbf7a9d79c597471d68ff
>> 08d3774ea7ec%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gtrPWrykDnb
>> wzMZnzSURkS%2fkKmggyqlb6IACd4D0JcE%3d | @neha
>
>
>

Received on Monday, 9 May 2016 01:40:22 UTC