Thanks for your comments.

NSTIC identity ecosystem participants (identity providers, attribute providers, etc.) will operate under an accreditation framework, so that a participant that is breached or otherwise not performing securely can have its accreditation revoked. The experience from the SSL issues is very relevant: revocation needs to be a real option. It’s important that both the technology (revocation protocols) and practicalities (can’t have any participant that is “too big to fail”) all need to be considered to make this really work.

You do have the option to have more than one identity provider in NSTIC, just as you can have more than one credit card. The separation between identity providers and multiple attribute providers also is a separation of privileges. I’ll be writing more about this sort of separation in future installments.

   0 likes

I may have missed some points but it looks like this strategy moves the problem to the identity providers if I understood correctly. Nowadays, SSL is in the spotlight: certificate authorities hacked (see Comodo group incident) = the whole chain is dead. Without getting into privacy issues, how having NSTIC identity providers with that level of control is different? In my opinion, the strategy will work until one of those identity providers gets hacked, then back to square one…

Also, while remembering a whole set of random passwords has its drawbacks, it is powerful at the same time: if the service provider I am using is compromised, not all my service accounts are compromised, dramatically reducing the collateral damage.

I do not know how it can be improved, maybe separating key privileges would be a good start: an identity provider would be able to create an identity OR would be able to verify an identity OR would be able to revoke an identity but would never be able to perform more than one of those tasks.. at least so that key operations are not related to a single entity in charge of everything the system security is built on.

Cheers.

   0 likes