Re: Verifiable Claims Telecon Minutes for 2016-02-09

I can't think of the names, yet, functionally the mail system is rather
similar functionally.

It also has a 'minting' process surrounding the stamp on the mail article,
in addition to the postage marks that are used in processing the item.



On Tue, 16 Feb 2016 at 03:24 Dave Longley <dlongley@digitalbazaar.com>
wrote:

> 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.
>
>