Scott Kveton

Why would a site adopt OpenID?

Jason Barnabe of userstyles.org writes in with a few great questions:

I’m interested in learning more about OpenID. Most of the documentation I’ve found online deals with OpenID from a user’s perspective: “OpenID is cool because you don’t have to maintain logins at a bunch of different places.” What about from a webmaster’s point of view (I believe in your terminology, “Consumer”)?

What gets me excited about OpenID is that the value proposition is both for the end-users and for the consuming sites. First, let’s review the user-side of the value proposition:

Don’t have to remember so many logins; one password, one login
Portability of user identity (especially if you own the domain you’re delivering your identity from). This gives users better control of their identities.
Users can associate OpenID’s across multiple sites. For example, today there is no way to determine if one John Smith on site is the same as on another. OpenID will at least make it so you can say you are the same OpenID on each site (now that’s not saying that user is John Smith but more on that below).

And for consumers (aka website operators):

No more registration form: The OpenID process makes it so the registration screen on sites goes away allowing users to quickly engage in conversations, commerce or feedback.
Increased stickiness: Users are more likely to come back since they don’t have to remember yet-another-username-and-password combination
Up-to-date registration information: How many sites have you registered on as ‘asdf’ or filled out bogus information? Probably quite a few. With simple registration in OpenID v1.1, this information is gathered quickly and painlessly (assuming you get the users permission).

I’ve found some documentation and libraries on *how* to implement, but not *why* or in what configuration. For example, I believe I read somewhere that e-commerce type sites that should use OpenID would require the providers to have strong passwords. What are the recommendations for a simple user-generated content site, like mine at userstyles.org? Should all providers be trusted, or could a malicious provider do something really bad?

I did a walk-through of OpenID that explains a little bit of the terminology as well as the flow from the users perspective. Let’s take the example of logging into an e-commerce type site. The user only enters their password on their identity providers’ site. That means the e-commerce site would have no way of knowing what kind of password schemes were in use by just looking at the identity provider. They could figure it out pretty quickly with a manual inspection but there is no flag that tells the consuming site what kind of password strength is required.

If you were to enable OpenID on your site, you would be consuming OpenID’s. If you were also serving OpenID’s you would be producing them. In the latter case you become an identity provider (IdP) that creates OpenID’s for use in the OpenID eco-system. This is an important distinction. For smaller sites, I would recommend just enabling the consumer side; make it so users can login with their OpenID. If you have users wanting to create new OpenID’s then I would suggest partnering with an identity provider that will allow you to send users their way. For example (and this is a shameless plug so treat it as such) we do this for a few sites, the most notable of which is Zooomr. Now there are several other identity providers out there as well that you can use to do this which is great for you as a website operator. The most important part about that is that we’re all doing this stuff everyday. How much time do you really want to spend on “user accounting” on your site anyways? Its the least “main thing” you have to deal with when having a site with logins. You want to focus on photo sharing, social bookmarking or in your case, empowering users to tweak website and application styles.

Now, should all identity providers be trusted? That’s a toughy. There is an interesting discussion going on about this on one of the OpenID mailing lists. The de-centralized nature of OpenID is what makes it so compelling. However, that is also what could lead to bad things like spammers setting up their own IdP’s and then spamming blogs and wikis out of existence (or just making OpenID go away). Solutions like Akismet and captchas help with the comment piece but what we really need is some sort of reputation component that says “yes, this is a valid user tied to this OpenID and not some bad person or bot”. We don’t have it yet and to try and engineer that out today would be nuts; it will happen, it’ll just take some time as we watch and learn how OpenID is used in the real world.

About The Author

kveton

3rd

October 2006

bykveton
posted in Identity, JanRain, OpenID
17 Comments »

17 Comments Add Yours ↓

The upper is the most recent comment

Paul Madsen #

10.03.2006 22:27
1
Scott, in your description of password schemes, it sounds as if you are suggesting it’s a strength of OpenID that the SP doesn’t know whether I authenticated to the IDP with a 3 character password or something stronger.

There should/must be a way for the IDP to say how they authenticated the user – the SP might need this info in assessing the relevance of the IDP’s claim to its security requirements.

Paul
kveton #

10.03.2006 23:10
2
What’s to stop a rogue IdP from saying they required a super high security level for their passwords when they didn’t really? Or are you suggesting that we assume we trust the IdP?
Will Norris #

10.04.2006 17:47
3
Well nothing of course, but that goes back to the issue of trusting an IdP. If you’re going to accept anything from a given IdP, then there must be some level of trust as to the accuracy of that information. Once that trust is established (however that would work), it would be possible to provide something akin to SAML’s AuthnContext element. Of course this makes everything a little bit heavier than perhaps it should be. I’ve always viewed OpenID (perhaps incorrectly?) not as a direct competitor to the various SAML products, but rather as a lighter weight solution when the full weight of SAML isn’t necessary. Given that, even though it may be possible to provide an AuthnContext in OpenID, it might not be a “good thing” in the long run.
kveton #

10.04.2006 17:52
4
The key here is we don’t know how that trust will be established. OpenID has been successful because it made as few assumptions as possible; once we see how users and sites are using this stuff, we can better craft the protocol. The same is true of trust; we’re not sure of the mechanism yet so trying to bake it in yet would be crazy. I’m a firm believer that the market will yield the solution for us.

I completely agree that SAML and OpenID are not competitors. The discussions we’ve been having in the OpenID community have always revolved around ways we could either leverage the work done by the Liberty camp or better yet use some of the solutions directly in the OpenID stack as it starts to mature.

When I look at a protocol for something like this I have to ask “what technology has the best opportunity to evolve with the community that is using it?” OpenID seems to be a pretty good fit with lots of sharp people getting on board and an excellent community forming around its use. I’m hoping we can continue to stay nimble and work with folks in the SAML, Higgins, etc camps. Seems like the right thing to do to me.
Jason Barnabe #

10.04.2006 19:26
5
“No more registration form: The OpenID process makes it so the registration screen on sites goes away allowing users to quickly engage in conversations, commerce or feedback.”

But what about that site’s existing users? And what about additional information, such as site-specific settings or data, that the consumer requires that’s not provided by the provider?
Paul Madsen #

10.04.2006 19:33
6
Wrt SAML 2.0’s Authentication Context, at its lightest, it can be just a URI that the IDP inserts in its Assertions. The SP parses the URI and recognizes the authentication mechanism (and maybe other info as well).

It’s not just for the IDP to use in its assertions, the SP might want to indicate what it expeced/desired when it asked the IDP.

Seems to me that if you want OpenId used for multiple authentication mechs (password, OTP, biometric, whatever), you need ways to express these in the protocols. SAML does it with AC, Cardspace has a different syntax.
kveton #

10.04.2006 20:20
7
Jason: you are prolific with the great questions … :-)

What I’ve seen with most sites is that they actually create a local account that is keyed on the OpenID. This allows the ability to deal with all of the site-specific information quickly and easily while still leveraging OpenID. There is also the concept of attribute exchange coming to OpenID very soon. Think about being able to keep create, manage and update arbitrary attributes tied to your OpenID for use on any site on the Internet. A great example of this would be the ability to register on a Drupal site and get any of the special stuff that a Drupal user needs updated in your OpenID attribute profile. The next Drupal site you go to could then get access to that information (assuming the user wants them to have it).

You’ll find that applications like Drupal, Plone and others use the method of just creating a local account and then keying it off the OpenID.
Will Norris #

10.04.2006 23:27
8
Another use of simple registration is keeping your local copy of this data up to date… this is what we are trying to get our Shibboleth service providers to do. So a user may login and create an account with an email address X, but next week he changes his email address at his IdP to Y. If you receive his attributes each time he logs in to your application, you can check to see if you have the latest data and update if not.

Of course, there are cases when you might NOT want to update your local data… suppose a user is being hassled by another member in your community, so they change their contact information in your application. You wouldn’t necessarily want to change it right back the next time they log in, now would you? So you definitely need to think through everything, but it has the potential for providing real data provisioning.
kveton #

10.05.2006 01:56
9
The possibilities are endless. The other thought on this would be to notify sites when you change the information at your IdP. So you update your email and instead of having to login to all of your sites your IdP actually sends a note saying “hey, we just updated this user’s email address”. This is a non-trivial thing to do because you have to really trust the IdP.

In the case that you mention; user hassling another user on a specific site. Odds are if they know their OpenID they can hassle them all day long no matter what site they are on. In that case, maybe a using an anonymizer would be a good thing.
karl #

10.05.2006 06:36
10
More trust is good in some cases and not in others. As in connecting too many dots together and we enter in a privacy issue because of the lost of opacity.

So I would be careful, Open ID is good, but I would encourage to have more than one depending on their online personae.
Forsooth #

10.05.2006 07:41
11
Paul Madson wrote:

>There should/must be a way for the IDP to say how they authenticated the user – the SP might need this info in assessing the relevance of the IDP’s claim to its security requirements.

Why would it need this info? Who cares? It should be the user’s responsibility not to choose a crappy IdP, just like it should be the user’s responsibility to not post porn pix to the consuming site.
Will Norris #

10.05.2006 23:45
12
@Forsooth:

There are plenty of use cases in which a Service Provider is concerned about the strength of an Identity Provider’s authentication mechanism. Imagine I’m a banking website and I allow users to login with their OpenID (I’m not sure that I’d recommend that, but just suppose..) I have a real concern with making absolutely sure that the person at the keyboard really is the person who owns a particular bank account. I am the one releasing the data (or allowing access, whatever), so it is ultimately my responsibility to authenticate the user. As a convenience I may delegate this authentication to another party, but in the end it is still my responsibility. Granted, they have a responsibility of choosing a good IdP, but I would also have a liability risk if I release someone’s personal banking data because I didn’t adequately authenticate the user. Requiring a specific level of assurance would alleviate this to a certain degree. (Of course as already mentioned, I’d have to trust the IdP to be honest in how they authenticated the user).
Forsooth #

10.06.2006 07:35
13
You can’t say the bank would be liable if a user’s security is compromised because of a poor IdP. That’s tantamount to saying the bank would be liable if the user left his password taped to the monitor and his brother logged in and emptied his funds. (of course there are probably no legal precidents yet in this arena but it seems highly unlikely…)
Blane #

11.24.2006 16:55
14
Probably not quite the place to post this comment but we are desperate. We are working on accepting user-centric identities. We plan on accepting OpenId and CardSpace. We have a similar page that whobar provides.

We develop with the JanRain .NET library from openid.org.

You mentioned in this blog OpenId mail forums and I was wondering how to get to them? We are very confused about how we get identity claims from the OpenId token.

There does not appear to be anything in the JanRain that lets you do that. Even WhoBar talks about getting the claims but when we run the code we don’t get anything.

Thanks!
Blane #

11.24.2006 16:56
15
I see your website grabbed some claims so any insight would be much appreciated!
Andrew #

01.09.2007 19:23
16
If by “claims” you mean getting the user profile information from the person using OpenID to login to your web site, I just posted on how to do it using JanRain’s assembly on my blog.
Azox #

03.23.2007 06:01
17
Awesome, man

Why would a site adopt OpenID?

About The Author

kveton

3rd

October 2006

17 Comments Add Yours ↓

Your Comment

About Scott Kveton

Recent Tweets

Archives

Tags Cloud

Latest Post