[Uri-review] Initial inquiry into URI proposal (nym)

[DataPacRat <[e-mail]>]

For my own purposes, I’ve started roughly defining a pseudo-URI,
loosely based on ‘tag:’. I initially put it together to use as a
framework for authenticating a peer-to-peer reputation system, but it
seems as if it could be general enough for many other uses, as well.

Going through the process of writing up a full Internet Draft proposal
is a bit of an effort for a personal toy URI, but I don't mind doing
so - if it actually is something worth doing. As far as I can tell,
this mailing list seems to be the most appropriate place to ask the
question: Does nym: meet the very basic requirement for a URI, of
providing "clear utility to the broad Internet community, beyond that
available with already registered URI schemes"? If there's a consensus
here that it does, then I'll try to fill out a scheme registration
template, and proceed as RFC 4395 suggests from there. If not, then I
apologize for taking up your time.

I've posted some of my initial notes at
http://blog.datapacrat.com/2013/06/08/early-draft-for-nym-uri/ and
http://blog.datapacrat.com/2013/06/10/nym-first-improvements/ ; the
contents of which I'll paste below for ease of future reference.



-----8<-----

http://blog.datapacrat.com/2013/06/08/early-draft-for-nym-uri/
Early draft for ‘nym’ URI
June 8th, 2013 by DataPacRat

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:([e-mail]),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.)



http://blog.datapacrat.com/2013/06/10/nym-first-improvements/
Nym: First improvements
June 10th, 2013 by DataPacRat

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.

----->8-----


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