Liberty Alliance Releases Specifications

Darren.Moffat writes "Has the time come for Passport to move over ? Technical Specs of the Liberty Alliance Project technology are now available from the website and were officially announced at the Burton Group conference today." We've done stories on the Liberty Alliance and digital identity before.

Comments

whew...

[Em Emalb]

I was thinking rather pessimistic about all this, until this little beauty popped up:

"The Liberty version 1.0 specifications do not involve the exchange of personal information. Instead, they involve a format for exchanging authentication information between companies so the identity of the user is safe, and specific details about the customer's identity are not shared. The user may choose which accounts he/she wants to link, and may maintain separate identities in different locations while still benefiting from a seamless sign-on experience."

So, it's cool. Well, not that Em Emalb would be targetted anyway, more along the lines of some poor dude named Pete Slashtaco (who for some reason, lives in New York City 10101) and makes $15,000 a year working as a CEO of a Fortune 500 business with 250,000 employees. Poor, poor Pete.

Interesting Convergence

[Zeinfeld]

The problem I have with Liberty is that Sun appear to be more focused on stopping Microsoft than on developing a product that is going to succeed on its own merits.

Ironically, passport started as a stop AOL Instant Messenger affair. So I don't think it is impossible that Passport and Liberty will eventually merge.

On a technical level this is certainly possible and if folk look hard at the underlying SAML spec that Liberty is based on you will notice that there is an interesting intersection between SAML and the GXA world.

Can someone translate into English?

[slamb]

I downloaded the specification, but it's obnoxiously long/buzzwordish and my Linux PDF software sucks. I've got some pretty basic questions I'm hoping someone can answer:

• Are passwords ever sent through service providers?

  One would hope they are only sent to the identity provider, and encrypted. But this talk of using existing deployed clients makes me nervous, since I don't see how both things are possible together.

  They mention HTTP redirects...I think you go to the Service Provider's page, they redirect you to the identity provider as the form action, and they redirect you back, authenticated. That doesn't seem like a good plan to me, no one will actually check that the form action goes elsewhere.

  I'd be much more comfortable with something similar to Kerberos: you get a TGT (ticket-generating ticket) from the Key Distribution Center (excuse me, Identity Provider) and use that to provide a ticket to the Service Provider. That ticket can't be used elsewhere and will be invalidated after a certain length of time.

• Does it work for protocols other than HTTP?

  I'd like to use it to authenticate with HTTP, SSH, IMAP, SMTP, and Jabber - probably others I'm forgetting, too. A GSSAPI and/or SASL mechanism would help a lot here.

• Who can set up providers?

  I'd hope that anyone can set up Identity Providers and Service Providers at little or no cost and have them work with major players. I think this would require

  • a good Public Key Infrastructure. The existing X.500 PKI used for web stuff now costs ~ $100/yr/certificate to get a widely-trusted CA to sign your key. DNSSEC might end up being free (depends on what the TLD people do, I think) but isn't really deployed yet
  • addresses that make it obvious what Identity Provider they belong to. I.e., email-style with SRV records or something.

• Can multiple Service Providers requiring the same credentials without knowing the identity is the same?

  Here, I think the answer is yes. They said something about opaque tokens that gave me hope. I'd like clarification, though.