Lesson #86 - SDI Use Cases

Kris Durski

We are so grateful for your loyalty and support. You are the reason we do what we do. Thank you for being part of our amazing community. You rock! 👏🤟

---

Introduction

SDI (Secure Digital Identity) is a cryptographic proxy to the user’s true identity. It is conformant to the ZKP (Zero Knowledge Proof) standard:

1. Completeness: if the statement is true, a verifier will be convinced of this fact because only the private key that is a counterpart of a public key can decrypt the nonce

2. Soundness: if the statement is false, a prover cannot convince otherwise because the inability to decrypt the nonce means lack of possession of the corresponding private key, i.e. wrong identity

3. Zero-knowledge: if the statement is true, a verifier cannot learn anything else but the fact that the statement is true because the public key or decryption of a nonce does not convey any information about the private parameters

With SDI the proof reaches 100% certainty after only one cycle. The SDI security supports the ZTA (Zero Trust Architecture) model without external account management. The provider may use either a single SDI service so all authorizations will be done with the same pair of asymmetric keys and the ephemeral nonce (one-time use) or multiple SDI services where each will require a different pair of keys and the ephemeral nonce. A nonce is ephemeral because it is not stored anywhere in the open form even on the SDI server.

SDI Initiated Login

The user starts the SDI app if not running yet and connects to the authentication service to bring their PCM (Personal Cryptographic Matter) container or logs in to the cached PCM. Once the SDI app is authorized, the user selects the company and starts the managing app to initiate communication.

1. The managing app formulates a directive to start browsing and sends that directive via the SDI app which attaches the SDI data and sends it to the SDI server.

2. The SDI server verifies the SDI data and if not correct, it aborts communication.

3. If correct, the SDI server forwards the directive to the content server.

4. The content server finds the user in its database and sends the push notification to the chosen device.

5. The push notification shall contain the URL and data needed to recognize the user, e.g. token.

6. The user responds to that notification, e.g. by clicking it, which shall launch the browser for a given URL.

7. The browser sends a request for the user’s topics page.

8. The content server finds the user, creates the user’s topics page, and sends it back to the user.

9. The user’s browser receives the page and the user can start working.

Browser Initiated Login

The user starts the SDI app if not running yet and connects to the authentication service to bring their PCM (Personal Cryptographic Matter) container or logs in to the cached PCM. The user opens a browser, navigates to the desired URL, and clicks a link that requires authorization.

1. The browser sends a request for the topics page to the content server.

2. The content server sends a login page with the attached topic.

3. The login page shall contain information about the unknown user’s request.

4. The user types their login name and leaves the password field blank if provided.

5. The login form with the user’s login name shall be associated with the original request.

6. The server finds the user’s record based on the login name and sends a push notification to the user’s chosen device that runs the SDI app.

7. The push notification shall contain the URL of the service and the requested topic.

8. The user’s SDI app finds the provider based on a given URL and asks the user for confirmation. The user either approves or denies.

9. The user’s decision, SDI data, and the requested topic are sent to the SDI server.

10. The SDI server verifies the SDI data and if incorrect, it aborts communication.

11. If correct, the SDI server forwards the directive to the content server.

12. If the directive approves the request, the content server sends the requested page to the user’s browser. Otherwise, the content server denies access.

13. The content arrives at the user’s browser and the user can start working.

Continue to the Next Topic

The user finishes working with a given topic and moves on to the next by clicking the desired link.

1. The user’s browser sends a request for the next topic, which also requires authorization.

2. The content server finds the user’s record in its database and sends the push notification to the chosen device.

3. The push notification shall contain the URL of the service and the requested topic.

4. The user’s SDI app locates the provider based on a given URL and sends the notification to the managing app, which asks the user for confirmation or does auto-confirmation if configured so.

5. The user’s decision, SDI data, and the requested topic are sent to the SDI server.

6. The SDI server verifies the SDI data and if incorrect, it aborts communication.

7. If correct, the SDI server forwards the directive to the content server.

8. If the directive approves the request, the content server sends the requested page to the user’s browser. Otherwise, the content server denies access.

9. The content arrives at the user’s browser and the user can continue working.

Thank you for reading our newsletter and stay tuned for more updates from Vault Security!

---

It’s been a pleasure to share this article with you today. I hope you found it informative and interesting. I’ll be back next Sunday with more insights and stories. Until then, I wish you a great day and all the best.👋.