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

> On Mar 31, 2022, at 10:54 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On 3/30/22 7:59 PM, James Chartrand wrote:
>> The letters, which are PDFs, include a QR that encodes (via CBOR-LD) a 
>> complete Verifiable Credential (all using the wonderful libraries from 
>> Digital Bazaar - thank you!)  Again the QR is NOT a link to a VC, but 
>> rather contains the entire VC.  The VC confirms the information that 
>> appears as text in the PDF.
> 
> James, this is amazing; we had no idea! We're glad that you found Digital
> Bazaar's open source libraries useful! Please let us know if you hit any snags
> so we can improve any rough edges you experienced.

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'm particularly interested in the specific VC you encoded and how well it
> did/didn't compress; happy to provide some insight if that would be useful.

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

{
 "@context": ["https://www.w3.org/2018/credentials/v1"],
 "type": ["VerifiablePresentation"],
 "verifiableCredential": [{
  "@context": ["https://www.w3.org/2018/credentials/v1", "https://w3id.org/dcc/v1", "https://w3id.org/security/suites/ed25519-2020/v1"],
  "id": "c4c6003d-aff4-4b93-a4a0-9942edeaf2a4",
  "type": ["VerifiableCredential"],
  "issuer": "did:web:credentials.mcmaster.ca",
  "issuanceDate": "2022-04-04T18:17:36.771Z",
  "credentialSubject": {
   "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."
  },
  "proof": {
   "type": "Ed25519Signature2020",
   "created": "2022-04-04T18:17:36Z",
   "verificationMethod": "did:web:credentials.mcmaster.ca#z6MkjF4EkZhsP8QfRjtUuQyJeMTWTKJJngTUh3ntNA6JpErC",
   "proofPurpose": "assertionMethod",
   "proofValue": "z48LD5MEHp17EK8ibW8c65rVjhrSVWDYc9NEuGAOtufrNj31PHnktCZm99uQj1WdrSv8fgKoxqh7Cka26udQNkHLB"
  }
 }]
}

> 
>> Yes, absolutely right - it is a Verifiable Presentation.  We’re using the 
>> Digital Bazaar vpqr library:
> 
> Neat! You're definitely using the library for its intended purpose. Some
> inside baseball:
> 
> We have committed to CBOR-LD and the use of the VPQR "VP1-*" output format for
> production. We've also committed to the Ed25519Signature2020 suite for
> production, though we do expect it's successor "eddsa-2022" (exact same
> signature format, but different `type` and `cryptosuite` value) to also become
> ratified in the VC2WG.
> 
> We are also exploring a "VPR1-*" format for purely local, purely optical (QR
> Code) VC exchange, AND for bootstrapping from an optical carrier (QR Code)
> into a wireless protocol (NFC, Bluetooth, WiFi, LTE, etc.).

Bootstrapping into another protocol would be very nice because we’re also interested in issuing something like a student ID (ideally into the DCC Wallet). A student ID would include more data than can fit directly in a QR (student photo, possibly a barcode for backwards compatibility, etc.).  

We’ve been thinking about doing something like uploading the full VC to some temporary location from which the verifying software could download the credential.  The QR would contain the link to that VC.  The VC would be removed from the temporary location after some very short period (e.g., 30 seconds).  Maybe also encrypting the VC and providing the verifier with the decryption key.   (Which altogether I guess sounds a lot like the recent thread 'IETF: Secure Credential Transfer’, although their mechanism seems designed to store the credentials for a longer period of time to thereby handle other scenarios).

> 
> There are some design decisions that we had to make there that are not widely
> known, like avoiding protocol schemes and App Links in QRCodes (for the same
> reasons they're problematic when used in mobile). I expect the recent CHAPI
> conversation to uncover more of those design decisions.
> 
> In any case, really neat work, James -- you made my day! :)

Thanks!  But again, many more thanks are due to you and Digital Bazaar.

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