- From: Nate Otto <nate@ottonomy.net>
- Date: Thu, 28 Jul 2016 09:56:37 -0700
- To: David Chadwick <d.w.chadwick@kent.ac.uk>, Manu Sporny <msporny@digitalbazaar.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAPk0ugkEdfsxMhWf6nDY70YXezB15h8bHv0pHGLDDyXe9kCppQ@mail.gmail.com>
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
Received on Thursday, 28 July 2016 16:57:07 UTC