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