At least in the case of password resets, it's the site deciding they want "email" to be the weakest link, and many sites will require at least a little bit more (like secret questions) after a reset. In this scheme, email is by definition the weakest link.
The secondaries can never go away, unless sites are willing to straight up refuse customers based on their email address. There is an extremely long tail of corporate email servers out there, and those corporate employees are our users. I guess we just gracefully degrade back to standard usernames and passwords?
So the certa expire AND the key-pair is ephemeral, so if the user doesn't stay logged into their email account, they are going to get login prompts every 6 hours. If you use multiple emails, that means constantly cycling through your various gmail accounts every time the certs expire.
I think you need to allow flushing the key pair manually or else you're saying there really is no way to "Log out" with this. Worse, a user will click 'Log out' on their site, but the cert is still active so anyone can walk up / pick up the device and log right back in. So what we've been taught "make sure you log out and then quit the browser" wouldn't actually apply anymore.
Last thing for the night... If a site falls victim to a XSS vulnerability, does this mean an attacker can call id.get() and steal a users assertion, send it to themselves, and login as a user of my site by replaying the assertion? This is like stepping back to IE5 where cookies couldn't be HttpOnly!
Oh, sorry, there absolutely are prominent ways to log out / flush the keypair manually. It's after 02:00 local, so I need to get some sleep :).
As to XSS, the assertion that's transmitted to a site is scoped to that specific site, and is only valid for, iirc, 2 minutes. So replay attacks are severely constrained. Plus, the only meaningful data they contain is the user's email address, so phishing doesn't get you much of value or put the user at risk.
So that's a 'yes' this exposes authentication to XSS, albeit the attacker will have to hijack sessions in real-time as the assertions are forwarded to their server.
That's a huge step backwards in web security. Why pass the assertion to the RP via the most insecure channel possible, i.e. the client-side javascript? That was just the easiest way you could find so the RP could tie it to client's session id?!
Obviously the assertion must be sent from the browser plugin directly to the RP. You could do it by injecting an HttpOnly cookie for the RP's domain with the encoded assertion. Javascript can never see it.
In the case of a secondary, the secondary already has an HttpOnly session id with the end user, since they're authenticated in the first place. The secondary would post the assertion back to the RP directly at a well known URL, and the RP returns a URL to the secondary with a nonce built in. The secondary redirects the end-user to that nonce URL so the RP can give them an HttpOnly authenticated session id. I think you can do this in a way such that neither the assertion nor the nonce will be visible to client javascript.
Saying, 'oh your account can only be logged into by attackers for 2 minutes if they can XSS the RP' is beyond disappointing, it's borderline negligent.
At least in the case of password resets, it's the site deciding they want "email" to be the weakest link, and many sites will require at least a little bit more (like secret questions) after a reset. In this scheme, email is by definition the weakest link.
The secondaries can never go away, unless sites are willing to straight up refuse customers based on their email address. There is an extremely long tail of corporate email servers out there, and those corporate employees are our users. I guess we just gracefully degrade back to standard usernames and passwords?
So the certa expire AND the key-pair is ephemeral, so if the user doesn't stay logged into their email account, they are going to get login prompts every 6 hours. If you use multiple emails, that means constantly cycling through your various gmail accounts every time the certs expire.
I think you need to allow flushing the key pair manually or else you're saying there really is no way to "Log out" with this. Worse, a user will click 'Log out' on their site, but the cert is still active so anyone can walk up / pick up the device and log right back in. So what we've been taught "make sure you log out and then quit the browser" wouldn't actually apply anymore.
Last thing for the night... If a site falls victim to a XSS vulnerability, does this mean an attacker can call id.get() and steal a users assertion, send it to themselves, and login as a user of my site by replaying the assertion? This is like stepping back to IE5 where cookies couldn't be HttpOnly!