User:Nickr/LID-FAQ-OtherSystems-Liberty

From LID Wiki

Originally in-lined into LID-FAQ-OtherSystems, this may be a better place for it.

Contents 1 How is LID different from Liberty Alliance? 1.1 Not So Different, Actually: Same RESTful-ness, Same MEP, Same Semantics 1.2 A Few Style Differences 1.3 Otherwise Today's LID is Essentially Identical to ID-FF 1.4 Except for this Neat Idea 1.5 Maybe a Challenge of Equal Value?

How is LID different from Liberty Alliance?

Not So Different, Actually: Same RESTful-ness, Same MEP, Same Semantics

While LID is largely unspecified (so it is difficult to make a conclusive comparison; innovations are possible in many dimensions), another way to characterize the differences between Liberty Alliance and LID is in robustness. To help us build on the past, not blithely repeat it, it is worthwhile to understand that today’s specification of LID’s mechanisms are largely those of a defined, legal, subset of Liberty Alliance’s ID-FF1.2.

When used only in service of the problem domain that LID has adopted at this point, essentially the browser single sign-on problem domain, LID is almost precisely a repeat of a subset of ID-FF. For this profile, for example, ID-FF is entirely RESTful; the LID message exchange unfolds in the same manner. In terms of message content, a few things are different, but not much (and almost nothing once one adjusts for two effects: additional aspects required by LID, and a few style differences).

A Few Style Differences

As a style example, in ID-FF the identity provider (“LID SSOO Profile” actor) doesn’t get to know precisely what service is being requested, improving security and privacy; so instead of “BASETARGETURL”, ID-FF exchanges “ProviderIDs.” In ID-FF metadata is available (RESTful) in both directions, through which the identity of the “Providers” can be assured; although as in LID everybody might just put faith in each other if the exchange (appears to) unfold sweetly. In ID-FF, as in LID, the relying party gets to decide how to find the appropriate identity provider (in LID, assumed in the LID, which would be fine for ID-FF too); and the identity provider gets to decide how to authenticate the user (like LID, ID-FF offers a simple way to specify this, while also supporting a more substantial method) and ID-FF too communicates back the confirmation data.

As another style difference, ID-FF requires communications between the two “providers” be protected for integrity and confidentiality—not only to protect from man-in-the-middle attacks, among other fiddles, but also because this is necessary to protect the privacy of the principal (from, e.g., tracking behavior, as explicitly prohibited in EU directives). This protection can be, simply, TLS/SSL.

On the other hand, LID places additional requirements on the relaying party and authenticating actor that, well, although not in ID-FF, could benefit users (e.g., displaying state). To mention only momentarily the additional burden on the user of the LID itself (although for some, offering other benefits).

Otherwise Today's LID is Essentially Identical to ID-FF

Of note is that for this simplest of all exchanges, ID-FF requires nearly nothing more than LID—the caveats being related to minor bits such as providing for message version numbers, unique ids for messages, and keeping separate the uses of timestamps. (The need for each all born of harsh experience.)

Except for this Neat Idea

Now there is one difference of note: LID offers a method for any “joe” to just run a simple script on their own host and be the “Identity Provider” (supporting LID SSO Profile). Neither ID-FF, nor any successor, figured out how to do that—the other needs that ID-FF serves just demand more capabilities. Like, for example, serving the opportunities that arise for use cases where you don’t want to tie your LID to your own host, but rather want to locate it at an ISP—which is likely the more common ‘base’ case even with LID. Or for controlling how your identity can be discovered, which personal data you want to have discovered or published (among other dynamics), or how others might interact with you wherever you are.

Maybe a Challenge of Equal Value?

On reflection, a challenge as worthy as implementing LID might be putting together this ‘minimal’ ID-FF1.2 identity provider and seeing where that takes us.