OIX Attribute Exchange Summit - Washington DC

Open Identity Exchange (OIX) is holding this year's Attribute Exchange Summit in Washington, DC.

Identity attributes are core of the concept of digital identity. As federated identity ecosystem getting more mature and adoption grows among more sophisticated RPs  - with more consequential use cases such as government, health, education, commerce ... - so does the need for wider sets of attributes with more accurate and fresh values. This presents both tough challenges and opportunities for IDPs.

The challenges center, as one may expect:, around aggregating, correlating, transform and maintaining fresh copy of attributes in a cost effective manner and in a way that it does not compromise the privacy (and other rights) of the principle owner. IDPs can differentiate based on the range of attributes they provide in this way and there in lies the opportunities.

I will be talking more about identity attributes, their life cycle, uses cases and how they help establish and elevate trust among parties to commercial transactions (online and off-line) as part of a panel with Don Thibeau, OIX/OIDF chairman and Abbie Barbir, VP BoA.

If you are planning to attend, I'd be happy to hear from you.

OAuth vs. OpenID Connect ?

OpenID Connet 1.0 Spec is finally released (actually it was release back in Aug). Its release was accompanied by two predictable categories of questions/sentiments, one not very well informed and the other one a legitimate question:

-        OpenID is dead

-        OpenID Connect is really OAuth so why do we need a new protocol?

Granted, this is normally coming from software engineers and social application programmer community and not from identity community, but I feel they are significant enough to be addressed, especially at the time that more and more entities contemplating to become identity providers and they need to decide which protocol they should implement.

First, on the demise of “OpenId”:  It is true that the earlier versions of Open ID (version 1 and version 2) are, for all intent and purposes, depreciated and will not gain a whole lot of traction. But the general idea of “Open” standards for communicating between RPs and IDPs that enables users to provision fewer accounts and have a portable identity while still maintaining control over their privacy and data is alive and well and actually is even more vital than before.

Second, on relationship between OAuth and OpenID Connect, OAuth is a general protocol for authorizing an agent to access a resource on behalf of resource’s owner. OAuth does not assume any particular knowledge about the resource itself. What does this mean? Let’s go back to the canonical OAuth use case of a user who would like to authorize a printing services to access her photos from a Photo service provider. Now imagine that the photo service is slightly sophisticated and recognizes a few properties associated with photos e.g. resolution, size, whether they are shots with no humans, and if there shots with humans, who appears in the photos – basically let’s assume the resource served by SP has more semantics that simple “access”.

Now imagine that the user wants to grant access to only JPEG photos of himself and not a full access to all photos. How would the IDP encode this semantics in the authorization request and response? How would the SP know that they should only provide access to a subset of images?

To be sure, this is doable using OAuth, but the implementer has to add additional parameters to request and response or possibly constraint the input values of some other parameters.

A protocol that is built this way to access a specialized resource, would be a photo access protocol built on top of OAuth.

In essence this is exactly what OpenID Connect it: It is a protocol built on top of OAuth that supports features that are often desired and used when the resources being delegated is “identity” and attribute about an identity.

To illustrate the point, here are what we, at eBay, had to do for an internal authentication protocol on top of OAuth:

-  

      Force Authentication: adding parameters to authorization request to force users to authenticate no matter what the authentication state with IDP is

-        Authorization Behavior: adding parameters to authorization request to indicate to IDPs whether it should display the consent page and how to display the login page (overlay, full page)  

-        Standard Claim Set: Defining the default set of attributes returned by IDP

-        Requested Attributes: adding mechanism to allow RPs to ask for additional attributes, and annotating them to indicate whether explicit user consent is required.

-        Authentication Context: adding a fragment to response to communicated authentication context (single v.s multi-factor, PIN vs. Password, number of retires etc.)

-        Protection: adding parameters to indicate how access tokens should be protected (encryption, signature and order of operations)

-        Token Validation end point: adding an endpoint to introspect access tokens on demand.

These are all features and facets that OpenID Connect enables in a standard and interoperable fashion. In absence of a standard such as OpenID Connect though, any RPs integrating with our IDP had to implement basically a proprietary protocol, be it on top of OAuth.

The point is that if you want to operate an IDP and you want to use just OAuth, you have to add a few things to OAuth, depend on the depth of your requirements, to make it work for “Identity” resource. This is exactly what Facebook did with FB Connect – and they also did a good job of wrapping it with JavaScript plug-ins. The goal of OpenID Connect is to use OAuth as the basic access authorization protocol and add identity specific features to it so that it becomes a standard “identity protocol” that can enable seamless interoperability. 

PayPal Access & Commercial Identity

Today eBay Inc. announced an identity and attribute provider product called PayPal Access. Some described as a "Facebook Connect for Commerce", others described it as an easy registration tool for mobile site. Today at the X,Commerce Innovate Conference someone suggested to me that this is the first step for eBay Inc. to offer full cloud based user management for e-commerce sites and merchants. You can also see the official press release from eBay Inc. here.

Most of the press and coverage today focused on "Consumer Identity" - or more accurately Consumer Commercial Identity - and the benefit of PayPal Access for consumers and online merchants visited by those consumer. Consumer identity is indeed one facet of "Commercial identity" - but there is another side to commercial identity, a less understood - and arguably less sexy - side and that is Merchant Identity. What do I mean by this? Let's look at a scenario:

Merchants themselves are consumers of so many online and offline services (think of it as B2B services) - a company that sells on eBay - or any other online channel - has an eBay account, an account with a shipping company (FedEx), a Facebook account, perhaps another account with a email marketing service, bank account etc. Clearly merchants suffer from the same "account and password hell" that consumers do - but this hell is a lot deeper and hotter for merchants, consider these facts

- Most merchants have employees/contractors who create these accounts on behalf of the merchant,
- A lot of these employees (for smaller merchants) are part time or temps
- Employee turn over is high

Here in addition to the usual forgetting one's password - which for merchant leads to loss of productivity and money - sometimes the person who created the account simply leaves - if you are lucky and s/he good terms, you end up having to chase the employee and restore your access, if not, you are exposed to unauthorized access by the employee or down right "account take over".

You might say, what is the difference between this and consumer identity, these employee are consumers to and technically there is no difference. But look closer. Merchant use cases are fundamentally different. In consumer identity use cases, a consumer is a principle and gives consent on his/her own behalf to a agent (another site or application), the IDP itself recognizes the consumer is the principle and allows her (and ONLY her) to change or revoke this access. In Merchant cases, what appear to be the consumer is really not a principle binded to the merchant identity but an employee. In this case IDP must recognize this "hierarchical relationship" and allow and "admin" employee of merchant to monitor and manage the life cycle of tokens (and identities) of employees.

In the use case above, merchant X would not reveal its primary eBay user name and password to any employee, the would provision an account for each employee. Employee then logs into eBay using her own account - and via PayPalAccess - All the while PayPal Access monitors and manage all the tokens issued to all employees of merchant X. Should an employee leave or changes function, the token can be revoked by merchant X admin regardless of employee's decision.

If this sounds familiar to LDAP or ActiveDirectory, b/c it really serves the same function: Enterprise Identity, in this case enterprise is really a merchant. This is not unexpected in the world where enterprise identity, consumer identity (a.k.a social identity) are converging - and there is a need for a cloud based enterprise user management.

Please note that this is NOT an annoucement (or leak) for PayPal Access Cloud-Base user directory. IT IS NOT, REALLY. I just wanted to point out the there is two sides to commercial identity, a sexy side (consumer) and a side that can make you money (merchants).

In the next post, I will write a bit about Consumer Commercial Identity and how it may be different that social identity.

OpenID Tech Summit - Mountain view, CA - 9/12-13

I am attending the OpenID Tech summit tomorrow (Monday) and Tuesday at the MSFT Silicon Valley campus.

There are two main topics, first the official announcement of  OpenID Connect - a standard built on top of OAuth 2.0 to that allows RPs obtain connect and obtain extensible profile information about an identity -  and second is the introduction of a concept called Account Chooser - a UX pattern for federated login pages proposed based the experience of Google in dealing with federated authentication scenarios.

I am also part of a panel discussion on "Identity Schizophrenia - How users want to apply their online identities" moderated by Allen Tom, OIDF Board Member. It is scheduled for Tuesday September 13 @ 1:40pm. For a full schedule of the summit see here.


It should be interesting ... If you there tomorrow, please do stop by and say hi ...

Social Norms, Market Norms and IDPs

Last week LinkedIn caused a backlash and lost a lot of good will – including mine – by opting everyone into their social advertising program. Before that there was (and still is) a LOT of discussion – and disagreement – about Google+ strict real name policy and the words facebook and privacy can almost be used as antonyms…

But why users react so strongly to use of their identity, relationship and data by these networks, after all most people, I presume, understand that companies like Google, FB, LinkedIn etc. are for profit firms with the goal to make money, and that is a the core of most of their policies (and not that anything is wrong with that!).

As someone once said “if you are not paying them, you are not their customer, you are their product”, and, as harsh as it sounds, they do (and have to) sell their product one way or another.

I am not claiming that one unified theory explains the users’ strong reactions to them - and possible solution - but Dan Airely in “Predictable irrationality” may come close. If you have not read “Predictable irrationality” you should. It is an easy read and a very enlightening book – not to mention entertaining – by behavioral economist Dan Airely.

Among many interesting observations he makes is the notion of “Market and Social Norms”. It is basically a very simple and common sense notion: All of us live in two worlds simultaneously, a social world where exchanges of good and services are regulated by social norms, the need for being part of a community and a delayed- reciprocity, and a market world where exchange of goods and services are regulated by a cold, sharp edge rules of the market, prices, interest rates, cost and benefits. Life is good as long as these world are kept separated (as George Costonza famously pronounced) – but when you mix the two the real trouble starts and “it blows up”.

Airely gives a few examples: You go to your mother-in-law for thanksgiving and offer to pay her a large sum for the sumptuous spread she put on the table for you … and next year you’d be sitting in front your TV with a frozen dinner. Or more vividly, the example of a guy who takes out a girl to three or four expensive dates and finally brings up the subject of money and how much the romance is costing him! …and of course suffers the dire consequences. Next time he will sure remember Woody Allen’s word of wisdom: “The most expensive sex is a free one”.

The “Social Networking” sites and identity seems to be a classic example of crossing social and market norms. The use of social networking sites is free and there is no other signal that the relationship between user and network operator is a market or commercial relationship. Users may feel/perceive that they are dealing with a “host” one that allows them to interact with their friends, family and catch up on “social” stuff …you know, everyday life that is so outside the “market norms”. I don’t have data but I feel users do understand that these sites have to make money, and are OK with some ad poping up from time to time or being displayed alongside their content, but I doubt that most people understand how those ads relates to their data (posts, searches, conversations etc.) . Every now and then someone (say WSJ or some tech blog) reminds them of how their data is being shared with others – or why the need to “report” accurate names – and that is the moment where “worlds collide”.

Maybe (and only maybe), if an identity provider (or social network) actually started an informed conversation with its users about the data sharing and gave them meaningful control, can it bring the relationship to the “market world”. In that world users are not the network “product”, but informed partners. For example, if an identity provider (or network operator) makes it clear to me that they can get me a good deal on a camera lens with free shipping if I give them my shipping address and the consent for them to obtain the shipping history to that address from a few large merchants, then I may be happy to share my address – that is firmly a relationship in market domain – and I am happy, but when I start to see ads from drunk-driving lawyers in Denver area b/c I searched for “maximum legal blood alcohol level”  - I was taking an online traffic school exam to clear a ticket – while attending a conference in Denver area, that is crossing  the line, and that is when I might have come close to understanding how that girl felt on the fourth date in Dan Airely’s example!

BrowserID...and the search for perfect Identity Selector

This is a long post, and here is the gist of it:

In general I think we, as identity community, are still looking for a practical solution to a simple yet adequate "identity selector", CardSpace represent a solution on the rich and complex end and BrowserID represent a solution on the simple (but not rich) end, every solution is a valuable iteration to the final solution of the perfect identity selector - I feel the iterations will continue.

Now, here is for those you are interested in the details:

A few days ago Mozilla announced the availability ofBrowserID. Identity is a hot topic these days, so almost immediately the community (and my mail box) was buzzing with predictable questions such as:

• Is BrowserID the next generation of OpenID?
• What are the differences between OpenID and BrowserID?
• Will BrowserID is the answer to Identity on the web?
• Is BrowserID secure?
• What is the relationship between BroswerID and OAuth or OpenID Connect?
• Should I implement BrowserID now?

All legitimate questions to be sure, but perhaps a few of them could have been clarified more easily if Mozilla had called this feature, say, “Verified Email” – after the title the specification the BrowserID is based on (see Averified email protocol for the browser). I think that would have been a name that reflected the intent and use of this feature and helped answered these questions.

In this post I write about where I think BrowserID would fit in the space and, as risky as it, venture a guess as to whether it will be adopted by identity providers and relying parties (not wise I know…but hey this is a personal blog) - if you want to read more about the implementation details of BrowserID see a very good writeup by Lioyd Hilaiel here, and I also recommend reading Dick Hardt notes on BrowerID as well.

To start let me summarize what BrowserID is. BrowserID is a protocol for 

- Verifying users email addresses (as many as a use wants) as reported by an email provider (or Identity Provider)

- Storing it in browser (Firefox as of now) safely - or one would hope so.

- Transmitting email address safely to a "relying party" that is a site that requires an email address securely.

It uses PK cryptography to ensure integrity of all communications. BrowserID requires two key pairs, one generated by IDP (email provider) to sign the assertion (email x belongs to subject y) and another key pair generated later by browser to sign the (subject+email+IDP public key) token and pass it on to relying party (that is your web site). So it is reasonably safe and uses a subject confirmation method known as "Holder of Key.

So how should one use BrowserID? is this OpenID? is this a replacement for OAuth? 

I think the proper use of BrowserID, if it ever gets support from other browser vendors, is to replace the annoying "email verification dance". BrowserID is a fantastic lower level solve for this problem. Is this a replacement for OpenID or OpenID Connect? I think not! does it replace OAuth, absolutely not, there are simply two different things.

BrowserID, in my view, really is not an ID - my definition of identity is something I can replace registration with, not just login panel. 

An identity is more about attributes than about authenticating an identifier (such as email address). and BrowserID is by design is silent about that matter, in the words of Mike Hanson, the author of Email Verification Protocol:

"The idea that led to the BrowserID work was not "how can we fix identity on the web", but "what is the smallest possible claim we could make to make progress on the browser as a claims agent?"

And

 

"...Attribute exchange is deliberately out of scope"

Mike states the design goals clearly and the solution achieve its goals perfectly, the only thing that complicates the matter is the name BrowserID and the fact that identity means so many things to so many people.

Will BrowserID be adopted widely as a form of identity? will it replace your login button? I have my doubts on both counts.

First off, let me say that I would use BrowserID for email verification (if it is adopted by consumers), it is a very elegant solution for that. As for wider adoption as a form of identity, let's look at the three main actors in any identity ecosystems: RPs, IDPs and User/Consumers.

For a large number of relying parties, an identity provider that simply asserts one attribute (email address) is not valuable enough to dedicate scarce real estate of "login page" to (and add to their NASCAR complexity), RPs would opt for richer IDPs (Facebook, G+, Twitter etc.), that way they not only get an email address by rich set of information about a user (you may ask how about privacy? more on that later). 

IDPs (for example email providers such as Gmail, Yahoo, MSN etc.) also do not have clear cut incentive to support BrowserID  - maybe receiving fewer number of "confirmation emails"? Entities such as FB and Twitter are unlikely to support BrowserID (x@y.com does not have to be a real email address, it is simply an identifier so FB could decide to support user@facebook.com) since they are strategically dedicated to have a presence on RPs login pages and not to be inter-mediated by Moziall's sign-in button.

There are also a few questions on the users adoption, prime among them is what happens when a user switches browser or device (with most user today using more than one device/browser to access the internet)

and to lesser degree whether general population of user will sufficiently understand the use experience.

Finally I have to say I am impressed by one aspect of implementation (which I assume was a lesson learned from CardSpace lack of adoption) and that is the near dead simple implementation for RP sites.

In general I think we, as identity community, are still looking for a practical solution to a simple yet adequate "identity selector", CardSpace represent a solution on the rich and complex end and BrowserID represent a solution on the simple (but not rich) end, every solution is a valuable iteration to the final solution of the perfect identity selector - I feel the iterations will continue.

Identity and E-Commerce: Talk @ Cloud Identity Summit 2011

I am attending Cloud Identity Summit in Keystone, CO. It is fast becoming THE identity conference of the year where you can see all, be it small group of,  "identeratees".

I am also giving a talk tomorrow (7/20/2011) @ 4:00pm titled "Role of Identity in E-Commerce' where we share our findings and observations over the past year while building an identity provider for e-commerce sites.

You can see the presentation here:

Identity and E-Commerce

View more presentations from Farhang Kassaei

The slides are not meant to be read, but to support my talk, so they may feel a bit choppy when you read it.

If I want to summarize it, it is

"A viable commercial identity is a Super Identity, one that is not just an identifier but a complete, accurate and up-to-date federated profile compose of attributes from multiple trusted providers, obtained with users' consent and control in exchange for real value"

If you attend the talk tomorrow, please stop by and say hi.

Power to the People - Data Sharing Power That is - UMA Draft Recommendation Released

After more than a year of hard work, UMA WG (User Managed Access Working Group ) announced the draft recommendation for UMA protocol.

UMA is a communication protocol and is defined by its formal FAQ as

User-Managed Access (UMA, pronounced "OOH-mah" like the given name) is a protocol designed to give a web user a unified control point for authorizing who and what can get access to their online personal data (such as identity attributes), content (such as photos), and services (such as viewing and creating status updates), no matter where all those things live on the web.

Former colleague and current lead of UMA WG @ Kantara Eve Maler gave a very good presentation last year at Cloud Identity Summit that you can see here. There is also a Webinar on July 13.

To explain UMA and what it tries to do, I feel an example works the best (the spec and the terminology are not the easiest way to understand UMA).


Alice is an on demand speaker and celebrity chef, she travels a lot. She uses 

•         A Calendar application,
•         A general purpose social networking site
•         A niche professional networking/community site of food enthusiast
•         Owns a selling account with a popular marketplace for high end kitchen gadgets and appliance.

(All above service are called resources and Alice is a resource owner)

She uses the services of several useful applications:

• Travelers Guide: An application that recommends restaurants and activity in all major cities based on Alice’s preferences of profile on general purpose social network.
• Chef Tracker: An application that notifies Alice’s professional connections and fans when she is coming to their town and where she speaks.
• Merchandise Lister: A web application that lists Alice’s autographed recipe books and limited edition appliances to multiple online channels including the marketplace.

(All above are called consumer or requester)

Alice can grant authorization to the three applications above using OAuth directly. In this case the four resource servers (Social network, professional network, calendar server and marketplace) each maintain Alice’s authorization to respective application(s).

However Alice (a busy professional) does not have a centralized and easy to access location where she can see all the authorization she granted to different applications.  It is true that each resource server maintains a record of Alice’s granted authorization, but since each server has a different way to display the authorization (and they often buried in random places around the resource server) it is unlikely that Alice ever gets a clear view of how different applications are using her information.

Or alternatively, Alice can go to a one server – called Authorization Manager (AM) – and give authorization to three applications at one place.

The benefits are clear. Alice can literally see all applications that access her information (and the extent of their access) at one place. For example Alice can limit the access of Travelers Guide to one week (during which she travels)  

To understand why UMA is important and what UMA does, we should first understand some of the implicit assumptions (or some may argue simplifications) behind OAuth 2.0 authorization.

OAuth 2.0 does require an authorization step, where the “resource owner” authorizes a consumer application to access a resource on his/her behalf. This authorization however requires and assumes:

-       

• Authorization is performed at the time of resource access by consumer
• Resource owner should be present to grant authorization
• Authorization assume that future access to resource is always made on behalf of resource owner  by requester (consumer application) – not on behalf of someone else (say Alice’s assistant in the example above) - This is very important point and deserves its own post :-) OAuth scope does not cover this class of use cases at all.

And more importantly in my view (and from giving the power back to people point of view)

•        Resource owner (user) has to keep track of application/consumers s/he has authorized to access various resource on his/her behalf (how many of you know how many application you have authorized to access the collection of your online accounts? And exactly what type of privileges you granted to them? Think about it!)

Now, granted, this is not OAuth problem, by it is the byproduct of individual consumer obtaining authorization to access variety of resources individually.

UMA is set to address all the above with the introduction of a central Access Manager (AM – in UMA terminology) and, the protocols to connect Resource Server and Consumer to AM.

UMA is an ambitious undertaking (in my experience all authorization initiatives are!) primarily because its success depends on whether users (resource owners) can successfully express policies the govern consumer access to the resources owned by them. This is the linchpin of any authorization project I have ever seen or been part of.

Whether UMA is adopted and implemented as a viable product is remained to be seen, but UMA protocol is a firm step in the right direction.

In the next entry, I will focus on UMA model and associated communication protocol among its participants.

W3C Workshop on Identity in the Browser

OK, it is a a little old, but this was an interesting get together of identity community discussing the role browser can play in managing users identity and perhaps authentication. Although it did come up that in the age that more or more people use embedded apps, any identity solution based on the assumption of a runtime environment called a browser may not be sufficient.

What I feel was the most insightful comment though was in the last paragraph of Dick Hardt position paper titled "The
Chicken,
 the 
Egg
 and 
the 
Rooster:
Why
 Internet 
Identity
 is 
Still 
Unsolved":

Identity 
is 
more 
than 
authentication.
The 
success 
of 
Facebook
 et
.al. 
is
 driven 
by

access 
to 
information
 about 
the 
user 
rather 
than 
just 
which 
user 
it 
is. 
A
 broadly

adopted
 solution 
will 
enable 
the 
user 
to 
share 
profile 
information 
and 
delegate

authorization.

This is the key point that I some times referred to it as "Pizza and Delivery", authentication, SSO is like delivery mechanism, but RPs are interested in "information about the user" or attributes and profile, not how it is delivered to them. Much like people who order pizza are interested in pizza not how it is delivered.

2011 OpenID Retail Summit - March 8 @ PayPal Offices

Our collegues at PayPal are hosting the OpenID Retail Summit tomorrow from noo to 5:00pm. It sounds like it will be an interesting exchange of ideas between identity providers and retailer (as relying parties). I will be presenting our experiences (and wishes) as large relying party tomorrow @ 3:00pm.

I will post the presentation and a short post tomorrow.

CardSpace II : "Change of Authentication Behavior"

After I wrote a short post on announcement of end of life for CardSpace, Kim Cameron (a great visionary in the field of digital identity and someone I learned a LOT from but never had the opportunity to meet) reflected on it here.

A few people (independently) emailed me and asked me whether Kim is implying that Card Space lack of adoption, at least partially, was “eBay’s fault”.

I read his post, partially quoted below, a few times and although to me it more sounds like a reflection, but I see how one may think that way. So, I decided to add a bit more details to my original post on “change of behavior”.  

“In the history of computing there have actually been plenty of cases where users DID change their behavior - even though at first only a few people could understand or use the new alternatives.  But those “early adopters” were able to try the new inventions on their own.  They didn’t need anyone else to approve something or decide they would like it first.  Once convinced, they could show the new ideas to others.

When Visicalc appeared, I don’t know how many people in IT would have bet that every accountant in the world would soon be throwing out his pencils and starting to use spreadsheets for things no one can even now believe are possible!  The same is true for a thousand other applications people came to love. 

But because authentication doesn’t stand on its own, users never got the chance to start using Information Cards “just because they felt like it”.  They needed web sites to make the same bet they did by implementing Information Card support as an option.  

Web sites didn’t want to bet.  They wanted to keep to “the matter at hand” and prevent their users from getting lost or distracted.  The result: a preemptive chill settled over the technology, and we never really got to see what users would make of it.

My conclusion:  regardless of what new features they support, user centric identity solutions need to be built so they work with as many existing web sites as possible.  They can’t require buy-in from the all the big web sites in order to be useful.” 

I agree that users, and people in general, do change their behavior, and sometimes relatively quickly – if there is a direct and tangible benefit for them to do so. 

In case of CardSpace, our end users simply did not perceive the benefits, besides they had to download a large binary and deal with unfamiliar experience. Ashih Jain's post capture the sentiment around the time we were experimenting with CardSpace – 2008 -  (One seller kept asking me why I was asking him to “do all this just to login” ).

eBay is in the commerce business,  we do take reasonable risks in changing people’s behavior around commerce related activities such as listing, classification, payment, feedback, finding, shipping, trust etc. but for login and authentication we rely largely on users' already learned behavior (or as Andrew Nash refers to it the established “steady state” of authentication).

Perhaps one way to get a large number of users familiar with Card Space, and generate consumer demand for it, was full adoption within MSFT (including Windows login panel). Microsoft owns one of the largest (if not the largest) user-facing authentication experiences in the world, if they had fully supported Card Space everywhere a login panel appears today, maybe adoption story for Card Space would have been different. That would have made it much easier for company like eBay to adopt it as well. 

It is Finally Official: The End of MSFT CardSpace

There were a few things I wanted to write about recently ranging from all the discussion around OSGi in the Java community (and eBay) to what I would expect from an industrial grade Identity Provider (hint: it is not about which protocol it uses) and from when not to use No SQL to the emergence of a little known art and science called Entity Resolution, but let me resume my posts after a month with this:  Microsoft announced that it would not ship CardSpace 2.0.

Having worked on a authentication concept with MSFT for eBay sellers, I had mixed feelings about this. On one hand I was on the record not supporting the use of CardSpace for eBay sellers (or buyer). On the other hand I am concerned that technical community discounts the significance of Claim Based identity altogether and concludes that "FaceBook Conncet" is all we'll ever need.

There is a good reflection (from an insider's point of view) on Card Space here. (courtesy Gunnar Peterson) My personal view (and the reason I didn't support the adoption of Card Space at eBay) though centers around the challenges of "Change of Behavior" required by Card Space.

Basically, CardSpace failed b/c it requied uses to change their behavior. See, the "User name and password" protocol (a simple challenge and response) IS a protocol, one where a human being (a normal user) is a participant in. It has taken about 20-30 years (depending on how you count) to train users what to do when they see a "login panel" , the "login panel" contract is so widely understood that despite all of its short coming is the most viable remote authentication protocol we have today. It is flawed, it is costly, it is not secure, but it is a widely understood by users on the other end of the protocol. CardSpace, despite all its advantages, was not understood, would (and did) make people confused, they did not know what to do when the CardSpace screen popped up ... a technology whose adoption depends on change of a strongly learned behavior is unlikely to succeed (or at least I didn't think eBay sellers - not the early adopters of technology - would learn and accept it).

It also didn't help that a lot of browsers didn't support it (installing a plug-in does not count), and the fact that developers didn't know how to issue cards (or validate, update or revoke them).

Having said that, I did like the idea of decentralized identity provider and not having any one identity provider to be THE identity provider that everyone else had to rely on (putting user in control of their own identity). Compare this with a world where one identity provider (be it facebook or Google or twitter or anyone else) is the dominant identity provider because it is easy for RPs to embed a simple button  and for users to click on it.

Cannonical Use Cases for a Relying Party

I have always felt that in identity community we spend most of our time discussing identity providers and their concerns (such as token format, protocol etc.) and do not spend enough time on and attention to relying parties. At eBay we play both roles i.e. we are both an identity provider (we provide sellers' identity and attributes to 3rd party developers) and relying party (accepting identities provisioned outside eBay marketplaces as eBay users). I can say that building a architecturally sound relying party is as challenging as building an identity provider.

In this post I simply want to enumerate the major use cases that any major relying party (that is anyone that for example plans to accept Facebook Connect) has to account for. I used the qualifier "major" to denote that these use cases are important if a given relying party has millions of uses and many services and applications (much like eBay does).

The list of use case are:


1-Sign-In and out

2-Connect and Reception

3-Link/Unlink

4-Profile Access Extension

5-Role Elevation

6-Recovery


7-Disconnect


8-Force Authentication

9-Customer Support 


10-Capturing Alternative/Second Secret 


and here is the descriptions:


1-Sign-In and out: This includes changes to your standard sign-in page to make it a "federated sign-in" page. The challenge here is mostly user experience i.e. how to design the UI correctly to achieve two goals:
   - Not confuse existing users who will not sign up with external IDP
   - Communicate to the user of external IDP what they need to do (without creating the NASCAR problem)
 There are also techniques for detecting the IDPs that user may have an account with and to show a "smart" list of IDPs

2-Connect and Reception: Once users clicks on "Connect" button (if you are using connect style IDPs such as FB) or entered her OpenId URI (although this is unlikely to be adopted by users), the user is send to IDPs to sign-in and given consent to his/her information to be send to you site - let's refer to this process as Connect - then user is sent back to your site to a page/application that we refer to as "Reception". This is the processes that greets the users for the first time and provision an account in RP for him/her. I use the word "reception" to make it distinct from "registration" which is when provision is done based on data collected by RP itself. The reception process is significant b/c it covers the gap between data received from IDP and what is needed for a user to be provisioned, also it assigns the roles for new user. These roles are typically minimal since data coming from external IDPs are normally not trusted or verified. Also during reception token received from external IDP together with associated meta data is stored in a central location accessible to different functional units (application) of RP

3-Link/Unlink: Another use case (often part of reception) is to detect whether the user connecting to RP is one who already has an account. The detection can be done based on mapping the data received from IDPs to existing account, the simplest form is to check whether email addressed returned by IDP already exists.Once an account is detected, user has to prove s/he actually owns it (normally by providing password) and the accounts are link. Since architecture hygiene calls for symmetric operation, you should also allow for unlinking of accounts.

4-Profile Access Extension: RP obtain a token during reception (such as OAuth token that comes with FB Connect), this token stores a set of access permissions to user resources (perhaps hosted by IDP). Any large RP has a set of applications that will use this token (for example MyeBay application as well as eBay Search Application) it is likely that one of these applications requires more information/access privileges that user originally consented to, in these case RPs should provide a central capabilities that conduct the process of requesting, receiving extended permissions from user and updating token meta information associated with user

5-Role Elevation: The first time users connect to RP they are granted a certain role (roles), normally this is a basic role since data provided by most IDPs are not reliable (eBay as an IDP does provides verified reliable data), at some point during the user's life cycle, users needs to perform an action that requires higher role assignment, in this cases RPs should provide capabilities to assign users higher role, this normally requires users to enter more information or go thru verification. This processes produce more attributes that will become part of users profile at RP.

6-Recovery: Every RP always has to establish a method for externally provisioned identities to authenticate WITHOUT the presence of external IDP. What does this mean? suppose you accept FB Connect and FB is down for 6 hours (an event that recently happened), further imagine that you operate a site that every minute of users not being able to login means financial loss. What do you do in this scenario? You may say, this is easy, ask users to enter a password during the first time reception, but wouldn't this defeat the whole purpose (or a big part of it) of users not having to remember many passwords?

7-Disconnect: All RPs must provide the capability for a user to "disconnect" i.e. close the account that was created based on an identity provided by external IDP. I personally believe that user owns his/her data and if user wants to disconnect and remove all of his/her activities from the record. s/he should be able to (to the extent that is legal)

8-Force Authentication: This is actually a capability of IDP, but RPs need to use this when they require user to be authenticated regardless of session's authentication state as seen by IDP. For certain operation RPs require a fresh session (or session that started in the past N minutes), in this cases RPs should request a forced authentication (I am using SAML terminology here) from IDP.

PayPal Identity Services Talk @ PayPal Innovate 2010

Today at the PayPal Developers conference Ashish Jain, my friend and colleague and PayPal’s point man on all things identity, talked about PayPal vision of identity and PayPal Identity Service in his presentation titled, not surprisingly, “PayPal Identity Services”.

If you are involved in the world of internet, as a developer or even an observer, or if you have attended any web related conference in the past 12-18 month (including our own DevCon) you must be familiar with the core identity problem: users have too many accounts, too many password, too often they forget them, it is too easy to phish passwords and too expensive for companies to support users who either forgot their passwords or have had their account taken over …. Ashish talked about it in his presentation (as it is mandatory for these presentations, including mine, to recount the carnage first).

You may have guessed the next step, PayPal, among many others, offers to be an Identity Provider (IDP). Your one and only account you ever need (at least for whenever you want to shop on the Internet). 

You may think, so what? There are so many other identity providers (most notably Facebook) … but (as Lee Corso of ESPN says) “not so fast my friend”, there is actually a difference in this game of being identity provider between PayPal and everyone else, what Ashish, modestly, calls “Qualified Data” (interestingly the second bullet point in his slide – why not the first? I have to ask him).

See, as it turns out providing identity (as in what an IDP does) it is not that hard, pick a protocol (OpenID, OAuth, SAML …) and transfer identity data (unique identifier, name, email, phone number etc.) from the IDP to Relying Party (RP). You can do that in few hours (literally), what turns out to be hard (and expensive and complex), is providing “High Quality” identity, as in identity data the someone actually validates and make sure they are accurate and up to date and actually owned by the person who claims s/he owns it. This is what Ashish means by “Qualified Data”. Now if you are a merchant, which identity you rather rely on? An identity from a site that simply takes users claims (about what her name is, where she lives etc.) and toss it over to you or from PayPal where this set of data is verified and maintained and by the way you know that there is a valid financial/payment instrument attached to it? 

Too often people responsible for building an identity provider argue endlessly  about merits of protocols, compare OpenID to OAuth and talk about how complex SAML is. In the process they miss the much bigger point: what matters is the quality of identity provided not the means by which it is provided.

This is what make PayPal identity (regardless of whether they use OpenID or OAuth or anything else) potentially the most interesting and useful identity in my view.

Ashish also shows a demo where PayPal OpenID service is wrap by Gigya API. Gigya is an aggregator of identity provider, instead of learning multiple APIs from different IDPs, developers simply deal with Gigya API. It is an interesting concept. Check them out here.

It would be interesting to see how far PayPal push their Identity Service (both in terms of end user adoption and merchant adoption) and whether or not they offer different classes of identity (based on data quality) and respective financial assurance levels.

JaveOne 2010 Talk

Latest details I received from conference organizers today (it is kind of late, isn't it?) about time and location of my talk @ JavaOne:

ID#   : S314414
Title  : Login Failed, Try Again: 10 Best Practices for Authentication in the Cloud
Track: Enterprise Service Architectures and the Cloud
Date  : 23-SEP-10
Time  : 14:00 - 15:00
Venue: Parc 55
Room : Cyril Magnin I

CAP Therom and Digital Identity

If you read this blog chances are you are familier with the CAP theorem, it basically states that any distributed system operating at scale can choose at most two of the followings three:
- Consistency
- Availability
- Partition Tolerance

There other examples of pick any "2 out of 3" in life are:

- The management rule of thumb: Good, Cheap, Fast
- Graduate student dilemma: Fun, Grades, Sleep (replace fun with your own idea of it)
- Investment advice: Low Risk, High Return, Legality - if you pick low risk and high return chances are you are compromising legality :-)

They way I look at all these "rules" is that the space of each of these domains offer only two degrees are freedom and once you choose two points (that effectively determine or fix your degree of freedom, the third point will be chosen for you)

For example in "Good, Cheap, Fast", your degrees of freedom are basically time and money, once you choose how much time and money you want to spend all three qualities are determined. So now, if you choose time and money not directly, but indirectly via the choice of say good and fast, you automatically also chosen "not cheap".

Interestingly digital identity offers the same 2 out of 3 dynamics among the three main attributes of

- Quality of Identity
- Usability
- Cost

"Quality of Identity" is a measure of how uniquely a set of data represents a real world person and how strongly an IDP stands behind such assertion (for example whether IDP guarantees up to a certain amount damages resulting from inaccurate data), usability is how easy it is for IDP to provision such identities.

It is clear that if an IDP chooses to provide high quality identity and also wants to makes its provisioning easy to use (or scalable for that matter), it has to spend a lot of money.

In practice though, IDPs segment the user base and only provide high quality identity for users to whom maximum credit are extended (e.g. users who can sell the most on eBay).

Enole - A New Identity Linking Startup

The other day, via Venture Beat, I learn about a new start up called Enole. Since the company is in Identity domain I was naturally interested and start looking around. The idea is as interesting as it is old: to unify all identities online and offline and to carry it with you with your cell phone. (use your fav search engine to look for products, ideas and patent on storing all sorts of identity information on cell phones ranging from credit card to login name and passwords to codes that unlock cars and doors etc.)
However it is often not the novelty of an idea that sets a company apart but the strength in execution and market strategy. So with a bit of healthy skepticism I looked at the site.
There is the usual marketing and hype in the web site – which I completely understand. Beyond the hype Enole is a service that allows a developer/application (identified by a pre-issued token) to link up a user and a device. A user simply means an identifier string (email or any other string). So effectively there is a link among three entities Application that creates a link, user and device.
The rest of the API is about the basic create, update, query of link, users and devices. However there a few key questions that are not answered in the documentation:
- Can an application that has not created a user or device query them?
- How does the system deals with duplicate email addresses and identifiers across multiple applications?
- If another application picks up my devices unique id, can they query Enole DB? If they can and get my information, do I need to authorize (OAuth style) the
information before application can use it?
- How would a user remove his/her account.
- How the "sign-up" tokens are stored and what happens if they are compromised

In essence, the API document describes the CRUD operation of user, device and link entity but does not describe a formal authentication protocol between users, devices etc. As such it can not really be evaluated in details.

Additionally, it is not very clear how end users (not developers) are in control of their own identity and information. This is really big for any company that has ambitions in the identity area.


Also, if you have been reading my blog regularly you know that I give a LOT of significance to the language and terminology one uses to describe either her problem or solution. The language used in Enole site is not that of identity, authentication or communication protocol domains. This, to me, is not the most positive sign.

Having said that, I think Enole is an early stage start up and like any other early stage start up their original idea will evolve, I will keep an eye them to see how they evolve and how their technology be used.

eBay DevCon 2010 Talk and The Spy Who Came in from the Cold

I will give a talk on federated identity and best practices for relying parties at this year's eBay Developers' Conference in San Jose. The talk in start @ 1:30 pm on June 10th, the location is San Jose Fairmont Hotel in grossly under rated San Jose's beautiful downtown.

The title for the talk is "The User Who Came in From the Cloud". It is a play on my favoriate cold war spy novels of all time "The Spy Who Came in from the Clod", if you are into spy novel or cold war buff, I recommend reading the it.

xAuth: Second Tier IDP Club

I learned today that the toolbar company Meebo today announced a proposed standard called xAuth to solve the so called NASCAR problem of OpenID.

The essence of the solution is to create a centralized database (xauth.org) where users preferred IDPs are listed. For example if you use Google Friend Connect then xauth.org DB saves that preference for you. Now the publishers/RP that you visit, make a call to xauth.org (upon your visit) and learn that you prefer to "login" using GFC and only show that logo to you instead of a dozen logos from FB, Tweeter, Yahoo, AOL, Google, Microsoft, VeriSign and whoever else who jumps on federated ID band wagon.

My initial reaction (emphasis on initial) is "Are you serious?" and "Is it opt-in or opt-out" (apparently it is opt-out).

Two comments:
1- Of course collecting all people's information in one central database make a lot of things easier/smoother or more efficient, but there is a reason we don't do it (at least not yet), regardless of how noble the initial intent maybe.

2- And this is important, identity provider business is one of those things that have a real network effect, that means by definition and nature, in the IDP business there can not be dozen winners, it is a winner take all type of a game (or maybe a few - two, three) winners at most. NASCAR problem exists because no one wants to admit that it will not be one of the winners. But time will take care of this. For now support for xAuth seems to have become an admission of membership to "Second Tier IDP Club". after all if you think you are going to be one the winners, why would you want to remove your logo from the NASCAR race?

Identity Assertion Framework Talk @ Stanford Presentation

Here is the presentation for my talk today @ Stanford.

eBay Identity Assertion Framework (IAF)

View more presentations from farhangkassaei.

You can download the presentation for eBay's Identity Assertion Framework now. The talk is today (April 19, 2010), here is more information on time and place.

I have promised to write a bit more about IAF to a few people and I intend to keep my promise.