On Tue, Aug 30, 2016 at 12:17 AM, <[email protected]> wrote:

> It's sparse, because it re-uses the existing account verification
> end-points.  The flow goes like this:
>
> * Submit credentials to /v1/account/login [1].
>
> * For whatever reason, the server decides the request needs
>   additional verification.  It sends the email and includes the
>   following fields in the response body:
>
>     {
>       "verified": false,
>       "verificationReason": "login",
>       "verificationMethod": "email",
>       [...other existing login response fields here...]
>     }
>
> * The email includes a link with a verification code, in exactly
>   the same way as the existing account-verification email.
>
> * When clicked, this link loads a page that submits the code
>   to /v1/recovery_email/verify_code [2]
>

I'm not sure how this makes it possible for me to use the Sync API like I
had previously. My app POSTs to account/login and gets back enough info for
me to retrieve the key needed to decrypt my bookmark data. I get that key
by accessing the crypto/keys storage object using the current Storage APIs.
The process all happens synchronously, and is non-interactive from the
moment I click a button on a web page to when the decrypted bookmark data
gets rendered to a web page. I read the above links but it's not clear how
they will allow me to get to my bookmark data. And it's only bookmark data
I care about.

How can I use this new security framework in my app to achieve the same
thing? Is it even possible given the flow I described?

Chris
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev

Reply via email to