Trust relationships in OpenID

A while back I wrote the following to the OpenID general list serv.

As I see it there are 3 parties involved in the transaction: the user, the OP and the RP. There is some trust/risk factor associated with each relationship.

From the user's perspective they "trust" the OP (either because they want to spam and so are using an OP that makes "false assertions", or because they trust the OP to protect their authentication credentials and represent them correctly on the web). The user may or may not trust the RP, but by logging in they are making some level of trust/risk assessment.

From the OP's perspective the user represents some risk/value metric (too many "bad" users and the OP gets blacklisted). The OP protects that risk by potentially verifying email or cell number, supporting PAPE and other strong authentication methods, etc. The OP also has a risk/value metric with the RP though this is probably not super important right now. I can envision a smart OP warning me about authenticating to an RP that it some how determined is not "trustworthy".

From the RP's perspective, they have a risk/value metric on the user (e.g. Is the user going to be a good citizen of my community? Are they going to abuse the resources I provide? How much effort do I want to put into detecting "bad apples"?). The RP also has a risk/value metric on the OP (e.g. When the OP says they support the PAPE extension do they really do it?). Finally the RP has a risk/value metric on the resource/service they provide. From a business perspective I don't believe it's wise to blatantly "trust" the user if the resource/service is highly valuable (e.g. moving funds between accounts). Most users today don't have the sophistication to make good decisions.

Ok, so maybe I was a little unfair in my characterization of “most users”. I was trying to say that I don't believe many users know how to chose a good OP. In fact many will just use an OP they already have (which puts pressure on those OPs to be good citizens; that's a “good thing”). So, if an RP has a high trust metric with the user's OP, then they can more confidently trust the user as well. On the RP side its really an assessment of risk against the “User:OP“ pair.

Tags: OpenID, Trust

"Open" Foundation Overload

With the creation of the OpenSocial Foundation, the DataPortability Group (they'll need a Foundation soon), the Information Card Foundation and of course the now established OpenID Foundation... I'm getting "foundationed" out.

I wonder if the community couldn't do something closer to OASIS and have one over arching Foundation with sub-groups working in each of these important areas. The IPR could be consistent for all the groups, but each group would have it's own "board of directors" and control the results of specifications and other efforts.

All the different focuses are important, and new areas will arise as the identity layer grows across the internet. However, convincing "management" to join multiple different organizations is a deterrent to participation.

Tags: OpenID, OpenSocial, DataPortability, Information Cards, Foundation

Is AOL exploiting OpenID?

Today, Michael Arrington (of Tech Crunch) posted an article posturing that AOL (along with Microsoft, Google and Yahoo) are attempting to exploit OpenID by being OpenID Providers (OP) and not becoming OpenID Relying Parties (RP). I attempt to address a number of issues in this post below.

"By becoming Issuing parties, AOL and Yahoo hope to see their users logging in all over the Internet with those credentials. But they don’t accept IDs from anywhere else, so anyone that uses their services has to create new credentials with them. It’s all gain, no pain."

In addition to not being true (about AOL), the above statement doesn't make sense. There is little value in having to store a user's identity credentials and then verifying against them when it comes to identity management. A company's decisions around when to require a local account and when to accept 3rd party identities revolves around the risk of the resources being offered. If the 3rd party identity provider (in this case an OP) is trustworthy, then it's much preferrable to "outsource" the identity verification to that provider rather than deal with the security and privacy issues of storing credentials. Plus with OPs that support one-time-passwords, hardware tokens, etc, a RP can gain the benefit of strong authentication without having to implement the infrastructure themselves. So, it's not "all gain, no pain". In fact, requiring people to create account is PAINFUL (both for the company and for the user).

"Issuing parties make their user accounts OpenID compatible. Relying parties are websites that allow users to sign into their sites with credentials from Issuing parties. Of course, sites can also be both. In fact, if they aren’t both [OP and RP] it can be confusing and isn’t a good user experience."

Actually, I would disagree with this statement. The point of OpenID is to provide a user with a few identities (maybe one) that they can use at many web sites across the internet. This means that many sites will just be RPs and won't need to support the OP parts of the protocol. I do agree that the next wave of adoption will be more sites (large and small) becoming RPs.

For AOL, being an RP is important because it allows more people to use our services without requiring them to create yet another account with another password to remember. The more people that visit and interact with AOL services, the more successful AOL will be. Both ficlets and Circa Vie are OpenID relying parties and a substantial number of their users are 3rd party OpenIDs.

"It’s time for these companies to do what’s right for the users and fully adopt OpenID as relying parties. That doesn’t fit in with their strategy of owning the identity of as many Internet users as possible, but it certainly fits in with the Internet’s very serious need for an open, distributed and secure single log in system (OpenID is all three)."

I have two things in regards to this quote. First, it is not AOL's strategy to "own the identity of as many Internet users as possible". I've already stated why above. Second, there is another element that is key to the "Internet's very serious need" and that is "trust". Some call it reputation. It's great that OpenID 2.0 is open, distributed and secure (from a data-on-the-wire perspective). However, relying parties need to assess the business risk in regards to the resources (e.g. free storage, free domain names, free email) they are providing. With OpenID 2.0, it's possible to implement an OpenID Provider that claims using strong authentication to verify the user but in reality is not even requiring a password. This means anyone can sign up at any RP without needing an account at the OP. The RP needs to determine if the business risk to this kind of abuse is acceptable.

I believe it is this later case that is causing the larger companies to move more slowly when it comes to enabling all their services to 3rd party OpenIDs. Note that not even at Live Journal can you create an account with a 3rd party OpenID. What you can do at Live Journal is leave comments and be added to friend's lists.

[Disclaimer: For those that don't already know, I work for AOL.]

Tags: OpenID, AOL

Authentication for clients

Today AOL relaunched the OpenAIM initiative. One of the key parts of this effort is supporting authentication for clients (whether those clients are native code or FLASH/AIR/Silverlight/etc). To enable this we added a 'clientLogin' API to our OpenAuth suite of APIs.

This support is to enable a user experience that comfortable to AOL's existing members. If a user installs a client application, it is expected that any authentication that is needed is done through the client. To secure this method we use the password and a session key (transfered via SSL) to sign all requests from the client application. This ensures that all valid requests are coming from a client where the user entered their password. In addition, all API calls are monitored for abuse.

For the signing mechanism we used the OAuth signature base string method. However, given that we already had parameter names (in existing APIs) that map to the OAuth parameter names, we used the existing parameter names in favor of the OAuth names. Otherwise, the logic is the same.

I realize that from a pure privacy and security perspective, the OAuth flow of "popping" a browser and having the user only enter their credentials at the "owning" IdP is better. However, for many of our customers this is an unexpected user experience. clientLogin enables the desired user experience.

Tags: OpenAIM, Authentication, OAuth

How times change

A couple nights ago my teenage son was on the family computer “working” on facebook.

So I asked him “How are your friends doing?” (trying to be a good parent and get my kids to talk:) ).

My son answers “I'm trying to help Judson and Samuel be friends” (names changed to protect the innocent).

I ask, “Why, are they not getting along? Did something happen?” (rather surprised).

“No”, he answers, “they can't find each other on facebook.”

I should have known.

Valentine's one day early

I'm not sure what it is about Valentine's Day and Virginia but this is the second year in a row.

More on Email to URL discovery

Just a couple more thoughts on this topic.

1. I believe that the mapping from email domain to XRDS URL should include some addition pattern to make deployments easier. Deploying a servlet or other mechanism on the root email domain is not always easy. Having a different pattern such as xrds.my-email-service.domain would simplify deployment issues.
2. While it is nice that an email to URL mapping service can provide user-centric identifier management, I don't know how much it will be used by the general public. Discovering that the email provider is also an OpenID 2.0 provider would be enough to start a directed identity flow. This I believe would be more convenient for most users.

Email to URL discovery

In the ongoing "world" of IdP discovery a new proposal has been made by Brad Fitzpatrick on his blog. This proposal provides for a direct mapping between an email address and a personal URL (e.g. an OpenID). The mapping between the email address and personal URL is provided by an email2url_mapping service run by the email provider. Discovery of the email2url_mapping service endpoint is found via XRI URL resolution on the domain of the email address.

Whether the user needs the full indirection capability to have an arbitrary mapping between email address and URL or is fine with allowing the email provider to be their OP/IdP is yet to be seen. It is encouraging to see consumer's UX needs being addressed.

Looking at the evidence...

... it seems that we still have a ways to go when it comes to user education, user-centric identity and IdP discovery. I applaud Yahoo! and Blogger for supporting OpenID by being OpenID Providers. That is a huge step forward. However, it's interesting to note how these main stream relying party (RP) sites are implementing the user experience.

From the OpenID listserv it appears that Yahoo! would prefer RPs to put a Yahoo! logo on their site that is clickable to enable Yahoo! users (and others) to login to that site (using the "directed identity" flow).

Also, looking at the Blogger implementation of accepting OpenIDs they list 4 main OpenID providers (I'm guessing Yahoo! will be added to the list) and then a button for "Any OpenID".

Maybe lesser known, but propeller.com (an AOL property) which accepts OpenIDs uses the OpenID protocol to authenticate AOL/AIM users but presents the UI as "Sign in using my AOL Screen Name".

What I find fascinating about this trend is that it bypasses one of the benefits of an OpenID (built in IdP discovery). Basically, these main stream RP sites are using the "User picks their IdP" solution for determining where to send the user rather than having the user type in their IdP (yahoo.com, openid.aol.com, etc) or full OpenID URL. At the moment, this scales OK as there aren't that many mainstream providers, but either user education needs to get better so this mechanism isn't needed, or we need a different technical solution.

WebGuild Web 2.0 Conference

I'm participating in a panel at WebGuild's Web 2.0 Conference and Expo being moderated by Johannes. The panel will be discussing OpenID and OAuth among other things. It should be a good discussion given the recent announcements by Yahoo! and Google.

Discovery, wherefore art thou Discovery?

The web seems "a buzz" these days with different flavors of "discovery". I've recently been hearing more and more need for Personal Service Discovery. This is coming from both internal and external customers. Two key questions are asked. (1) What is the user's preferred service? (e.g. picture service) and (2) Where is this user's specific service located. The two questions are not mutually exclusive. What I find quite humorous is that the Liberty Alliance has had a "Discovery Service" for quite some time that is capable of answering both those questions (and others). I wish I had Paul's witty way of poking fun... but alas I'm not that talented.

Here are a few recent proposals for "Discovery" services. I'm sure there are many I'm missing...

• XRI Resolution -- a mechanism for describing and querying personal service endpoints (among other things)
• XRD Provisioning Protocol (XPP) -- an XRI based mechanism for Service Providers to attach their service to a user's individual XRDS file hosted by the user's IdP
• "DHCP for Identity" -- "As users, our identity, photos, videos and other forms of personal data should be discoverable by, and shared between our chosen tools or vendors."
• Dynamic Federation -- service provider metadata is discovered via transformation of a user identifier
• OAuth Discovery 1.0 Draft 1 -- This is really "service provider metadata" that is "discoverable".

Interesting to me is the leveraging of XRDS as a containing structure for describing service metadata amongst a number of these proposals. Anyway my hope is that as an industry we leverage all the work that has already been done while looking for ways to make things easier for users and developers.

"Standing on the shoulders of giants" comes to mind.

Tags: Discovery, Liberty Alliance, XRI, XRDS, OAuth

Soapbox: "Likely to offend some" ???

I smiled at Paul's recent post of Xmas Cards. I find it humorous that in our society we quibble over such silly things. However as I thought more about it, what really struck me was the double standard that exists but we ignore all the time.

What is it about “Merry Christmas” that might offend someone?

Is it that Christmas is equated to a Christian holiday and somehow recognizing that such a holiday exists is offensive?

• This doesn't make sense to me because I would guess that the majority of people who celebrate “Christmas” do not hold to the “truths of the Christian faith”. Christmas for them is a merry time of year to give to others and receive gifts from others. It's a time to enjoy family and friends. What is so offensive about that? Would people be offended if the greeting were Happy Hanukkah?

Is it that the word “Christ” appears in Christmas and hence that is offensive to some?

• This really doesn't make sense as the same people who are offended by the term “Merry Christmas” probably use “Christ”, “Jesus”, “God”, etc on a daily basis as an expression or expletive. So if it's OK to use these terms in a way that doesn't relate to the object of the term, why would the rule change for “Merry Christmas”?

The double standard is that it's OK to offend people who believe in God and Jesus Christ, but it's not OK for those people to use the same terms in an honoring way because they might be offensive to those who don't hold the same beliefs.

So I'm not quite sure whether I should smile or be “offended” that “Merry Christmas” is “Likely to offend some” :)

From the "Feeling rather behind..." department

A few weeks ago Johannes Ernst's posted a blog entry, in which he describes a number of tiers regarding different classes of identity relationships between a business and it's partners/customers. I like the taxonomy and agree that its a good framework for communicating both identity issues and technology relevance.

I just wanted to add that Ping! Identity's proposed “dynamic federation” would perfectly suit Tier 2. It provides good secure SAML based federation while being easy to deploy. Of course, some of those 100's of affiliates might not support SAML as their identity solution so other easy to deploy mechanisms will need to exist as well.

This multiple protocol, deployment environment is the main goal of the Concordia project. The definition of these environments as use cases and then the proposed solutions will significantly help businesses integrate their affiliates in a quick and seamless manner.

Finally, I would expect that a business would want to use a single standard technology for Tier 0 and 1 as “federating” internally is a real pain.

Tags: Identity, Dynamic, Federation

OAuth framework code checked in

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.

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:)

Tags: Idenity, Web Service, Framework, Mac OS X

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

Tags: Photo, Thanksgiving

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).

Tags: IdP Discovery, Concordia

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.

Tags: IdP Discovery, XRDS, OpenID SAML

"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.

Tags: Liberty Alliance, TEG, Soccer

Blessings of an early flight home