There has been much talk in our industry about Technical Convergence (i.e. moving toward one protocol for a particular task). However, before there can be Technical Convergence, there needs to Community Understanding and potentially Convergence.
That's why I'm excited to be attending the Internet Identity Workshop in Mt. View, CA the week of May 12. This is one of those places where Community Understanding takes place and sometimes even Community Convergence.
Hope to see you there!
Showing posts with label Convergence. Show all posts
Showing posts with label Convergence. Show all posts
Friday, May 02, 2008
Wednesday, May 09, 2007
Technology convergence or seamless integration?
A while ago I wrote that users want convergence not interoperability. I still hold that this is true, however “convergence” in this case, is “convergence of the user experience” not necessarily the technology. Paul describes the issues very well in his recent post. For users, the experience has to be that using one identity meta-system is all that is necessary to interact with the entire set of services on the web. Forcing a user to know about which meta-system is needed for which online services will never succeed. This means that the industry has to solve the problem somehow “under the covers”.
I applaud Sun's entry into the OpenID space. However, I disagree with some that this will lead to technological convergence. The existing meta-systems are too entrenched in their existing deployments to change to something new. Some believe that convergence will come through domination of a single protocol, but I have a hard time excepting that. So that leaves determining how to interoperate between the different identity meta-systems.
I don't think this is unsolvable but it will likely NOT be simple. There are issues with token exchange, token transformation, provider discovery, etc. With a number of good choices for back-channel web services (WS-*, ID-WSF), front-channel communication (OpenID, SAML, Cardspace, WS-Fed, ID-WSF, ...), and SSO (OpenID, SAML, Cardspace, WS-Fed, ID-WSF, ...) it seems the time has come for the industry to slow down the spec development work and instead focus on seamless interoperability.
Here are some starting use cases...
Tags: Convergence, Interoperability, OpenID, SAML, ID-WSF
I applaud Sun's entry into the OpenID space. However, I disagree with some that this will lead to technological convergence. The existing meta-systems are too entrenched in their existing deployments to change to something new. Some believe that convergence will come through domination of a single protocol, but I have a hard time excepting that. So that leaves determining how to interoperate between the different identity meta-systems.
I don't think this is unsolvable but it will likely NOT be simple. There are issues with token exchange, token transformation, provider discovery, etc. With a number of good choices for back-channel web services (WS-*, ID-WSF), front-channel communication (OpenID, SAML, Cardspace, WS-Fed, ID-WSF, ...), and SSO (OpenID, SAML, Cardspace, WS-Fed, ID-WSF, ...) it seems the time has come for the industry to slow down the spec development work and instead focus on seamless interoperability.
Here are some starting use cases...
- User uses Cardspace to authenticate to a picture services that uses ID-WSF with it's billing partner(s)
- User authenticates with her college library using SAML and then wants to SSO into zooomr.com
- User users OpenID to sign in to their favorite hiking site which wants to display their buddy list as part of the site experience
Tags: Convergence, Interoperability, OpenID, SAML, ID-WSF
Friday, February 16, 2007
Users want convergence, not interoperability
Paul Madsen has a great post today regarding the permutations that must be supported to allow for interoperability between the different identity systems. A meta-system framework is great, but implementing it can be a big problem. Interoperability is a great first step but it can not be the end goal.
Stopping at interoperability has some unfortunate consequences for each of the parties in the identity transactions.
Identity Provider: Must implement multiple protocols. This isn't so bad for IdP's because there are relatively few of them and they can get a fair amount of value for their effort because it means more people will want to use their IdP (why Paul selected ProtectNetwork over AOL).
Relying Party: Must implement multiple protocols based on the services they provide. This is much more invasive because there are a lot more RPs than IdPs. Getting lots of RPs to support multiple protocols will be difficult unless it is made extremely easy through available toolkits. Developers (people?) are inherently lazy and spending time writing the equivalent of a TCP/IP stack by hand is not something they want to do. You can also apply these same consequences to web service providers.
Users: Must have multiple identities from different IdPs and know when to use them. This is the one that will kill the internet identity layer if we don't figure out a way toward better convergence. Here is my reasoning (corrections greatly appreciated)...
As we work toward convergence, we need to be mindful of the impacts on users. If we don't make it easy for them, the coolness of the technology doesn't matter.
Tags: Identity, Convergence, Liberty Alliance, OpenID, Cardspace
Stopping at interoperability has some unfortunate consequences for each of the parties in the identity transactions.
Identity Provider: Must implement multiple protocols. This isn't so bad for IdP's because there are relatively few of them and they can get a fair amount of value for their effort because it means more people will want to use their IdP (why Paul selected ProtectNetwork over AOL).
Relying Party: Must implement multiple protocols based on the services they provide. This is much more invasive because there are a lot more RPs than IdPs. Getting lots of RPs to support multiple protocols will be difficult unless it is made extremely easy through available toolkits. Developers (people?) are inherently lazy and spending time writing the equivalent of a TCP/IP stack by hand is not something they want to do. You can also apply these same consequences to web service providers.
Users: Must have multiple identities from different IdPs and know when to use them. This is the one that will kill the internet identity layer if we don't figure out a way toward better convergence. Here is my reasoning (corrections greatly appreciated)...
- Web site will need to implement multiple identity systems in order to take advantage of services available on the web
- Supporting multiple identity systems means that the bootstrap problem must be solved (how to exchange my OpenID authentication for a WS-Trust binary security token)
- Solving the bootstrapping problem is most easily done at the IdPs
- Not all IdPs will support all the necessary bootstrapping mechanisms
- Therefore, users will need to have identities at the "right" IdPs in order to use certain web sites
- Those web sites will have to figure out how to inform the user that their single-sign-on identifier doesn't work at their site.
As we work toward convergence, we need to be mindful of the impacts on users. If we don't make it easy for them, the coolness of the technology doesn't matter.
Tags: Identity, Convergence, Liberty Alliance, OpenID, Cardspace
Subscribe to:
Posts (Atom)