Subject: [VCARDDAV] Initial inquiry into vCard extension

From: DataPacRat <[email-masked]>
Date: Fri, 28 Jun 2013 02:17:59 -0400

To whom it may concern,

I'm currently working on a problem which, after some false starts, I
believe can be solved by adding to the existing vCard specification
(or, failing that, in creating a new specification derived from
vCard). I believe that this is the mailing list and working group to
go over such matters. If that's the case, then I'll be happy to go
into more details. If it's not, then I apologize for intruding, and
ask for nothing more than directions to a more appropriate group.

Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

---

From: Simon Perreault <[email-masked]>
Date: Fri, 28 Jun 2013 10:19:59 +0200

Le 2013-06-28 08:17, DataPacRat a écrit :
> go over such matters.

It is.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: DataPacRat <[email-masked]>
Date: Fri, 28 Jun 2013 05:13:05 -0400

>> vCard). I believe that this is the mailing list and working group to

Thank you kindly for the quick reply.

The problem I am trying to solve involves digital identity management.
I would like to be able to express something like the following idea:
"Authority A asserts that X and Y refer to the same entity, with N
confidence, and confirms the whole assertion using an authentication
hash." I would like A, X, and Y to be broad enough to be any of a
domain name, an email address, or an URL of a social media profile or
another vcf file, among other possibilities. (One of the more
important items for X or Y would be the KEY name, to refer to a public
encryption key which an authentication hash can be based on.)

>From my current understanding of vCard, I think that I might be able
to accomplish my goal by making four changes to the existing vCard
standard - two so trivial they can be implemented immediately with
X-type experimental fields, one likely so, and one that was giving me
fits before I finally thought of an obvious alternate approach. A
summary of these changes are:

* Add a name field, to describe which authority is the one which is
responsible for the vCard. This may or may not be the same as the
person or group described in the vCard itself; for example, I could
write a vCard with my brother's contact information, or an
organization may issue vCards for its members. The quick solution is
to create an X-AUTHORITY name; the more permanent solution would be to
create an AUTHORITY name.

* Add a "confidence level" field. For various mathematical reasons, I
would like this to be based on Bayesian analysis, measured in
decibans. In practical terms, in any vCard, this would have a value of
a number, usually an integer, nigh-certainly between -127 and 127. (I
can go into more detail about this elsewhere.) Again, the short-term
solution is an X-CONFIDENCE name, and the long-term one a CONFIDENCE
name.

* Make some sort of arrangement so that any given field can have a
date, time, date-time, or period (from ISO 8601) to it. Eg, to have
the vCard declare that a particular phone number will be (or was)
valid from January 2011 to June 2013. A quick kludge might be to add a
whole set of X-names, one per name; eg, to describe the date of a TEL
name, using X-TEL-DATE. A longer-term solution would be to add some
sort of time-based property parameter, to go along with Language,
AltID and Geo.

* Finally, and perhaps most importantly, I would like to be able to
take all of the data described above, and within the same stream of
text as the vCard's data (as opposed to being sent in a separate file,
through metadata, or anything of the sort), have a cryptographic hash
to authenticate that the whole vCard was in fact created by the listed
authority. Presumably this will be based on a PGP/GnuPG or X.509 key
referred to in a previously-established KEY entry. Since including a
hash inside the vCard proper would lead to all sorts of difficulties
with recursion, the best idea I currently have is that, after the
vCard's END VCARD line, that a BEGIN VHASH line can be entered. The
hash inside the VHASH block would sign the VCARD block, without
complicating the VCARD proper. However, given the existence of hCard
and jCard, among other derivative formats, this does open a few
potential cans of worms. It may, in fact, be infeasible to do anything
like this with vCard itself; in which case I might have to try working
on a vCard-derived format instead of vCard itself, or take some other
approach.

After having read through this list's last few months of archives,
I've noted that a possible fifth change may be required in order to
allow arbitrary URIs to be included, such as Twitter, Facebook, or
other social media profiles. The current default seems to be
X-SOCIALPROFILE, but as long as vCard is being improved in the above
ways, this might be worthwhile to throw in as well.

If all of these changes (or changes like them) can be made, then what
results is a format allowing for a full-fledged web-of-trust system;
which is simple and flexible enough to be used by people who may or
may not have an email address or a website to post a vcf file to;
which can be exchanged via pasting text in IM/chat clients which don't
allow file transfers; which allows for Bayesian analysis to gauge how
trustworthy any particular member of that web is; and which is
distributed enough to not rely on any particular certificate
authorities or other single points of failure.

I look forward to these ideas being torn apart in as much detail as possible.

Thank you for your time,
--
DataPacRat
"May accuracy triumph over victory."