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

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

Tags: SAML, OpenID, AIM, Trust, Social Networks Protocols

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

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.

Tags: OpenID, AOL, Whitelist

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

1. User browses to the relying party (RP) and is prompted by Cardspace to authenticate
2. User selects one of their cards (that they've previously used with the RP) and is logged in to the site
3. 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)
4. 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
5. AIM validates the credentials and returns a service API token
6. The RP uses the service API token to request the buddy list
7. 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...

1. User browses to relying party A (RPA) and enters their OpenID to login
2. Relying party A invokes the OpenID authentication flow redirecting the user to their OpenID Provider (OP)
3. The user authenticates to the OP and is redirected back to RPA
4. RPA requests a service token from relying party B (RPB) using a browser re-direct
5. RPB requests an authentication of the user via their OP
6. Since the user is already logged into the OP, this authentication step could be “seamless” to the user
7. RPB creates a service invocation token for RPA and redirects the browser back to RPA
8. 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.

Tags: Concordia, Cardspace, Identity Meta-System, OpenID, Service Invocation

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.

Moses speaking in Deuteronomy 9:9-10...

“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.”

Yahweh communicated directly with the people of Israel and Yahweh still desires to communicate with each of us as well.

I do, however, agree with Paul on one thing. Too often we are “screening” out God.

Yahweh22: YT?
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.

How can we possibly have a relationship with Yahweh (the creator of the universe; Genesis 1) if we don't listen?

Tags: Theology, Relationship

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.

Independence Day on the Potomac...

"Better late than never"
(between Family and Work these had to wait till today)

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.

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

Tags: Identity Meta-System, Cardspace, OpenID, SAML, User Experience

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.

1. Even enterprise deployments have issues with the user experience. Enterprise users want a easy/seamless experience as much as consumers.
2. Companies have figured out to get COTS products based on different protocols to work together, albeit in a rather complex deployment architecture.
3. Scaleability of federation is a real issue. Scaleability issues exist in deployment configurations, administration as well as technically.
4. 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.

Tags: Concordia, BurtonCatalyst2007, User Experience, Federation

Sometimes you just have to go fish

Shenandoah River, Virginia

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.

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.

Tags: Identity, OpenID, Cardspace, SAML

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.

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

Tags: Architecture, Symmetry

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.

Tags: Identity, SAML, OpenID, Cardspace, Service Provider

AOL supports simple federation with SAMLv2

In addition to the work AOL is doing to support OpenID, we've also been working with SAMLv2 to provide a simple federation profile for our partners. This allows users to federate an account at a partner to an account at AOL so that SSO is enabled from the partner to AOL or vise-versa.

This implementation uses the “SAMLv2 Lightweight Web Browser SSO Profile” and “SAMLv2.0 HTTP POST SimpleSign Binding”. Since the current use cases are fairly restricted we simplified the process even more such that only source-first SSO, using an unsolicited <Response> message is supported.

The actual federation of identifiers is done during the registration process using existing AOL protocols. SAML is then used for the SSO Assertion between the partners. The flow goes something like this...

1. User goes to browser and loads site A
2. User authenticates at site A using the account credentials associated with site A
3. User clicks on link to partner site B
4. Site A generates the SSO Assertion for site B using site B's pre-determined federation identifier
5. Site A uses the http POST method to post the SSO Assertion to site B
6. Site B validates and verifies the SSO Assertion
7. User is “signed-on” to site B with site B's federated identifier

Using the Simple-Sign binding significantly simplified the development effort as XMLDSIG is one of the more complicated parts of SAML. As more tools for XMLDSIG become available this will be less and less of a barrier to adoption.

Tags: SAML, AOL, SSO

Wednesday @ IIW 2007

Thankfully Wed. was not quite so intense, at least for me. The main items of interest for me were a review of Pythia (a reputation system that Phil Windley has been working on), the results of the OSIS interop event, and a discussion about user experience and identity.

Pythia
Phil Windley lead a session on the reputation system (pythia) he's been working on with his graduate students over the last year and a half. The system is based on evaluating transactions between identities. Reputation scores are calculated on a “personal” basis meaning that I can define my own ruleset for calculating reputation that might be different than someone else's ruleset. This, I think, is important because it allows me to value the information I receive about another identity according to my own view of what's important. For example, just because an identity has a great reputation within the drug culture doesn't mean that I want to ascribe a high reputation to them. Reputations are very contextual and I ascribe different levels of value to the different contexts.

In a very concrete example, there was a fair amount of discussion by relying party implementors (both during and after the session) about how to get transaction data (i.e. initial reputation) when a new identifier shows up at their site. The basic question being, is there a way for a relying party to know whether they can “trust” the 3rd party OpenID to be a genuine user. If there was a way to convey transaction data such identifier creation date, date of last use, number of “publish” transactions (meaning blog posts, comments, etc) then RPs could make a much better decision on whether to just let the identifier use their site, or whether they need to do some additional “verification” of the user. In this specific case there is immediate value in identity providers providing some additional attributes about the identifier that relying parties can use to make business decisions. For OpenID this probably means adoption of the Attribute Exchange extension or some additions to SREG.

OSIS interop event
I didn't participate in the OSIS event but was interested in the issues that arose from the event. Being an “outsider” it seems that while a number of issues were found, over all the event was a success. I think a next step is to get more RP's and IdP's involved especially where RP's are bridging identity meta-systems. Things like namespace mismatches, claim mismatches, and certificates are small hurdles that can easily be fixed.

User Experience
This was a very interesting discussion as it did not focus on computer user experience and UI for interacting online. Instead it was much more about how people use identity in the offline world and how does that map into the online world. One of the interesting points to me is that in the offline world, there is a lot of context available as part of the interaction. These could be visual clues (body language, facial expressions, etc), auditory clues (tone of voice, distance from sound, etc), olfactory clues (smell, etc) and the list goes on. In online social interactions much of this additional context is lost and hence a “distance” in the communication is created. This “distance”, or incompleteness in the context, causes some to feel safe to say anything and others to hold back and mask themselves. As more transactions and social interactions move online, it will be increasingly important for consumers to understand these dynamics. A more complete summary will likely be appearing on Heather's blog.

Tags: iiw2007, Reputation, OSIS, Offline Identity

Tuesday @ IIW 2007

Tuesday was a very full day at IIW. The sessions I attended are listed below with a brief summary.

AOL OpenAuth -- Overview
Srinivas Lingutla from AOL gave an overview of the AOL OpenAuth API's and discussed the differences between the OpenAuth capabilities and existing OpenID authentication. The key additions of OpenAuth are the ability to retrieve a “security token” that represents the authentication and can be used in a back-channel way with other AOL services (e.g. instant messaging), and the consent model that is structured around the use of the “security token”.

HTTP binding for identity web services
This discussion was intended to gage interest in a standard framework for invoking identity based web services using HTTP as the core binding. The focus being support of browser based applications that make use of AJAX and XSS. The session was not well attended so the group present ended up covering many different issues relating to HTTP based invocation of services. John Panzer from AOL discussed some work he's done extending the HTTP support for authentication and authorization to support authentication use of ATOM/APP interfaces. There was some consensus that for REST based API's extending the existing HTTP mechanisms is the best solution. For AJAX based applications, this method does not work well so another method is required. I discussed the simple framework that AOL has defined for its Open Services APIs (e.g. Web Instant Messaging). We also discussed a couple of different invocation models that can be used (front-channel based vs back-channel based) with HTTP.

Rich Client Authentication
In this group we discussed the issues around allowing device specific applications (i.e. not a browser) to authenticate the user and then invoke identity based web services on the user's behalf. From the client developer perspective, the general consensus was that they didn't want to deal with implementing this and would rather the environment provide a consistent API that could authenticate the user and return the appropriate token. Of course this sort of just pushes the problem to a different layer. One idea was to look at OSIS and Cardspace as possible client side systems that could be used to do the authentication though this requires the user to adopt a new model of authentication. It is not clear to me how long that sort of user “training” is going to take.

Another aspect of client authentication is the desire to provision the authentication credentials in such a way that they are specific to the device. This way if they are compromised, they are not valid outside the context of the device. One solution here would be to use PKI provisioned through some “installation/setup” step. What that would be was not discussed, though one could use the Liberty Alliance Advanced Client specifications if willing to implement SOAP web services.

OpenID Token Exchange extension
Srinivas Lingutla also did a session on a proposed extension to OpenID that will allow relying parties (RP) to request an authentication token from the OpenID Provider (OP) at the time of authentication. The token can then be used to access identity based web services. AOL has implemented this proposed extension and demoed it during the “speed geeking” session on Monday by using an AOL OpenID to launch a buddylist using the AOL Web IM APIs. There were a number of questions around how to support different token types (simple support already present in the proposed extension), and whether some level of application id (or provider id) is required. The next steps include evaluating the other related proposed extensions and seeing if these can be combined into a single extension to support token request and validation. The proposed extension should be posted to the OpenID list/wiki in the next week or so.

What's broken with OpenID 2.0
Dick Hardt led a session on what is broken with the existing OpenID 2.0 spec. I'm sure the details will be appearing on his blog in the near future. The session of course grew beyond just what is broken to business issues and next generation feature requests. It was a very lively discussion. The “really broken” things were tackled during sessions on Wed. At the closing session on Wed. Dick promised that the 2.0 specification would be ready “real soon now”.

Tags: iiw2007, OpenAuth, OpenID

Identity issues at IIW 2007

Something “new” happened at IIW 2007 yesterday. Instead of the normal “state-of-identity” talks and “introduction to the issues”, Monday afternoon focused around “speed geeking” and collective identity issues. We divided into groups and each group came up with a set of issues that they felt were important. Kaliya collected all the different issues/questions into a mind map (picture of it came be found here). Other summaries can be found here and here.

Of noticeable interest to me was the commonality of a lot of the questions/issues.

• privacy
• trust
• reputation
• delegation
• user experience
• interoperability between identity systems
• identity relationships (parental controls was brought up and not by me:) )
• and the list goes on

These issues are at a different level that just figuring out how the technology will work to do SSO or authentication. It should be a good conference.

Tags: iiw2007

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

1. User uses Cardspace to authenticate to a picture services that uses ID-WSF with it's billing partner(s)
2. User authenticates with her college library using SAML and then wants to SSO into zooomr.com
3. 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

Identity Meta-System SSO

In his entry “OpenID bootstrap to ID-WSF”, Paul describes the results of a very interesting IOS session in Brussels. As he outlines, the bootstrapping possibilities are pretty straight forward. An interesting point of the second option is that the RP would need to know how to obtain the appropriate security token in order to invoke the Discovery Service (DS) as defined in the publicly available DS-EPR. In the OpenID case, the OpenID “assertion” would need to be exchanged for the appropriate token used to invoke the Liberty DS service (in most cases a SAMLv2 assertion).

It's this token exchange mechanism that I find intriguing. Does it work both ways? Can I exchange a SAMLv2 Assertion for an OpenID “assertion”? This seems doable if the user is using a single IdP that “speaks” all the identity protocols. With this kind of a deployment model, the IdP can use browser cookies and other mechanisms to maintain the authentication session of the user. An example flow could be...

1. User visits RP-A which only supports SAMLv2
2. User's browser has a stored cookie identifying the SAML IdP to use (existing SAML IdP discovery mechanism)
3. RP-A re-directs the user's browser to the IdP to authenticate via the AuthnRequest
4. User authentications and the IdP sets authentication state cookies in the user's browser
5. The IdP re-directs the user's browser back to RP-A passing the AuthnResponse
6. User is not authenticated at RP-A
7. User now loads RP-B which only supports OpenID
8. User's browser has a stored cookie identifying the last OpenID used with RP-B
9. RP-B invokes a check_immediate with the OP resolved via OpenID discovery (in this case the same IdP)
10. The check_immediate re-directs the user's browser such that the IdP can validate the user's authenticated session
11. The IdP now verifies that there is a previously established federation between the OpenID and SAML identifier
12. If the federation exists, then the IdP can return the OpenID authenticated response

This would allow seamless SSO between different front-channel identity systems, though it is dependent on “identifier federation” at the IdP. However, if the IdP's are not the same, it should still be possible, but more complicated, as the user's identity would need to be federated across the involved IdP's.

Tags: Identity, OpenID, SAML, SSO, metasystem

A knife... a real knife... magnetized!

To anyone familiar with the Tray Table blog, it is certainly no surprise that a certain unnamed individual was once again traveling in 1st class. However, just a metal knife in business class? Boring... Mine were magnetized!


Not sure what caused the magnetism. Feel free to post theories in the comments.

AOL releases OpenAuth

As has been blogged by Praveen Alavilli and John Panzer, today AOL released a set of http-rpc based API's for authenticating AOL identities and leveraging that authentication to access AOL services. These API's fill a niche in the existing http based web protocols by supporting the concept of authenticated service access and user consent. As many web based applications move to an AJAX model, being able to expose identity based services in a user-centric way becomes very important. Hence the importance on user consent for access to a user's data by a 3rd party application.

There are a lot of similarities in the identity processing model between the AOL OpenAuth API's and the Liberty Alliance ID-WSF SOAP based framework (authentication tokens and multi-party transactions to name a few). The similarities are intentional. The goal has been to leverage the work done by the Liberty Alliance and other internet standards organizations, and apply it to the http-rpc space for which till now there hasn't been a “good” solution. While these API's only support AOL services, the model is extensible to other protocols (as Praveen mentions in regards to an extension to OpenID).

The basics for web developers are...

• Provisioning

1. Get a provider id (called a developer key)


• At runtime

2. Request an authentication token

• requires both authentication and consent from the user before returning the authentication token

3. Invoke AOL identity based service

• requires user consent (can be remembered) before returning requested data

Much more detailed documentation is available at http://dev.aol.com/openauth.

Full disclosure: I work for AOL but not directly as part of the Authentication team.

Tags: Identity, AOL, OpenAuth, OpenID, Liberty Alliance, ID-WSF

Spring Blossoms

When it is a Phish

So after my experience with getting a valid notification from eBay (thanks again eBay), I received the following email supposedly from PayPal.


This one was immediately suspicious. For one, the href for the URL was a dotted quad (85.234.150.131). Two, the “whois” entry wasn't in anyway associated with PayPal.

OrgName: RIPE Network Coordination Centre
OrgID: RIPE
Address: P.O. Box 10096
City: Amsterdam
StateProv:
PostalCode: 1001EB
Country: NL

ReferralServer: whois://whois.ripe.net:43

...

% Information related to '85.234.128.0/19AS29550'

route: 85.234.128.0/19
descr: PH-Network Europe, operated by Euroconnex Networks LLP
origin: AS29550
remarks: *********************************************
remarks: For Peering and more info: www.euroconnex.net
remarks: *********************************************
mnt-by: POUNDHOST
source: RIPE # Filtered

And three, the email was not sent to the email address associated with my PayPal account.

The rest of the email looked pretty legit however, and after my experience of the previous week... I had to look closely to file this in the “scam” folder. I have to wonder if this email is in any way related to the credit card fraud of the previous week.

Tags: Phishing, eBay, PayPal

Happy Easter!

"He is risen!" ... "He is risen indeed!" <><

When it's not a Phish

On March 29 I received the following email from eBay (I left out the “boiler plate” text regarding how to protect yourself from fraud).


My first thought was another clever phishing scheme as I don't have a credit card on file with eBay other than my PayPal account. So I looked through the email for links or other telltale signs that would indicate a phish. I couldn't find anything so I went to eBay and logged in (not via the email of course). There were the same two emails in my eBay “inbox”. I checked my account at eBay and everything looked fine. I then checked my associated PayPal account and there were no purchases via that account. Next step was to check my credit card balance.

Hmm... there on my activity statement was a charge from snapfish.com. The immediate red lights started whirring as I don't have a snapfish account. So off to the hassle of calling the credit card company, snapfish.com etc. The result of these calls was to watch my credit card account (the first fraudulent charge was $1.33). The following day there were two more fraudulent charges from snapfish.com ($2.90 and $41.65 respectively). Now back to the phone to remove these charges from my bill, cancel the credit card and get a new card issued with a new number. The biggest hassle being finding all the companies that have re-occuring charges against that card. Yet another thing to keep track of in the event this happens again.

A BIG thank you to eBay for sending this email and helping me catch the fraud right from the start. Needless to say this experience has not been pleasant, including monitoring of online credit card statements while on vacation this week. This is my first experience with this sort of fraud and I don't hope to repeat the process anytime soon:)

Tags: Fraud, Credit Card, Phishing

Identity Relationships: User vs Service Provider

There has been a significant amount of discussion and work (People Service, XFN, and FOAF to name a few) around the concept of managing personal or social relationships. These relationships are managed from a user-centric perspective and are really a one-to-many relationship between the user and the identities being managed. This allows the identity of the user to be implied in regards to the other identities and groups (e.g. it is my buddy list). The group structure provides a form of role classification that can then be leveraged for permissions and access control among other things.

However, managing relationships between identities at the service level is a little different. For a service provider the relationship is not one-to-many but rather many-to-many. For example, a hospital will want to manage which patients are assigned to which doctors. A doctor can have many patients and a patient might have many doctors. The existing social relationship mechanisms don't really fit this model as these relationships are defined from a service provider centric perspective. The hospital manages the relationships not the user; though the user is free to leave one doctor and move to another.

Where social relationships tend to be defined in a uni-directional manner (from the user to the other identity), service based relationships are often bi-directional. I don't see this as a problem as it is rather easy to model and implement. However, it is important to distinguish between these two kinds of relationships.

Tags: Identity Relationship, People Service, Social Networks

How DST cost me $5

So in the US we started daylight savings time (DST) three weeks early. I'm sure most of you received the wonderful emails from the IT department that outlook entries would be tenuous for the weeks between March 11 and April 1. I figured I'd just have a few meetings that were messed up and nothing major.

However, after returning from a Liberty Alliance TEG meeting in Ipswich, UK, I got a rude awakening. I did the normal airport procedures and paid my parking fee in the terminal using the "pay-and-go" ticket I had received when entering the parking lot 7 days earlier. The parking receipt is below. Notice that the payment time is 16:25pm.


I then walked to Daily Garage 1 (about 5-8 minutes), put my stuff in my car and proceeded to the parking lot exit. Normally, you just put in your ticket and it raises the gate and off you go. Not so this time. I received a screen on the monitor stating that the "grace period" (the time between paying in the terminal and exiting the parking lot; around 45 minutes) had expired and I needed to pay and additional $5 or press the button to speak with someone over the intercom. Without thinking, I just put in my credit card and paid the $5. The receipt for that is below.


Then as I was driving home (in the surprise snow/sleet/ice/rain) I realized that there was no way my approximately 10 minutes between paying in the terminal and exiting the parking lot could have been more than the grace period allowed. The time in the machines must be off. This turns out to be the case. The time on the second receipt is 17:35pm which should be 16:35pm. I'm guessing the machines in the parking lot initially didn't adjust so they were adjusted manually. Then a "software update" came through and adjusted the times again.

Unfortunately, I have no excuse as to why I didn't think this through before paying :(

Provisioning Mobile Applications with SAML

So earlier this month I described a method that would simplify provisioning a user's identity credentials to a mobile application. This method will work but requires the application provider (e.g. an Instant Messaging service) to be able to send a binary SMS message to the phone to configure the application with the necessary credentials.

A less invasive method would be for the mobile operator and the application provider to federate their identities such that when the user activated an application on the phone, the mobile operator could authenticate the user to the application provider via a SAML assertion. This is not complicated and already supported via the existing SAML protocols. A possible flow could be...

1. User goes to application provider (Instant Messaging service) web page
2. Web page asks the user if they want to activate their IM account on their phone
3. User selects the link to start the process
4. The web page asks the user to authenticate their Instant Messaging account (if not already authenticated)
5. After authentication, the web site asks the user for their mobile operator and phone number
6. One the information is received the web site sends a SMS message to the phone
7. The user enters the SMS confirmation code to the web site
8. The web site sends a SAML federation message to the mobile operator providing a pseudonymous identifier and phone number for the user
9. The mobile operator receives the SAML message and maps the phone number to the user's account and stores the pseudonymous identifier for the IM service

Now when the user activates the IM application on the phone, the phone communicates it's identity to the mobile operator. The mobile operator sends a SAML assertion (containing the pseudonymous identifier) to the IM application to authenticate the user. The user is now authenticated and the IM application can send back any connection information required to complete the IM session.

This model keeps the interactions between the mobile operator host services and external application providers. It also makes it much easier for users to configure their applications because they don't have to enter their credentials into the phone itself. A win-win.

Tags: Identity, Mobile, SAML

Update: In my rush to post this entry I was remiss in pointing out that this solution was discussed over lunch at a Liberty Alliance interim TEG meeting. The other principals in the discussion were Fulup Ar Foll and Alvaro Armenteros.

When phishers get lazy

So I received this email at one of my email accounts this week. It's not nearly so clever as the one pointed out by Conor here. What I found interesting is that I don't use that email account with eBay and I've never sold anything on eBay. So naturally I was suspicious. I suppose it's just easier for the phishers to swamp the "market" rather than do their homework.

Hmm... I wonder if all those PowerSeller ratings are real?



Tags: Phishing, eBay

Do we really want SSO?

With the recent flurry of announcements around OpenID the same SSO issues are once again being raised. Kevin Farham documents some of these in his piece on OpenID. Kevin's friend's issues are not around OpenID but rather the whole concept of Single-Sign-On (SSO).

This begs the question, "Do users really want SSO?" Unfortunately, the perception might be scarier than the reality.

"You mean, if someone knows my password they can access all my web sites?"

Well... yes and no (depending on the implementation). However, the reality is that many users have the same password at all/most their sites and so the "hacker" can already get access to all their sites without SSO.

With a good Identity Provider (IdP) and strong authentication, the user should be more secure even though a single authentication event allows access to many sites. In fact, for many users, they expect this within a "proprietary" or "closed" environment ( AOL, Google, Yahoo, MSN, etc). It's extending this SSO concept beyond the "proprietary" environment that "scares" them.

Of course part of the issue is that this kind of "cross-domain" SSO doesn't really exist in the general consumer space. The unknown always breads fear; it's human nature. To overcome this "fear", we need SSO to be common place (known not unknown), and show how SSO is "just-as-secure" as the "money under the mattress" solution.

Tags: SSO, Identity, OpenID

Simplifying Parental Controls

In his blog entry "Social Engineering" Paul Madsen describes the classic "parental control" problem where the children understand the technology better than the parents:) However, this doesn't have to be the case. I can think of a number of simple solutions.

In my household, all members have their own OS user account (yes, including my 3 1/2 yr old daughter who dutifully types in her password to sign on). This works out great for them and simplifies my life as I don't have to deal with changed desktops pictures, dock apps appearing/disappearing (yes it's a Mac), etc. I highly recommend setting up OS user accounts for individuals (there can be a family one as well if necessary). On the parental control front at the very least it allows you to turn off Administrator rights for certain accounts.

Getting back to a solution.... Once signed in to my OS user account, I could click a widget/gadget/desktop-thingy to generate an assertion to my PS2 or other device authorizing the suspension of parental controls. I suppose that the PS2 could support something like Cardspace, but that seems a little overkill. Remembering the OS account password is not too difficult and should provide the necessary level of assurance as to the subject of the assertion.

Then again, a simple USB fob with appropriate credentials would work as well. Now where did I put that "key" for the TiVo.

Tags: Identity, Parental Controls

Provisioning identity to mobile applications

Not to long ago I decided to try and set up the instant messaging client on my cell phone. I dutifully went through the painful process of entering my authentication credentials (loginid and password). However, when I got to my password, I couldn't find one of the characters in my password using the phone character entry system. This was rather frustrating and I gave up using the instant messaging client for a while. Later I tried a different account where I knew I could find the characters for the password and the mobile application worked.

This got me thinking that there has to be a better way to provision the identity to the phone for use with mobile applications. One possible process flow would be...

1. User authenticates to web site of mobile application provider
2. User enters their phone #, and carrier to the web site
3. The web site sends a code to the phone
4. User receives the code and enters it into the web site
5. The web site generates a unique set of authentication credentials for the phone
6. The web site sends a binary SMS message to the phone with the mobile application identity configuration
7. User starts up mobile application and is automatically authenticated

This should all be doable with today's technology. Of course, the next step would be secure provisioning of multiple identities for the device, where the identities are consumable by multiple applications. For this, the Advanced Client work underway in the Liberty Alliance should help.

Tags: Identity, Mobile, Instant Message, Liberty Alliance

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

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.

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