I’d say I have the opposite of a narrow view of software one can write, having written everything from typical web/mobile apps to DBs, network protocols and VMs :)
My initial explorations were focused on the web, but the network-level scheme I landed on does indeed do discovery on the backend.
Appreciate this feedback. I’ve been in the weeds of this stuff for some time, so it helps to see the rubber meet the road so I know what I missed.
I don't understand why you need discovery in personal apps at all. They are just for you, you know exactly what's available and what's not.
Do you need document storage? Hardcode `sftp://192.168.1.18/data` (or `sftp://data-server.local/data` if you want to be fancy), it's just for you. Do you need to send a notification? Pretty sure you know what your favorite method it, call it directly. Maybe add a local proxy that adds your token to avoid copying token around. Need ollama access? Don't mess with discovery, hardcode again...
Easy to imagine that haha. That’s part of the reason I’d lean on a standard like JOSE and make signing happen automatically for users who prefer to use an SDK
Fair. I assume you mean asymmetric key cryptography and not JWKs in particular? JOSE is a pretty good library if you need the latter and you’re already working in JS
IMO this is a tooling issue. You can make your SDK generate keys and even base64 encode them so they appear opaque to the uninitiated (like an API key)
It's interesting to imagine taking the pubkey as identity concept to its full extents in situations like this, for example if you could create a cloud account, spin up resources, and authorize payment for them all programmatically without having to enter payment details on a form (because your keypair can authorize payment with the whatever payment method you use)
Not sure which way of constraint you're referring to, but WebAuthn credentials are bound to a domain via Relying Party ID.
There's a proposal for cross-domain usage via Related Origins, but that scheme depends on the authority of the relying party, meaning you can't say "I'd like to be represented by the same keypair across this set of unrelated domains"
> Pity that Passkeys are so constrained in practice by browsers, that using them pretty much requires you trust the cloud providers absolutely with all your critical keys.
Passkeys are not constrained so you have to trust cloud providers or anyone else with all your critical keys. The key is resident in whatever software or hardware you want to use, and anyone can create passkey software or hardware that will work with Chrome etc. I'm talking about (and I'm pretty sure the OP was referring to) the other side of WebAuthn: where the credentials surfaced to JavaScript via WebAuthn actually come from and how the browser relays requests that a challenge is signed.
Yeah, I am sort of a fan of Passkeys in principal, but they are domain bound (you can't use them across domains).
I wish there were something built into browsers that offered a scheme where your pubkey = your identity, but in short there are a lot of issues with that
The key distinction I am getting at is: self-signed as in “signed with a self-issued key pair”, as opposed to using an API key/credential that has been issued to you
1. With self-signed JWTs, you could start consuming APIs with free tiers immediately, without first visiting a site and signing up. (I could see this pattern getting traction as it helps remove friction, especially if you want to be able to ask an LLM to use some API).
2. Compare this scheme to something like the Firebase SDK, where there's a separate server-side "admin" sdk. With self-signed JWTs, you just move privileged op invocations to claims – consuming the API is identical whether from the client or server.
3. The authority model is flexible. As long as the logical owner of the resource being accessed is the one signing JWTs, you're good. A database service I'm working on embeds playgrounds into the docs site that use client-generated JWKs to access client-owned DB instances.
For web dev, where, sadly, it's the norm to have about 13 different services for a website, it would greatly simplify having to herd 13 API keys around
Yeah that's not happening. In fact most services with free tiers still ask for a credit card number, and if not still ask for a lot of information. It is a marketing scheme after all.
> you could start consuming APIs with free tiers immediately, without first visiting a site and signing up
I’m yet to see a website that provides an API and doesn’t have a ToS that you have to agree to. Unless you control both parties, or you expose your service only to pre-vetted customers, there is no legal department that is going to allow this.
you put as part of the claims in the jwt that you agree to the TOS (may be something like { ... TOS:www.service.com/tos.txt, TOSAgreed:true ... }), which you sign. Then this is an explicit agreement from you as a client.
