Ok, I've got the Mac OS 10.4.x port of OAuthConsumer framework checked in. You can get the code via anonymous svn here.
Monday, November 26, 2007
Thursday, November 22, 2007
OAuth consumer framework for Tiger
Just a short post to say that I've completed a Mac OS X Tiger port of Jon Crosby's OAuth Consumer framework and it should be appearing in the google code repository shortly. The back-port to Obj-c 1.x was very simple and I've tested the framework on Tiger against the version 2 ma.gnolia APIs. Start writing those cool Mac apps:)
Happy Thanksgiving from Virginia
Shenandoah River Valley
(taken Oct. 28, 2007)"God saw all that He had made and it was very good." Genesis 1:31
Wednesday, October 24, 2007
Standards glue (a.k.a. conventions)
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).
Tuesday, October 23, 2007
YAIDO - Yet Another IdP Discovery Option
In reading through Eve Maler's slides from this year's XML Summer School, she describes the standard IdP discovery problem for an RP initiated authentication event. One of the standard options is "Client tells RP". Putting this together with the proposal by Laurent Michel on the OpenID lists regarding mobile use of OpenIDs, why not just use the convention of an HTTP header to describe the user's IdP? (I suspect this has been proposed before. Feel free to add a comment stating so). This HTTP header would not have to be sent with every request, because the identity agent could detect when an RP needed it from some additional simple HTML markup.
The RP could then do a XRDS (XRI resolution v2.0 section 6) based discovery on the presented URI from the HTTP header. This would allow the IdP to expose multiple services and protocols via a simple XRDS file. The RP would then just pick the the appropriate protocol and endpoint from the XRDS file and start the RP initiated authentication process.
One danger with this kind of a "push" mechanism is that over an untrusted channel the user is susceptible to MIT attacks. With a smart client and SSL I believe this is better than the cookie mechanism. For OpenID it's probably better to take the seatbelt and sxipper approach of just posting the user's OpenID to the OpenID login form. However, for a protocol like SAML2, identifying the IdP in this kind of a manner should improve the user experience.
"Schooled" again...
I'm here in Tokyo for a Liberty Alliance meeting of the Technical Expert Group. This noon we had a "pick-up" soccer (football to the rest of the world) game. Not being in the best shape our TEG co-chair made quick work of our challenges on the field:)
Here are some less incriminating pictures from the event.
Many thanks to Mikko Laukkanen for taking the pictures.
More pictures by Phil Hunt found here. I'm sure more will be appearing shortly.
Here are some less incriminating pictures from the event.
Many thanks to Mikko Laukkanen for taking the pictures.
More pictures by Phil Hunt found here. I'm sure more will be appearing shortly.
Friday, September 21, 2007
DIDW 2007: Shameless Plug
Like many others I'll be at DIDW 2007 next week. I'll be giving a talk on the evolution of identity at AOL. I'm very proud of the significant identity model changes that AOL has been able to make over the last couple of years. I'll be covering this and amongst other things, our continued support of open standards.
Trust in social networks and identity protocols
So I've been “noodling” over this analogy for a while. People often complain that protocols like SAML are complex and not scaleable because they require “out-of-band” provisioning. In other words, in deployment something has to happen first, before the protocol becomes valuable. In the case of SAML, this “out-of-band” provisioning is what adds trust to the deployed network (hence the name circles-of-trust). (For all the SAML experts out there, please forgive my simplistic characterization).
One of the big selling points for OpenID is that it does not require this “out-of-band” provisioning and hence is easier to deploy and more “scaleable” (I believe the term is “internet scale”). However, one element missing from OpenID is trust. The ideal is that both OPs and RPs trust the user, but that is a lot of risk for especially the RP to take on in today's business climate.
So how does this relate to social networks? Well, in many social networks, both parties have to agree to the relationship before the relationship becomes valid. This might not be explicitly “out-of-band” but it is similar in concept. For example, if I invite someone to be a friend on Facebook, they don't show up as a friend until they have explicitly approved the relationship. Because of this factor, I am in essence building a “circle-of-trust” that is my friends on Facebook.
The “OpenID” example in social networks is AIM. I can add anyone I want to my buddy list (provided I know their AIM id) and they will be part of my network. I will also see when they are online and offline. The only way for a person to “block” this behavior is to reject presence information for all users except those on their buddy list.
My buddy list on AIM is definitely a social network of “people-I-know” but I don't think I could go so far as to call it a “circle-of-trust”:)
One of the big selling points for OpenID is that it does not require this “out-of-band” provisioning and hence is easier to deploy and more “scaleable” (I believe the term is “internet scale”). However, one element missing from OpenID is trust. The ideal is that both OPs and RPs trust the user, but that is a lot of risk for especially the RP to take on in today's business climate.
So how does this relate to social networks? Well, in many social networks, both parties have to agree to the relationship before the relationship becomes valid. This might not be explicitly “out-of-band” but it is similar in concept. For example, if I invite someone to be a friend on Facebook, they don't show up as a friend until they have explicitly approved the relationship. Because of this factor, I am in essence building a “circle-of-trust” that is my friends on Facebook.
The “OpenID” example in social networks is AIM. I can add anyone I want to my buddy list (provided I know their AIM id) and they will be part of my network. I will also see when they are online and offline. The only way for a person to “block” this behavior is to reject presence information for all users except those on their buddy list.
My buddy list on AIM is definitely a social network of “people-I-know” but I don't think I could go so far as to call it a “circle-of-trust”:)
Friday, August 17, 2007
AOL OpenID provider whitelist
So there has been a lot of discussion regarding AOL's support for 3rd party OpenIDs and the fact that currently AOL has a whitelist of approved OpenID providers. A number of good points have been raised.
Kim Cameron writes...
I fully agree with Kim that eyeballs are the desired commodity. In fact, that is the whole reason AOL is implementing open standards and allowing 3rd party identities. However, I do believe that accounts cost money (or at least can cost money depending on what that account is allowed to do at a service provider). Take a picture sharing site for example. The picture service will provide some amount of space for each account (this is true of email providers, etc). The picture service could charge for the space in which case the “real” accounts would be easily distinguished but most sites these days are trying the “free and paid by advertising” business model. Also, another indirect cost of an account comes from whether the account can publish content. Spammers love to create accounts for the sole purpose of posting one or two messages. They don't care that they are spinning through zillions of accounts. So yes, AOL is looking to get as many eyeballs as possible, but doing so carefully for this initial release.
Ashish Jain writes...
Jeff Bohren writes...
Being a relying party however is a different matter. If someone compromises a provider and falsely authenticates to your relying party, they are misusing someone’s resources. The sensitivity of these resources would make the difference between allowing unrestricted OpenID or white list controlled OpenID.
Ashish and Jeff both make great points. The crux of the issue is that all the risk is assumed by the relying party. That means the relying party needs to be able to detect “fraud” and take appropriate action. This could be done through a number of mechanisms like a “Provider” Reputation service or “fraud” detection infrastructure. The OpenID model is similar to the email model. Anyone can stand up a SMTP server and send mail. It's the receivers of the mail (ISP or individual) that have to filter the spam. In order to learn from our implementation and fix any bugs, we decided to take a cautious approach at first.
I would say this approach is actually very common in the Web 2.0 community. How many sites starting out are by invitation only? Do they do that to create buzz? Well maybe... but I suspect that the biggest reason is that it limits their exposure to invalid/spam accounts.
Finally, Carsten Pötter writes...
Well... I hope it is a positive signal to the community:) AOL is the first major provider to support OpenID as a relying party. As to strategy, yes there is one. It's one thing to implement the OpenID RP protocol. It's another to have all the associated infrastructure in place to detect and protect against “fraud”. As was pointed out earlier, the relying party assumes all the risk in the OpenID protocol. We are actively working on that infrastructure and process so that in the future we can remove the whitelist.
Kim Cameron writes...
What would make $$$ for AOL? To get my pretty eyeballs over there PDQ. What’s the best way to make that happen? Make it easy! Acquire new eyeballs! Acquire new eyeballs! Acquire new eyeballs! From anywhere and everywhere!
The secret? Auto-create an account on AOL no matter WHAT credential a user employs to get there. You need this anyway to manage their profile. Then get the user transparently to great experiences and start ringing up those eyeball seconds.
I fully agree with Kim that eyeballs are the desired commodity. In fact, that is the whole reason AOL is implementing open standards and allowing 3rd party identities. However, I do believe that accounts cost money (or at least can cost money depending on what that account is allowed to do at a service provider). Take a picture sharing site for example. The picture service will provide some amount of space for each account (this is true of email providers, etc). The picture service could charge for the space in which case the “real” accounts would be easily distinguished but most sites these days are trying the “free and paid by advertising” business model. Also, another indirect cost of an account comes from whether the account can publish content. Spammers love to create accounts for the sole purpose of posting one or two messages. They don't care that they are spinning through zillions of accounts. So yes, AOL is looking to get as many eyeballs as possible, but doing so carefully for this initial release.
Ashish Jain writes...
As it turns out, SignOn.com is not in their initial list. I talked to the AOL folks and they promised to add it during their update next week. Fair enough. However, this model isn’t scalable. Given the distributed nature of the protocol, it doesn’t seem right for IdP/OPs and RPs to individually contact each other to maintain this list. Isn’t there a need for an OP Reputation, a.k.a. qualification, a.k.a certification suite that the RPs can leverage?
Jeff Bohren writes...
In OpenID, there is very little perceived risk in being a provider. If a user compromises your site and uses your site to authenticate to a relying party as someone else, there is really very little consequence to you. After all you don’t have any agreements with any specific relying parties. Why not be a provider, if there is so little risk involved?
Being a relying party however is a different matter. If someone compromises a provider and falsely authenticates to your relying party, they are misusing someone’s resources. The sensitivity of these resources would make the difference between allowing unrestricted OpenID or white list controlled OpenID.
Ashish and Jeff both make great points. The crux of the issue is that all the risk is assumed by the relying party. That means the relying party needs to be able to detect “fraud” and take appropriate action. This could be done through a number of mechanisms like a “Provider” Reputation service or “fraud” detection infrastructure. The OpenID model is similar to the email model. Anyone can stand up a SMTP server and send mail. It's the receivers of the mail (ISP or individual) that have to filter the spam. In order to learn from our implementation and fix any bugs, we decided to take a cautious approach at first.
I would say this approach is actually very common in the Web 2.0 community. How many sites starting out are by invitation only? Do they do that to create buzz? Well maybe... but I suspect that the biggest reason is that it limits their exposure to invalid/spam accounts.
Finally, Carsten Pötter writes...
Is this the positive signal to send out to the community? Is there even a strategy at AOL? It seems like there is not much support for OpenID from within the company. But I may be wrong and see things too negative but I am actually really disappointed. :(
Well... I hope it is a positive signal to the community:) AOL is the first major provider to support OpenID as a relying party. As to strategy, yes there is one. It's one thing to implement the OpenID RP protocol. It's another to have all the associated infrastructure in place to detect and protect against “fraud”. As was pointed out earlier, the relying party assumes all the risk in the OpenID protocol. We are actively working on that infrastructure and process so that in the future we can remove the whitelist.
Wednesday, August 08, 2007
The lowered expectations of web applications
I find it interesting that consumers continue to put up with more and more “bugs” in the software and appliances we use. Today, in trying to publish my last post, I had to try 3 times to get blogger to accept the entry, including getting the wonderful page to the right.
While hardware appliances are better, I run into the same thing with my wide area wireless broadband connection. The first trouble shooting step is to reboot the wireless unit to see if that solves the problem.
Then just recently after getting back from vacation, I found that my satellite TV DVR service had been deactivated. When calling customer service to get it re-instated, it took the representative a couple tries to get it working. He finally had to first de-provision my DVR service and then re-activate it.
I guess the “benefit” for technologists is that we don't have to work so hard to build good products ;-)
Cardspace & Service Invocation
I got thinking about Cardspace the other day and it struck me that Cardspace does a great job of authenticating me to the relying party, but the relying party can't use that authentication for service invocations on my behalf.
For example...
Now it would be nice if the RP could use the existing authentication “session” with the user (as represented by the Cardspace token) without forcing the user to re-authenticate to AIM. Of course, the RP has no way of knowing whether the token it has is valid at AOL, nor probably, how to transform the token it has into a token that is valid at AOL. I suppose that if the token is a SAML token, then the RP could look at the issuer of the token and check to see if it is the AOL STS and from that try to use the token at AOL. The problem for the RP is that it might need to interact with many different services. What kind of claims does the RP request of Cardspace in order to get a token with the desired capabilities (e.g. service invocation with either Google or AOL)?
In order to solve this problem, it is very common in today's web experience for relying party A to request relying part B's authentication credentials in order to provide a service to the user. However, I always feel very nervous about giving relying party B's authentication credentials to relying party A. As the number of identities that consumers have to manage shrinks, the overlap of an authentication session across multiple relying parties grows. The identity meta-system should allow for the re-use of the authentication session across multiple relying parties as approved by the consumer.
One workable model, though somewhat inefficient, is for relying party A to request a service invocation token from relying party B. Using OpenID as the authentication protocol, the flow goes something like this...
All the front-channel redirects make it easy to get the user's consent as necessary. However, depending on the bandwidth of the consumer's internet connection, and the physical locations of RPA, RPB and OP, there can be some significant performance implications.
For example...
- User browses to the relying party (RP) and is prompted by Cardspace to authenticate
- User selects one of their cards (that they've previously used with the RP) and is logged in to the site
- Next the RP wants to import the user's AIM buddy list in order to enhance the user's experience at the site (e.g. find other users who also use the RP)
- The RP either requests AIM credentials and uses a back-channel API call to authenticate the user separately, or it redirects the user to AIM to authenticate
- AIM validates the credentials and returns a service API token
- The RP uses the service API token to request the buddy list
- Note that the user now has two different and distinct authentication sessions (one with the Cardspace or Managed STS and one with AIM)
Now it would be nice if the RP could use the existing authentication “session” with the user (as represented by the Cardspace token) without forcing the user to re-authenticate to AIM. Of course, the RP has no way of knowing whether the token it has is valid at AOL, nor probably, how to transform the token it has into a token that is valid at AOL. I suppose that if the token is a SAML token, then the RP could look at the issuer of the token and check to see if it is the AOL STS and from that try to use the token at AOL. The problem for the RP is that it might need to interact with many different services. What kind of claims does the RP request of Cardspace in order to get a token with the desired capabilities (e.g. service invocation with either Google or AOL)?
In order to solve this problem, it is very common in today's web experience for relying party A to request relying part B's authentication credentials in order to provide a service to the user. However, I always feel very nervous about giving relying party B's authentication credentials to relying party A. As the number of identities that consumers have to manage shrinks, the overlap of an authentication session across multiple relying parties grows. The identity meta-system should allow for the re-use of the authentication session across multiple relying parties as approved by the consumer.
One workable model, though somewhat inefficient, is for relying party A to request a service invocation token from relying party B. Using OpenID as the authentication protocol, the flow goes something like this...
- User browses to relying party A (RPA) and enters their OpenID to login
- Relying party A invokes the OpenID authentication flow redirecting the user to their OpenID Provider (OP)
- The user authenticates to the OP and is redirected back to RPA
- RPA requests a service token from relying party B (RPB) using a browser re-direct
- RPB requests an authentication of the user via their OP
- Since the user is already logged into the OP, this authentication step could be “seamless” to the user
- RPB creates a service invocation token for RPA and redirects the browser back to RPA
- RPA requests the data from RPB using the returned service invocation token
All the front-channel redirects make it easy to get the user's consent as necessary. However, depending on the bandwidth of the consumer's internet connection, and the physical locations of RPA, RPB and OP, there can be some significant performance implications.
Wednesday, July 11, 2007
Divine IM? ... no ... Divine I AM
Paul in his usual humorous way has an entry here describing some of the annoyances of IM systems. (I've recently run into something similar but that will have to wait for a different post).
Not surprisingly :), I do have an issue with Paul's “theology”. Yahweh (the God of the Bible) is a God of Relationship. IM is a rather un-relationship form of communication. In fact, I distinctly remember a conversation with someone well known in the identity industry, talking about how IM “paled” (my word) in comparison to meeting the person face-to-face. IM is useful in its own right but not one that takes the place of a personal conversation.
The giving of the Ten Commandments was not a short handoff of a “set of instructions” but rather a time where God spoke directly to the whole nation of Israel (Exodus 19-20). God then called Moses to a 40 day conversation at the end of which he received the stone tables.
I do, however, agree with Paul on one thing. Too often we are “screening” out God.
P.S. For those wanting the Biblical facts... the story of the burning bush can be found in Exodus 3-4 and the story of the 10 commandments can be found in Exodus 19-20.
Not surprisingly :), I do have an issue with Paul's “theology”. Yahweh (the God of the Bible) is a God of Relationship. IM is a rather un-relationship form of communication. In fact, I distinctly remember a conversation with someone well known in the identity industry, talking about how IM “paled” (my word) in comparison to meeting the person face-to-face. IM is useful in its own right but not one that takes the place of a personal conversation.
The giving of the Ten Commandments was not a short handoff of a “set of instructions” but rather a time where God spoke directly to the whole nation of Israel (Exodus 19-20). God then called Moses to a 40 day conversation at the end of which he received the stone tables.
Moses speaking in Deuteronomy 9:9-10...Yahweh communicated directly with the people of Israel and Yahweh still desires to communicate with each of us as well.
“When I went up on the mountain to receive the tablets of stone, the tablets of the covenant that the Lord had made with you [Israel], I stayed on the mountain forty days and forty nights; I ate no bread and drank no water. The Lord gave me two stone tablets inscribed by the finger of God. On them were all the commandments the Lord proclaimed to you on the mountain out of the fire, on the day of the assembly.”
I do, however, agree with Paul on one thing. Too often we are “screening” out God.
Yahweh22: YT?How can we possibly have a relationship with Yahweh (the creator of the universe; Genesis 1) if we don't listen?
Moses88: I am not here right now.
Yahweh22: Moses, I know you're there, I can SEE you.
Moses88: Sorry Boss, I was screening.
Yahweh22: Well don't, it's annoying.
P.S. For those wanting the Biblical facts... the story of the burning bush can be found in Exodus 3-4 and the story of the 10 commandments can be found in Exodus 19-20.
Saturday, July 07, 2007
Independence Day on the Potomac...
"Better late than never"
(between Family and Work these had to wait till today)
Friday, June 29, 2007
Passive identity meta-system markup
In talking to a number of people both internally to AOL and externally (most recently at the Burton Catalyst conference) I've become more convinced that in order to enable intelligent identity agents in client devices, service providers (SP) need a standard way to passively describe what identity meta-systems they support. This passive description allows “dumb-mode” browsers to act in the current way, while allowing “advanced clients” to provide more sophisticated user experiences as described in my recent entry on “Clients to the rescue”.
It's important to note that OpenID and Cardspace already provide this passive description albeit in an implicit rather than explicit way. In OpenID the login text field should be named openid-url, and in Cardspace there is the <object type=“application/x-informationCard“ .../> tag which intelligent clients can search for in the DOM. However, “cool” dynamic web design can make finding these implicit descriptions difficult. And AFAIK, there is no best practice/recommendation/suggestion to do this passive description for SAML.
So I'm advocating an explicit markup in the HTML that would allow identity agents the ability to determine the identity meta-system characteristics of the site. This metadata would be used to make the user experience as seamless as possible while still protecting the user-centricity of the different protocols.
I don't think this needs to be complicated. For many web sites the description of protocols supported could be done with an XRDS or SAML metadata document. Reference to this document could then be done through <link> tags.
The next step might be to use something like a microformat to describe the actual login form.
The <div> that contains the login form could then be referenced by id (or maybe just use the id of the form itself) via another <link> tag.
The goal of these examples is to show a possible method for explicit, passive declaration of capabilities. I'm sure there are many ways to optimize and improve the concept... but hopefully this is enough to make the suggestion concrete.
[Credits: Many thanks to Kevin Lawver for microformat suggestions/corrections.]
It's important to note that OpenID and Cardspace already provide this passive description albeit in an implicit rather than explicit way. In OpenID the login text field should be named openid-url, and in Cardspace there is the <object type=“application/x-informationCard“ .../> tag which intelligent clients can search for in the DOM. However, “cool” dynamic web design can make finding these implicit descriptions difficult. And AFAIK, there is no best practice/recommendation/suggestion to do this passive description for SAML.
So I'm advocating an explicit markup in the HTML that would allow identity agents the ability to determine the identity meta-system characteristics of the site. This metadata would be used to make the user experience as seamless as possible while still protecting the user-centricity of the different protocols.
I don't think this needs to be complicated. For many web sites the description of protocols supported could be done with an XRDS or SAML metadata document. Reference to this document could then be done through <link> tags.
<link rel=”metadata” class=”saml” href=”http://path/to/sp/metadata”/>
<link rel=”metadata” class=”xrds” href=”http://path/to/sp/xrds”/>
The next step might be to use something like a microformat to describe the actual login form.
<div id=“signin-openid“ class=“login-openid“>
<form action=“http://ficlets.com/signin/openid.signin“ method=“post“ id=“openid-form“>
<ul>
<li>
<label for=“openid-url“>Your OpenID:</label> <input
type=“text“ name=“openid“ id=“openid-url“
class=“text-field login-openid-identity“
value=““ /><input type=“submit“
value=“Login“ class=“submit“ />
<i>Ex: http://your-username.livejournal.com/,
http://your-username.myopenid.com/</i>
</li>
</ul>
</form>
</div>
The <div> that contains the login form could then be referenced by id (or maybe just use the id of the form itself) via another <link> tag.
<link rel=”login.form” class=”openid” target=”signin-openid”/>
<link rel=”login.form” class=”infocard” target=”nameOfDivId”/>
The goal of these examples is to show a possible method for explicit, passive declaration of capabilities. I'm sure there are many ways to optimize and improve the concept... but hopefully this is enough to make the suggestion concrete.
[Credits: Many thanks to Kevin Lawver for microformat suggestions/corrections.]
Wednesday, June 27, 2007
Concordia workshop @ Burton Catalyst
Yesterday I gave a presentation at the Concordia workshop (a pre-conference event to the Burton Catalyst conference) on issues consumers face when dealing with the user experience exposed to them by different identity meta-systems. Good summaries of the workshop can be found here and here.
A number of points stood out to me as I listened to the different presentations.
Overall, it was a very productive workshop. Expect more information to appear on the Concordia wiki shortly.
A number of points stood out to me as I listened to the different presentations.
- Even enterprise deployments have issues with the user experience. Enterprise users want a easy/seamless experience as much as consumers.
- Companies have figured out to get COTS products based on different protocols to work together, albeit in a rather complex deployment architecture.
- Scaleability of federation is a real issue. Scaleability issues exist in deployment configurations, administration as well as technically.
- Solving how to federate between federations is an important task that needs clear best practices.
Overall, it was a very productive workshop. Expect more information to appear on the Concordia wiki shortly.
Tuesday, June 26, 2007
Friday, June 15, 2007
Clients to the rescue
So last week I blogged about issues the SP faces when trying to reach as many consumers as possible. There are things the SP can do to make this easier for consumers… but maybe “clients” are the “real” solution. Praveen Alavilli started a very interesting internal (to AOL) email thread which is in part summarized below.
For the sake of discussion, let’s assume that SPs have a way to markup up their sites with which identity protocols they support/require. Let’s also assume that the client knows which identities the user has authenticated in the current session and which identities were used with which protocol.
Using the use case from the previous post… My mother-in-law opens the browser to find a new coffee-cake recipe. She finds cooking.example.com which accepts OpenIDs. The client (browser/identity agent/etc) recognizes that the site supports OpenID and pops up a message to my mother-in-law saying “You can log into this sight using your AOL account. Would you like to continue?“. If she clicks the “Continue“ button, she starts the process of signing into the site with OpenID. If she is already authenticated, she should just get a consent page. [Note that the Versign Seatbelt and Sxipper plugins provide this kind of behavior for OpenID already.]My problem with the current solutions is that they are all protocol specific. The client code has to look for OpenID named form elements, or Cardspace Object tags in order to determine what the site supports. In addition, SAML has no mechanism (as far as I know) to allow the SP to declare that it supports SAML. Sure the client app could try to query for SAML metadata for every web site but that is a lot of overhead where some simple markup would be so much easier. Consolidating this markup via a mirco-format or some simple <link> mechanism to a XRDS file would make this kind of client support that much easier.
Finally, if the client can detect and manage cross identity protocol interactions, then these additional features would make the user experience that much better.
(1) “Remember Identity” means that the client will remember the mapping between an identity and the site at which it is used.
(2) “Auto-Login” means that the client will initiate a login sequence without user interaction.
For the sake of discussion, let’s assume that SPs have a way to markup up their sites with which identity protocols they support/require. Let’s also assume that the client knows which identities the user has authenticated in the current session and which identities were used with which protocol.
Using the use case from the previous post… My mother-in-law opens the browser to find a new coffee-cake recipe. She finds cooking.example.com which accepts OpenIDs. The client (browser/identity agent/etc) recognizes that the site supports OpenID and pops up a message to my mother-in-law saying “You can log into this sight using your AOL account. Would you like to continue?“. If she clicks the “Continue“ button, she starts the process of signing into the site with OpenID. If she is already authenticated, she should just get a consent page. [Note that the Versign Seatbelt and Sxipper plugins provide this kind of behavior for OpenID already.]My problem with the current solutions is that they are all protocol specific. The client code has to look for OpenID named form elements, or Cardspace Object tags in order to determine what the site supports. In addition, SAML has no mechanism (as far as I know) to allow the SP to declare that it supports SAML. Sure the client app could try to query for SAML metadata for every web site but that is a lot of overhead where some simple markup would be so much easier. Consolidating this markup via a mirco-format or some simple <link> mechanism to a XRDS file would make this kind of client support that much easier.
Finally, if the client can detect and manage cross identity protocol interactions, then these additional features would make the user experience that much better.
Remember Identity (1) | Auto-Login (2) | Behavior |
x | The identity agent would remember the mapping between the identity the user specified and the site. However, the identity agent would not automatically log the user into the site. The identity agent could present pop-up UI to ask the user if they want to log in or just enable a button in the frame of the client that the user can click when they want to log in. | |
x | The identity agent would start a login to the site. The agent could just pop up UI with the current set of authenticated identities that match the supported identity protocols of the site. If there are no authenticated identities that match, it should show any identity it knows about that matches (this of course is more like Cardspace). | |
x | x | This is the SSO option for the client. Now when I browse the web I can be selectively, automatically signed in to the sites I care about. If the previously mapped identity is not already authenticated, the agent would start the authentication process. |
(1) “Remember Identity” means that the client will remember the mapping between an identity and the site at which it is used.
(2) “Auto-Login” means that the client will initiate a login sequence without user interaction.
The simplicity of symmetry
When it comes to architectures I've always liked the simplicity of symmetric solutions. They are much easier to understand and it is easy to spot inconsistencies in process flow. Well... given the following story... it MUST be that symmetry is much easier for children to understand as well.
Principle: Don't underestimate the power of a simple solution:)
The other morning it was raining and my almost 4yr old daughter asked where her Cinderella umbrella was because she couldn't find it. My wife replied that it was in the mud room closet and was likely hanging up in the closet. My daughter went to investigate and came back in a few minutes with the following question. “Mommy can you help me hang it down?”
Principle: Don't underestimate the power of a simple solution:)
Thursday, June 07, 2007
Identity at the SP
When it comes to identity, a Service Provider (SP) or Relying Party (RP) has a couple of key issues. One is customer facing (user experience) and another is technical (supporting multiple identity protocols). Of these two, the user experience is more important as it affects the consumer.
Take the following use case. My mother-in-law goes to a cooking web site to search for a new coffee-cake recipe. The cooking site (SP) allows for personalization and saving of favorite recipes, so she is presented with UI to login so she can save the recipe as a favorite (we'll assume that the “create the account” process has already occurred). The cooking site wants to support the widest range of people possible to access their site so they decide to support Cardspace, OpenID, and SAML at the identity protocol layer. Questions? How does the SP represent the UI so that it's not confusing to my mother-in-law? She doesn't understand anything about Cardspace, OpenID or SAML. She does understand that she has an AOL account.
Does this mean SP/RP's should be putting up icons of well known identity providers? That solution is not equalitarian and it doesn't scale. It's great that we have all these cool technologies that tackle different parts of the identity space, but it doesn't really help consumers if it is too confusing to use. I suspect most users know who they have an account with but not many know what protocol is used by their account. For example, I suspect that most Live Journal and AOL users do not know that they have an OpenID.
As for the technology side, the problem at the SP/RP is not that the issues are unsolvable (or even not currently solved). The problem is that all this code has to be written (or incorporated) and glued together to enable these different identity protocols. That is a rather significant barrier to entry. Currently, this tends to drive SPs to pick one of the existing identity protocols. From a business perspective this limits the total number of people that can use the service.
I tend to agree with Johannes, all this talk and work won't mean much if we don't make things simpler for the consumer first and the SP developer second.
Take the following use case. My mother-in-law goes to a cooking web site to search for a new coffee-cake recipe. The cooking site (SP) allows for personalization and saving of favorite recipes, so she is presented with UI to login so she can save the recipe as a favorite (we'll assume that the “create the account” process has already occurred). The cooking site wants to support the widest range of people possible to access their site so they decide to support Cardspace, OpenID, and SAML at the identity protocol layer. Questions? How does the SP represent the UI so that it's not confusing to my mother-in-law? She doesn't understand anything about Cardspace, OpenID or SAML. She does understand that she has an AOL account.
Does this mean SP/RP's should be putting up icons of well known identity providers? That solution is not equalitarian and it doesn't scale. It's great that we have all these cool technologies that tackle different parts of the identity space, but it doesn't really help consumers if it is too confusing to use. I suspect most users know who they have an account with but not many know what protocol is used by their account. For example, I suspect that most Live Journal and AOL users do not know that they have an OpenID.
As for the technology side, the problem at the SP/RP is not that the issues are unsolvable (or even not currently solved). The problem is that all this code has to be written (or incorporated) and glued together to enable these different identity protocols. That is a rather significant barrier to entry. Currently, this tends to drive SPs to pick one of the existing identity protocols. From a business perspective this limits the total number of people that can use the service.
I tend to agree with Johannes, all this talk and work won't mean much if we don't make things simpler for the consumer first and the SP developer second.
Subscribe to:
Posts (Atom)