They give you a key and only if you have a higher tier account. The act of doing that requires that there is a step in the process where they know you’re requesting a key and who you are. They could bind them in the backend if they wanted, before giving it to you.
You’re still trusting them. Not to mention they could round them all up by IP or browser fingerprinting.
There is still some level of trust.
I happen to trust them enough for that; but it is still trust.
I am not an expert in the underlying cryptography, but the claim is indeed that the cryptographic approach makes it impossible for them to link the key to the queries in the backend.
Sure! But there is a stage where they generate those keys for you and give them to you. You need to be logged in to get that page. That is trust there.
No, issuer-client unlinkability is a feature of the design. The token is finalized by the client using private inputs so Kagi never actually sees the redeemable token (until it's redeemed).
Using the example doc you’re citing from kagi.com - though not the RFC, I don’t have the time to dive into that one at the second, I see that a session token plus some other stuff is passed in and a token comes out.
Where does it show that on the Kagi backend they couldn’t, theoretically, save the session key before performing the token response?
Sure, they probably do. Doesn't matter because neither the session key nor the token response can be linked to the tokens.
If you're not going to make an effort to understand how it works, don't make assertions about how it works. Ask your favorite LLM about the RFC if you have any further questions.
You’re still trusting them. Not to mention they could round them all up by IP or browser fingerprinting.
There is still some level of trust.
I happen to trust them enough for that; but it is still trust.