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

DataPacRat <datapacrat@gmail.com> Thu, 27 June 2013 21:24 UTC

Return-Path: <datapacrat@gmail.com>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC60F21F9D68 for <uri-review@ietfa.amsl.com>; Thu, 27 Jun 2013 14:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.067
X-Spam-Level:
X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE7KuDqYEo5r for <uri-review@ietfa.amsl.com>; Thu, 27 Jun 2013 14:24:13 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 70B0B21F9BAF for <uri-review@ietf.org>; Thu, 27 Jun 2013 14:24:13 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id hj3so130095wib.16 for <uri-review@ietf.org>; Thu, 27 Jun 2013 14:24:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=t3WSHMTnlTYK+L+vCyyiYiPJ4s4tm1s+LKgDheDt33s=; b=UgYIw4z8jI9FEiXdcqwbpau9XkRddXbS09GJ6SYMcSPWfgjau+dCK4PmiQX3K1F+K5 BGdlIOUgDgOtt6BDaIkDit/rL+ee9NfN8WA7y0e1LRFcm2m5guPDrc/1JAyGKlBpBuol UyiblCL7BaJHU91bdAlgd6U9MmnEfjHHMYfGnidlkxrpVYZ1tRP20gMM4nyc8qf2Y5Jt /38BbF1WM/jYH5zkrurtKNnSCkwfT5IqKSiOzIZn5IOAmtoy+sxeliT/ZkqfmILn771+ taXBouPRTPoUTL/lZHxC9XdIDEjcT91n0fF4XUzqjWHYZvFKrCTiOuxZoxqG67QDR4D6 NwgA==
MIME-Version: 1.0
X-Received: by 10.180.183.40 with SMTP id ej8mr353538wic.37.1372368252547; Thu, 27 Jun 2013 14:24:12 -0700 (PDT)
Received: by 10.194.243.193 with HTTP; Thu, 27 Jun 2013 14:24:12 -0700 (PDT)
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C180881AC175E9@Rock-Exchange1.microfocus.com>
References: <CAB5WduCMF+HMyHPFU1bJkOcbzpyAM063XvCM-uDn2zGAoZkFEg@mail.gmail.com> <C68CB012D9182D408CED7B884F441D4D3471E4101A@nambxv01a.corp.adobe.com> <CAB5WduCz4nRSeMUVKnjmUNEDxzRB54khCiU2-1sqCYr1TKLSFA@mail.gmail.com> <CAB5WduAmmMkwBs5fU4Nzz1S8mTqn_oBp+7j0APSOib51OVSdTA@mail.gmail.com> <C68CB012D9182D408CED7B884F441D4D347221DBE6@nambxv01a.corp.adobe.com> <CAB5WduBfMNnTx1sj2C14vkZRJ+9bibxY=Ee4c6K0KwJF4FQpuw@mail.gmail.com> <C68CB012D9182D408CED7B884F441D4D347221DC55@nambxv01a.corp.adobe.com> <CAB5WduAWR+cxuMDfCsrs1az19=0gX10sbnkqSKnifePgD4=4Lg@mail.gmail.com> <CAB5WduCvMZWu0wLt4Lu2RLTRHtyQv77s4ymy4wtcP9e1OOxvSA@mail.gmail.com> <51CC1E33.6050701@ninebynine.org> <CAB5WduAUbnY4Trnsc41QX_mLkVHDrpB0m_-ObVxCg8gO61hfvw@mail.gmail.com> <B550B44BF8AF314BB00C4E2AC1C180881AC175E9@Rock-Exchange1.microfocus.com>
Date: Thu, 27 Jun 2013 17:24:12 -0400
Message-ID: <CAB5WduDFKJkkBc=ZdACW8s1kMA=EsWRtxUPASEBj23_01r33Kw@mail.gmail.com>
From: DataPacRat <datapacrat@gmail.com>
To: Michael Wojcik <Michael.Wojcik@microfocus.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "uri-review@ietf.org" <uri-review@ietf.org>
Subject: Re: [Uri-review] Initial inquiry into URI proposal (nym)
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2013 21:24:16 -0000

On Thu, Jun 27, 2013 at 3:20 PM, Michael Wojcik
<Michael.Wojcik@microfocus.com> wrote:
>> From: uri-review-bounces@ietf.org [mailto:uri-review-bounces@ietf.org]
>> On Behalf Of DataPacRat

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


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

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.


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

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.


>> 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.
>
> I think that's worse. Then the single-item nym URI has different semantics from the multiple-item nym URI.

Fair enough.


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

I can understand that.


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

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


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