While attending DIDW (ok, this is a little late for a DIDW blog entry) I heard an interesting presentation by Michael Barrett CISO of PayPal. One of his concerns is that we are getting more and more identity standards rather than fewer. In some senses we are fracturing the market rather than uniting it even though most agree that identity is critical to the success of the web and services going forward.
I've been feeling for a while that we have enough protocols to satisfy the different use cases that exist and many that will come up in the future. What we don't have is a way to use what exists as standards across a wide range of disparate deployments. This causes confusion for users and lots of work for developers. There is also the "I'll wait and see" affect in the industry as companies wait to see which "protocol" will "win".
However, getting something that covers 50% to 80% of the use cases approved as a standard and adopted is rather a long process. So what about just some simple conventions that would allow existing protocols, services, and deployments to work together? In the past I've talked about both HTML markup on the RP web site as well as specifying the user's IdP in an HTTP header via an identity agent on the user's device.
Here is another. What about a simple transform on an email address to construct an URI that can then be put through the "Discovering an XRDS document from an http(s) URL" process? This would be another way to determine the IdP in an RP initiated authentication event. This could be something like take alice@example.com and transform it to http(s)://services.example.com/idp. I'm not particular to the transform itself, just that there be a way to convert an email address into a URI than can be commonly processed to determine the IdP endpoint(s) and supported protocol(s).
1 comment:
Sam Ruby has proposed using SRV records (see http://intertwingly.net/blog/2007/09/28/Email-addresses-your-OpenID-via-DNS) for discovery of OpenID options for email addresses. It seems like there are basically two approaches, that one or a close equivalent, or your proposal or a close equivalent. It would be interesting to see a comparison. I wonder if SRV records are simply inherently vulnerable to MITM attacks, for example?
Post a Comment