Hello,
> I'm a little concerned that the set of scope-specific keys is
> unbounded, and we have a public-key encryption for each one. That's
> very expensive. Perhaps we want to limit the set of keys provided, or
> do just one encryption for the entirety of the keys: {} data.
Actually we certainely don't want to limit the number of public keys
because we don't want that a compromised key reveal data of all reliers.
You were talking about GPG, yes GPG is quite expensive but with
libsodium having a pub/priv keypair is really cheap. (basically a random
32 bytes string is you private key and you derive it to get the public key)
That also the reason why we want a service that can link a Firefox
Account to the scoped public key used by an email address.
> A little off topic, but what happens if the user wants to convey "you
> can only see one key" or "no keys at all"?
I supposed we don't accept him to use the application then.
Also because the key are scoped, we may not need to ask him the
permission. I think client_id related keys should always come with an
oauth login if the PUBKEY is provided.
> * is there any request and response integrity at the fxa-oauth
> protocol level? I'm going to assume encrypt() is encrypt-and-HMAC
> throughout. How does the relier know the keys in /authenticate are
> the same as those in /token? Is this kind of state something that
> reliers expect to maintain already?
What I understood is that the public key is send only on the
/authorization endpoint and kept for use on the /token
Ryan, if I understand correctly, the oauth content-server is talking to
another server to validate the user the keys, the aim is to give to that
server the public-key so that it can build kAr and kBr and encrypted them.
It looks good to me.
Thanks for taking the time to go through all this.
Rémy
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
