Re: Request for Presenters: In-Person Presentation of Credentials

Thanks Manu,

> On Apr 5, 2022, at 11:38 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On 4/5/22 9:13 AM, James Chartrand wrote:
>> The libraries were great - super easy to use, and the documentation was 
>> very clear.  One small change I made was to substitute a different QR 
>> library (into a fork of vpqr) so that I could get a PNG image. The PDF 
>> library I used wouldn’t take the image type that vpqr normally produces (I 
>> can’t remember what that image type was).  The vpqr code is really well 
>> structured, so it was pretty easy to make the change.
> 
> I raised an issue on the VPQR library to track your comment:
> 
> https://github.com/digitalbazaar/vpqr/issues/10
> 
>> Here’s an example of a VP we encode (this won’t validate because I redacted
>> the student name and ID - if you want an example that does validate just
>> let me know):
> 
> Yes, interested in a sample that does validate because I'd like to include it
> in the CBOR-LD examples:
> 
> https://github.com/digitalbazaar/cborld/tree/main/examples

Will submit a PR (once I’ve incorporated your suggestions).

> 
> Some commentary on the credential you provided:
> 
> vc.credentialSubject.name and vc.credentialSubject.description really should
> be one level up... they're attributes of the credential itself, not
> necessarily the credential subject. I would've expected something closer to
> the following:
> 
> {
>  ...
>  "name": "Enrollment Status",
>  "description": "[Student Name goes here] (Student ID: [goes here]) is
> registered at McMaster University as a Full-Time Undergraduate student for the
> 2022 Winter term from Jan 1st 2022 to Apr 30th 2022."
>  "credentialSubject": {
>    "name": "John Doe",
>    "studentId": "23-48382",
>    "studentStatus": "Full-Time Undergraduate",
>    "affiliation": "McMaster University",
>    "description": "Student for the 2022 Winter term from Jan 1st 2022 to Apr
> 30th 2022."
>    ...
>  }
>  ...
> }
> 
> IOW, in a VC, you can describe the credential, and then you can describe the
> credential subject... and you should be careful to not use one mechanism for
> the other.

I tried to follow the pattern in the VC Data Model example for Bearer Credentials (even though the spec does say that bearer credentials shouldn’t include subject identifiers, whereas we do include student name and id):  

https://www.w3.org/TR/vc-data-model/#bearer-credentials

That bearer credential example puts the degree inside the credential subject:
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/temporary/28934792387492384",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    // note that the 'id' property is not specified for bearer credentials
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}

If I’d properly followed the pattern of the bearer credential above, I should have had something more like this (re-using your suggestion of a ’studentStatus’ property):

"credentialSubject": {
    “studentStatus": {
      “name": “Enrollment Status",
      “description": "[Student Name goes here] (Student ID: [goes here]) is registered at McMaster University as a Full-Time Undergraduate student for the 2022 Winter term from Jan 1st 2022 to Apr 30th 2022."
    }
  }

But, this was very much a ‘get-it-working-quickly’ proof of concept kind of thing, and because I struggled with the size of the QR I tried to keep the credential as small as possible.

And so, caught up in my zeal to ‘cut, cut, cut!', I thought, well, maybe I can also get rid of the ’studentStatus’ property and just move name and description up a level. I do now see, though, that I've thereby completely changed the semantics, making studentStatus the subject of the credential rather than the student themself.

I could also have extracted the student name, id, and affiliation as separate properties of the credentialSubject like you did, but again I was trying to keep it small.  And, we have other letters that assert even more information, like a full list of courses for the term, so space becomes very limited.  Bigger QRs also seem much harder to reliably scan.

In fact, all I really wanted is to sign a single human readable statement that can be shown at verification time.  A generic property like ‘assertion’ or ‘humanReadableAssertion’ would have been ideal, maybe kind of like your point below about having display-specific properties.  In which case the credential could simplify to:

{
  "@context": [..],
  "id": "c4c6003d-aff4-4b93-a4a0-9942edeaf2a4",
  "type": [“VerifiableCredential”, “HumanReadable"],
  "issuer": "did:web:credentials.mcmaster.ca <http://credentials.mcmaster.ca/>",
  "issuanceDate": "2022-04-04T18:17:36.771Z",
  “humanReadableAssertion":  “James Chartrand (Student ID: 292-3291) is registered at McMaster University..."
}

> 
> One of the things I wish we had gotten to in VC v1.0 was defining the use of
> "name", "image", and "description" on the credential itself so that wallet
> display code could always count on that information being there for display
> purposes. I expect we'll discuss this at length, and put those attributes in
> the core data model, in the VC2WG.

That would be very nice.  Coincidentally (or not), on a few of the recent DCC (Digital Credentials Consortium) calls we've talked about how a student card could live in the DCC Learner Wallet, and how it would be displayed.  A student card might want to show different things like the student photo, maybe a barcode for backwards compatibility, QR, student name, id, etc. and even then the student card from one university might be layed out differently than another.  

So one approach might be to bundle a single ‘all-in-one’ image into the VC that is shown when the ’student card’ credential is opened in the wallet (or opened in a verification app after having confirmed everything in the image has been signed).  The single image would contain everything that is to be shown:  photo of the student, barcode, name, id number, status, etc.  The wallet/verifier wouldn’t then need to know how to layout the credential (i.e., with different ’templates’ for different credentials).  Each university would independently decide what they want to include, pre-organized in whatever layout they like.  

This is pretty much what we did with McMaster’s Blockcerts degrees:  rather than make use of the Blockcerts ‘displayHTML’ field to supply HTML for display (which might prove brittle over time), we instead provide a single image that is shown in the wallet/verifier - the very same image that is used to print the paper copy of the degree.

> 
> Does that make sense?

Completely, and I very much appreciate your help!

James

> 
> -- manu
> 
> -- 
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>