Q: wnfs + ucan + oidc ... gw?

1

Hello.

I read a bit about WNFS an UCAN first time few months ago, but I have not been paying much attention so feel free to slam me with links to documentation, specs, even code.

I have a use-case and would like to learn if it is (eventually) possible, or if I need to change direction - and hopefully open a discussion on how to address it.

Use case is “simple” - I want to build a chess-like game on top IPFS - or better with WNFS and UCAN as IPFS does not solve encryption at rest and authentication/authorization.

My two biggest problems seems to be

  1. Holding personal game data in decentralized world - ie. how can you securely store it and ensure only the right the person can use it?

  2. How can we reuse social logins, so we don’t force people to create just another account, but also simplify onboarding and possible recovery?
    (not to mention whole mess of managing personal identification data, but more on that later)

Also side note - I have not looked at Etherum apps at all, so maybe it’s solved there, but … I would prefer WNFS (IPFS) + UCAN + something instead, as I already invested time and energy into this and hope to continue.

Anyway, here is direction check question - does it make sense to build UCAN-OIDC gateway?

As I mentioned on Discord somewhere long time ago, OAuth is industry standard … and OpenID Connect is just extension of it allowing to authenticate/authorization against (centralized?) endpoint.

Would it be possible to …

  • Have a server application that be OAuth server as a wrapper for UCAN tokens? (it’s been a while, so ignore, but better correct if fundamentally wrong pretty please)
  • Extend UCAN specification to allow similar standard for OpenID Connect
  • (or again) have a server that can serve as OpenID Connect endpoint to allow access from existing applications but allowing decentralized source of truth
  • Server that can use OpenID Connect endpoints to provide the UCAN tokens after authenticaion/authorization - ie. with social login by Microsoft/Google/GitHub … and Facebook

How that would work? (examples)

Workflow 1 - Game user with social login

1.1) I start my own WNFS … node (instead of IPFS node?) and I start my OIDC GW on top/alongside of it.

1.2) I can now start my game, that can use social login … instead of crafting some crazy IPLD structure with (your-religious-entity forbid) hashed e-mail (even with something like PBKDF2 SHA-256) inside to identify user and maybe some other metadata (for more deeper dive I of things I checked, see the links I have attached).

1.3) Because the provider of OpenID Connect endpoint (again, based on OAuth) handles the login, it could grant us a token and we can re-use built-in expiration and token renewal strategies - by wrapping it to UCAN token.

This I hope can postpone the problem of storing some hashed form of password in by design immutable and decentralized world storage (in this case IPFS network).

We would probably need for game server to provide user ID - UUID or CID - but that’s for game server to do the mapping and I am afraid there is no avoiding it there.

Workflow 2 - Game server user accounts

2.1) On WNFS node with OIDC GW, I start my game server and I create DNS records for others to join this specific game server

2.2) With social login they can register

2.3) Game server could allow invite other players

2.4) For each game session - where players involved can be different, we simply always create new UUID/CID objects as session ID, and leave the mapping to game server

The problem here is user database management … in decentralized world, and maybe it’s beyond the OIDC GW, so maybe we can open new thread for this in future if there is (I hope) interest.

Workflow 3 - OAuth endpoint

3.1) Source of truth is in WNFS storage

3.2) I want my own (ie. game) server to provide API

3.3) Does it make sense to convert UCAN grant to OAuth token? ie. for frontend application - especially if existing stack/language doesn’t support UCAN yet?

Workflow 4 - System Administration

If we use WNFS (or IPFS) for replication of data sets (IPLDs and any new WNFS structures I have not learned about),
we could possibly have not only a High-Availability (HA) solution, not just Content Delivery Network (CDN), but also possibly Identity Provider (IdP) solution.

Games are great, but having user database that I might as well use for Kubernetes authentication/authorization, or even use it for the edge computing I read a bit about …

And I dare to say that de-centralized (and self-replicating) HA IdP with Single Sign-On (SSO) capabilities sounds like … (sorry for the pun) game changer.

Anyway …

…

TL;DR

Thank you if you read so far.

I do realize this is not small thing, and there are lot of gaps and assumptions,
but does it make sense to have something like this?

Please let me know your thoughts on this topic, things I missed, got wrong, or problems I didn’t think of yet.

Sincerely - JV

Links:

1 Like
2

Having a server that does OIDC on the frontend and translates that to UCANs is definitely a thing.

I know that at some point at least, that was the plan for BlueSky’s PDSes - they’d talk UCAN to each other, but users would log in via email + password or OIDC in the future: https://github.com/bluesky-social/proposals/blob/e8f42e49a7ea49aa438e12bd320febff7da6b0bc/0004-oauth/README.md

Extending a BlueSky PDS could be a neat starting point for this - BlueSky PDSes already store IPLD-encoded data (just like WNFS, actually both are dag-cbor mostly).
One thing that such PDSes need to be extended with is secrets management though, depending on how you want users to be able to recover their data, though.

3

Thank you @matheus23. You definitely gave me a lot to read through.

The secret management was what I was thinking about (and again hoped to avoid for now).

That said, I think I can craft some basic IPLD structures to mimic unix’s shadow files
and if WNFS would allow me to keep such IPLD objects private and local only,
I believe I could make simple proof of concept.

I just know I am no security expert and last thing I want is to spoon feed stuff to bots and rainbow tables.

4

You can put secrets into WNFS, that’s fine and secures them, but only if the key to WNFS is secure itself. And obviously, you can’t put that inside WNFS and forget about it.

So in the end you need to think about where you root your trust.
Here’s some examples of what other applications do:

  • 1password creates a pdf file with your master key, they call it the “emergency kit” - you can print it and keep it safe. I think you can re-generate a different pdf as long as you still have access to your account in any one of your devices & remember the master password.
  • Web3 wallets often store your master seed, at-rest encrypted using a password. This is simple, but neither very user-friendly (if users forget their password) or safe (password can be bad).
  • There’s hardware-based secure keys like the ledger, trezor or similar. They unlock with a fingerprint or a password or simply sign/encrypt/decrypt stuff without the private key leaking to the device they’re connected to. This is secure, but doesn’t really solve the problem with a user losing their device.
  • Some wallets like Argent allow you to recover secrets by splitting your secret across a bunch of friends you choose, who should verify that a recovery request really comes from you, e.g. in person. Argent calls these “Guardians”. Apple is embarking in similar directions with their Advanced Data Protection features that support recover contacts.
  • Companies like signal store your secrets on their servers, but inside HSMs (hardware security modules). These are configured to only be able to extract your secret when you enter a 4-digit pin correctly, but because they’re HSMs they can enforce a X-tries-maximum rule, where after X unsuccessful tries it deletes the secret and X is some low two-digit number. This somewhat improves upon normal password-based secrets, because (1) the password is way shorter and often easier to remember and (2) you can’t try lots of guesses, assuming the HSM hardware can’t be hacked.
  • I’ve also heard people mention lit protocol a bunch, but haven’t looked deeply into that myself.

I know all of these things are quite some effort. Using an auto-generated seed phrase that users are encouraged to store in their password manager is a good early compromise IMO.

In the end I’d prefer a system that (1) generates keys with high entropy for you, so you can’t choose a bad password and (2) either puts these keys into a secure enclave (most devices like phones and laptops support these nowadays) or combines multiple secrets from multiple machines, so these parts are never in RAM on one machine and the secret is never sent over the network at once.

Anyhow - these are my rough notes on this problem, I don’t know if I would recommend building something like this, because it’s hard, but perhaps it helps to get an overview?