The session tokens that allow the Mobile ID API to obtain signed certificates and generate assertions have no expiration date by default. However, the server might revoke these tokens on some specific circumstances (for security or other reasons like bug 1023436). In these cases we will be stuck with an invalid session token that will make impossible to obtain a new assertion unless the user reinstalls the application. We need this fix to properly obtain a new valid session token from the server.

In other words, without this fix the user won't be able to login to Loop if the token is revoked on the server.

Romain - Do we need this to ship Loop? If so, do you read this as a feature or a bug? If it's a feature, then we probably should set the feature-b2g flag.

This sounds like a feature to me. Is the only scenario to revoke a server token when a new user of Loop starts using Loop with a previously registered MSISDN?

FWIW I don't think this is a feature but a fix for a potential (and pretty bad for the user) issue. (In reply to Romain Testard [:RT] from comment #4) > This sounds like a feature to me. > Is the only scenario to revoke a server token when a new user of Loop starts > using Loop with a previously registered MSISDN? No, it isn't. The token can also be revoked for security reasons.

Alright - I'll leave this on the nom list then & will discuss at triage.

Hi, Fernando, can we get your latest update? This bug has not update for more than one week. Thank you!

This one is on my list for next week.

Hi, Fernando, "next week" is going to be finished, any update? Thanks.

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #10) > Created attachment 8453647 [details] [diff] [review] > v1 Thanks!! Fernando!!!

Jed, have you got a few minutes to take a look a this patch, please? Thanks!

Comment on attachment 8453804 [details] [diff] [review] v1 Review of attachment 8453804 [details] [diff] [review]: ----------------------------------------------------------------- Looks good to me, Fernando. Thanks for catching this case and providing the fix! ::: services/mobileid/MobileIdentityManager.jsm @@ +929,5 @@ > + if (error === ERROR_INVALID_AUTH_TOKEN && > + !aOptions.refreshCredentials) { > + log.debug("Need to get new credentials"); > + aOptions.refreshCredentials = true; > + _creds && this.credStore.delete(_creds.msisdn); Why not delete _creds entirely from the credStore?

Thanks Jed! > > ::: services/mobileid/MobileIdentityManager.jsm > @@ +929,5 @@ > > + if (error === ERROR_INVALID_AUTH_TOKEN && > > + !aOptions.refreshCredentials) { > > + log.debug("Need to get new credentials"); > > + aOptions.refreshCredentials = true; > > + _creds && this.credStore.delete(_creds.msisdn); > > Why not delete _creds entirely from the credStore? That's actually what credStore.delete does ;). Instead of the whole object it only takes the msisdn as it is the db object key.

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #14) > > Why not delete _creds entirely from the credStore? > > That's actually what credStore.delete does ;). Instead of the whole object > it only takes the msisdn as it is the db object key. Ah yes. Thank you.