Liberty Alliance Completes Phase 2

g0_p writes "According to CNET the Liberty Alliance project released its phase 2 specifications for the Liberty Identity Web Services Framework. This will provide the much talked about 'single-sign-on' to multiple websites capability. Websites will be able to securely share information about the user including credit card data. The biggest benefit of sharing this kind of data is for people using web services through handhelds and mobile phones (Lesser buttons to click to buy birthday gift..). This may be significant, since many of the new phone models have web browsing capability and there is a considerable surge in sales. Now that this phase is complete we should start seeing this standard being implemented out there on the web. It would also be interesting to see how it stands up against Microsoft Passport in terms of security which has had troubles in the past."

Comments

Passport does not compete against Liberty

[finkployd]

WS:Federation does.

In the federated identity world, the showdown is going to come between Liberty and WS:Fed. Liberty currently has the advantage of actually existing, and the spec followed a very open and transparent development model that was very inclusive (as spec development goes). WS:Fed on the other hand was developed behind closed doors by Microsoft and (to a lesser extent) IBM, and is just now applying for standards body recognition.

Another noteworthy point is that Liberty by design is very similar to Shibboleth, an Internet2 Middleware initiative for higher education federated authentication/authorization that has been very successful. Both are built off of Oasis's SAML spec. Shibboleth however places far more emphasis on user privacy.

Finkployd

Any OSS implementation's

[IA-Outdoors]

I only know that Sun has a liberty compliant implementation. Does anybody know of an OSS project geared at being compliant? Also, I think one thing this project needs to tackle next is authentication strength. I may have app A and app B authenticating to one backend data source (i.e. Active Directory, LDAP, IMAP, etc) but app A may have more critical data and may require additional creditional (i.e. biometrics, smart card, etc). Being able to chain these credentials to the applications desire authentication strength is going to be key.

Re:centralization == bad

[stevesliva]

SSO in its standard form simply allows using the same identity and credentials at multiple sites. Your SSO credentials are only the intersection of all sets of personal information needed by SSO sites, not the superset. Each site then stores additional information hashed with your unique SSO id. It's a matter of debate what that intersection should be:

• Username/Identifier
• Password/PIN/etc.
• Secret Question?
• Secret Answer?
• Zipcode?
• etc...

It is possible to have SSO with only the first two, but the many numbnuts that forget their password require some secure form of reset.