Re: Blockchain Private Key and Web Same-origin policy

in your PDF (https://people.rit.edu/smp1697/CSCI762/BlockchainPKI.pdf)

StorJ project(https://github.com/Storj/) is interesting.
they are trying to use user's drive (sharing metadata through blockchain)
any other research for bittorrent and blockchain?

for MIT Certcoin
it is supporting existing PKI (touching part of PKI)
don't we need certificate?



On Thu, May 19, 2016 at 2:34 AM, Jeff Sonstein <jsonstein@gmail.com> wrote:

> some might find this to be useful in clarifying things a bit
>
>   https://people.rit.edu/smp1697/CSCI762/BlockchainPKI.pdf
>
> jeffs
> --
> Jeff Sonstein
> Assoc. Prof. (ret'd)
> College of Computing, R.I.T.
>
>
> On May 18, 2016, at 12:17 PM, Mountie Lee <mountie@paygate.net> wrote:
>
> I'm narrowing mailling list to public-blockchain@w3.org which is
> blockchainCG's.
>
> I shortly reviewed blockstack document(
> https://blockstack.org/blockstack.pdf ) which is quite interesting.
>
> just adding additional comment for PKI.
>
> as my understanding, PKI is public key INFRASTRUCTURE.
> many standards are involved with existing PKI (CMP, PKCS#, ASN.1,
> Certficate, CRL, OCSP,.....)
>
> still I'm not sure
> is blockchain able to SUPPORT existing PKI?
> is blockchain able to REPLACE existing PKI?
>
> the approach to PKI of blockstack seams non of above two cases.
>
> regards
> mountie
>
>
> On Thu, May 19, 2016 at 12:08 AM, Ryan Shea <ryan@blockstack.com> wrote:
>
>> 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*
>>
>
>
>
> --
> Mountie Lee
>
> PayGate
> CTO, CISSP
> Tel : +82 2 2140 2700
> E-Mail : mountie@paygate.net
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net