Posts tagged: Identity

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

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.

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

OpenID Nascarization

Chris has an interesting post about user experience around OpenID - Does OpenID need to be hard?

I  raised the issue of Nascarization more than an year ago . There should be one OpenID button. Not two. Not three. Else it’s not scalable for the relying parties. And it’s confusing for the user.
OpenID isn’t new in terms of the user flow. Every other SSO type protocol (SAML, WS-Fed, OAuth) essentially has the same flow where the user shows up at the RP, authenticates at the IdP and logs in at the RP. VerifiedByVisa, PayPal user flows aren’t much different either.

They all also have the the following major constructs (one could argue that different protocols could learn/leverage from each other, but let’s not go there) :

  • Token format
  • Key Management
  • Discovery

Discovery is the hardest since that has the most impact on user flow. SAML doesn’t really have to face the issue to the same extent as OpenID since most SAML federations today are in B2B with limited or clearly defined IDPs.

Great to see the acknowledgment of the issues and a focus to address the problem. I’m hoping to see more developments in  IDIB and/or a cleaner discovery service. And as a user, I get my one button.

Speaking of elephants in the room, it would be nice to have some agreement on a way to exchange attributes/claims between IdP and RP. As it stands today, I can use SReg, AX or OAuth. There is definitely some overlap there and the lack of clarity often results in “wait” for most implementors.

Consumer Privacy

Since last fall, I’ve been going to Denver University for my EMBA program. This quarter a team of us were to present a paper and as it turned out, our topic was privacy. Even though the topic was broader and we were required to cover many other aspects of privacy as – workplace privacy, citizen privacy, privacy laws and statues in the country and so forth, we found it interesting to add in a piece for consumer privacy. As part of our class presentation, we picked a fellow student (hey Toby!) and simply by knowing his name, in less than 5 minutes, we were able to find his:

  • Date of Birth
  • Home Address
  • Phone number
  • Home Price
  • Cars that he drive
  • Previously known home addresses
  • Wife’s name
  • Relatives names
  • Mortgage info
  • Employer Info
  • School Info
  • Pictures of him and his family

Here are some of sites that we used to get this information:

And interestingly enough, while doing so we didn’t break any laws (nor did we spend any money – a lot more is apparently available for $9.95).

ID Theft

Now…in the past few years I have spent decent amount of time going through the use cases around user’s personal information especially date of birth. Should we exchange ‘DOB’ or ‘Age’ or simply the claim that the user is ‘over 21′. I have read and articulated many times, Kim’s Laws of Identity and why user control and consent should be required and why RPs should respect the ‘minimal disclosure for a constrained use’.

However, I’m wondering the practicality of it. The privacy statement at the home page of http://www.birthdatabase.com interestingly states that “Our birthday data is obtained from public records and available to anyone with a simple knowledge of public record access.” If all of my information is publicly available anyway,what’s point of splitting hairs on what part of information should be shared. It’s not like it’s even possible to hide my age from anyone….and do I really care for the control and consent of the information on a per RP basis – information that’s available publicly for everyone.
A while back, Sun’s CEO Scott McNealy made a statement “You have zero privacy anyway, Get over it”. As much as I appreciate the thinking behind some of the identity laws, I can’t help agreeing with the sentiment that argues ‘Get over it’.
Now if the information is indeed protected by law, that changes things. But for everything else, why bother?

Here are some of the slides that were used in our class presentation.

Image | WordPress Themes