Author Topic: Delegates going public with their identity -- risks?  (Read 5959 times)

0 Members and 1 Guest are viewing this topic.

Offline roadscape

IF NOT VERIFY(ident.message, ident.sig.gpg)
  user is anonymous
ELSE
  user claims ident.message

So we can reduce to:
Code: [Select]
"ident" : {
  "message"   : "",    # your sworn identity statement
  "sig" : {            # signatures (optional)
     "gpg": "",        # GPG signature of messagehash
 }
}

# Message samples
# Full name:  "I, John Smith, run delegate del.jsmith as of 2014-01-02. Proof: linkedin.com/jsmith"
# Alias only: "Roadhead operates del.roadhead as of 2014-01-02. github.com/roadhead"

As simple as it gets. Perfect. :)
http://cryptofresh.com  |  witness: roadscape

Offline pseudoscops

others might fear that having all publicly named delegates introduces new vulnerabilities.

I'm interested in this. Had always assumed being open about identity would be seen in a more positive light by the community - despite the additional risks this might open an individual up to depending on their location/circumstances. But Troglodactyl's point above seems like a valid one. What do others think, might it be beneficial to try and keep a 50/50 balance of public and anonymous delegates?

If so then perhaps it would make sense to add a new boolean field 'delegate.anonymous' or 'delegate.incognito' to the delegate fields added to public-data that Xeroc and svk were working on recently. See Wiki:

http://wiki.bitshares.org/index.php/Delegate/PublicData

Bravo. Great work as usual Xeroc  :)

As per my earlier post above I'm still interested on what people think the ratio of an know/anonymous delegates should be - 50/50?


Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Good idea to add a BTS sig. Which account would be signing? The delegate account itself, or its operator?
I thought it would make sense to use the delegates key (owner) key for that .. but it really doen't make sense as you have to sign the transaction with that key already .. so scratch that and let's stick with outside crypto .. GPG

Quote
Serializing JSON and hashing it is adding too many moving parts IMO. Something like this might be easier:
Agreed

Quote
Code: [Select]
"ident" : {
  "anonymous" : false,
  "message"   : "",    # your sworn identity statement
  "sig" : {            # signatures (optional)
     "gpg": "",        # GPG signature of messagehash
     "bts" : "",       # BTS signature of messagehash
 }
}

# Message samples
# Full name:  "I, John Smith, run delegate del.jsmith as of 2014-01-02. Proof: linkedin.com/jsmith"
# Alias only: "Roadhead operates del.roadhead as of 2014-01-02. github.com/roadhead"
# Anonymous: (blank)
I think it makes sense to have just one text attribute that can be easily hashed .. no need to have something machine-readable here as people still need to verify what is stated in the message ..

Quote
What do we mean by 'anonymous' delegates? Simply that their real name is not known?
Yep ..
https://bitsharestalk.org/index.php?topic=11898.msg157415#msg157415
but why set the anonymous then in the first place .. we could also go fo

IF NOT VERIFY(ident.message, ident.sig.gpg)
  user is anonymous
ELSE
  user claims ident.message


So we can reduce to:
Code: [Select]
"ident" : {
  "message"   : "",    # your sworn identity statement
  "sig" : {            # signatures (optional)
     "gpg": "",        # GPG signature of messagehash
 }
}

# Message samples
# Full name:  "I, John Smith, run delegate del.jsmith as of 2014-01-02. Proof: linkedin.com/jsmith"
# Alias only: "Roadhead operates del.roadhead as of 2014-01-02. github.com/roadhead"
I would leave "sig" open for other methods for now .. who knows, we could add SSL or a bts signature of the OWNER of the delegate .. not the owner key.. so key "xeroc" for "delegate.xeroc" .. that would make alot more sense then .. maybe something like

Code: [Select]
...
  "sig" : {
     "bts" : {
          "signee" : "xeroc",
          "sign" : "" # signature of HASH(message) signed by signee using bts
      }
   },
...

Offline roadscape

Update:

Code: [Select]
"ident" : {
  "anonymous" : false,
  "text" : {
    "fullname" : "",   # full name
    "proof" : "",      # social media url / url to (img) proof
    "message" : "",    # a message in the line of "I, XXX, run delegate XXX as of XXX" (alternatively, json object with "driver licence id, contact, ..."
    "date" : ""        # date string or timetamp
 }
 "sig" : {             # signatures
     "identhash": "",  # hash of the obect "ident.text" (requires standardized method of representation for json objects!!!)
     "gpg": "",        # GPG signature of identhash
     "bts" : "",       # BTS signature of identhash
 }
}

Thoughts?

Good idea to add a BTS sig. Which account would be signing? The delegate account itself, or its operator?

Serializing JSON and hashing it is adding too many moving parts IMO. Something like this might be easier:

Code: [Select]
"ident" : {
  "anonymous" : false,
  "message"   : "",    # your sworn identity statement
  "sig" : {            # signatures (optional)
     "gpg": "",        # GPG signature of messagehash
     "bts" : "",       # BTS signature of messagehash
 }
}

# Message samples
# Full name:  "I, John Smith, run delegate del.jsmith as of 2014-01-02. Proof: linkedin.com/jsmith"
# Alias only: "Roadhead operates del.roadhead as of 2014-01-02. github.com/roadhead"
# Anonymous: (blank)

What do we mean by 'anonymous' delegates? Simply that their real name is not known?
http://cryptofresh.com  |  witness: roadscape

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I'm concerned about not signing the proof field. If a delegate was compromised, someone could swap in a forged proof and the signed message would appear to support it.

So I think we need the message to contain the proof url, and maybe even the fullname too.

edit:

Actually, I'm thinking every field should be signed. To prevent partial identity hijack,
we need to ensure any change to an "identity" field forces you to re-sign the whole thing.

.. and of course, if people don't want to sign, they don't have to.
But it would be great to have this procedure in place and documented.


Update:

Code: [Select]
"ident" : {
  "anonymous" : false,
  "text" : {
    "fullname" : "",   # full name
    "proof" : "",      # social media url / url to (img) proof
    "message" : "",    # a message in the line of "I, XXX, run delegate XXX as of XXX" (alternatively, json object with "driver licence id, contact, ..."
    "date" : ""        # date string or timetamp
 }
 "sig" : {             # signatures
     "identhash": "",  # hash of the obect "ident.text" (requires standardized method of representation for json objects!!!)
     "gpg": "",        # GPG signature of identhash
     "bts" : "",       # BTS signature of identhash
 }
}

Thoughts?

Offline roadscape

can we come up with a unified json object to store these data:

Code: [Select]
"ident" : {
 "anonymous" : false,
 "fullname" : "",
 "proof" : "",   # social media url / url to (img) proof
 "message" : {
    "text" : "",
    "signature" : "",
 }
}

This is great!

I'm concerned about not signing the proof field. If a delegate was compromised, someone could swap in a forged proof and the signed message would appear to support it.

So I think we need the message to contain the proof url, and maybe even the fullname too.

edit:

Actually, I'm thinking every field should be signed. To prevent partial identity hijack,
we need to ensure any change to an "identity" field forces you to re-sign the whole thing.

.. and of course, if people don't want to sign, they don't have to.
But it would be great to have this procedure in place and documented.
« Last Edit: December 02, 2014, 10:20:57 pm by roadkill »
http://cryptofresh.com  |  witness: roadscape

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
can we come up with a unified json object to store these data:

Code: [Select]
"ident" : {
 "anonymous" : false,
 "fullname" : "",
 "proof" : "",   # social media url / url to (img) proof
 "message" : {
    "text" : "",
    "signature" : "",
 }
}

Offline roadscape

Delegates should be able to choose the level of detail to reveal in their "proof"

 - A hand-written note (for those wishing to be 99.99% anonymous)
 - Just a picture of you, holding your public key on a slip of paper (or use audio/video!)
 - Government Id

Basically, it's a digitally-signable human-signed slip-of-paper. With adjustable levels of anonymity.

I like the idea of anonymous delegates/users showing their handwriting.
So that if additional proof is needed in the future, we would at least have the power to see if the handwriting matches.

edit:

I really dig that Riverhead gave his LinkedIn url on his delegate bid.

So as an example.. If he wanted to take that to the next stage, he could:
 - add his PGP key to his LinkedIn
 - to his delegate, add the linkedin url plus a PGP signature
 - post a signed message here (or wherever the future "delegate central" will be)
« Last Edit: December 02, 2014, 07:22:25 pm by roadkill »
http://cryptofresh.com  |  witness: roadscape

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I'd say, let's wait for the 'vote' features to become online .. maybe BM can drop some details about that particular feature and how it will be implemented ..

anyway .. having a identity attribute would be a good idea ..

Offline roadscape

Maybe PGP (and keyserver?)

Post publicly a photo of your driver's license and hand-written PGP public key..
From then on, you can sign messages proving you are the one who posted the original photo/documentation.

A signed message would be added to delegate info.
"I, XXX, run delegate XXX as of XXX". (It must be updated periodically.)

Also, in the delegate info you could have proof_url -- pointing to a server hosting your uploaded image proof.
http://cryptofresh.com  |  witness: roadscape

Offline pseudoscops

In the short term perhaps the 'delegate.identity.anonymous' boolean is just that - a yes/no that shows your intention to remain anonymous or not. This still serves a purpose. The fact that we can't easily yet prove someones identity does not mean we shouldn't allow people to flag their intention to stay anonymous.

Proving identity is important but could be handled separately to indicating intention to remain anonymous. Having the latter quickly by adding the field to the public delegate data would be a win in my book. To prove ID in the short term might be difficult, time consuming and not an immediate priority. Most people believe with pretty much 100% certainty that BM is Dan Larmier without needing proof. He's built this trust over time and it's probably this sort of public identity that will get us through and be adequate in the short term for those wanting to run publicly. Perhaps a link to LinkedIn might help - still not proof though I know.

As the BitShares ecosystem matures then trusted third-parties already engaged and required to Know Your Customer (KYC) via passports etc could provide verification of delegates as service to the community. They could then provide a publicly available directory of those verified delegates. This might need two 'delegate.identity.verified' & 'delegate.identity.verifier'. Those third parties within the BitShares ecosystem don't exist yet, but maybe there are other services that I'm not aware of that could be leveraged for the purpose of verifying IDs. Do you need to prove your ID to register an SSL certificate? If so maybe we could bootstrap something together that takes advantage of this fact? Maybe others have more experience here and I'm missing something obviously easier to prove ID.
« Last Edit: December 02, 2014, 04:58:52 pm by pseudoscops »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
If so then perhaps it would make sense to add a new boolean field 'delegate.anonymous' or 'delegate.incognito' to the delegate fields added to public-data that Xeroc and svk were working on recently. See Wiki:

http://wiki.bitshares.org/index.php/Delegate/PublicData
I like that idea .. makes it easier for shareholders to figure out publicly known delegates ..
however, there needs to be a way to PROOF that an identity has been revealed .. Any ideas?

Offline pseudoscops

others might fear that having all publicly named delegates introduces new vulnerabilities.

I'm interested in this. Had always assumed being open about identity would be seen in a more positive light by the community - despite the additional risks this might open an individual up to depending on their location/circumstances. But Troglodactyl's point above seems like a valid one. What do others think, might it be beneficial to try and keep a 50/50 balance of public and anonymous delegates?

If so then perhaps it would make sense to add a new boolean field 'delegate.anonymous' or 'delegate.incognito' to the delegate fields added to public-data that Xeroc and svk were working on recently. See Wiki:

http://wiki.bitshares.org/index.php/Delegate/PublicData

Offline hpenvy

  • Sr. Member
  • ****
  • Posts: 451
    • View Profile
In short, everyone just has to assess their own risks in the context of their own circumstances.

This all makes sense, but I'm looking for specific examples to discuss.

Troglodactyl, what country are you in, and what might concern you about going public?

I'm in the United States, and if I were to run a delegate, I would be concerned about tax authorities reinterpreting the rules such that I was in violation, or generally wasting my time and resources determining if I was in violation or not.

 +5%
=============
btsx address: hpenvy
Tips appreciated for good work

Offline cusknee

  • Full Member
  • ***
  • Posts: 174
    • View Profile
  • BitShares: cusknee
Location in certain countries is a great cause for concern.