Category: Identity

While setting up PayPal.com as an OpenID provider to enable third party authentication, two issues came up for session management:

The session timeout for PayPal.com is set for a short duration. As a payment provider, it makes complete sense; However, as an Identity provider it didn’t result in an ideal experience It required user authentication for every RP access and hence added to user friction. RP’s preference was for a more seamless user experience and reduce (if not eliminate) the login challenge.

The concept of login to a site using another site’s credentials is still new. Users were not sure if they were login to a RP or PayPal or both; Users didn’t always realize that by using PayPal.com to login to a RP, they were leaving an active session at PayPal.

We wanted to make sure tha the security of the user’s PayPal.com account wasn’t compromised; while providing the best experience that we can offer. We took a couple of measures:

Decouple the OP session from PayPal.com – If you use PayPal as an OP, it will not result in an active session at PayPal.com.

Allow the OP session to be longer lived – The maximum duration for OP session is 8 hours. Depending on the RP’s preference, user may not be challenged again for 8 hours.

Allow RPs to request session duration via max_auth_age – Depending on the sensivity of the transactions, RPs can request their session duration preference. It can be done either at on-boarding time or during the OpenID Authn request.

There are a still a few more tweaks that we are planning to make in the near future, but we believe the current solution will allow RPs to have a better control of the user experience.

Another feature that’s not shown here is to configure the solution for user’s to select their own IdP at run time. This can potentially allow Google Apps hosted enterprises to offer their employees a handful of IdP options (PayPal, Enterprise AD, Facebook…) and let the employees pick the one they feel most comfortable with.

One of the benefits of using Open standards is the interoperability with other product and solutions. I connected with the Intel Cloud Access 360 team during IIW. And it took less than an hour to hook up PayPal Authentication to Google Apps and Salesforce login via SAML.

More than an year or so ago, PayPal announced its participation in Open Identity for Open Government initiative. We worked closely with Janrain in helping us standup a beta OpenID provider at PayPal-IdS.com that links with our proprietary Authentication service. At Innovate last year (in partnership with Janrain and Gigya), we showcased a few sites that were enabled to accept PayPal as an IdP. The beta OpenID provider gave us a chance to work closely with our partners and consumers and get a better understanding of requirements around setting up a commercial identity provider.
I’m happy to share that we now have an OpenID provider that’s hosted on PayPal infrastructure and completely integrated with PayPal.com. The new functionality will allow consumers to login to a PayPal approved OpenID relying party using their existing PayPal account.

I consider this as another forcing function that provides an opportunity for several providers to work together. There is no dearth of opinions in the identity community . GSA, I believe has done a tremendous job in putting together the ICAM profiles for OpenID , Information Cards and the Trust framework .The profiles have allowed the providers to focus and converge on some of the important issues surrounding the technologies.

RE: OpenID
There has been some questions from the very start (and there is still no consensus) if the resting state should be lightweight, simple to use, distributed, low-value transactions. Or should it grow and evolve towards more security, trust, e-commerce and whatever comes with it.

If the answer is latter, then the ICAM profile is very appropriate. The mandatory use of SSL, directed Identity, support of white list, trust framework for certification, sensitvity towards PII etc. are all good steps for a robust identity framework geared towards value-transactions. One could argue that the trust frameworks would push it towards a centralized system but hopefully there will be several entities serving as trust framework providers.
Authentication is a critical function for any site and it’s understandable that a site (that has something to protect) wouldn’t outsource it without first establishing trust (implicit or explicit). This has been one of the sticky points in the community since establishing trust (via RP specific whitelist or third party providers) can potentially hinder adoption and innovation.

RE: Information Card
Even though a lot has been done in the past few years, a few issues still remain:

Platform support for information card/selector is limited.

The UI experience is too foreign and that’s get even more challenging due to the maturity level of current selectors.

Mobility/portability of cards (and hence identity) is still unresolved.

There are very limited “maintained” tool/libraries for relying parties to use.

The issues around running a managed card provider (e.g. practices around issuing/renewing/revoking cards, cert/key expiry, advising user in an intelligent and non-intrusive way on what claims should (or not) be shared with the RP etc.) haven’t yet surfaced. Hopefully the pilot will make IdPs (that includes us) think harder on some of the production issues around running a card server.

Irrespective of how far the Open Identity initiative will go, it’s definitely a step in the right direction.

Have you ever wondered how and why do you get certain catalogs at home?

Last quarter we had a presentation from the CTO of a company (name withheld intentionally – let’s call it company X) who’s into data mining of consumer data.

Their business model is pretty simple. They take customer data from a bunch of retail stores (e.g. Kohl’s, REI, Sears…), put it together, process it and sell it back to the stores. It’s a co-op arrangement where the stores have gotten together to get a better understanding of their customers.

They take things like age, gender, origin, number of visits, average spending, size, color of clothing etc and categorize them into segments. And then they match each user to a segment(s) to predict their buying behavior. For instance, if you are 24 year old Chinese living in San Mateo, you would like to buy orange polos (since that’s what 24 year old Chinese people living in San Mateo are buying).

This also allows retails stores to customize their catalogs per region as well as per customer. I won’t be surprised if 5 years from now, the catalogs delivered to my home will have pictures of me (and my Facebook friends).

The company X claims that they are able to determine with up to 50% accuracy whether a customer will show up in the store if he/she receives a catalog.

Though the stores compete with each other but agree to this arrangement since they all benefit by combining the data. Stores never get to see each other’s data. Stores don’t get the data back if it’s not their existing customer i.e. if you have never shopped at Kohl’s, but are a life time REI customer, Kohl’s cannot get your data from company X. However, the day you buy a $5 tee at Kohl’s, Kohl’s will be able to find out your spending habits as well as your waist size.

The stores can then use this to estimate ‘Customer Lifetime Value‘ and determine if you are worth sending catalogs (with ads for orange polos).

When talking about consumer privacy, Company X claimed that the consumers can always ask the retail stores or them to stop processing their data. However, they have a transactional model and get paid by the number of customers in their database. And hence they have no reason to encourage/educate the customer on how to do that. No wonder there is no web page or even an email address where the customer can request exemption. Most of the time, the customer has to find the postal address (in fine print), write a letter and then mail it.

Of course, Company X believes they are doing a service to consumers by narrowing their choices (if you are a 24 year old Chinese living in San Mateo, why wouldn’t you want to buy that orange polo).

Not sure where I stand on this and where is the line between helping consumers and manipulating them.

I do believe that it’s only a matter of time when some aggressive company will skip the catalogs and simply start shipping the orange polos. I can only hope they get my size right.

During one of the conferences last year, Bob made some interesting points regarding adoption of new technologies. As a general rule, they need to be

easy to describe

easy to get

easy for first time use.

Given the above guidelines, I believe we still have some work to do when it comes to describing Information Cards (or whatever “the thing” is).

The card metaphor has been there for a while. I believe we all understand fairly well the concept of physical cards in our wallet and how to pick one based on the context. However, explaining how that can be mapped to the digitial world has been challenging.

In conversations with technologists, implementers, early adopters, consumers, I have seen the use of following terms interchangeably and therefore spending the first part of the discussions in getting the terminology right.

I understand there are multiple things that are being described here – the protocol, the GUI Metaphor, the token format, the blob that the user stores on his PC and so forth. I also understand the need of innovation and may be it’s too early to agree on a single terminology. But if the techonology does get some success and the branding people start joining the discussions, it’s only going to get tougher.

So…here is my request to ICF:
“Get an agreement on the basic naming conventions, share the results and stick to it.”