Subject: [VCARDDAV] Signed vCards

From: Michael Angstadt <[email-masked]>
Date: Sun, 1 Sep 2013 09:33:21 -0400

I don't think that example is appropriate.

Also, why are you including the SOCIALMEDIA property in this specification?
 What does that have to do with signed vCards?

On Sunday, September 1, 2013, DataPacRat wrote:

> Would it be within reason for me to use the following as an example
> for the DATE parameter?
>
> N;DATE=1987-12-17/2013-08-22:Bradley
> N;DATE=2013-08-22:Chelsea
> GENDER;DATE=1987-12-17/2013-08-22::M
> GENDER;DATE=2013-08-22:F
>
>
>
> Thank you for your time,
> --
> DataPacRat
> "Then again, I could be wrong."
>

---

From: Etan Wexler <[email-masked]>
Date: Sun, 1 Sep 2013 09:47:01 -0400

No, DataPacRat, it wouldn’t be within reason that you include
allusions to Chelsea Manning in an Internet Draft (“Internet-Draft”).
Nor would it be within the bounds of personal respect that you
broadcast in an Internet Draft your presumptions about her gender or
genders.

---

From: DataPacRat <[email-masked]>
Date: Sun, 1 Sep 2013 10:18:00 -0400

> I don't think that example is appropriate.

Would a more historical example be within bounds? Eg:

N:Chevalier d'Eon
BDAY:1728-10-5
GENDER;DATE=1728-10-5/1774:M
GENDER;DATE=1774/1810:F
DEATHDATE:1810-05-21

(Source: https://en.wikipedia.org/wiki/Chevalier_d%27Eon and links therefrom)

> What does that have to do with signed vCards?

The primary purpose of signed vCards is to allow for
cryptographically-authenticated "identity assertion" (as opposed to
current vCards, which are more along the lines of "identity
description".). For various reasons, online identities have become
more complicated than in the early years of the internet, and there
are a number of situations in which it's infeasible to use, say, a
simple email address as a canonical identity string. The existing URL
property is insufficient to describe such things as forum profiles,
rss feeds, Tor-network hidden-site communications, and so on. Thus, I
believe the SOCIALMEDIA property is necessary to have established in
order for signed vCards to fulfill their purpose.

There doesn't seem to be any particularly good reason to split
SOCIALMEDIA into its own Internet Draft, and there is arguably good
purpose to keeping it with the rest of the identity-assertion bundle
of properties, so it's currently all part of the same draft. If the
benefits to creating such a split were shown to outweigh the costs of
working with two I-Ds instead of one, that could change, but I don't
expect that to happen.

Thank you for your time,

---

From: Michael Angstadt <[email-masked]>
Date: Sun, 1 Sep 2013 15:02:33 -0400

> GENDER;DATE=1728-10-5/1774:M

No. -_-

---

From: DataPacRat <[email-masked]>
Date: Sun, 1 Sep 2013 16:03:01 -0400

>> GENDER;DATE=1728-10-5/1774:M

I'm afraid that I don't understand the reasoning behind your rejection
here, and so I know neither what you would find acceptable, nor
whether your criteria are valid ones to use in this context. (Put
another way, I don't know whether you're objecting to the two
gender/date examples I've proposed so far because it's insulting to
those particular individuals, or because they're offensive to to some
group, or because the very idea of using vCards to describe the
transitions of transgendered people is something you wish to avoid.
Since the latter is part of the core of the premise that "identity is
complicated", which is what this I-D is supposed to cover, if that's
the reasoning in play, it seems counter-productive to avoid such an
example; but at this point, I can't tell whether or not that's the
basis behind your objection.)

So I'll try again: instead of a present-day or historical figure, what
about a fictional one? Eg:

N:Dax
GENDER;DATE=2285/2367:M
GENDER;DATE=2367/2374:F

(Reference: http://en.memory-alpha.org/wiki/Dax_%28symbiont%29 )

Thank you for your time,

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 1 Sep 2013 16:27:34 -0400

The most common case of identity change is a name change by e.g., marriage. Please use that - you can illustrate a name change and email address change and even a mailing address change all with that one use case. You can stick an anniversary property in there too to illustrate the point. 

-- 
Cyrus Daboo
(Tapped out on my iPhone)

> On Sep 1, 2013, at 4:03 PM, DataPacRat <[email-masked]> wrote:
>

---

From: Kevin Marks <[email-masked]>
Date: Sun, 1 Sep 2013 13:45:03 -0700

If you want to construct an appropriate example of gender transition, talk
to Sarah Dopp, who advised on the nuances for vcard 4.
I'm pretty sure you should be using the gender identity component rather
than the sex component.
On Sep 1, 2013 7:18 AM, "DataPacRat" <[email-masked]> wrote:

> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>

---

From: DataPacRat <[email-masked]>
Date: Sun, 1 Sep 2013 16:57:20 -0400

> The most common case of identity change is a name change by e.g., marriage. Please use that - you can illustrate a name change and email address change and even a mailing address change all with th…

You mean something along these lines?

BDAY:1990-01-01
FN;DATE=1990-01-01/2010-06-12:Jane Doe
EMAIL;DATE=P2Y/2010-06-12:[email-masked]
ADR;DATE=P2Y/2010-06-12:;;123 Main Street;Any Town;CA;91921-1234;U.S.A.
ANNIVERSARY:2010-06-12
FN;DATE=2010-06-12:Jane Doe Smith
ADR;DATE=2010-06-12:;;456 Blackacre Road;Any Town;CA;91925;U.S.A.
EMAIL;DATE=2010-06-12/P9M:[email-masked]
EMAIL;DATE=2011-03-15:[email-masked]

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Sun, 1 Sep 2013 17:08:09 -0400

I would be more than happy to accept any suggestions and advice from
anyone who has a better understanding of gender identity issues than I
do.

Sarah, as of the current draft for extending vCard (
https://datatracker.ietf.org/doc/draft-boese-vcarddav-signedvcard/),
I'm not planning on changing vCard's "GENDER" property (
https://tools.ietf.org/html/rfc6350#section-6.2.7 ), save by adding
two parameters to all properties: DATE (which can be a particular
moment, or a period of time) and CONFIDENCE (assigning a numerical
value to how accurate the property's value is believed to be). I would
like to use a gender transition as an example of how to use at least
one of those two new parameters, which is what sparked this current
conversation. I welcome any commentary you might wish to offer.

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Sun, 1 Sep 2013 17:45:01 -0400

Another set of details I'm considering adding is more extensive
information on deciban values. I keep a textfile with a table
describing them handy for my own reference; would it be worthwhile to
include some or all of this in the description of the CONFIDENCE
parameter?

Decibans / Level of belief / Rough Odds / notes

-127 / 0.00000000002% / 1:5 trillion / min belief storable in one signed byte

-30 / 0.1% / 1:1,000 /
-20 / 1.0% / 1:100 /

-10 / 9.9% / 1:10 /
-9 / 11.2% / 1:8 /
-8 / 13.7% / 1:6 /
-7 / 16.7% / 1:5 /
-6 / 20.0% / 1:4 /
-5 / 24.0% / 1:3 /
-4 / 28.5% / 2:5 / a reasonable doubt
-3 / 33.3% / 1:2 /
-2 / 38.7% / 2:3 / probable cause
-1 / 44.3% / 4:5 /
0 / 50.0% / 1:1 / neither belief nor disbelief; agnosticism, 1 bit
1 / 55.7% / 5:4, 1.25:1 /
2 / 61.3% / 3:2, 1.5:1 /
3 / 66.6% / 2:1 / clear and convincing evidence
4 / 71.5% / 5:2, 2.5:1 /
5 / 76.0% / 3:1 / beyond a reasonable doubt, 1 standard deviation, 2 bits
6 / 80.0% / 4:1 /
7 / 83.3% / 5:1 /
8 / 86.3% / 6:1 /
9 / 88.8% / 8:1 / 3 bits
10 / 90.9% / 10:1 / one nine
11 / 92.6% / 25:2, 12.5:1 /
12 / 92.5% / 15:1 / 4 bits
13 / 95.2% / 20:1 / lone studies with p=0.05, 2 standard deviations
14 / 96.2% / 25:1 /
15 / 96.8% / 30:1 / 5 bits
16 / 97.6% / 40:1 /
17 / 98.0% / 50:1 /
18 / 98.4% / 60:1 / 6 bits
19 / 98.8% / 80:1 /
20 / 99.0% / 100:1 / two nines, lone studies with p=0.01

21 / 99.26% / 125:1 / 7 bits
24 / 99.62% / 250:1 / 8 bits
26 / 99.7% / 400:1 / confirmed studies with p=0.05, 3 standard deviations
27 / 99.80% / 500:1 / 9 bits
30 / 99.9% / 1,000:1 / three nines, 10 bits
40 / 99.99% / 10,000:1 / four nines, confirmed studies with p=0.01
42 / 99.993% / 16,000:1 / 4 standard deviations, 14 bits
45 / 99.9968% / 30,000:1 / 15 bits
50 / 99.999% / 100,000:1 / five nines
60 / 99.9999% / 1 million:1 / six nines, 20 bits
62 / 99.99994% / 1.5 million:1 / 5 standard deviations
70 / 99.99999% / 10 million:1 / seven nines
80 / 99.999999% / 100 million:1 / eight nines
87 / 99.9999998% / 500 million:1 / 6 standard deviations, 29 bits
90 / 99.9999999% / 1 billion:1 / nine nines, 30 bits
99 / 99.99999998% / 8 billion:1 / 33 bits
100 / 99.99999999% / 10 billion:1 / ten nines
110 / 99.999999999% / 100 billion:1 / eleven nines
116 / 99.9999999997% / 400 billion:1 / 7 standard deviations
120 / 99.9999999999% / 1 trillion:1 / twelve nines, 40 bits
127 / 99.99999999998% / 5 trillion:1 / max belief storable in one signed byte

1,000 / 99.99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999%
/ 10^100:1 /

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Mon, 2 Sep 2013 17:23:52 -0400

Yet another example I'm considering adding is a rough description of
how to use signed vCards to create an ad-hoc certificate authority
system. This would involve one vCard with an authority describing
itself, and signing it all; another vCard where that authority issues
a card describing a second entity and its key, using the CONFIDENCE
parameter to give its level of belief; and a third card where that
second entity describes a third, offering its CONFIDENCE level. And,
finally, a simple analysis of how the first CONFIDENCE value can
affect the second, for anyone who is able to examine the full chain of
vCards. Finishing up with how the full analysis would need to take
into account how trustworthy the reader considers the AUTHORITY to be,
which could be accomplished out-of-sight of a user using web-of-trust
techniques, such as the second and third entities issuing their own
vCards describing their CONFIDENCE level in the first.

Anyone care to comment before I try writing that up?

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Tue, 3 Sep 2013 20:31:05 -0400

Here's my latest write-up for the CONFIDENCE parameter, for whatever
feedback I can evoke before submitting the -02 draft.

3.1.  Parameter: CONFIDENCE

Namespace:

Parameter name: CONFIDENCE

Purpose: To specify the confidence of the authority that the
information of the given parameter is accurate, measured in decibans.

Value type: A single number, usually an integer.

Description:

A CONFIDENCE value of 0 decibans indicates odds of 1:1 (ie, 50%) that
the information is correct. A change of 10 decibans changes the odds by
a factor of 10; 10 decibans means 1:10 odds (~90%), 100 decibans 1:100
odds (~99%), -10 decibans 10:1 odds against (~10%). A change of 1
deciban is roughly equivalent to changing the odds by a factor of 5:4.

Here is a table covering enough integer deciban values to allow for
easy reference.

-127 / 0.00000000002% / 1:5 trillion

-30 / 0.1% / 1:1,000
-20 / 1.0% / 1:100

-10 / 9.9% / 1:10
-9 / 11.2% / 1:8
-8 / 13.7% / 1:6
-7 / 16.7% / 1:5
-6 / 20.0% / 1:4
-5 / 24.0% / 1:3
-3 / 33.3% / 1:2
-1 / 44.3% / 4:5
1 / 55.7% / 5:4, 1.25:1 / preponderance of the evidence
2 / 61.3% / 3:2, 1.5:1
4 / 71.5% / 5:2, 2.5:1
6 / 80.0% / 4:1
7 / 83.3% / 5:1
8 / 86.3% / 6:1
11 / 92.6% / 25:2, 12.5:1
14 / 96.2% / 25:1
16 / 97.6% / 40:1
17 / 98.0% / 50:1
19 / 98.8% / 80:1

127 / 99.99999999998% / 5 trillion:1

Given human factors, it is rare for hand-typed data to be able to have
a CONFIDENCE that every single bit is accurate of more than 50
decibans. Without getting into the details of recursion, and given that
at least one out of roughly ten billion people is thoroughly
disconnected from reality, it's very difficult for a human to have more
than 100 decibans of confidence in anything, even that H2O is a useful
description of water or that the subjective reality they are
experiencing is connected to the same subjective reality experienced by
other humans.

If a user wishes to manually generate signed vCards, but does not have
much experience with mathematics, then one option to get rough
estimates of what CONFIDENCE values are appropriate could be to use
Laplace's Sunrise Formula, also known as the Rule of Succession. This
takes two pieces of input: the number of times in which something might
have gone one way or the other; and the number of times it went one
way. For example, it might be used with the number of times an email
has been received from a particular address, and the number of times
that email has been from the owner of that address instead of viral
spam. The formula produces an estimate of the odds that future trials
will go the same way, by calculating:

FutureProbability = (Successes + 1) / (TotalTrials + 2)

For the example, if one has received 1,000 emails from an address, out
of which 1 was spam, then the formula says that the future probability
will be on the order of (999+1) / (1,000+2) = 1,000/1,002. This implies
that a CONFIDENCE value based on this data would be on the order of 30
decibans - but, barring other forms of evidence, it would take around
10,000 such emails before a claim of 40 decibans of confidence would be
warranted.

Note that this is an extremely simple formula, and there are many
better ones that can provide more accurate results, and take into
account more kinds of evidence. Any user who knows of a better method
to generate CONFIDENCE values should use those ways; the Sunrise
Formula is provided as a basis for users who have nothing else to
create estimates with.

More sophisticated Bayesian analyses can be used to create ad-hoc
certificate authority systems. This would involve one vCard with an
authority describing itself, and signing it; another vCard where that
authority issues a card describing a second entity and its key, using
the CONFIDENCE parameter to give its Bayesianically-generated level of
belief; and a third card where that second entity describes a third,
offering its CONFIDENCE level. A user with access to all the vCards
could then determine, based on its own trust-level of the root
authority, how much to trust the other entities. This trust of the
root authority could be generated either with the Sunrise Formula, or
with an analysis of web-of-trust data.

Examples:

BIRTHPLACE;CONFIDENCE=50:Winnipeg, Manitoba, Canada

ABNF:

confidence-param = "CONFIDENCE=" (INTEGER / FLOAT)

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Fri, 6 Sep 2013 17:07:14 -0400

> confidence-param = "CONFIDENCE=" (INTEGER / FLOAT)

Offlist, I've gotten a suggestion to modify this parameter, by
allowing for two possible values; place a float or integer of the
value in decibans, as currently described; or place a float or integer
followed by a '%', and have the value treated as a straight
percentage. That is, 'CONFIDENCE=20' and 'CONFIDENCE=99%' would
provide just about exactly the same information.

I'm mildly hesitant, as this adds both complexity and the potential
for confusion, as a common typo in hand-generated signed vCards would
be leaving off the '%' symbol. (I also don't want to open the can of
worms of suggesting just using straight percentages only. A
significant part of the reason to use logarithmic decibans is because
it's impossible to know how much accuracy a given piece of software
will use for FLOAT, which would make it all too easy for
99.9999999999% to be confused for 99.999999999%.)

So - anyone here care to weigh in before I decide whether or not to
add this to the next draft?

Thank you for your time,