> In both cases the underlying identity model is actually based on DNS, IP, and internet domains - whoever controls those for your email/JWKS controls
Hmm I wonder if you are thinking that the JSON webkeys of the user need to be hosted publicly. I don't think they technically do. It's a common convention to do so (especially at some well-known URL).
But the user actually could instead send their public key on each and every JWT-bearing request they send, and as long as that public key is both (1) pre-registered with the API owner and tied to some identity the API recognizes as some authorized user and (2) can successfully be used to validate the signature, it should work just fine.
How do you pre-register them then? What prevents someone else from trying to register or push my JWKS to the API owner? If you are in an open security context (eg the Internet) you would then still need another way to handle Identity
Exactly my complaint. You still have to go into some web portal and install your public key, I guess.
> What prevents someone else from trying to register or push my JWKS to the API owner?
Well for one thing they wouldn't have access to your public key since you won't be hosting them publicly somewhere. But for another thing it will be useless to them unless they have access to your private key
Hmm I wonder if you are thinking that the JSON webkeys of the user need to be hosted publicly. I don't think they technically do. It's a common convention to do so (especially at some well-known URL).
But the user actually could instead send their public key on each and every JWT-bearing request they send, and as long as that public key is both (1) pre-registered with the API owner and tied to some identity the API recognizes as some authorized user and (2) can successfully be used to validate the signature, it should work just fine.