I've been seeing an odd behavior with the navigator.id.watch() call. It appears that on page reload, navigator.id.watch will return the onlogin() event regardless of the logged in state of the user. I believe that the suggested solution for this is for the .watch object to contain a loggedInUser field that matches the email contained in the verified assertion. This is a bit sub-optimal because it means either adding extra code on the requester to trap for this otherwise causing the login window to flash up and disappear, or a constant loop of request, authorization, page refresh, request, etc. Is it possible to add a cookie to the browser's request to the Persona server to indicate that the user has already logged in so that this loop doesn't happen? Possibly with an "override" argument in the .request() call to force the assertion return, in cases where the RP needs to refetch the current assertion?
JR: FYI the place for these types of bugs that are about the protocol and not about the native implementation is in github: https://github.com/mozilla/browserid/issues The behavior you describe above is according to spec. Check out: https://developer.mozilla.org/en-US/Persona The idea is that, when you call navigator.id.watch(), you should provide the email address of the user *your* site believes is currently logged in, according to your session. Then, onlogin() is called if your site doesn't think the user is logged in. That should solve your problem. If not, please find us in #identity!