Session Timeout for PayPal OpenID

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

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

Login to Google Apps using PayPal

It was great to see Pam setup and configure PingFederate to accept PayPal OpenID and show login to Google Apps.

The following screen cast illustrates:

  • User accesses integralcurve.com (a Google Apps domain)
  • SAML SP Initiated SSO to PingFederate.
  • PingFed redirects to PayPal OpenID endpoint for authentication.
  • User authenticates at PayPal.com.
  • PingFed accepts PayPal OpenID response, creates a SAML assertion and redirects to integralcurve.
  • User is logged in to integralcurve.

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.

SAML SSO using PayPal

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.

The following screen cast illustrates how Intel Cloud Access 360 can
a. initiate OpenID request to PayPal
b. accept PayPal OpenID response
c. create a SAML assertion with appropriate attributes to login into Salesforce.com

PayPal OpenID Implementation details

Follow up to the previous entry for PayPal OpenID provider:

Main Links

OpenID Endpoint https://www.paypal.com/webapps/auth/server
OpenID Identifier https://www.paypal.com/webapps/auth/server
This should return the XRDS that can be used to discover the end point)
Docs Link https://www.x.com/community/ppx/xspaces/identity
Submit RP for whitelisting https://www.x.com/create-appvetting-app!input.jsp


Simple Registration (
http://openid.net/sreg/1.0)

Prefix http://openid.net/sreg/1.0
openid.sreg.required email,fullname,dob,postcode,country,language,
timezone

 

Attribute Exchange (http://openid.net/srv/ax/1.0)
Generic Attributes

first name http://axschema.org/namePerson/first
last name http://axschema.org/namePerson/last
email http://axschema.org/contact/email
full name http://schema.openid.net/contact/fullname
dob http://axschema.org/birthDate
postcode http://axschema.org/contact/postalCode/home
country
http://axschema.org/contact/country/home
language
http://axschema.org/pref/language
timezone
http://axschema.org/pref/timezone
street1
http://schema.openid.net/contact/street1
street2
http://schema.openid.net/contact/street2
city
http://axschema.org/contact/city/home
state
http://axschema.org/contact/state/home
phone http://axschema.org/contact/phone/default


PayPal Specific Attributes

Verified Account https://www.paypal.com/webapps/auth/schema/verifiedAccount
Payer ID https://www.paypal.com/webapps/auth/schema/payerID

PAPE (http://specs.openid.net/extensions/pape/1.0)

preferred_auth_policies  

 

 

http://schemas.openid.net/pape/policies/2007/06/phishing-resistant 

http://schemas.openid.net/pape/policies/2007/06/multi-factor

http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical

max_auth_age [ integer value greater than or equal to zero in seconds]
preferred_auth_level_types papeauthlevel1 papeauthlevel2
auth_level.ns.papeauthlevel1 http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
auth_level.ns.papeauthlevel2 http://www.jisa.or.jp/spec/auth_level.html

PayPal OpenID Provider

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.

Here is a list of specifications that are supported:

Here is a list of standard attributes that are available for sharing

  • first name
  • last name
  • email
  • full name
  • dob
  • postcode
  • country
  • language
  • timezone
  • street1
  • street2
  • city
  • state
  • phone

In addition, users can also share the following PayPal specific attributes

  • PayerID – PayPal specific unique identifier for users
  • Verified Account – Indicator if the user has a financial instrument attached to the account.

If you are a relying party and interested in accepting PayPal OpenID, you can signup at X.com.

OpenID Security Discussion

Here are the slides that we presented during the OpenID Summit. The basic premise was to identify the list of issues that have been mentioned in the past and classify them as

  • Protocol Issues
  • Browser / Http Issues
  • Deployment Issues.

Breno (Google) had a follow up session at IIW to address the protocol issues.

OpenID Protocol Issues

OpenID Protocol Issues

Michael Hanson (Mozilla)  and Jeff had a session to address browser / http issues. (Still trying to find notes from that session).

Open Identity for Open Government

At the Gov2.0 conference yesterday, US government announced Open identity for Open Government initiative.

PayPal is one of the participants that has joined the pilot programs for both OpenID and Information Card.

ReadWriteWeb provides a good explanation of the initiative here.

A good FAQ is available at ICF website here.

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.

Off topic – Social media for a social cause

A few weeks back a friend sent out a slide deck explaining the potential issues with “bottled water”.
The bottom line was:

  • It’s bad for health since there is no expiry, no regulations and cheap plastic leaks chemicals.
  • It’s bad for the environment since the bottles aren’t bio-degradable, fills landfill, water bodies etc.

And of course, it costs more (on an average it costs $1.50 per bottle).
crane

The email led to a conversation and eventually a few of us decided to start a campaign (or join a campaign) to spread awareness around the issue. Some of the ideas that have been mentioned:

  • Start a twitter petition or a Facebook Cause.
  • Put together a website with all the resources (we found bunch of articles but not at a single place).
  • Talk to local universities, conference owners where there is a large consumption of water bottles.
  • Talk to alternative sources e.g water filter companies and take their help in spreading the word.

If you have some suggestions, opinions and have some cycles to help, please get in touch.

Catalogs, Correlation, Privacy etc.

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.

Name “the thing”

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.

  • Information Card
  • InfoCard
  • CardSpace
  • Self Issued Card
  • Managed Card
  • Personal Card
  • Password Card
  • p-card, pcard
  • m-card, mcard
  • i-card, icard
  • h-card, hcard, Higgins card
  • r-card, rcard, Relationship card,
  • a-card, acard, Action Card
  • IMI Cards
  • Digital Cards, Identity Cards…
  • and my favorite – “the thing”

This, in addition to the basic identity terminology (IdP, RP, AP, SP, Selector, Client, Agent, Active, Passive…) and multiple protocols doesn’t make things easy.

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

Image | WordPress Themes