DataPacRat's Warren

After chatting with the nice people at Uri-review, I’ve accepted their suggestion that nym, or something like it, would be better constructed more along the lines of a filetype, or even an end-to-end cryptosystem application, than a URI. Thus, I’ve started chatting with the nice people at vcarddav, pkix, and apps-discuss about just that. Specifically, by creating a “signed vCard” extension to the existing vCard standard; and working out an easy-to-use-as-possible set of ways to use such cards.

The name ‘nym’ seems to have been lost entirely in the transition. (Unless it turns out a name is needed for the whole system, but that’s speculative.)

Original

In order to try to evoke whatever constructive criticism might be
found here, I'll try one last time to offer an explanation of why I
think nym has useful potential. Should no such suggestions be
forthcoming, well, I'll have at least given my best shot here.

The problem:

The Certificate Authority (CA) model of authentication on the web is
broken, in ways both several and serious. There are far too many CAs
who are supposed to be trustworthy but aren't; fraudulent certificates
are known to have been issued; man-in-the-middle attacks have been
done. One of the main reasons for such problems seems to stem from a
fundamental assumption of the security model used: a CA is either
trusted, or it isn't.

The web-of-trust model offered by PGP/GnuPG improves on those
assumptions slightly, by offering an additional level of moderate
trust - if enough moderately trusted authorities all support a
certificate or key as being connected to a digital identity, then that
key is assumed to be accurate. Statistical analysis of a large
population of keys allows for somewhat more complicated key
verification, but tends to be impractical for the individual user.

A possible solution, or at least potential improvement:

There's a whole host of mathematics to support the idea that when
faced with an incomplete set of evidence about any fact (such as
whether a key is tied to an individual), the best possible solution is
to use Bayesian analysis. This involves measuring confidences, and
updating them as new evidence is learned, in a particular fashion. (
http://yudkowsky.net/rational/bayes is one introduction to this math.)

The purpose of nym is to leverage as many of the available and
existing technologies as possible, in order to allow a user to apply
Bayesian reasoning to identity verification, as easily as possible;
without being tied to any particular piece of software. The output of
one set of Bayesian reasoning, asserted by a particular authority, can
be used as the input for anyone else's Bayesian analysis. Thus,
instead of the mere two levels of 'trusted' or 'untrusted' used by
CAs, or the three levels used by PGP, users can use an infinite number
of shades of gray to describe exactly how likely it really is that a
given key represents a given individual.

I've run through a few drafts, adding and deleting details; but I
think the above covers all the core points without getting bogged
down.

I'm unaware of any existing solution to the above problem that meets
the described requirements. It would be reasonably simple to cobble
together a piece of software to, for example, replace GnuPG's
web-of-trust model with a Bayesian function; but that would only solve
a small piece of the problem, for one particular group of
keys/identities. However, putting together a URI, which is designed to
point to the abstract identity pointed at by a particular email
address or social media profile, seems to be at least as within the
spirit of URIs in general as tag: is; and offers the potential for
interacting with any form of encryption software, existing or
yet-to-be-written (in much the way that ftp: and telnet: did when
http: came along).

If you feel that the core problem isn't important enough for a URI to
be used as a solution, that's one possible discussion. If you feel
that using a URI is an inappropriate way to solve it, that's another
possible discussion. And if you feel that some URI may be a good idea,
but my initial ideas for nym: are bad, that's yet another possible
discussion. But if you do reply, I would greatly appreciate if you
would, at the very least, let me know at which point you feel nym:
fails, instead of simply offering a generic 'it's a bad idea' without
any specifics. The former sort of response offers something to build
upon, even if it's to build an entirely different solution; the latter
is hard to distinguish from a personal opinion which may or may not be
relevant to the issue at hand.

I look forward to my ideas being torn apart in as much detail as possible.

Thank you for your time,
--
DataPacRat
"May accuracy triumph over victory."

Original

Original

Watched John Hodgman’s “Ragnarok” on Netflix, after a recommendation from Kottke. Liked a song I heard. Found only one copy online: http://blip.tv/play/hpcYgf21BAA%2Em4v

Video by David Buckland

Lyrics:
Things fall apart, everything tends to decay
And so it takes a lot to combine atoms in such a way
That they resist the lure of that darkness
that lurks around the edges of every day

So I’m inviting you to join me in this fight
to go down to the river, and come up all three times
Hank Williams was right: no one gets out alive
All we can do is try to have a really good time

Resist the tide, stand in the water
That’s baptism, that’s making light
Electricity is proof that there can be
A little bit of light in all this darkness

So please don’t go so gently into that good night
Rage, rage, rage against the dying of the light
You know you got a voice, to talk with you can call your own!
So clear your throat, and start singing this song:

Resist the tide, stand in the water
That’s baptism, that’s making light
Electricity is proof that there can be light
It takes a lot of work, but oh baby, it’s worth it.

Whether or not you have a ‘business’ for which a card is required, there is still good value in having a social card, sometimes called a networking card – or, if you prefer to go old-school, a calling card.

(I’ve blurred out the details I don’t feel like spreading /too/ wantonly: my phone number, and the QR code which contains my name, email address, phone number, and a link to an online vCard file which contains the most recently updated versions of all of the above.)

I know of few-to-none business cards which contain cuneiform. I know of even fewer which have it as an accurate translation of information on the card, rather than as merely a background decorative element. (Ditto Mayan hieroglyphs, Egyptian hieroglyphs, tengwar, Ogham, Morse code of a ham radio callsign, international phonetic alphabet, etc.)

Original

Recursion and reflexivity: If nym ever does become a formal IETF spec, then it would be a full-fledged URI; which would mean that the Identity fields in a nym could themselves be nyms. I don’t see any reason to rule this out, as long as it’s made clear that if a nym is used as an identifier, the identifier is referring to the act of assertion made by the nym rather than whatever that nym is itself referring to.

Time periods: ISO 8601 and RFC 3339 allow for time-strings that don’t just refer to a moment, but to an extended period of time. This seems to be quite useful, such as using the string “2000/P1Y” to refer to the whole of that year. And since the current draft for nym’s format doesn’t use the “/” character, no extra ambiguities seem to be introduced by allowing such date-fields.

Next up: Looking up whether there are any ISO or RFC standards on numbers and mathematical notation; and checking on whether it’s meaningful to measure decibans with complex numbers, or if nym should limit the confidence field to real numbers.

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.)

I’ve been in touch with the authours of RFC 4151, and they don’t endorse complicating up that simple protocol with my ideas for an authentication URI. I can fully understand that, and don’t disagree.

Thus, if the idea does get off the ground, it will nigh-certainly be under a different name than ‘tag:’. The first few possibilities that came to my mind were ‘nym:’, ‘dub:’, ‘peg:’, and ‘id:’.

Relatedly, they pointed out that the dating could be improved. So I’m most likely going to have the new URI, whatever its name is, allow for not just a date for the authority, but also for each identifier being described, so that the system can express the idea “The person who had email X on 2013-06-05 is the person who had email Y on 2013-06-06”. (If done right, this could also allow for the expression of “The person who had email X on 2000-01-01 is the person who still/also has email X on 2012-12-21”.)