Digitary & Evernym SSI Webinar

Digitary & Evernym collaborate on SSI webinar!

Digitary and Evernym recently collaborated on a webinar, with a specific focus on enhancing learner mobility through Self-Sovereign Identity. If you missed our live session or were unable to join us on the day, we’ve included the recording at the bottom of this page for your convenience. With fantastic engagement and great input from the audience, we actually ran out of time to cover off all questions raised so we’ve prepared the details below to summarise our responses. Thanks to everyone who was able to participate and we hope that you enjoy the additional information.

Can credentials be used everywhere or only in organisations within the Digitary/Evernym ecosystems or on a certain network? Digitary credentials using SSI can be used everywhere they are supported. A key pillar of the technology is that it does not rely on any single vendor to deliver this capability. It is Digitary’s aim that the capability go well beyond our platform as it supports all manner of digital credentialing and claim assertion across many aspects of our digital lives.

If a learner loses the device on which they keep their wallet, can they recover the pairwise DID, relationship with issuers & verifiers, and credentials stored in the wallet? The short answer is yes. Digital credentials are far more secure than the paper credentials we use today, and a lot of work has gone into the domain of decentralised key management to make sure that students and other holders will be able to access and control their digital credentials even if their phone has been lost or stolen. This Evernym/Sovrin whitepaper aptly named “What if I lose my phone?” explains that mechanism.

How does this fit in with the Groningen Declaration’s call for student data portability? As an original signatory to the Groningen Declaration in 2012, Digitary has always aimed to keep learner mobility central to our mission. We believe SSI reinforces that and elevates it to the next level by handing power and control of learner credential information back to the learners themselves. Learners would no longer need to rely so much on third parties to assert their claims but could do so independently using dynamic curated profiles, ensuring they present the best version of themselves.

Do you have non-technical documentation, which I can use to convince my university to take a deeper look into the topic? Evernym has written a great non-technical introduction to the role of self-sovereign identity can play in higher education, focusing on three core use cases: 1) onboarding and verifying students (especially important in a remote learning environment),  2) empowering students with verifiable proofs of their accomplishments, and 3) setting students up for success in their post-university lives. This blog post was also the topic of discussion for another webinar, which you can view here.

Are the independent parts of the proof individually signed by the keys associated with the DID of the issuer? Yes. Each attribute in a credential is individually signed by the issuer using a unique key. So the issuer has a private key per attribute. This allows a holder to select a subset of attributes to present (“selective disclosure”) without having to reveal them all. The issuer’s verification keys for each attribute are held on a credential definition on the Sovrin ledger. The credential definition is unique to the issuer. It is signed by the issuer’s public DID private key. The credential definition is created from a credential schema which could have been put on the ledger by the issuer or another party (e.g. as a template for re-use by others).

What is a typical implementation timeframe? As always, this will vary. In cases where an institution already on our platform is issuing academic credentials using structured data, this will be much quicker than say, a new implementation where we would be reviewing various data models in addition to the broader platform’s capabilities. We are aiming to provide the capability for institutions to issue credentials using SSI with minimal setup and configuration once they’re on our platform.

Are tokens involved in credential exchange and usage? If so, what is their role? By default, no they are not. Tokens are not a required part of credential issuance or verification. There are interesting use cases that can be delivered by combining exchange of credentials with exchange of value. Tokens could play a part in such use cases.

Is the Digitary platform an Access Management / Authentication platform as well? The Digitary platform does not operate as an IdP. The platform uses a number of common mechanisms to authenticate learners including social and professional networks as well as the institutions themselves. This is part of what we are working to evolve and have learners assert their identity on their terms and not necessarily only through third-party networks.

The PDF data, if transformed to an SSI credential, wouldn’t be verifiable based on the institution at that point, but would be issued by Digitary, is that correct? To issue a digital credential, we would require granular data. Like we mentioned in the webinar, we do not scrape PDF files for information and rely on structured data provided by institutions to support the type of capabilities we showcased. The end state would be that the digital credential would be issued by the institution and Digitary as a service provider to these institutions would facilitate the process. We aim to continue to support the many ways to issue academic credentials to learners including existing mechanisms and emerging technology like SSI.

What work is being done on the employer end (uptake)? Without market recognition, what’s the typical value? This is an ongoing process. You’re quite right, until we get what starts to look like a critical mass the practical value might be low. There have been a number of key initiatives lately across almost every continent where SSI was being used to not only showcase the technology and capabilities but also start to fulfil some real-world use cases from banking to Government departments. The uptake of SSI is not necessarily dependant on any single sector so progress across many different places is happening now and we remain confident that momentum will continue to steadily grow.

As a Verifier, how do I send the list of attributes I require? Is there a standard? The proof request attributes can be customised, it can technically be anything (key strings), the attributes should be based on available schema definitions (from the whole Sovrin Network). We can help verifiers define their proof request template, so whenever they want to send a proof request, they can ask for one specific proof request template (e.g. in our current PoC, we can do it with registered public key, so template per key, or we can pass on some form of template ID that is defined in our SSI service. An example like the one we used in the webinar demo is shown below:

{
   "source_id":"9c61bc5a-4f8d-4114-991e-ab2662f19001",
   "name":"dlp_proof",
   "requested_attrs":[
      {
         "name":"Full Name"
      },
      {
         "name":"Certificate Issuer"
      },
      {
         "name":"Major"
      },
      {
         "name":"Enrolment Period"
      },
      {
         "name":"GPA"
      },
      {
         "name":"Enrolment Status"
      },
      {
         "name":"Date Conferred"
      }
   ]
}

Check out this recording of the webinar with our technology partners Evernym, where Evernym’s MD EMEA Andrew Tobin along with Digitary CTO Takis Diakoumis and COO James Murray-Beckman talk about our work using self-sovereign identity to issue Verifiable Digital Credentials and enhance learner mobility.

Contact us for more information, email: hello@digitary.net