Re: [VCARDDAV] Signed vCards

DataPacRat <> Mon, 01 July 2013 13:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1572F11E8125 for <>; Mon, 1 Jul 2013 06:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.48
X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=1.120, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eFzOoCnRpwCX for <>; Mon, 1 Jul 2013 06:42:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::22c]) by (Postfix) with ESMTP id B706311E811B for <>; Mon, 1 Jul 2013 06:42:08 -0700 (PDT)
Received: by with SMTP id q56so3336844wes.31 for <>; Mon, 01 Jul 2013 06:42:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9VloNBnn1vEXWG6sOS0YlxDfbMLoxKS8ylmdmoj4nyA=; b=vjV8YyhyZUL6HaaVQeikvADoAW4/TuWRY31Oy8zhYHUYF+8MJyaj71EvEjD1H0HpPP IHqjRFSmO6z+bj9thtqKBtzF65YQp2zyq1HMfEYqW+r/04MmJyJScHCyrDmFVSMqH9Pg L1fI1qbE3YNxEPEVWp8tA37DJtFjhhtr1GZ1/cLHCBLtq/9nsBWYbQlQSzNdM46MOklj mN0pN04RBLUwo7ez2J9Uhd9OqMSwIYctBx0YqQujJ0ljtr7UuKsH7c+Xso1sAamtn6wu wBax42i3oeb23gQxg2cNiaiZbndNbUX4W9tcAtvR1GdQVbftdKZDsvB68Dd4Q1smhfH6 YtjA==
MIME-Version: 1.0
X-Received: by with SMTP id wz4mr20208364wjc.28.1372686127880; Mon, 01 Jul 2013 06:42:07 -0700 (PDT)
Received: by with HTTP; Mon, 1 Jul 2013 06:42:07 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Mon, 01 Jul 2013 09:42:07 -0400
Message-ID: <>
From: DataPacRat <>
To: Kevin Marks <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Skip Levens <>, Barry Leiba <>, "" <>
Subject: Re: [VCARDDAV] Signed vCards
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Jul 2013 13:42:10 -0000

On Mon, Jul 1, 2013 at 6:32 AM, Kevin Marks <> wrote:
> On Sun, Jun 30, 2013 at 8:13 PM, DataPacRat <> wrote:
>> On Sat, Jun 29, 2013 at 9:27 PM, DataPacRat <> wrote:

>> > As a related thought; would it be sufficiently useful to add a tag to
>> > state
>> > which of the other fields in that vCard is to be preferred for sorting
>> > and
>> > identification purposes? For example, webfinger and webfist use an email
>> > address as the unique identification string; Apple seems to use UID; and
>> > I'm
>> > trying to work with vCards that have little more than a Twitter handle.
>> >
>> > As a minor variation of the above, perhaps instead of a single canonical
>> > ID
>> > string, a list in preferential order, to allow for better
>> > interoperability
>> > between systems requiring different sorts of ID strings.
>> After some initial fiddling around; something at least resembling the
>> above seems to be a near-necessity, for the various uses I've been
>> able to work with so far.
>> The tricky part seems to be that, when taking one authenticated vCard
>> and using that identity as an authentication authority itself, there
>> isn't any firm rule about what string to use as the identifier for
>> that authority. Given that some vCards have email addresses and some
>> don't; some have UIDs; some have Twitter handles; etc; there doesn't
>> seem to be any practical way to declare that one particular sort of
>> field /has/ to be used as a canonical ID-string. So having a
>> PREFERRED-ID field to have the option to declare what string is most
>> useful to be used as such would make implementing a full-fledged
>> authentication system a heckuvalot easier.
>> And once the field exists at all, it seems that allowing it to list
>> more than one field, presumably in descending order of preference,
>> would allow for easier interoperability between vCard systems
>> containing different subsets of identifying information. Eg, "The UID
>> is the preferred ID-string; but if your particular system doesn't
>> handle that, you could use the email address instead, or failing that,
>> the nickname."
>> As a practical example; the webfist protocol uses email addresses as
>> canonical ID strings, which, with a bit of hash function trickery,
>> allows for relatively easy lookups in the webfist ID database. Having
>> even just a short list of potential ID-strings could allow, if nothing
>> else, all of them to be hashed into a similar database, so that in the
>> future, someone seeking to authenticate that identity can lookup
>> whichever one of those strings they happen to have available to them.
>> So unless someone has a better idea, I'm definitely adding this to the
>> signed vCard proposal. (And since we seem to have passed the initial
>> inquiry stage, I'm updating the subject line accordingly.)

> do email addresses (or acct: extension thereof per webfinger/fist to
> accomodate email-like jabber addresses) and http addresses cover all
> practical IDs?
> A twitter handle is a URL: @kevinmarks is shorthand for
> A facebook ID is an email or a URL - is the
> same as
> The hCard practice is uid's are URLs
> Is there a case I'm missing here?

One case: Identifying a user of a Tor-based forum which allows people
to register nicknames-and-passwords, but doesn't publish individual
member-pages anywhere on its .onion site. There's an identity there,
but no standard IM or email address, or URL to point to.

Another case: Since the system uses Bayesian confidence levels, it's
possible for an authority to use that as the whole point of issuing
vCards for persons who it's only mildly sure about. Eg, using the
PHOTO field as the main identity, adding a FN or NICKNAME, and using a
confidence level of the equivalent of around 60% surety, to have the
vCard state "We /think/ this pic is of this guy, but we could easily
be wrong".

Another: An authority can issue vCards for people who have no (other)
digital presence at all. There's an old practice, now mostly gone by
the wayside, of competent authorities writing letters of introduction
to identify their bearers, which signed vCards could revive with a
modern cryptographic twist.

Another: vCards don't have to be about people at all; one could be
issued with GEO and NICKNAME announce, eg, that a feature at
43.1012,-79.237 has the informal name of "Unexpected Tunnel".

Another: Since the proposal is to add DATE as a parameter which can be
used by any property, that would open up using GEO with DATE to allow
full four-dimensional time-and-space locations. For example, with a
bit of programming jiggery-pokery, a vCard could be issued with data
exported from a GPS, to state "So-and-so was at location A at 09:30, B
at 09:31, C at 09:32, etc - and I'm so confident this was the case,
I'm signing the whole thing". There's no particular reason such a
vCard would be required to use an EMAIL or URL to identify the
thingummy being described in such a way.

... and I'm sure there's more, since I came up with those in just a
few minutes of thought; but they should suffice as inspirational

Thank you for your time,
"And perhaps the horse will learn to sing."