I was quite happily surprised when they started to talk about identity issues. It was gratifying to see that the stuff I and many of my cohorts have been working on for years has come to the forefront in everybody's mind -- although I still have trouble explaining to my mother exactly what I do at work.
I was even slack-jawed with the mention and discussion of OpenID. At first I was a bit shocked, later a bit jealous (how come they didn't talk about my stuff :-() and finally happy -- both for the OpenID guys and for the industry. I congratulate the OpenID guys with their success at getting into the limelight and making what appears to be real progress forward.
I'm not so impressed with the discussion about the phishing-resistant flag as it really doesn't add much value today. My problems with the flag include:
- A relying party (RP) would be hard-pressed to require a phishing-resistant credential nowadays given that only something like 0.000000001% (yes, I made that up, but I'm thinking I'm not far off there) of people today have phishing-resistant credentials that can be used for SSO transactions (yeah, many of us have cell phones with SIMs -- very phishing-resistant -- but the cellular providers severely restrict access to the SIMs to protect their own security).
- There's no definition about what it means to be "phishing-resistant" and from the discussions I have had with people (some of them very smart) who thought they had come up with a new solution for phishing, I think that many parties will think they have added phishing resistance when they haven't.
- Phishing isn't an issue of the OP or RP doing good authentication. It's an issue of the user being fooled into thinking they are talking to the OP when they really aren't. That won't be solved by a flag on the insecure request from the RP to the OP.
That aside, I think the most significant statement made in this area was the statement that Microsoft would work towards integrating better with OpenID in a future release of their products. I read this as Microsoft has recognized that there are other reasonable SSO protocols out there that they need to work with and this is a great step forward for the industry.
I now wait for Microsoft to recognize the other major player in the area of SSO and federation protocols: SAML 2.0. SAML is a convergence of work done in several areas including OASIS, Shibboleth/Internet2, and the Liberty Alliance and has a number of very large deployments throughout the industry.
If I had my druthers, I'd like to see SAML's ECP protocol support added to Cardspace so that a SAML relying party could make use of the Cardspace identity selector, so the user would have a single consistent place for local management of their identity information.
Perhaps I'm just a wishful thinker. I hope not.