On Wed, Dec 17, 2014 at 12:44 PM, Ryan Kelly <[email protected]> wrote:
> On 18/12/2014 01:54, Tarek Ziade wrote: > >> On Wed, Dec 17, 2014 at 11:44 AM, Ryan Kelly <[email protected] >> <mailto:[email protected]>> wrote: >> >> I'd love to avoid public-key crypto here...perhaps there's a way for >> the content-server to generate a symmetric encryption secret and >> communicate it directly back to the relier without it transiting our >> servers? >> >> There's one semi-related use case we need to cover - that I guess is a >> complement from what you have described: >> >> The ability to discover an FxA user, and their public key (or whatever >> public key we can use to send the user encrypted data.) >> In other words, a browseable user directory ala LDAP like what SKS >> provides (or closer to us, Mozillians) >> > > I'd like for this to be done as a layer above the core FxA auth/oauth > infrastructure. It could be part of the profile server, or could be done > as a separate "fxa-pubkey-server". But this user public key should not be > derived from the core kA/kB key material. > > My hope is that this proposal, or something like it, gives you everything > you need to implement the above as a separate oauth service provider. > Seconded: this is a consumer of the key-providing service that rfkelly is mooting. I'd also like to ask we "need to cover" this service. This is the kind of service that I see no reason for Mozilla to provide. GPG and maybe keybase.io do similar things, and I'm pretty convinced neither have taken the consumer market by storm. I can see some neat applications, but none that are particularly compelling. What am I missing? Nick
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
