Re: VC Evidence Discussion

We chose to use `relatedLink` because it did not have the `evidence`
semantics, and we didn't want linked documents to get automatically
downloaded as part of "validation"...

Here are some "related links" from schema.org:

https://github.com/schemaorg/schemaorg/issues/1959
https://github.com/schemaorg/schemaorg/issues/1152

> Would you mind elaborating on what you mean by "where you would want to
include a reference and sign over a reference instead of a value."?

Sure, when you mint an NFT it has a URI that points to references... that
could be very large... Why not just put all that data directly into the
smart contract?

A user wouldn't need to read from anything other than the blockchain then...

The answer is the similar for evidence:

1. You might want to change that data behind the URI without breaking the
signature
2.  You might want the signature to break if the data behind it changes
3. You might want to add new data behind the URI after the credential was
issued
4. The data behind the URI might be several orders of magnitude larger than
the credential (like a large ML model / or training set).


OS

On Fri, Apr 8, 2022 at 1:41 AM Morgan Hedges <morgan.hedges@gosource.com.au>
wrote:

> My apologies.
>
> When I said "relatedDocument", I actually meant "relatedLink". This bit:
> "relatedLink": [
>     {
>       "type": [
>         "LinkRole"
>       ],
>       "target": "did:example:789",
>       "linkRelationship": "commercialInvoiceLink"
>     },
>     {
>       "type": [
>         "LinkRole"
>       ],
>       "target": "https://www.example.com/template/123",
>       "linkRelationship": "millTestReportLink"
>     }
>   ],
>
> Looks to me like a fairly general approach?
>
> Morga
>
>
> On Fri, 8 Apr 2022 at 16:25, Morgan Hedges
> <morgan.hedges@gosource.com.au> wrote:
> >
> > Hi Orie,
> >
> > I've just noticed the "relatedDocument" field used here:
> https://w3c-ccg.github.io/traceability-vocab/#BillOfLadingCertificate.
> Not sure how I've missed this before, but is that the general approach
> you've got in mind? Would you mind elaborating on what you mean by "where
> you would want to include a reference and sign over a reference instead of
> a value."?
> >
> > Apologies if I'm a little oblivious.
> >
> > Morgan
> >
> > On Fri, 8 Apr 2022 at 09:18, Orie Steele <orie@transmute.industries>
> wrote:
> >>
> >> We've also been discussing evidence and it's usage in supply chain use
> cases...
> >>
> >> I remain hopeful that it will be better tested in the next version of
> the spec.
> >>
> >> It needs some serious interoperability tests to support it better, but
> there are many cars where you would want to include a reference and sign
> over a reference instead of a value...
> >>
> >> I don't think adding hash links or other non standard uri formats is a
> path towards better adoption or interop... But normal URIs seem
> reasonable... Maybe even DID URLs.
> >>
> >> Regards,
> >>
> >> OS
> >>
> >>
> >> On Thu, Apr 7, 2022, 2:24 PM Steve Capell <steve.capell@gmail.com>
> wrote:
> >>>
> >>> Agree with Michael about clear separation. And with Phillip about
> maintaining integrity of linked data using hashlinks.  The ability to
> discover a graph of linked credentials is core to many of our use cases
> >>>
> >>> But what im less sure about is where to put the linked credential list
> >>> - in the Extensibility mode as the VC specification seems to hint?
> >>> - in the Evidence model as Kerri suggests  ?
> >>> - somewhere in the VC specific claims structure(not keen on this one)?
> >>>
> >>>  and, wherever the linked credential list goes, what is its structure?
> >>> - a simple list of hashlinks? - verifier would have to follow all to
> find the one they want
> >>> - an array of type / hashlinks pairs ? If so, how to consistently
> represent the type of the linked credential?
> >>>
> >>> If the group has reached some consensus on the best way to represent
> linked credentials that would allow verifiers to construct trust graphs -
> I’d be very keen to hear about it
> >>>
> >>> Many thanks - and my apologies Kerri if this question is misaligned
> with your question ..
> >>>
> >>> Kind regards
> >>>
> >>> Steven Capell
> >>> Mob: 0410 437854
> >>>
> >>> On 8 Apr 2022, at 4:47 am, Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
> >>>
> >>> 
> >>>
> >>> As a general pattern, consider a clear separation of the “thing” from
> the ownership rights and assignment of those rights to another entity (e.g.
> person or organization).
> >>>
> >>>
> >>>
> >>> A VC is an obvious representation of the thing whether it be an
> educational achievement, an NFE in an NFT, or house (in the case of
> homeownership). Use a second VC to represent the ownership rights and the
> assignment of those rights to an actual person or organization (a
> verifiable capability authorization is useful for the latter).
> >>>
> >>>
> >>>
> >>> …more or less applying the concepts of traditional database
> normalization to the world of VCs.
> >>>
> >>>
> >>>
> >>> Michael
> >>>
> >>>
> >>>
> >>> From: Kerri Lemoie <klemoie@concentricsky.com>
> >>> Sent: Thursday, April 7, 2022 11:04 AM
> >>> To: W3C Credentials CG (Public List) <public-credentials@w3.org>
> >>> Cc: public-vc-edu@w3.org
> >>> Subject: VC Evidence Discussion
> >>>
> >>>
> >>>
> >>> Hello all,
> >>>
> >>>
> >>>
> >>> I’m seeking some input on VC evidence. This is a topic relevant for
> VC-EDU because education data specifications like Open Badges and CLR may
> contain an evidence property to support the achievement. This evidence
> could be a test score, a link to an image, video, and/or web page, etc.
> that demonstrates competency or participation. These specs are working
> towards aligning with VCs and it was originally thought that this type of
> evidence would be included as part of the credentialSubject if it existed.
> >>>
> >>>
> >>>
> >>> This would look something like this:
> >>>
> >>>
> >>>
> >>> https://json.link/21SpTf0rC4
> >>>
> >>>
> >>>
> >>> But since VCs already have an evidence property that allows for an
> array of evidence, it seems to make sense to use that property instead of
> using a separate property like the one demonstrated above. The
> rationalization is that VC evidence could be an array that supports what is
> needed for a credentialSubject to offer to support the verifiability of a
> VC such as a student id or it could also support the achievement that is
> being claimed as discussed above. This would look more like:
> >>>
> >>>
> >>>
> >>> https://json.link/0gqe5D1U4K
> >>>
> >>>
> >>>
> >>> Can you share your thoughts on this second approach? Do you think the
> VC.evidence support the achievement evidence too?
> >>>
> >>>
> >>>
> >>> Thanks!
> >>>
> >>>
> >>>
> >>> Kerri
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --------
> >>>
> >>> Kerri Lemoie, PhD
> >>> Director, Digital Credentials Research & Innovation
> >>>
> >>> badgr.com | concentricsky.com
> >>> she/her/hers
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
>
> --
>
>
> ---
> The content of this email and attachments are considered
> confidential. If you are not the intended recipient, please delete the
> email and any copies, and notify the sender immediately.  The information
> in this email must only be used, reproduced, copied, or disclosed for the
> purposes for which it was supplied.
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>