proxy for account/reset

[dannycoates]

Analogous to account and session create, we would need a proxy to do account resets. /raw_password/account/reset ?

[zaach]

Another option is to host the entire flow on the web.

[ckarlof]

This is important, but is this actually a blocker for you guys right now?

[zaach]

I think people were jazzed about hosting the whole flow from the "jelly". So, we'd put a link in the Settings on FxOS that points to the browser. In that case, the jelly takes the fall. We could still provide a proxy endpoint for the web, but the major gain is slimming the client library we ship on the phone. Without password reset, we could get away with leaving out sjcl, ect.

[dannycoates]

I can throw this together tonight if it helps

[zaach]

It's not vital -- we can still redirect users to the jelly and have them wait several seconds for the key-stretching to complete. The major gain is doing all the crypto remotely, which we get with a redirect or a proxy. Let's go with redirect, since jgruen et al were enthusiastic about it. The jelly can already handle a redirect to the password reset flow.

[ckarlof]

I think we need to discuss this further, as well as our near to medium term plans for the proxy endpoints.

[zaach]

Yeah, the proxy endpoints could be useful for demoing in the short term. Ideally, we'll be able to land the native crypto in time for FxOS 1.3. I don't think we want to support these proxy endpoints forever, which tends to happen when we ship stuff on the phone.

[dannycoates]

/account/reset serves two cases, change password and change wrapKb.

// /raw_password/account/reset
// request body
{
  "email": "me@example.com",
  "old_password": "foo",
  "new_password": "bar",
  "wrapKb": "ABBA" // do we want this?
}

Do we want to allow changing wrapKb with this endpoint?

[ckarlof]

Do we want to allow changing wrapKb with this endpoint?

The alternative is that the server would generate a new random one. /account/reset could also function this way. @warner should weigh in.

[dannycoates]

The server currently generates a new random wrapKb if the unbundled value of the submitted wrapKb is 32bytes of 0s. If I recall correctly the intent of sending wrapKb is to maintain the existing value. For a raw_password equivalent I think a property specifying if wrapKb should be reset would be sufficient.

{
  "email": "me@example.com",
  "old_password": "foo",
  "new_password": "bar",
  "reset_wrap_kb": true // false or excluded to keep the same
}

???

[dannycoates]

I implemented /raw_password/account/reset with the optional parameter resetWrapKb. I left it undocumented in api.md. If we want to keep it I'll add it to the docs and if we don't I'll delete the parameter.

f? @ckarlof @zaach @warner
r? @rfk

[rfk]

I really like having these moved into a separate file

[ckarlof]

Too dirty to be with the main code? ;)

[rfk]

Yes, I like to imagine being able to rip it out one day, even if I know that day may never come ;-)

[rfk]

It's not entirely clear from the code, is resetWrapKb a boolean flag or is it the old wrapKb? It seems to be the later. Otherwise code looks fine.

Something about futzing with wrapKb in this flow is deeply unsettling to me. IIUC it's not possible to obtain a keyFetchToken via the raw_password API, is that accurate? If so then I argue that it doesn't make sense to expose key-handling functionality via other raw_password endpoints either.

I'm going to wait for @warner and @zaach feedback before signing off on this.

[ckarlof]

@dannycoates and I discussed. This endpoint should be something like /raw_password/password/change and reset_wrap_kb should be omitted (the server will manage that). In addition we'll need (proposed) /raw_password/password/reset that takes:

{
  "accountResetToken": "99ce20e3f5391e134596c2ac55c0520f2edfb026761443da0ab27b1fa18c98912af6291714e9600aa349917519979b93a45e6d0da34c7509c5632ac35b2865d3",
  "newPassword": "bar"
}

the accountResetToken is gotten from a call to /password/forgot/verify_code. Our convention is camelCase here not snake_case, correct?

[rfk]

Our convention is camelCase here not snake_case, correct?

nod

[dannycoates]

Its actually easier (for me) to HAWK the reset request with the accountResetToken instead of passing it in the body. Unless its a problem for the client I'd rather do that.

[dannycoates]

@rfk test for /raw_password/password/reset is still coming...

[ckarlof]

Its actually easier (for me) to HAWK the reset request with the accountResetToken instead of passing it in the body. Unless its a problem for the client I'd rather do that.

We can of course be flexible here. Just so I understand, you're proposing:

/raw_password/password/reset takes:

{
  "newPassword": "bar"
}

and is Hawk-ed with the accountResetToken?

[dannycoates]

@ckarlof yes

@rfk ready for r? (ps - I wrote this in a hurry)

[rfk]

worth adding something like "...to a new randomly-generated value" to make more explicit what happens to wrapKb?

[dannycoates]

ok

[rfk]

What does it to to wrapKb?

[dannycoates]

wrapKb is unchanged

[rfk]

Awesome, I'm feeling much better about this with the new endpoints like that. r+ with doc nits as noted above.

[ckarlof]

Awesome, I'm feeling much better about this with the new endpoints like that. r+ with doc nits as noted above.

Feeling better with more /raw_password endpoints? Welcome to the dark side, dude.

[dannycoates]

@rfk updated api.md.