Re: Questions about Linked Data Signatures for Verifiable Claims

 Thanks, Manu, for the in-depth response. Some response and follow-ups from
30,000ft over Oregon:

>From Manu:
> We might need to be careful with this, as a few of the organizations
that we're talking with want to offload the inspection of verifiable
claims to other organizations.

Noted, though it seems like if we're going to build something complicated
(if this use case is justified), we could provide a mechanism for the
inspector to ask for a record signed to the key of the verification service
they wish to use.

> That said, I'm not sure this really protects one's privacy as the
> information is in clear text and in 99.9% of the cases, that information
> is going to be valid.

> So, the question is - what's the actual attack? What are we trying to
> prevent?
> ...understanding the use cases for this feature are important.

Use case: Advertising network pays $0.01 for all verifiable claims people
share with it in order to add to its database of consumer targeting data.
The network doesn't pay for claims it can't verify, because suppliers could
game the system and generate huge amounts of fake data. Users don't want
their data included in the advertising network and opt to use verifiable
claims with forward-sharing protection.

I agree this would make the system quite a bit more complex (for some
credentials). I don't grant that this wouldn't provide some protection to
user privacy. If large-scale consumers assumed that 99% of claims they
couldn't verify that they came across were nevertheless accurate, a user
could pollute the space with a large amount of plausible noise in terms of
claims about them, that would be initially trusted, and then would rapidly
degrade over time as consumers learned they couldn't depend on this data. I
think claims that can be verified would have a much higher degree of trust
after a short while.

> If the answer is "make sure information is not shared", we may find
> that's impossible to do given bad actors in the system (for example,
> inspectors that forward information to other organizations via 3rd party
> information sharing agreements).

If I trust an inspector who asserts that some claims they received are
valid, then you're right -- this doesn't provide much protection within
that relationship. But if that trust is not absolute, and where it doesn't
extend, there would be protection.

> We may find that the W3C Permissions and Obligations Expression language
> to be more useful to us than making the crypto more complex:
> http://w3c.github.io/poe/vocab/
> ... coupled with enough Common Law to give the restrictions some legal
bite.

This is interesting. Thanks for the link. I may have use for this in a
number of places, whether or not the complex forward sharing system is to
be built.

> and if you dereference the "owner" of that key, you should get:
> {...}
> ... plus any other information you deem appropriate.

This is probably worthy of another thread, but I'm interested in ways that
key owner descriptions may be portable between systems or not need to have
a HTTP @id. I suppose if I need to put my key on an HTTP server somewhere,
I could presumably put it somewhere I control and update the reference to
the key owner when I want to change hosts.

URLs sure are the easiest, but what about putting a description of the
owner in the key file itself, and then using that key to sign the file
instead of hosting the identity elsewhere indexed by HTTP? We want to
enable users to move their identity from being dependent on one service to
another. I'd like their identity endpoint service to be discoverable from a
key file or a linked data blob describing them, but not sure what the most
viable mechanism to accomplish that it.

> Keep in mind that every option other than an HTTP URL needs to have a
> corresponding dereferencing mechanism that the client understands (that
> is, how do you get at the data pointed to by the identifier?).

True, HTTP is pretty easy and built in to almost everything. Limit the
number of complicated things you're doing.


Dave, I'll respond to your questions next; they are good questions to ask
about an idea like this.


Nate Otto
Director of Technology, Badge Alliance
badgealliance.org