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

Michael Wojcik <Michael.Wojcik@microfocus.com> Thu, 27 June 2013 19:19 UTC

Return-Path: <Michael.Wojcik@microfocus.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 336D821F9E6D for <uri-review@ietfa.amsl.com>; Thu, 27 Jun 2013 12:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 pxBHscmXeHFV for <uri-review@ietfa.amsl.com>; Thu, 27 Jun 2013 12:19:37 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.148]) by ietfa.amsl.com (Postfix) with ESMTP id 52E3321F85CC for <uri-review@ietf.org>; Thu, 27 Jun 2013 12:19:37 -0700 (PDT)
Received: from [85.158.139.19:9078] by server-12.bemta-5.messagelabs.com id C0/1A-22750-7409CC15; Thu, 27 Jun 2013 19:19:35 +0000
X-Env-Sender: Michael.Wojcik@microfocus.com
X-Msg-Ref: server-12.tower-178.messagelabs.com!1372360774!24563907!1
X-Originating-IP: [63.172.247.30]
X-StarScan-Received:
X-StarScan-Version: 6.9.9; banners=microfocus.com,-,-
X-VirusChecked: Checked
Received: (qmail 21323 invoked from network); 27 Jun 2013 19:19:34 -0000
Received: from unknown (HELO Rock-Exchange1.microfocus.com) (63.172.247.30) by server-12.tower-178.messagelabs.com with SMTP; 27 Jun 2013 19:19:34 -0000
Received: from ROCK-EXCHANGE1.microfocus.com ([fe80::2d6f:6574:e831:417d]) by Rock-Exchange1.microfocus.com ([fe80::2d6f:6574:e831:417d%14]) with mapi id 14.02.0309.002; Thu, 27 Jun 2013 15:20:05 -0400
From: Michael Wojcik <Michael.Wojcik@microfocus.com>
To: "uri-review@ietf.org" <uri-review@ietf.org>
Thread-Topic: [Uri-review] Initial inquiry into URI proposal (nym)
Thread-Index: AQHOaGX4Ct9tNJSUp0iRwhYDXdPHbZk0iQYAgAABVICADC6uAIAAFLYAgAADOoCAAEMRgIAAA+oAgAbPqQCAAdksgIAAXHAA///YQUA=
Date: Thu, 27 Jun 2013 19:20:05 +0000
Message-ID: <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>
In-Reply-To: <CAB5WduAUbnY4Trnsc41QX_mLkVHDrpB0m_-ObVxCg8gO61hfvw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.150.13.247]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 19:19:42 -0000

> From: uri-review-bounces@ietf.org [mailto:uri-review-bounces@ietf.org]
> On Behalf Of DataPacRat
> Sent: Thursday, 27 June, 2013 12:44
> To: Graham Klyne
> Cc: uri-review@ietf.org
> 
> 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.

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

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.

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

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

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

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

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