[VCARDDAV] Signed vCards

DataPacRat <datapacrat@gmail.com> Mon, 01 July 2013 03:13 UTC

Return-Path: <datapacrat@gmail.com>
X-Original-To: vcarddav@ietfa.amsl.com
Delivered-To: vcarddav@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604F621F9E91 for <vcarddav@ietfa.amsl.com>; Sun, 30 Jun 2013 20:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.472
X-Spam-Level:
X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.128, 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 M5h9tMAtbZZU for <vcarddav@ietfa.amsl.com>; Sun, 30 Jun 2013 20:13:06 -0700 (PDT)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 935FE21F9D8B for <vcarddav@ietf.org>; Sun, 30 Jun 2013 20:13:06 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id m46so2843445wev.2 for <vcarddav@ietf.org>; Sun, 30 Jun 2013 20:13:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=WJen7p1UAWJM9Hh1dR/zY7U2ALFj/t2Z+8AmV+H91UE=; b=UtNKKZEYSSLVH8K8lFkdV+WxkxIzOEKADEAlqM5bBtXa5C3LahZC7zwo57uJ+0UrkK pr/uvN7w7vdhdjO7awgkFbhGdghjUR7Rlrt7kfkDmR+Oh777eKSO5gPbDshgcS4G/ICP cnSLXsbGXejDvhioL0PgEzHCmXRJO9mBAKsNkYXJ+iWyHTymNCc+zMTr1ZyulKETMESb dsBdPtVAxxGWC6RwowA8vrG2zv1Nzp/Lr+3+2lfwIy6aRdbemnEEiZVt8QjmJFMg3dSk frhmya6klLPJ31fpRRaEFnnZjlkkMGGbj3wUQIL/A8f4MUjqclYyZNQ/ZkIkW7hOQbZZ fNCQ==
MIME-Version: 1.0
X-Received: by 10.194.243.164 with SMTP id wz4mr18666842wjc.28.1372648385608; Sun, 30 Jun 2013 20:13:05 -0700 (PDT)
Received: by 10.194.243.193 with HTTP; Sun, 30 Jun 2013 20:13:05 -0700 (PDT)
Date: Sun, 30 Jun 2013 23:13:05 -0400
Message-ID: <CAB5WduA09GVZ7j2q4e9aM-CYBj27_deKT=VHhVL0+gzG1yRq0A@mail.gmail.com>
From: DataPacRat <datapacrat@gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Skip Levens <skip@legacyportal.com>, "vcarddav@ietf.org" <vcarddav@ietf.org>
Subject: [VCARDDAV] Signed vCards
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jul 2013 03:13:07 -0000

On Sat, Jun 29, 2013 at 9:27 PM, DataPacRat <datapacrat@gmail.com> 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.)


Thank you for your time,
--
DataPacRat
"Half of knowledge is knowing the questions." -- The Cynic's Book of Wisdom