Sunday, February 25, 2007
Where's the ice?
Unfortunately, predicting the weather here in VA is a bit of a trick. Instead of 1/4" to 1/2" of ice, we ended up with 7+" of snow:)
Friday, February 23, 2007
No ads for kids
Consider this for a moment.... My child gets online and goes to google to do some research for a school project. Google senses that the user is a child and does not display any ads (OK, maybe I'm dreaming) or displays child appropriate ads. This kind of claim "under 13" could be tied to an anonymous identifier so that each time my child interacts with a web site, they aren't being tracked and all their actions correlated to build a profile about them (of course there are many ways to do the correlation; using an anonymous identifier just makes it a little harder). The next piece of the puzzle would be for user agents to expose this information directly to the web site through some means.
My one concern is whether "pushing" the claim of "under 13" leaks too much information. Would this enable someone to target my child because they know s/he is "under 13"? However, I fear that if the claim is not "pushed" most web sites would just ignore it and not bother to go check with the appropriate attribute provider. Maybe the only way to solve this is through legislation (any one want to sponsor a "No ads for kids" bill?). Until then Firefox2 + AdBlock Plus is your friend.
I'd be interested to hear if anyone else has ideas or even considers this a significant problem.
My one concern is whether "pushing" the claim of "under 13" leaks too much information. Would this enable someone to target my child because they know s/he is "under 13"? However, I fear that if the claim is not "pushed" most web sites would just ignore it and not bother to go check with the appropriate attribute provider. Maybe the only way to solve this is through legislation (any one want to sponsor a "No ads for kids" bill?). Until then Firefox2 + AdBlock Plus is your friend.
I'd be interested to hear if anyone else has ideas or even considers this a significant problem.
Monday, February 19, 2007
OpenID and reputation
So the news that AOL supports OpenID finally bubbled up to Slashdot. What I found interesting is that most of the slashdot readers focused on the single-sign-on capabilities of OpenID. In doing so, there were a lot of comments regarding the privacy exposure of using a single identifier at many different sites. In fact, some were suggesting that having a unique account at every site is a "good thing". I understand their privacy concerns though that doesn't mean the user has to give up the benefit of SSO. SAML2 solves this problem just fine.
However, what is being missed by most of the slashdot community is that OpenID's are fantastic public personal identifiers. A few astute readers pointed out that in order to build reputation its important to have the same id. Otherwise, how will people realize I'm the same person on multiple sites? OpenID's provide an identifier that I can use so that people will recognize me at multiple locations. Now OpenID's are not the only kind of identifiers that provide this capability; XRI's and any consistent identifier will do the trick.
I found it interesting that while the "identity community" have no problems with the above concepts (if you've made it this far you're probably yawning), there is still a very large technical community that does not understand the ramifications of identity.
One final thought. There should be no reason why my IdP can't provide public personal identifiers in certain instances, pseudonymous identifiers in others, and temporary identifiers with claims in still others.
Tags: Identity, OpenID, Reputation
However, what is being missed by most of the slashdot community is that OpenID's are fantastic public personal identifiers. A few astute readers pointed out that in order to build reputation its important to have the same id. Otherwise, how will people realize I'm the same person on multiple sites? OpenID's provide an identifier that I can use so that people will recognize me at multiple locations. Now OpenID's are not the only kind of identifiers that provide this capability; XRI's and any consistent identifier will do the trick.
I found it interesting that while the "identity community" have no problems with the above concepts (if you've made it this far you're probably yawning), there is still a very large technical community that does not understand the ramifications of identity.
One final thought. There should be no reason why my IdP can't provide public personal identifiers in certain instances, pseudonymous identifiers in others, and temporary identifiers with claims in still others.
Tags: Identity, OpenID, Reputation
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
Thursday, February 15, 2007
OpenID and AOL Consumers
As has already been noted by John Panzer, Kevin Lawver and others, AOL is providing an OpenID URL for all AOL & AIM members. This enables a significant number of consumers with an OpenID URL. I hope this encourages greater participation amongst existing services on the web. I find that many of the services I want to try out, don't support OpenID and hence I tend not to go through the whole registration process just to see if the site offers the services I'm interested in. Greater participation by relying parties will be key for adoption and use of OpenID by the "mass market".
In the "adoption and use" department... Given that many AOL users will not realize they have an OpenID, it would be great if the help text for "what is an OpenID?" on relying party "login" screens would mention that if you have a LiveJournal or AOL account, you already have an OpenID. This isn't very inclusive so maybe there could be a link ("Do I already have an OpenID?") to a wiki page or something that could be updated as more OpenID Providers become available. This isn't that important for those who explicitly create OpenID's at OpenID providers, but is important for those consumers who have an OpenID by virtual of having an account for other services.
Tags: OpenID, AOL
In the "adoption and use" department... Given that many AOL users will not realize they have an OpenID, it would be great if the help text for "what is an OpenID?" on relying party "login" screens would mention that if you have a LiveJournal or AOL account, you already have an OpenID. This isn't very inclusive so maybe there could be a link ("Do I already have an OpenID?") to a wiki page or something that could be updated as more OpenID Providers become available. This isn't that important for those who explicitly create OpenID's at OpenID providers, but is important for those consumers who have an OpenID by virtual of having an account for other services.
Tags: OpenID, AOL
Wednesday, February 14, 2007
Tuesday, February 13, 2007
OpenID: Not all Chocolates and Roses
There has been quite a bit of hype regarding OpenID within that last few weeks. One of the biggest announcements is that Microsoft will work to support OpenID with its Cardspace card selection metaphor. While there are not many details about how this will work, this is still very good news for the OpenID community. There are other major identity players also working to support OpenID for their customers.
I would, however, like to bring some practicality to all this hype. OpenID as an identity system is perfect for the blogosphere and any publicly published content. It provides single-sign-on and auto-correlation across all comments, blog posts, picture galleries, etc that I publish. However, it's the auto-correlation part that causes problems when I'm NOT wanting to operate on the web in a public manner.
There are many tasks I do online that I do not want to ever by public (e.g. my banking site, purchasing history from Amazon, etc). While OpenID provides the single-sign-on benefit I desire even for these kinds of tasks, it also inherently allows for the correlation of my activities by those sites without my consent. This is definitely NOT user-centric.
The problem this creates is that most users will not understand the impact of using a correlatable identifier at all the sites they interact with and will leak privacy information in the process. I do want to note that the OpenID 2.0 draft spec addresses this issue by allowing an interaction method where the user can allow the OpenID Provider (OP) to pick a unique identifier for them. The user will then be known by that identifier at that site. However, my concern is that while this method is supported, it's not getting much traction in the industry.
As OpenID becomes more main stream it will be important for OpenID Providers to address not just the social-web tasks of users, but also the personal tasks of users and provide appropriate privacy protection.
Tags: OpenID, Correlation, Privacy
I would, however, like to bring some practicality to all this hype. OpenID as an identity system is perfect for the blogosphere and any publicly published content. It provides single-sign-on and auto-correlation across all comments, blog posts, picture galleries, etc that I publish. However, it's the auto-correlation part that causes problems when I'm NOT wanting to operate on the web in a public manner.
There are many tasks I do online that I do not want to ever by public (e.g. my banking site, purchasing history from Amazon, etc). While OpenID provides the single-sign-on benefit I desire even for these kinds of tasks, it also inherently allows for the correlation of my activities by those sites without my consent. This is definitely NOT user-centric.
The problem this creates is that most users will not understand the impact of using a correlatable identifier at all the sites they interact with and will leak privacy information in the process. I do want to note that the OpenID 2.0 draft spec addresses this issue by allowing an interaction method where the user can allow the OpenID Provider (OP) to pick a unique identifier for them. The user will then be known by that identifier at that site. However, my concern is that while this method is supported, it's not getting much traction in the industry.
As OpenID becomes more main stream it will be important for OpenID Providers to address not just the social-web tasks of users, but also the personal tasks of users and provide appropriate privacy protection.
Tags: OpenID, Correlation, Privacy
Subscribe to:
Posts (Atom)