[signin] API concerns

[Jared Hirsch]

Hey all,

I have some concerns I've been struggling to articulate, seems like I should just share them as-is.


## 1. Backwards-breaking API changes

I am **extremely** skeptical of this.

* the new API is really a minor revision on an existing API, there doesn't seem to be an extreme compelling technical need to do this.
* we aren't leaving beta, so we can't offer assurance we won't make more backward-breaking changes next quarter.
* two APIs is enough for this product--I think we've already used up our complexity budget
* new API breaks advanced use cases instead of allowing them, see next item


## 2. Breaking realms instead of making it optional

Calling this out as a separate item, I see several strong reasons not to adopt a new API here:

* my understanding (based on hearsay, I don't think any docs exist) is that Firefox Accounts *could* use Persona if realms support were merged. It seems like Persona is throwing away a big opportunity (lots of potential new users) by changing the API.
* realms enables the SSO solution users have often asked about.
* throwing away a ton of work by 50% of the current signin dev team, this is a bummer and adds to the social reasons not to make the change.


## Wrapping up

I've drafted many emails on this API stuff over the past two weeks, and have done a lot of mailing list reading and re-reading. It's hard to raise concerns without sounding negative or just bringing stop energy. I really want to see this team and product come out of all the recent leadership/org changes strong and successful, and I'm only raising these issues to try to get us there. Not sure what to do, figured I'd just get my thoughts out there and see what others have to say :-\

Comments/feedback very welcome.

Jared

[Edwin Wong]

Could we separate Core Persona (Goldilocks plan) and spin off SSO/Session Management into a different repo where developers could optionally add such features?

-edwin

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity

[Francois Marier]

On 08/10/13 14:40, Edwin Wong wrote:
> Could we separate Core Persona (Goldilocks plan) and spin off SSO/Session Management into a different repo where developers could optionally add such features?

One of the problems with Realms that Dan highlighted on IRC is that
given the state of 3rd-party cookies and new localStorage sandboxing, we
can only hope to make Realms work in Chrome and Firefox.

Francois

[Jared Hirsch]

Here's my attempt to quickly summarize the API discussion and proposals that have gone around the list recently. I'm hurrying this out, so I am not referencing existing threads, and I'm sure I am missing *some* stuff. Hopefully getting the big picture, though.


## Background

With the original Callback API (navigator.id.get), Persona did one simple thing: verify a user's ownership of an email address.

With the Observer API (navigator.id.watch), Persona added session management: we asked RPs to listen for login and logout events, and to tie their sessions to Persona, effectively giving up primary control of user session duration.

Why'd we do this? If I understand Callahad's explanation, the idea was to change the nature of web browsing by taking control of the user's session away from individual websites and giving it back to users. This is a subtle and deep change, and it is fundamentally at odds with how websites are built. I don't want to get too deep into this, I hardly understand all the implications, but do want to point out that this feature was introduced with the goal of empowering users.

Overall, library authors and RPs have struggled to work around or paper over the session management features of Observer. Observer also complicated Firefox OS integration.


## Proposals summarized

One of the topics discussed at the Paris work week was how to change our session management approach to improve usability. The discussion was summarized in a proposal called the Paris proposal. Callahad later came up with an alternative proposal, which he dubbed the Goldilocks proposal, and in which he *referred to* watch as 'configure' and request as 'prompt', intending to avoid confusion. Funny enough, I thought part of the Goldilocks proposal was to *actually change* the APIs to configure/prompt (sigh) which motivated a lot of my concern in the previous email.

### 'Paris' proposal

Persona is stateful and "knows" if the user should be logged in or not. It will always automatically fire onlogin to try to enforce this, given the chance. (onlogout is removed)

### 'Goldilocks' proposal

Persona is effectively stateless. It pretty much only works in response to direct user action.


## Paris vs Goldilocks, going a bit deeper

Now that I understand it, I really like the simplicity of Goldilocks. Some other points Callahad mentioned (I'm running out of steam, just pasting out of IRC now):

"Paris" still has full Persona-owned session management going on. Lloyd just wants Persona to stop calling onlogout automatically. (This would technically let us remove onlogout, and move that into a callback passed to .logout() directly). RPs would have to change all their stuff to only call .watch() when *they* don't think someone is logged in, but if they call .watch() and Persona thinks the user should be logged in, then Persona will automatically fire onlogin. So if you mess up your logout (only clearing your cookies, not calling id.logout), your users automatically get logged back in whenever they see your login form. (This happened to many RPs on their first attempt at integrating Persona.)

Nice things about Goldilocks:
1) We can support existing .get() sites with *no* regressions purely in a 7 line client-side polyfill.
2) We can support existing Observer API sites with minimal regressions purely in a slightly longer client-side polyfill. The only things we would break are sites that expect require automatic session extension. (I don't know of any.)
3) We can tie this to the FxOS 1.3 release (March), which gives us the full, promised 6 month deprecation window

The two big things we lose with Goldilocks are automatic session extension (Moz OpsSec wanted this) and cross-domain SSO. But we can't *really* deliver cross-domain SSO (realms) because of the upcoming localStorage / third party cookie changes being made by, well, everyone.

Also useful, Callahad put together a Goldilocks prototype, see [1]. Reading this cleared up some points for me.


## That's all folks

Huge, huge thanks to Callahad for talking me through this at length.

There are infinity other threads on the mailing list about this, but hopefully this summary helps people who, like me, were kinda lost about what the proposals were fundamentally all about.

Cheers,

Jared

[1] https://gist.github.com/callahad/6807882

[Lloyd Hilaiel]

Jared,

Thank you for challenging the API proposals, digging deep to understand them, and summarizing on the list to make your learnings accessible.

I'm excited to see goldilocks winning folks over. She quickly swayed me in the Bulgaria Sessions.

A couple thoughts inline, that hopefully helps folks understand rationale -

On Oct 8, 2013, at 10:52 PM, Jared Hirsch <6a...@mozilla.com> wrote:
>
> ## Proposals summarized
>
> One of the topics discussed at the Paris work week was how to change our session management approach to improve usability. The discussion was summarized in a proposal called the Paris proposal. Callahad later came up with an alternative proposal, which he dubbed the Goldilocks proposal, and in which he *referred to* watch as 'configure' and request as 'prompt', intending to avoid confusion. Funny enough, I thought part of the Goldilocks proposal was to *actually change* the APIs to configure/prompt (sigh) which motivated a lot of my concern in the previous email.

Yes, important point! We're not proposing new function names. We're proposing changing semantics on existing functions.

I still believe we can do this in a way that does not break existing users of watch and get, and does so with minimal backwards compatibility code. This belief is strengthened by the fact that we were able to "make ios7 work" and that's the environment that has restrictions that prevent everything except the subset that is goldilocks.

To explore this further, with dan in the Bulgaria Sessions, I started an experimental branch [1] to rip out everything obviated by the goldilocks proposal. My thinking was to aggressively reduce the footprint of include.js and the communication iframe, then make minimalistic changes elsewhere, and discover a couple things:

1. how well can goldilocks support existing users of get and watch?
2. how well does goldilocks deliver on the goals? (enumerated in paris, including reduced complexity, much faster load times)

My conclusion was that we could actually deliver goldilocks using the communication iframe in a much reduced capacity, and then as a next step we might be able to eliminate it all together. It feels extremely promising.

[1]: https://github.com/mozilla/browserid/tree/goldilocks

> ### 'Paris' proposal
>
> Persona is stateful and "knows" if the user should be logged in or not. It will always automatically fire onlogin to try to enforce this, given the chance. (onlogout is removed)
>
> ### 'Goldilocks' proposal
>
> Persona is effectively stateless. It pretty much only works in response to direct user action.
>
>
> ## Paris vs Goldilocks, going a bit deeper
>
> Now that I understand it, I really like the simplicity of Goldilocks. Some other points Callahad mentioned (I'm running out of steam, just pasting out of IRC now):
>
> "Paris" still has full Persona-owned session management going on. Lloyd just wants Persona to stop calling onlogout automatically. (This would technically let us remove onlogout, and move that into a callback passed to .logout() directly). RPs would have to change all their stuff to only call .watch() when *they* don't think someone is logged in, but if they call .watch() and Persona thinks the user should be logged in, then Persona will automatically fire onlogin. So if you mess up your logout (only clearing your cookies, not calling id.logout), your users automatically get logged back in whenever they see your login form. (This happened to many RPs on their first attempt at integrating Persona.)
>
> Nice things about Goldilocks:
> 1) We can support existing .get() sites with *no* regressions purely in a 7 line client-side polyfill.
> 2) We can support existing Observer API sites with minimal regressions purely in a slightly longer client-side polyfill. The only things we would break are sites that expect require automatic session extension. (I don't know of any.)

/me is hopeful

> 3) We can tie this to the FxOS 1.3 release (March), which gives us the full, promised 6 month deprecation window

Yes. We need feedback from the native team on this. The thing that helps native folks with goldilocks is because of the simplified api, we can reduce our footprint in native environments, and drastically simplify and improve those implementations.

> The two big things we lose with Goldilocks are automatic session extension (Moz OpsSec wanted this) and cross-domain SSO. But we can't *really* deliver cross-domain SSO (realms) because of the upcoming localStorage / third party cookie changes being made by, well, everyone.

Back story: The usage of session extension in mozilla infrastructure was motivated by the desire for quick session revocation. The idea was with short sessions, upon disabling a user account, it would quickly (but not immediately) be the case that the device is locked out of all sites to which they no longer have access.

If we no longer have session extension, then for internal mozilla sites we will simply check our LDAP systems directly to see if the user account is still enabled and if session was started before a password change operation.

This gets us instantaneous session revocation, at the cost of less decoupling between individual applications and our authentication service, but pragmatically speaking, we're still much more decoupled. We still have the fantastic security property that user's LDAP passwords are typed into fewer places, and visible by less of our internally and externally hosted applications.

So it's still true that persona meaningfully improves the security of mozilla infrastructure.

> Also useful, Callahad put together a Goldilocks prototype, see [1]. Reading this cleared up some points for me.
>
>
> ## That's all folks
>
> Huge, huge thanks to Callahad for talking me through this at length.
>
> There are infinity other threads on the mailing list about this, but hopefully this summary helps people who, like me, were kinda lost about what the proposals were fundamentally all about.

Thanks again jared for digging deep and making this conversation (hopefully) more accessible to folks.

<3,
lloyd

[tcub...@gmail.com]