[tor-dev] Creating a p2p identity authentication protocol

[DataPacRat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As suggested by Tor Project's helpdesk, I'm forwarding this message to
tor-dev, in hopes that I might be able to evoke any useful references,
suggestions or commentary.


- ---------- Forwarded message ----------
From: Matt Pagan via RT <help at rt.torproject.org>
Date: Fri, Jun 7, 2013 at 4:42 PM
Subject: [rt.torproject.org #10568] Adapting 'tag' URI into p2p
identity authentication system
To: datapacrat at datapacrat.com


You should subscribe to the tor-dev mailing list and bring this up on that
public mailing list: https://lists.torproject.org

On Fri Jun 07 18:02:44 2013, datapacrat at datapacrat.com wrote:
> I'm working on the initial stages of a project which seems likely to
> be of use to many who use the Tor protocol; and which could itself
> likely benefit from the experience of the people who build and use Tor
> extensively.
>
> I am currently looking into creating a new URI based on 'tag:' (
> http://www.taguri.org/ , https://tools.ietf.org/html/rfc4151 ) to use
> for distributed reputation systems. I would like a common protocol so
> that this idea can be easily expressed: "Authority A says that X and Y
> are the same person" (with an optional field for the certainty of that
> statement) (with an optional comment field) (with an optional
> authentication hash). It seems likely to be simple to implement the
> new URI (perhaps called 'nym:') in existing mail/contact software, so
> that nym: links can be automatically imported into contact lists to
> update them.
>
> Might you be interested in helping me work this out; or pointing me in
> the direction of anyone else who might be?
>
>
> Here's an initial draft of what I mean:
>
>
>
nym:Authority[,DateTime]:(Identity1)[,date];(Identity2)[,date][;(Identity3)[,date]][?comment1[&comment2][#authenticationHash]
>
> While based on 'tag:', there are a number of changes from that URI's
> format:
>
> The authority can be not only an email address or a domain name, but
> some other identifier, such as the URL of a social media profile, such
> as http://twitter.com/DataPacRat or http://www.facebook.com/DataPacRat
> .
>
> The date is no longer limited just to a particular date, but can be
> specified (using ISO 8601 format) down to a particular second, for any
> rapidly-changing identities.
>
> The identities can be plaintext names, social media profile URLs,
> library card numbers, or any other chosen identifiers; though
> regularly-formed URIs, email addresses, and domain names are most
> likely to be most common.
>
> The comment fields are left incompletely defined, to allow for future
> expansion; such as to indiciate trustcloud whuffie scores, how the
> authority knows the individual being identified, or anything else that
> someone comes up with. It seems a good idea to suggest the use of
> existing fields from vCard and FOAF, to ease interoperability.
>
> By default, if a comment field is a number, that number is assumed to
> be how confident the authority is that all the listed identifiers all
> refer to the same individual, measured in decibans. (Decibans are
> logarithmic, with 0 decibans being equivalent to 1:1 odds, or being
> 50% confident; 10 decibans to 10:1 odds, or ~90% confident; 20
> decibans to 100:1 odds, or ~99% confident; and so on.) It is
> recommended that these numbers be integers, unless there is a specific
> reason to be able to specify confidence to greater accuracy; and with
> a magnitude under 128, as it requires extraordinary effort to have 100
> decibans of confidence for even the most fundamental facts.
>
> (This method also implicitly allows for revocation of an identity
> referral, simply by using a negative number instead of a positive
> one.)
>
> The authentication hash is to provide strong evidence that the listed
> authority is actually the one making the assertion. By default, it is
> assumed to be based on whatever public cryptographic key (eg,
> PGP/GnuPG or X.509) is linked to the listed authority ID; and that
> what is being signed is the string of text before the hashmark.
>
>
> This could allow for something like the following:
>
> nym:datapacrat at datapacrat.com:(datapacrat at datapacrat.com),2013-06-
> 05;(http://twitter.com/DataPacRat),2013-06-05;(Daniel
> Eliot Boese)?100&TrustCloud,774&Klout,29#randomhashofletters
>
> ... to indicate that as of that particular date, I indicate with
> maximum confidence that my name, email address, and Twitter account
> all point to me, and that I have two social media scores. (I would
> have used 127 decibans instead of 100 if I'd just been asserting my
> own identity.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (MingW32)

iQEcBAEBAgAGBQJRskfVAAoJEBrKNlQrJtDDHWoIAKn6wCfrQhinNC6zCvf2D3eS
CuSKB0XFPkm903ZwzA29aZKnhC6MJGO78Pu5pUuwZg0oWfB6zJshvmQR9A+QQdif
s0Y84iNoeqVHqAqZgCk3sXPxqaNyEU2yEWREr09qNqVmuu6vhxODNInXf46PjV/6
BAlb26Ea75UwZfMpKY7rxYprTkIbkx3/55r16v8bZyKCKEkcb+0QQWf/pXA114eD
Ec9YXIBEdPDrrhDOe2hAhJWI3ul3pcf/BK13Ch2ngSp757jxGJrz5QxmGNIu+bgQ
Us1SPBS/e8JI9xX2xOa3p/CAh/McxfzFWqPO78t2v77bn/sl45WLfl4RoQ7ulvc=
=9XrL
-----END PGP SIGNATURE-----


Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."