"IIW SSI Spotlight: 5 Priority Topics of the SSI-Community 1 wallet backup, 2 on-device credential sync, 3 public DID verification, 4 control over public DIDs, 5 third-party identities"

IIW SSI Spotlight: 5 Priority Topics of the SSI-Community

Wednesday 13E

Convener: Andre Judra

Notes-taker(s): Andre Kudra

Tags for the session - technology discussed/ideas considered: 5 Priority Topics of the SSI-Community incl: 1 wallet backup, 2 on-device credential sync, 3 public DID verification, 4 control over public DIDs, 5 third-party identities

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

IIW SSI Spotlight: 5 Priority Topics of the SSI-Community Even though the global SSI community has cleared significant roadblocks for practical productive SSI use: There are still optimization potentials. Following a list of top topics currently being worked on or collectively deemed relevant, based on the author’s judgment call from his work in the SSI domain: 2 in user cluster, 3 in organization cluster, 2 in bonus cluster.

User Cluster

Things that just have to work on the end user side. Reliably, securely and convenient. Wallet backup – People are used to data being stored (and backed up) in a cloud and they can call or escalate to someone if data becomes unavailable. As pure SSI postulates the use of an “edge wallet” on the user’s personal smartphone, this goes along with the responsibility of securing the data on this device, on their own. Usability considerations demand a fool- and fail-proof backup solution, easily activated when installing the app. Policy setting possibilities are advised, e.g. in corporate scenarios, to stop the app from accepting new data if the backup mechanism is non-functional for a certain time period.

Discussion / comments / requirements

Secure data storage working group. How can we store something? See document: http://drive.google.com/file/d/1vf2CsD9QZstzrd6CJ4WFVHw0WKwwNLHf/view

It does not backup the keys, though. Different philosophies for key management.

Backup for a) restoring to same app b) exporting for import to new app/device (portability). Keys have to be stored somewhere else. May not be necessary to standardize. Could be vendor-specific. How flexible can individual vendors be? Counter: “My thought, though it may not be necessary to standardize it, today it is a need universally. It certainly is worth to have some guideline to enable starting point towards standardizing.”

Wallet backup is a crucial problem to be solved in SSI (coming from a federated identity world). Phones may fail, get stolen, get handed over to others. Security perspective: Backup mechanism may become the weak link.

Real-world analogy: What do end users have to do if they lose their physical wallet? They understand they have to go to great lengths to replace everything in it. This can be leveraged!

Secure elements / enclaves are getting accessible on common smartphones (iOS/Android).

Keeping keys in hardware is preferred. Need to be able to rotate keys in an easy manner. Key management is a critical success factor. Layering required to get to the secure enclave. What goes into the wallet needs to be secured. Making the backup is the easy part, decrypting the key to decrypt the wallet is the hard part. Tying backup to hardware is required, with decoupling the decryption key. Standard enterprise backup and restore can be applied to a wallet app. If portability is required, which should be considered crucial, a standardization is required. A “switch to another app” should be standardized.

It is a multi-layered problem. Digging deeper is required.

Maybe standard key chains on OSes are enough for now. If the VCs get more important at some point, reconsidering is needed. Bringing convenience to SSI would be helpful, users don’t like managing their keys. Probably not so aligned with the core understanding and principles of SSI.

Splitting the master keys across different service providers is wise. We will put in trusted entities again (third parties) to ring-fence undesired things from happening. I can choose where to put the keys and change my providers. A standard enables the choice!

On-device credential sync

Especially in the nascent stage of broader SSI use, innovators and early adopters may desire to implement their own wallet app or enhance their existing apps with SSI wallet capability. This will not only be confusing to end users as they may not understand why they need more than one wallet app and credentials are handled in different apps. Best way out is a synchronization of credentials across different wallet apps, with the possibility to filter for relevant credential types within an app and a “master wallet” showing all credentials. However, it is technically challenging as well: Popular smartphone operating systems have restrictions for sharing data between apps, i.e. a synchronization mechanism may not be straightforward to implement.

Discussion / comments / requirements

“Wallet first” paradigm. Your device becomes your wallet. Multiple wallets on a device is tricky: Requires key to be present in those. Might be able to do the querying in an encrypted state. Use of credentials across multiple apps not possible without key sharing. Secure storage outside of the app is key. Sharing of keys between wallets required. Shared wallet is necessary. Even if apps are operating independently, using credentials from different apps will be required. Cloud service may be the way around, data is not on the device any more!

Organization Cluster

Concepts for integrating SSI into organizational contexts. Trust-reinforcing, easily and flexible.

Public DID verification In a business context, most organizations will have a public DID on their network of choice for creating schemas and credential definitions, issuing credentials and being generally reachable with SSI mechanisms. In a digital trust network, knowing with whom an interaction is happening is vital. Even though a DID can be public on an identity network, its ownership is not published with it (anyway, it could only be a self-attestation). Hence a trusted public DID vetting process resulting in a verified organization mapping is a necessity. Properly extended, GLEIF (Global Legal Entity Identifier Foundation, https://www.gleif.org) records have a high potential for addressing this challenge.

Discussion / comments / requirements

Concept is cool, would be beneficial to the community.

Methods to resolve DIDs described here (like DNS): https://w3c-ccg.github.io/did-method-web/ and https://identity.foundation/.well-known/resources/did-configuration/

BC Gov is doing it: http://orgbook.gov.bc.ca/en/home

Option could be jurisdictional business registries, e.g. Handelsregister in Germany.

Not comparable to certificate registration as DIDs are self-registered. Making known who is behind a Public DID is the important part.

Control over public DIDs A transaction executed via an organization’s public DID is always an official, clearly attributable act of this organization. As usual in power of attorney settings, these acts are conducted by natural persons on behalf of the organization. Hence, exerting control over a public DID means power and demands responsible action. The related private keys must be ring-fenced and only made accessible to those who are legally permitted and eligible for speaking on behalf of the organization. The related terms of the SSI community are guardianship, delegation and custodianship, concepts and technology are work in progress. Access-controlled institutional SSI agents are available now to accommodate, in future built-in technical methods for DID control may be developed.

Discussion / comments / requirements

Not needed to secure THE key. Give users a credential to act on behalf of that organization. Root admin cannot be erased. And should not. Registering the stakeholders (like company owner) is the root, then delegation of authority is possible. Liaise with Sam Smith regarding KERI. Delegate responsibility to multiple stakeholders or entities, e.g. assign five keys and three have to be present for transaction execution. Shared keys.

Third-party identities

One of the major SSI design merits, i.e. flexible certificates called credentials, allow a multitude of cross-organizational use cases. They often encompass a data or system access requirement. In a classic world, the organization has to “onboard” the relevant third-party staff members in its own identity systems – a procedure causing tremendous work, trouble, and delays. In case the trust relationship allows, with SSI, third parties may easily be enabled to maintain “their” identities in the target organization's realm. Being closest to who is performing work for a client, representatives of the trusted external service provider can manage who of their staff is active in the target organization.

Discussion / comments / requirements

Give managers credentials which determine what they can hand out. Shared responsibilities. Revocation mechanism is vital for handling this. Revocation solution must be more scalable.

Bonus Cluster

Topics everyone talks about already. Not desired to reiterate here, just if time allows. Network interoperability – An omnipresent topic is network interoperability, i.e. the capability to manage and use DIDs and credentials of various identity networks, with one wallet app. This is relevant as currently dedicated networks are designed and implemented in diverse contexts. This requires not only trust in the respective network governance but also technical interoperability, ideally based on commonly defined and broadly used standards. Many resources of the community are flowing into network interoperability as of now.

Data schemas – Another often-addressed topic is data schemas for the various application domains. In some industries relevant data attributes, formats and suitable contents may be common knowledge. However, most likely in many scenarios to which SSI is first applied, innovators and start-ups will be breaking new grounds and come up with their own schemas. They have the chance of creating de-facto standards without clunky standardization processes.

Zoom Chat:

00:32:20 Von Andre Kudra : http://docs.google.com/document/d/1xxPkU9wbWkjsSk6VvzFyB3Digb-RjcdwxyF_H5mZ7HM/edit

00:36:21 Von rouven : http://drive.google.com/file/d/1vf2CsD9QZstzrd6CJ4WFVHw0WKwwNLHf/view

00:36:31 Von rouven : Secure Data Storage ^^

00:43:08 Von Eddie Kago : Is there a link to the document?

00:43:18 Von Christopher Hempel : http://docs.google.com/document/d/1xxPkU9wbWkjsSk6VvzFyB3Digb-RjcdwxyF_H5mZ7HM/edit

00:43:24 Von Eddie Kago : Thanks

00:43:27 Von mikhael : Scroll down to the bottom

00:48:46 Von rouven : Ahh - as host, I cannot raise my hand?!

00:49:15 Von swcurran : That's exactly the diffentiation I was making - backup (one app/vendor), portability (across vendors)

00:49:33 Von swcurran : Rouven - no. I was doing q+ on the last call :-)

00:49:55 Von rouven : haha - ok :(

00:50:17 Von rouven : q+

00:54:37 Von Kalyan Kulkarni : My thought, though it may not be necessary to standardize it, today it is a need universally. It certainly is worth to have some guideline to enable starting point towards standardizing.

00:57:45 Von johnnyfromcanada : Ephemeral perfect future secrecy

00:58:52 Von johnnyfromcanada : Perfect Forward Secrecy

01:02:15 Von Kalyan Kulkarni : Another perspective to bring here - we are not far away from guardianship/delegation. This also brings immense importance to backup/restoration.

01:06:57 Von mikhael : No one has mention biometrics. A chip in your arm isn’t very palatable, but it removes the need to create ‘back-ups’.

01:12:29 Von Kalyan Kulkarni : +1, it does compromise the SSI concepts

01:13:30 Von Ryo Kajiwara : +1 too, even when many people entrust organizations to do key management, we need to have options to do key management ourselves to be "truly self-sovereign"

01:14:10 Von Jonas Jetschni : i agree, this is what i meant with done right - users needs always the options to control there if they decide so

01:14:46 Von Jody : +100

01:14:56 Von Jonas Jetschni : You always need a choice! Most likely a legal framework for this would be fantastic

01:15:09 Von swcurran : Yup - agreed. Rouven said it really well.

01:15:35 Von swcurran : But we need to make it as easy as we can to do the secure thing.

01:19:29 Von rouven : http://w3c-ccg.github.io/did-method-web/

01:19:34 Von rouven : http://identity.foundation/.well-known/resources/did-configuration/

01:22:45 Von rouven : http://orgbook.gov.bc.ca/en/home

01:27:31 Von johnnyfromcanada : For CA vs. Public DID, per a cost-benefit analysis, the “benefits” are roughly the same, but the “costs” are not.

01:38:32 Von johnnyfromcanada : estatus SeLF (on Sovrin) demo yesterday talked about integrating SSI into existing IT-infrastructure. “SSI credential-based access rules are transformed into authentication and authorization objects that can be synchronized and used by conventional technologies like SAML or OIDC.”

01:41:22 Von Kalyan Kulkarni : Its almost dawn here in India :)

01:41:28 Von Kalyan Kulkarni : 5:15 AM

01:43:22 Von Kalyan Kulkarni : Thanks for a great discussion

01:43:25 Von Jonas Jetschni : thank you

01:43:35 Von Ryo Kajiwara : thank you!