Differentiating First-Party vs. Second Party & Evidential Claims

As I’m beginning to puzzle through various use cases and business models,
I’m running into something that the current verifiable claim proposal
doesn’t address.

To start the discussion, I’ll talk about some some current practices. I’m
going to also use some terminology that I am not sure is the best language
for this, but is the best that I have puzzled out so far.

We’ll start with a claim that I hold thy @ChristopherA account from Twitter.

Twitter could issue a first-party verifiable claim that I hold the
@ChristopherA quite easily, as it has total control over that account above
and beyond any privileges that I may temporarily hold. As a portable, the
claim from Twitter would be that I hold the account at  particular time,
but they can easily confirm that the account is valid without my
cooperation.They can also actively revoke the account at any time.

Twitter offers services such as OAUTH, that allows a second-party, with my
cooperation, to make a claim that I hold @ChristopherA at particular time.
However, they may, or may not, be able to verify in the future that I still
hold the account — they might have to wait to get my cooperation again via
OATH, but they may be able to check Twitter to see that I still have a
valid account. Any revocation of this type of claim may have wider number
of results: that the original claim at the original time for some reason is
invalid (procedural error, fraud, etc.), that the original claim at the
original time was valid then but the issuer can’t check for current
validity until a future day (say until I can cooperate), or that the
original claim at the original time was valid, but the currently in invalid
(account deleted by Twitter; attempted but failed to get my cooperation to
update, etc.).

There is also a variation on the second-party claim, where evidence is
offered. The simplest version of this is that a nonce is created by issuer
which is posted by me on Twitter using my @ChristopherA account. The issuer
can issue a verified claim saying that the nonce was published and share
the link to the published nonce. This isn’t that much more powerful than
the OAUTH method, however…

Instead, the issuer and I create a cryptographic signature with a nonce and
which I posted on Twitter by @ChristopherA. Like before, the issuer can
issue a claim verifying that the nonce was publicly posted and an
evidential link to it. However, due to the nature of the signature, I as a
verifier can confirm the evidence.

Some complications with the above:

* The issuer may, or may not, have a contractual relationship with either
Twitter to issue the claim, or be Twitter’s agent.

* They may, or may not have had my personal cooperation in the claim or a
contractual relationship with (only in the last cryptographic use case can
the issue prove to others that they had my cooperation).

I think that covers the types, but now to some of the use case issues:

There is a difference between the driver’s license department issuing a
true/false verified that someone is authorized to drive in their
jurisdiction, vs the information that they have verified (say by confirming
your address by mailing your license or that the photo on the license was
the person who applied), vs information that they have verified through
another party (say a credit bureau that confirms that the address on the
license is valid), vs information that is asserted by the holder to the
issuer but not validated (my height and weight, my organ donor preference,
etc.)

There is a difference between a third-party that has a contract that allows
them to connect to the driver’s license bureau to create verified claims
about drivers with or without the drivers permission (say an insurance
company), vs. a second-party that with the driver’s permission scrapes the
driver’s login to the driver’s bureau’s database to create a verified
claim, vs. a second-party that does not have a contract to scrape the
database but does so anyhow.

In many cases these differences have to do with various sources of data
and/or liabilities and contracts. A medical association is typically the
source of a doctor’s certification, but rely on a licensing body for
information on the doctor, and who has the actual liability.

Solutions:

Many.

Right now some thoughts on solutions:

* an optional field in a claim that asserts that this claim is a
second-party claim (I.e. without it it is assumed to be first-party) OR a
non-optional field explicitly require all claims to say if they are first
or second.
* an optional field used by both first-party and second-party claims, that
is a array of additional sources used by the issue to validate the claim
(but not necessarily the evidence), and optionally evidence from those
sources.
* an optional field in the claim’s signature with an array of cryptographic
evidence for the claim (as often you can’t put certain types of evidence in
the claim itself. In a sense, a time-stamp is the first of these.)
* optional link to liabilities/disclaimers document
* more kinds of results from a validity/revocation checks, including “may
be valid, but requires user’s cooperation to confirm. which has been
requested”
* The claim may have secondary revocation — for instance, I can issue and
revoke a certificate for a domain or sub-domain I own, but in fact my
domain is rented, and itself is revokable by yet another party.
* I may also choose a revocation or validation service that is separate or
additional to my issuing service (ala SSL-Revoke proof-of-concept).

For 1.0 purposes, I’d be happy to just see only the first with an optional
non-semantic notes text field.

I’m not sure that this addresses the problems raised in the Portable
Reputation Toolkit proof of concept from the last #RebootingWebOfTrust
https://github.com/WebOfTrustInfo/portable-reputation-toolkit where they
would like to see a difference between Proposition, Evaluation and Evidence
in an assertion. It may be orthogonal or it may be related.

— Christopher Allen