- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Mon, 15 Feb 2016 11:22:59 -0500
- To: public-credentials@w3.org
On 02/15/2016 10:34 AM, Timothy Holborn wrote: > Is it trusting the entity or the validity of the document and the > contents of that document? You need both, really. It's not enough to be given a valid document if you don't know that it applies to whomever you're talking with. It's also not enough if you know with whom you are talking, but you don't know them well-enough to trust what they're saying. Verifiable claims are mechanism for transferring the trust an issuer has in a holder to the "consumer". The consumer trusts the document because they trust the issuer and the trust that the document is representative of the holder because of, for example, some shared cryptographic binding. I think the primary focus of this work is on the former, but you also need the latter. > > Ie: birth certificate, passport are documents. Yet they are factored to > provide trust about the subject of that document, sometimes only to > specified systems (ie: e-passport, I don't think it can easily be read > outside of customs machinery). The production of those materials are > produced as to make the document tamper evident and/or, so they can be > validated to a level of certainty. > > Rather than specifically trusting something about another entity, it's > more about being able to trust the document IMHO. > > Yet, banking cards are less considered documents and moreover > instruments. The instrument is issued to the holder, who presents and > authenticates for use of the card to initiate an electronic IOU. Is the > transaction ledger therefore the document subject linked to the > (payment) instrument? > > Perhaps therefore It's a verifable claims instrument, which in-turn > becomes bonded to a verifable document. > > I think therein, I see a differentiation between the concept of the > document and the instrument. The credential instrument is generated and > stored, in association to the production and use of a trusted document. > This can then be presented, and verified for use by a valid recipient. There are a variety of different models that all fit into a "verifiable claims" ecosystem -- and industries will determine which one is appropriate for certain use cases. You can link to other trusted documents via verifiable claims or you can embed the claim information itself. > > I would have thought Multiple agents may be involved in verification, > Depends on the nature of the claims structure doesn't it? Assuming it's > not necessarily always singular..? All questions for a future WG. We'd like to keep things as simple as possible when starting the work. That doesn't mean we shouldn't plan for more complex cases in the future, though. > > Eg: Different departments of gov, for instance, are responsible for > different claims that end-up getting bundled for other instruments. > > In theory, I would have thought each department would be able to > maintain their own elements, involved in the bundled claim, should they > choose to...? Exactly how things get "bundled" or aggregated is another question for a WG. We have just specified some requirements that it be possible and controllable by the user (holder). > > Tim. > > On Tue, 16 Feb 2016 at 1:56 AM, Dave Longley <dlongley@digitalbazaar.com > <mailto:dlongley@digitalbazaar.com>> wrote: > > On 02/15/2016 08:51 AM, Shane McCarron wrote: > > Hmm. But a "consumer" might not be the one doing the verification. A > > consumer is the one that needs the claim to be true (presumably). > > That's my concern as well. We could do something new with the entire > terminology like "issuing party", "holding party", > "storage/aggregator/curator/agent party", "interested party", where > "interested party" takes over for "consumer". > > The "consumer" is the party that needs trust in the credential holder in > order for it to do something. They are a "relying party", an "interested > party", and sometimes a "service provider" (but not always). They are > the party that wants to know (and be able to trust) something about > another entity (for some reason). I don't know if any of that helps > anyone think of a better name. > > > Requestor is more accurate in the case where we are talking about the > > entity that is asking the holder for the claim. > > Unfortunately, "requestor" or "recipient" can be confused with the > "holder" because the holder must request a credential be issued to them > from the issuer. > > > > > On Mon, Feb 15, 2016 at 2:20 AM, Adrian Hope-Bailie > > <adrian@hopebailie.com <mailto:adrian@hopebailie.com> > <mailto:adrian@hopebailie.com <mailto:adrian@hopebailie.com>>> wrote: > > > > Verifier seems appropriate given that these are "verifiable" > claims > > > > On 15 February 2016 at 00:59, Steven Rowat > > <steven_rowat@sunshine.net <mailto:steven_rowat@sunshine.net> > <mailto:steven_rowat@sunshine.net > <mailto:steven_rowat@sunshine.net>>> wrote: > > > > On 2/14/16 1:44 PM, Manu Sporny wrote: > > > > I'm happy with 'evaluators', but wonder what our > colleagues > > in the > > education industry think? ...[snip] > > > > Credential/Claim Requestor and Credential/Claim Verifier > > could also work? > > > > > > IMO any of Requestor, Verifier, or Evaluator would be > preferable > > to Consumer. > > > > Except, Requestor could be confused with 'holder', the > > person/entity asking for the original issuing, since at the > > start they are 'requesting' that a credential be issued > for them > > -- which they then take elsewhere to be Evaluated or Verified > > (or, currently, Consumed). > > > > But as you noted, with multiple possible systems in play -- > > finance, education, payments, government -- it's going to be > > hard not to cause at least some confusion somewhere. > > > > > > Steven > > > > > > > > > > > > -- > > -Shane > > > -- > Dave Longley > CTO > Digital Bazaar, Inc. > -- Dave Longley CTO Digital Bazaar, Inc.
Received on Monday, 15 February 2016 16:23:26 UTC