On Tue, Dec 23, 2014 at 8:05 PM, Christopher Karlof <[email protected]> wrote:
> > > On Tue, Dec 23, 2014 at 1:42 AM, Tarek Ziade <[email protected]> wrote: > >> Ryan, Chris, >> >> I am using PyFxa to prototype the encryption flow here, by directly >> connecting to FxA : >> >> https://github.com/tarekziade/share/blob/master/share.py#L66 >> >> Can you tell me if that's the flow you had in mind ? >> >> > I don’t know the best way to do this yet. > > You suggestion gets the job done, but the idea would be that reliers would > integrate with a “public facing component” to get the keys, e.g., the OAuth > and Profile server. > Yes, as noted in my code, this direct access is temporary. It's done just because for now we can't get the keys back as an oauth relier. I used a direct Auth just to show how the kB key can be used. So the final version would replace this part with an oauth relier part to get the keys. > The Auth server isn’t the recommended way to interface with FxA (it’s > internal plumbing), but it is indeed open, and we’re not doing anything to > prevent developers from using it directly. > > -chris > > > >> Thanks >> >> >> >> On Tue, Dec 23, 2014 at 9:05 AM, Tarek Ziade <[email protected]> wrote: >> >>> >>> On Tue, Dec 23, 2014 at 1:07 AM, Christopher Karlof <[email protected] >>> > wrote: >>> >>>> Explicit revocation is different from “revocation as a surprising side >>>> of effect of doing something else that’s not obviously going to trigger >>>> revocation”. >>>> >>>> Ryan’s point is that password reset could easily fall into the latter >>>> type if we’re not careful. >>>> >>> >>> I don't see how this is avoidable though, without storing the old keys >>> on the server, which seems like a bad idea. >>> >>> >>> Did you have a solution in mind ? >>> >>> Cheers >>> Tarek >>> >>> >> >
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
