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

Athens

[mapnjd]

Am I the only one here who's heard of Eduserv Athens? (Disclaimer: I am employed by Eduserv in a different department).

Athens has over 2,500,000 users (from UK and Irish Academia and the NHS) and allows secure single sign on to more than 300 resources. It has also been around for years (at least 7). So all this talk of secure single sign-on being "new" seems to be a bit of misinformation as far as I can tell.

Downside: Athens is not open-source :-(
Upside: Eduserv are a not-for-profit company that makes substantial grants back to academia.

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.

Maybe for specific industries

[sbeast702]

I would be ok with a single sign on capability for a certain category of sites (like all newspaper sites, all computer resellers, etc) but a single sign on for a variety of categories would just make me a little nervous. And plus, I have multiple identities for the various things I do on the web (business, personal, pr0n, etc) and I wouldn't be able to decide on one un/pw combo.

Re:centralization == bad

[finkployd]

We are using federated identity in the higher education world via an Internet2 called Shibboleth which is very similar to Liberty (both based on SAML). It has been somewhat successful in our setting.

The rational for why we wanted is was that we (Penn State University) have a very strong central authentication and account management system. That is all well and good for internal services but like any university we license resources from external entities. Such as Webassign (popular web resource for Physics students), and various library resourses like OCLC, JSTOR, etc. Shibboleth allows our students to not have to create accounts on these resourses (and remember different userids and passwords) but use their PSU access id and password.

So to carry this over to the commercial side of things with liberty, they have the concept of an identity providor. This could be your bank, your isp, whatever. You only have to create an account with them, then you can use liberty to "assert" your identity to other commercial sites. Along with that you can choose to pass attributes like your credit card number, your shipping address, whatever. The benefit being that you do not have this data stored on mutiple databases at various companies, nor do you have multiple accounts to deal with at various companies.

Finkployd

SSO Doesn't mean All Your Information Belong to Us

[cybrthng]

SSO should be independant of your data sources. SSO doesn't rely on your billing address/information for authentication.

SSO is a token/cookie/uri that is passwd between websties that accept the "token" as proof that you have been authenticated.

SSO doesn't take the users data store and pass that along, each vendor maintains its own store and uses the token to authenticate from via an agent that handles this.

For example you can implement RSA clear trust on all of your sites/services but each user store remains to the application. An Agent simply parses the token, passes to the auth server and verifies the information. Your credit card number isn't passed and would be kept independant of your SSO.

SSO does not mean "Cyber Wallet" if that is what you fear.

Microsoft's Single Signon is a combination of LDAP/Active Directory, SSO and Wallet. It usually takes the combindation thereof to complete that cycle. Hopefully this is not the direction of the stated sso implementation.

Re:Who cares?

[jfengel]

Actually, I find it rather scary to have my CC# stored in my browser. First, I'm never sure when it's going to fill it out without my noticing. Is it possible to trick my browser into auto-filling it into a hidden form?

Second, how well protected is by browser's forms cache? Is my CC# stored, unencrypted, on my disk somewhere? The info is available to anybody who sits down an borrows my browser.

There are a host of problems with single-sign-on, but auto-fill is at least as dangerous, IMO.

Re:Where this needs to come from...

[John Hurliman]

I would like to see micropayments get worked in to a system like this, THAT would be a compelling reason for consumers to adopt such a system. Access premium content by logging in through a gateway and digitally signing a payment agreement, no credit card hassle every time you want 25 cent comics.

Re:centralization == bad

[4of12]

I like the idea of standard protocols for authentication, but with plenty of flexibility built in.

There should be no reason for Jim's Hardware Shack to have access to my full profile of personal information at all.

It should be sufficient that I can locally create a digital check:

1. my name or handle (and I should be able to create as many or few as I like),
2. Jim's Hardware Shack's name (or any of the names they want to use),
3. my secret pin to sign the check or fund transfer request,
4. an amount,
5. a time interval in which the transaction can be performed
6. the name of a server (aka the bank) (say in Cayman Islands) that will vouch for that transaction.

Then, Jim's Hardware Shack need only submit my digitally-signed transaction request to the named server. The named server is the only information that Jim will need to know.

As long as Jim's Hardware Shack trusts the named server to send them the amount of the transaction and "Jim's Hardware Shack" provides them with some registered server at which to dump the funds (I don't need to know where), Jim shouldn't ever even need to know who I am.

Internet banking can be secure and needn't disclose any more information than is absolutely needed.

Jim's Hardware Shack sure as hell doesn't need my blanket credit card number, my One Single True Name, etc..