For my own purposes, I’m putting together a new pseudo-URI, loosely based on ‘tag:’ ( http://www.taguri.org/ , https://tools.ietf.org/html/rfc4151 ), to use for peer-to-peer distributed reputation systems. What I am aiming for is a common protocol that can easily express this idea: “Authority A asserts that X and Y refer to the same entity” (with a certain amount of certainty) (with an optional comment field) (with an optional authentication hash). Depending on how well it works, I may even look into the Internet Draft submission process to put it on the track to become official.
Early draft for ‘nym’ URI
In math, ‘0.999…’ and ‘1’ are different representations of the same underlying concept. Multiple social media profiles and contact methods can represent the same underlying person. Books can be referred to by their author and title, or their ISBN. The ‘nym’ URI announces that a given authority asserts that two or more representations both refer, at least in a general sense, to the same thing; that is, they describe the same entity in different formats.
Preliminary formatting structure idea:
nym:Authority[,date]:(Identity1)[,date];(Identity2)[,date][;(Identity3)[,date]][?comment1[&comment2][#authenticationHash]
The ‘date’ fields can be any valid ISO 8601 date or time-and-date. If present, they should contain at least a four-digit year. The date for the authority field may indicate any time when the authority field referred to the authority making the assertion, in the same fashion as the “tag:” URI. The date for the authority field should refer to a date reasonably closely correlated with when the authority is making the assertion. The dates for the identity fields, if present, should refer to a point in time when that identity is connected to the underlying entity.
The Authority and Identity fields can be any relevant string. In descending order of preference, these should be:
* Well-formed URIs (eg, “http://www.example.com/SocialMediaProfile”)
* Email addresses lacking the “mailto:” header (which should be assumed to be identical to a field containing that header)
* Domain names
* Valid vCard property types (such as “key:” to indicate a public encryption key)
* Valid FOAF property labels (such as “openid:”)
* Some other field of the form “generalLabel:particularEntity” (eg, “LibraryCard:23043001054082”)
* Any other string
The Authority and Identity fields may have characters escaped. If they contain characters which would allow for misinterpretation of the overall nym statement, they must be escaped. The fields may be enclosed in quotation marks.
The comment fields may contain additional information, which is peripheral to the relationship being asserted between the Identities. Possible uses may include trustcloud whuffie scores, or how the authority knows the individual being identified.
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 entity, 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. If no specific confidence field is entered, the confidence value of the overall nym statement should only be assumed to be ‘greater than zero’.
While people tend to be very bad at assigning accurate confidence levels (eg, when people claim to be 90% sure of something, they’re often wrong 50% of the time), their initial estimates of their confidence levels can be used as the inputs for more sophisticated Bayesian algorithms. Until such time as more accurate estimates are available, here are some possible sample confidence levels:
0 decibans: 50%: You’re not sure whether the last digit of the phone number is a 3 or a 5.
1 decibans: 55% Just slightly more likely than not; a business card handed to you by a stranger.
Up to 10 decibans: to 90%: Someone you’ve chatted to for an evening.
Up to 20 decibans: to 99%: A distant acquaintance, who you talk to once a year.
Up to 30 decibans: to 99.9%: A co-worker who might have been re-organized into a new email since you last heard from them.
Up to 40 decibans: to 99.99%: A family member, who you might accidentally have mis-spelled the email address of.
Around 100 decibans: Your own personal information, closely checked. (There’s still a theoretical chance that you’re wrong, just as there’s a theoretical chance that you’re the star of something like the Truman Show.)
127 decibans: Data which relies on yourself alone, thoroughly re-checked and confirmed by others.
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.
Some examples:
nym:datapacrat.com:(datapacrat@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 extremely high confidence that my name, email address, and Twitter account all point to me, and that I have two social media scores.
nym:example.com:(example.com);(KEY;PGP:http://example.com/key.pgp)
Example.com asserts that its public key can be found at a particular URL.
nym:example.com:(ID1),2000;(ID1),2001
Example.com asserts that that the same identity referred to the same individual on two different dates. Unless some other nym statement is made, it may be assumed that what is being asserted is that the identity referred to the same individual during the entire period between those dates.
nym:example.com:(ID1),2000-12-31;(ID1),2001-01-01?-100
Example.com asserts with strong confidence that ID1 referred to an entity on one day, but did not refer to it on another day. This can be used to revoke an identity, such as if example.com shut down a social media account. (Note that a nym statement with a positive confidence level asserts that /all/ the identities refer to the same entity; while a nym statement with a negative confidence level assrts that /at least one/ of the identities does not refer to the same entity as the others. Thus, in order to make what identity is being revoked clear, the revocation statement should only contain two identity fields.)
Leave a Reply