Re: VC Evidence Discussion

Orie, thanks for the clarification and the useful relatedLink-related
links. It does seem to my uninformed eye like a sensible, flexible,
minimally wheel-reinventy approach. My reading of the current VC 1.1 spec
is also that this doesn't cleanly fit the intention of 'evidence'.

From your earlier reply, it sounds like you see hashlinks as unnecessary,
which I thought was interesting. I can certainly see some appeal in
avoiding them. For this to work, my understanding is that all linked docs
must be either 1. already verifiable, e.g. due to signature (VC) or some
other property such as being anchored to a block chain, or 2. hosted
securely under control of a party that is ok to change it- perhaps hosted
on the issuer's website. I might've imagined that this could require more
block-chain and/or hosting expense/complexity than just using hash-links,
but perhaps that's not the case. Any thoughts?

Thanks again. Will keep an eye out for that next version of the spec.
Morgan

On Fri, 8 Apr 2022 at 23:25, Orie Steele <orie@transmute.industries> wrote:

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

-- 


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