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

From: DataPacRat <[email-masked]>
Date: Thu, 13 Jun 2013 14:42:01 -0400

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:([email-masked]),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."

---

From: Larry Masinter <[email-masked]>
Date: Thu, 13 Jun 2013 16:11:50 -0700

" clear utility to the broad Internet community..."

If there is utility, it isn't clear.

You're packing lots of metadata irrelevant for locating into the locator.

---

From: DataPacRat <[email-masked]>
Date: Thu, 13 Jun 2013 19:16:35 -0400

> You're packing lots of metadata irrelevant for locating into the locator.

I was hoping to shuffle as much of such extraneous data as possible
into the optional comments fields.

May I ask what you would feel would be safe to remove, and whether
that removal would affect the core goal of stating "Authority X,
confirming with AuthenticationHash ABCD, asserts that Y and Z refer to
the same entity"?

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Fri, 21 Jun 2013 13:18:46 -0400

It's been about a week, and I haven't got any significant feedback on
nym, either positive or negative. So, unless some reason crops up to
do otherwise, I'll probably work on working through the RFC 4395
process whenever I have some spare time to do so; and since there
doesn't seem to be any rush, I'll take the time to do the best job I
can at every step.

(For example, I'm now going to consult with some experts about
calibrating the example levels of decibans.)

Thank you for your time,

---

From: Larry Masinter <[email-masked]>
Date: Fri, 21 Jun 2013 11:32:54 -0700

I'm sorry if you took my polite reply as anything other than
a strong negative. No, 'nym' seems inappropriate as a URI
scheme as poposed.

> -----Original Message-----
> From: DataPacRat [mailto:[email-masked]]
> Sent: Friday, June 21, 2013 10:19 AM
> To: Larry Masinter
> Cc: [email-masked]
> Subject: Re: [Uri-review] Initial inquiry into URI proposal (nym)
>

---

From: DataPacRat <[email-masked]>
Date: Fri, 21 Jun 2013 14:44:27 -0400

Fair enough - thank you for clearing up what you'd meant.

If I may ask, did you receive my reply to your reply? I inquired
whether removing anything would improve the 'extra details' issue you
commented on.

After another question elsewhere, I've come up with another way of
describing what I'm trying to accomplish with nym: that instead of
simply being a direct identifier of a particular resource, it's a
second- or third-order one. That is, while http://twitter.com/Profile
points to a particular online profile, embedding that URL in a nym
would be using it to point to what that online profile points to: that
is, the person identified by that profile.

Does such an approach suggest how nym might be less 'inappropriate' as
a URI scheme?

Thank you for your time,

---

From: Larry Masinter <[email-masked]>
Date: Fri, 21 Jun 2013 15:44:29 -0700

http://www.w3.org/2001/tag/doc/metaDataInURI-31.html 
is a good start.

---

From: DataPacRat <[email-masked]>
Date: Fri, 21 Jun 2013 18:58:30 -0400

>  http://www.w3.org/2001/tag/doc/metaDataInURI-31.html

Having read that page, I'm not quite sure which part of it is supposed
to apply directly to nym.

As a first stab, I'm going to guess that you're unhappy with the way
nym's current draft marks out the confidence-level field, and other
optional comments. Would your opinion of nym improve if I dropped the
comments fields entirely (other than the confidence field); or if I
used different characters than ? and & to mark them off?

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Wed, 26 Jun 2013 02:59:18 -0400

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

---

From: Graham Klyne <[email-masked]>
Date: Thu, 27 Jun 2013 12:12:51 +0100

(For some unknown reason, my email client stopped showing me emails to this 
list, so I'm late responding to this thread.)

You may have identified problem that needs solving (I'm not judging that), but 
I'm not seeing why the solution is another URI scheme.   A key question, for me, 
is an explanation of "what does a nym: URI actually *identify*", which I'm not 
seeing on a quick scan of the materials.  Once that's clear, it's possible to 
ask questions about whether a new URI scheme is needed or appropriate.

You say in your proposal: "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."   But this is not what URIs do:  they 
*identify* things (sometimes by location), they don't "announce assertions".

If you really want to use a URI to convey this kind of assertion, you could 
adopt or design an assertion language and corresponding MIME type, and then wrap 
the whole thing in a data: URI.

#g
--

On 26/06/2013 07:59, DataPacRat wrote:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: DataPacRat <[email-masked]>
Date: Thu, 27 Jun 2013 12:43:42 -0400

> list, so I'm late responding to this thread.)

(No worries.)

> You may have identified problem that needs solving (I'm not judging that),
> but I'm not seeing why the solution is another URI scheme.   A key question,
> for me, is an explanation of "what does a nym: URI actually *identify*",
> which I'm not seeing on a quick scan of the materials.  Once that's clear,
> it's possible to ask questions about whether a new URI scheme is needed or
> appropriate.

A metaphor:

A http: URL is like a finger pointing to a painting, or a finger
pointing to a poem. A nym: URI is a pair of fingers, one pointing to a
finger pointing to a painting of the moon, the other pointing to a
finger pointing to a poem about the moon, and announces that they are
both art about the same moon, even if the painting and poem don't look
anything like each other.

Another attempt: Having just skimmed RFC 2396, section 1.1 of that
mentions that a 'resource' doesn't itself have to be network
retrievable, and can include humans or corporations. If it helps, it's
probably safe to assume that the resources intended to be referred to
by nym: are people. (Though with something approaching the current
proposal, nym: is general enough to refer to just about anything else,
such as a moon.)

> *identify* things (sometimes by location), they don't "announce assertions".

The profile at twitter.com/DataPacRat refers to a particular page on a
particular website; the profile at facebook/com/DataPacRat refers to
an entirely different page on an entirely different website. What I'm
trying (poorly) to do is to have nym: identify the person described by
that twitter page, and by that facebook page, and to point out that
both of those persons are the same person.

Perhaps the current draft of nym: could be improved by making not just
the third, fourth, and further referenced URIs optional, but making
the second one optional as well, allowing a nym: URI to contain just a
single reference; in which case the nym: would be a simple
second-order pointer to whatever that reference is referring to. It
seems likely that a single-reference nym: wouldn't have any purpose to
the level-of-confidence field, authentication hash, or even authority;
but given how much trouble I've been having expressing the basic idea
behind nym:, it might at least be valuable as an introduction to an
indirect reference, if nothing else.

> adopt or design an assertion language and corresponding MIME type, and then
> wrap the whole thing in a data: URI.

Now this is an interesting thought. Not sure yet whether or not it's a
better solution than a URI, but it's certainly worth considering.

After a quick check of MIME types, I've confirmed that there's already
one containing almost everything which a text/nym MIME type would:
text/vcard (RFC 6350). It seems fairly likely that given the amount of
overlap, a proposal for an independent text/nym would be redirected
into a suggestion to simply add a few fields to extend the existing
text/vcard to include the fields nym requires (asserting authority,
dates, confidence-level, authentication hash). Which, quite possibly,
would simply be rejected on the basis that vcard has an entirely
different purpose; leaving the overall certificate-authentication
problem unsolved.

Another possible issue is that a vcard+nym format seems likely to be
limited in spread to roughly the current spread of plain-vcard; which,
even though I have a QR code on my own calling card pointing to a vcf
file, isn't all that widespread.

As far as I can tell, the vcard format was handed to the 'Internet
Mail Consortium' around twenty years ago - which itself closed down at
least ten years ago, leaving just its website for reference purposes.
So I'm not sure what group I would need to get in touch with in order
to even discuss the option - well, that is, short of simply taking it
upon myself to write an updated spec, which seems a bit more arrogant
than working through the established URI proposal process.

This compares to writing up nym: as a URI of second-order referencing,
which, once the bugs are hashed out (which would need to be done
anyway), seems easy enough to get an Internet Draft created; at which
time I can start, for example, getting in touch with the programmers
of software containing contacts to try to persuade them to include
nym:-based functionality, and start hunting down someone in the
CA/Browser Forum or CA Security Council to offer a Bayesian-based
alternative.

So, so far, as far as I can tell, working towards nym: as a URI offers
more paths, fewer blocks, and a greater chance of success of fixing
the identity-verification problem than working towards a text/nym MIME
type. But the latter is still worth keeping in mind as a backup plan
in case something blocks the former approach. (But, as always, I'm
open to being persuaded to change my mind.)

Thank you for your time,
--
DataPacRat
"No man spreads a lie with so good grace as he that believes it." --
John Arbuthnot

---

From: Graham Klyne <[email-masked]>
Date: Thu, 27 Jun 2013 19:05:51 +0100

> anything like each other.

OK, to continue the metaphor, a URI is just a finger, not a hand with more than 
one finger.  If you want to create a stucture that embodies a "pair of fingers", 
that seems to me beyond the scope of what a URI is intended to do.

> proposal, nym: is general enough to refer to just about anything else,

To be clear, I'm making no assumptions about network retrievability.

You seem to be saying that a nym: URI identifies a person, or maybe anything.  I 
feel there's a slight lack of clarity of purpose here.  For example, a common 
practice on the Web is to mint an http: URI to refer to something, and create a 
web resource containing a description of the thing referenced.  This is not 
without its difficulties and controversies, but there are some practices around 
this that can be adopted to avoid most of the bear-traps.  This doesn't need any 
new URI schemes.

What I'm working towards here is: why a new URI scheme?  What are the 
*identifying* semantics of this scheme that differ from all the other URI schemes?

> both of those persons are the same person.

So you're trying to make a URI that (a) identifies things known by two different 
names, and (b) asserts that they are naming the same thing.  This is a common 
enough requirement, but I've never seen anyone try to do it with a URI scheme.

I can only repeat my earlier claim that this is not what URIs are designed to 
do.  I think there are many better ways to address this problem than trying to 
shoehorn a whole new load of semantics into a URI scheme. (I'm not dismissing 
your goal, just suggesting that, as far as I can tell, you're trying to solve it 
with the wrong tool.)

> indirect reference, if nothing else.

I don't think that helps.  From my perspective, we're falling at the first 
hurdle and such details aren't really helpful or relevant.  The second, and 
further identifiers can be combined by some structure that is not part of any 
URI scheme.  This would possibly be a much more general solution to the problem 
you're addressing, as you'd be able to use the full range of existing URI 
schemes to identify the things you want to assert are the same.

> than working through the established URI proposal process.

At what appears to be an early stage of developing the ideas, I'd suggest 
defining a new format that may inherit some properties from an existing format. 
  That would be a relatively low-pain route for developing and exemplifying your 
ideas.  Whether such extensions might eventually become part of an existing 
format, I can't say.  But it seems a better bet to me than trying to stretch the 
very function of a URI in the way you seem to be attempting.

> CA/Browser Forum or CA Security Council to offer a Bayesian-based

You lost me there.  What is a "a URI of second-order referencing"?  If it's 
important, this is something that needs to be clarified, separately from all the 
issues of assertions and confidence.  It maybe that there's already some 
structure that achieves what you are trying to do, but without clear 
understanding, I can't tell.

> open to being persuaded to change my mind.)

Don't bet on the "fewer blocks".  The bar for general acceptance of new URI 
schemes is rather high compared with many of the alternatives, especially new 
data formats/content types.

#g
--

---

From: DataPacRat <[email-masked]>
Date: Thu, 27 Jun 2013 14:43:28 -0400

> On 27/06/2013 17:43, DataPacRat wrote:

If you don't object, I'm going to focus in on one particular point of
your reply. If that item can be cleared up, then the remainder seem
reasonably simple enough to; but if it can't, then there seems little
point in even trying to work out the rest.

> important, this is something that needs to be clarified, separately from all
> the issues of assertions and confidence.  It maybe that there's already some

Yet another metaphor: Back in the '80's, I played around a bit with
assembly programming of 8-bit CPUs. In general, a line of assembly
code consisted of an instruction and one or two pieces of data: "Jump
execution to this address", or "Add this number to that." This was
made much more versatile with what are called "addressing modes",
different ways of referencing a piece of data. There were complicated
variations, but most simply, there were three basic addressing modes.
There was direct addressing: "Jump to memory-entry 42"; there was
relative addressing: "Jump ahead 42 lines"; and there was indirect
addressing: "Jump to the address stored in memory-entry 42".

Most current URIs are based around direct addressing:
"http://www.twitter.com/DataPacRat" points to a particular resource.
Some current URIs allow for relative addressing:
"../different-subdirectory/file.gif". There seems to be a dearth of
ones that allow for indirect addressing: "the person described by
http://www.twitter.com/DataPacRat" or "the person shown in the picture
at ../different-subdirectory/file.gif".

What I'm trying to build with nym (one way or another, and with or
without other complications thrown in), is to have some sort of
structure that uses such indirect addressing: to take any given URI,
such as a webpage or mailto: address, and instead of referring
directly to whatever is pointed at by that URI, having the nym use
indirect addressing to be a reference to whatever that URI describes.
This seems to be within the general scope of URIs being references
that point to things, and to provide a novel form of doing so not
covered by an existing URI.

Does that provide any better clarity of this point?

Thank you for your time,
--
DataPacRat
"A little learning is not a dangerous thing to one who does not
mistake it for a great deal." -- William A White

---

From: David Booth <[email-masked]>
Date: Thu, 27 Jun 2013 15:06:05 -0400

On 06/27/2013 02:43 PM, DataPacRat wrote:
[ . . . ]
> indirect addressing to be a reference to whatever that URI describes.

That sounds very much like
http://thing-described-by.org/
(or the shorter version http://t-d-b.org/ ), except that
http://thing-described-by.org/ also allows the URI to be dereferenceable 
without requiring clients to implement a new URI scheme or protocol.

You might want to look at "Converting New URI Schemes or URN Sub-Schemes 
to HTTP" also:
http://dbooth.org/2006/urn2http/
The abstract:
[[
New URI schemes or URN sub-schemes are sometimes proposed for resource 
identification in applications where the HTTP protocol is deemed 
unsuitable.  This paper argues that URIs based on specialized HTTP URI 
prefixes would be a better choice in virtually all cases, even if the 
resource resolution or data transfer properties of HTTP are insufficient 
for these applications.   A simple recipe is presented for converting 
proposed URI schemes or URN sub-schemes to HTTP using specialized URI 
prefixes.  This technique cleanly separates the use of the URI as an 
identifier (to establish resource identity) from the use of the URI as a 
locator (to retrieve representations).  The resulting capabilities of 
the HTTP URIs are virtually a direct superset of those of URIs based on 
new URI schemes or URN sub-schemes.
]]

David

---

From: Michael Wojcik <[email-masked]>
Date: Thu, 27 Jun 2013 19:20:05 +0000

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of DataPacRat
> Sent: Thursday, 27 June, 2013 12:44
> To: Graham Klyne
> Cc: [email-masked]
> 

Except, according to your description, they aren't. The resources referred to by a nym-scheme URI are "identities", not people or moons or any other sort of entity. You might claim that an identity is an attribute of an entity, but that's a metaphysical proposition that is far from certain. It's more plausible to say that an identity is a concept-label that is understood to describe some particular, singular entity - but that's a very different thing from the entity itself.

And, in fact, your nym-URIs don't refer to identities either, as the resources they identify. Instead they identify an implicit assertion that two or more named entities are labeled by the same identity. That assertion is the resource that the nym-URI actually identifies.

> > You say in your proposal:
> >> "The 'nym' URI announces that a

I don't think this is a problem with the proposed scheme, since I don't see anything in 2396 that prevents an assertion from being the identified resource.

> both of those persons are the same person.

You're making an unjustified ontological leap here. A Twitter or Facebook page does not "describe" a person. The relationship between the resources included in the nym-URI (the Twitter and Facebook profile pages) and the assertion that the nym-URI identifies is rather more tenuous. It's more along the lines of "insofar as each of these web pages might be interpreted as labels for singular entities, all those entities are the same entity at some other level of interpretation".

And this is going to continue to be a significant problem with this proposal, I think. It's difficult to clarify the assertions identified by nym-URIs for two reasons: first because those assertions have no independent record elsewhere (the nym-URI doesn't point to some document where the assertion is recorded), and second because the assertion is founded on a number of assumptions and implicit arguments that have common-sense weight but are formally unsatisfying. You're trying to formalize (by specifying a URI scheme) a thing (personal identity and its relationship to a collection of online resources) that currently has no formal existence.

> second-order pointer to whatever that reference is referring to.

I think that's worse. Then the single-item nym URI has different semantics from the multiple-item nym URI.

> different purpose; leaving the overall certificate-authentication

I'd suggest looking into microformats (http://microformats.org/), which have a much easier path to standardization. Put the things you want in the nym-scheme into a microformat definition, document it, and wrap the microformatted data in a data-URI, as Graham suggested.

I'm sympathetic to the problem you're trying to solve (even though I think it's ill-defined) and your efforts on it to date, but I too don't see why it should be a URI scheme at this point. Users don't need to say "here's a pointer to the assertion (floating somewhere in concept-space) that these various online resources are associated with the same entity". What they need to say is "here's the assertion that these references...". You don't want to identify that assertion; you want to present it.

For that matter, maybe this is something better done with SAML - it is a language for expressing assertions about identity (among other things), after all. But I'm not a huge fan of SAML, as I think its complexity makes for a high barrier to entry, so my suspicion is that you'd have a better chance for adoption with a microformat.

> least ten years ago, leaving just its website for reference purposes.

RFC 2426 defines the current vCard specification (vCard 3.0). An updated vCard would thus go through the IETF standardization process.

-- 
Michael Wojcik
Technology Specialist, Micro Focus

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

---

From: DataPacRat <[email-masked]>
Date: Thu, 27 Jun 2013 16:32:34 -0400

> You might want to look at "Converting New URI Schemes or URN Sub-Schemes to
> HTTP" also:

Thank you for making the suggestion; but it's an approach I already
thought of, and rejected, for a number of reasons, at least two of
them major.

For one, both of them involve establishing or using a particular
domain to use as a storer or redirector; which introduces a single
point of failure, which goes rather against much of the point of
having a distributed protocol/format/whatever.

The other is a classic bit: "There are fourteen separate sites which
store personal identity information in different ways: Let's make a
new one that puts them all together!" -> "There are fifteen separate
sites which store personal identity information in different ways...".

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Thu, 27 Jun 2013 17:24:12 -0400

>> From: [email-masked] [mailto:[email-masked]]

(As an aside - this is precisely the sort of feedback I had hoped to
evoke. Thank you kindly.)

> And, in fact, your nym-URIs don't refer to identities either, as the resources they identify. Instead they identify an implicit assertion that two or more named entities are labeled by the same ide…

Hm... perhaps a different mental model might be useful to build on.

I can offer someone a card, physical or digital, which contains my
contact information: name, phone number, email address, website,
twitter name, Facebook name, LinkedIn name, and so on and so forth.
It's also possible for someone to find any one of those pieces of
information online, without necessarily knowing that any of the others
exist, or that one or more may have been revoked. A nym-URI (if that's
the approach taken) could serve as a distributed sort of reverse
phonebook, so that given any individual piece of information, someone
can find out not just the rest of the information; but also when any
other given piece of information was connected, who was willing to
stick their reputational necks out to confirm that, and related
information.

> And this is going to continue to be a significant problem with this proposal, I think. It's difficult to clarify the assertions identified by nym-URIs for two reasons: first because those assertions have no independent record elsewhere (the nym-URI doesn't point to some document where the assertion is recorded),

We may have somewhat different viewpoints on online interactions. A
significant part of my online interactions are even more ephemeral
than email: instant messages, chatrooms, and similar media in which
people temporarily link up, discuss some matter, and then separate
again, with no permanent record ever having been made. (In fact, in
some Tor-based networking, a significant part of the point is to
ensure privacy by deliberately making /sure/ no unencrypted records
remain.) It would be extremely handy to have some sort of nym-style
method to assert one's identity in such interactions, so that you
really can prove you're the same person they know from some previous
interaction without relying on pre-electricity-level pass phrases. If
nyms only exist in the form of external documents where the assertion
is recorded, that would remove a significant chunk of its usefulness.
Thus, being able to generate a nym-URI on the fly would seem to be
very useful.

(Not all IM systems support file transfer, so if a file-based format
ends up being the preferred approach, it should at least be
lightweight enough to be able to be generated on-the-fly and pasted
into a chat-window.)

> and second because the assertion is founded on a number of assumptions and implicit arguments that have common-sense weight but are formally unsatisfying. You're trying to formalize (by specifying a URI scheme) a thing (personal identity and its relationship to a collection of online resources) that currently has no formal existence.

Ever since I learned of Godel, I've been happy enough to aim for
practical consistency rather than formal completeness. But I take your
point; in fact, knowing that I don't have any special skill at
describing axioms, I hoped to find other people who might be able to
help me hammer out such details as need be.

> I think that's worse. Then the single-item nym URI has different semantics from the multiple-item nym URI.

Fair enough.

> I'd suggest looking into microformats (http://microformats.org/), which have a much easier path to standardization. Put the things you want in the nym-scheme into a microformat definition, document…

I've already come across the microformats site, as they're the ones
who've put together hCard, an XHTML variation of vCard. If I do take
nym into the realm of a file format rather than a URI, I expect I'd
likely do better just to build from vCard itself, and let the
nym-hCard microformat derive from that.

> I'm sympathetic to the problem you're trying to solve (even though I think it's ill-defined) and your efforts on it to date, but I too don't see why it should be a URI scheme at this point. Users d…

I can understand that.

>From what I've been able to pick up about SAML, the requirement for a
third-party for an identity provider makes it unsuitable for solving
the problem I'm working on.

> RFC 2426 defines the current vCard specification (vCard 3.0). An updated vCard would thus go through the IETF standardization process.

(RFC 6350 obsoletes RFC 2426, and describes vCard 4.0.)

Since a nym URI would also have to go through IETF, if I don't have to
worry about digging up whoever inherited the IMC's control of vCard,
then I'm entirely willing to work on that approach instead... either
by updating the vCard format itself, or by putting together a new
"nymCard" format based thereon. (And should anyone here have any
advice on doing so, I would welcome it.)

Thank you for your time,
--
DataPacRat
"A man who has committed a mistake and doesn't correct it, is
committing another mistake." -- Confucius

---

From: Eric Johnson <[email-masked]>
Date: Thu, 27 Jun 2013 14:52:02 -0700

Coming out of lurking mode, this quote captures the crux of the problem.

On 6/27/13 2:24 PM, DataPacRat wrote:
> If
Sounds like you want a nym to carry trust. I don't think it can carry that.

I think it far better to think of this problem the other way around - 
define a document that carries all the characteristics that you're 
currently trying to shove into a "nym". If a nym is sufficiently 
complicated (and the examples seem to be) that you cannot remember it or 
readily transcribe it, then it might as well be in a document anyway. 
See if you can get that document to satisfy the requirements you have. 
Only *then* try to address the problem of whether all of that 
information can be captured in a URI.

I think you'll discover that the answer is "no". In fact, existing 
identity solutions already exist (public/private keys, OpenID, etc.).

Poking at the problem, If I give you a "nym" that identifies me to you, 
I may still want to give a different nym to someone else to identify 
myself differently to them. Personal "eric" is different from work 
"eric", and I don't typically share identifying information across those 
boundaries (actually even more complicated than that). On top of that, 
if I start sharing identity information in order to "prove" myself to 
you, then I might be forcing the exposure of identity information I 
don't really want you to have. Think of social security numbers (SSNs) 
that have been badly abused in the US when companies tried to treat them 
as useful identifying information.

Eric

---

From: David Booth <[email-masked]>
Date: Thu, 27 Jun 2013 19:10:52 -0400

> having a distributed protocol/format/whatever.

That can be addressed using a .well-known URI suffix instead:
http://tools.ietf.org/html/rfc5785

David

---

From: DataPacRat <[email-masked]>
Date: Thu, 27 Jun 2013 22:17:08 -0400

After some reflection, I think that I might be able to accomplish my goals
by making four changes to the existing vCard standard - two so trivial they
can be implemented immediately with X-type experimental fields, one likely
so, and one that was giving me fits before I finally thought of an
obvious alternate approach. (In case you're wondering: adding Authority and
Confidence tags; adding date/time/period fields to any given tag; and
adding an in-line cryptographic hash authenticating the whole shebang.) And
if vCard itself can't be upgraded for this, I can base a new,
vCard-derivedformat on all of the above.

If anybody here can recommend an appropriate mailing list or (set of)
individual(s) I can contact, so that I can get some further feedback as I
try working through IETF's standardization process, then I will do my best
to graciously allow this list to return to its usual discussions on URIs.

I would like to thank everyone who put up with my naive fumblings here, and
especially thank those of you who gave me enough constructive criticism to
help me realize some of my fundamental errors.

-- 
Thank you for your time,
-- 
DataPacRat

---

From: Eric Johnson <[email-masked]>
Date: Fri, 28 Jun 2013 05:48:32 +0000

Kudos to you for continuing to poke at the problem and fumble around.

Good luck. Sorry, I don't have answers to your questions below.

Eric

On Jun 27, 2013, at 7:17 PM, "DataPacRat" <[email-masked]> wrote:

> After some reflection, I think that I might be able to accomplish my goals by making four changes to the existing vCard standard - two so trivial they can be implemented immediately with X-type experimental fields, one likely so, and one that was giving me fits before I finally thought of an obvious alternate approach. (In case you're wondering: adding Authority and Confidence tags; adding date/time/period fields to any given tag; and adding an in-line cryptographic hash authenticating the whole shebang.) And if vCard itself can't be upgraded for this, I can base a new, vCard-derived format on all of the above.
> 
> If anybody here can recommend an appropriate mailing list or (set of) individual(s) I can contact, so that I can get some further feedback as I try working through IETF's standardization process, then I will do my best to graciously allow this list to return to its usual discussions on URIs.
> 
> I would like to thank everyone who put up with my naive fumblings here, and especially thank those of you who gave me enough constructive criticism to help me realize some of my fundamental errors.
> 
> 
> -- 
> Thank you for your time,
> -- 
> DataPacRat