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

Graham Klyne <> Thu, 27 June 2013 11:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 153C421F9A31 for <>; Thu, 27 Jun 2013 04:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XmkxQqg3AlSA for <>; Thu, 27 Jun 2013 04:13:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1D92821F9A1F for <>; Thu, 27 Jun 2013 04:13:48 -0700 (PDT)
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1UsA93-0007oj-dM; Thu, 27 Jun 2013 12:13:45 +0100
Received: from ([] helo=conina.local) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1UsA92-0007Y6-4f; Thu, 27 Jun 2013 12:13:45 +0100
Message-ID: <>
Date: Thu, 27 Jun 2013 12:12:51 +0100
From: Graham Klyne <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: DataPacRat <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
Cc: "" <>
Subject: Re: [Uri-review] Initial inquiry into URI proposal (nym)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Proposed URI Schemes <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Jun 2013 11:13:54 -0000

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


On 26/06/2013 07:59, DataPacRat wrote:
> 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. (
> 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."
> _______________________________________________
> Uri-review mailing list