I do love Paul's sense of humor and the depth of his sarcasm and it's clearly at work in his comments on the article. I especially liked:
The following sentence particularly caught my attention.
The Liberty Alliance has churned out a number of PDFs but that seems to be the extent so far of their effort.
I don't know why people are constantly scoping the Liberty Alliance down to the publication of just PDF documents - we are far more than just that. It seems that just because the best known examples of our published material are in PDF, then somehow we get typed as only publishing in PDF.
Fundamentally, the Liberty Alliance defines a marketing framework, a platform on which can be built systems capable of publishing in a variety of formats appropriate to different marketing applications. Any particular publishing run is able to use the Liberty framework in a manner that suits the sort of marketing campaign being targetted. Examples of particular file formats supported by the Liberty framework include Powerpoint, HTML, JPEG, Flash etc and of course, yes, PDF.
There are lots of publishing frameworks that support one or two of the above formats, LAP is, AFAIK, unique in its "publishing format breadth".
He does forget to mention that we also have generated output in the all important plain-text form as well
On a more serious note (hard for Paul to be serious at times... just read his blog and you'll see what I mean) there are a number of issues with the yet-another-home-grown-solution-for-sso including:
- Requiring users to give out their IdP's password at each relying party (even if that party just sends it back to some verification server) is very, very bad for the user as now, that second party has their credentials and could act as them (and any employee at that second party can do so as well). Even accidental leaks via log file entries can be very troublesome in this manner.
- Security analysis for attacks and weaknesses of protocols are not something for the weak at heart... take advantage of the reviews & analysis that has already taken place on the standard specs rather than creating new holes in your own solution.
- Doing your own solution requires that everyone has to write one-off code and/or integrate your one-off code into their platform -- I know from real world experience while I was at AOL that it is not easy to get other parties to do this -- much better to use an off-the-shelf solution which they may already have in their application plaform.
- I could go on with more, but you should get my point by now... Try to use what's there before you re-invent the wheel yet again. It's alot less painful that way -- for everyone
And, while it really pains me to say it, Paul's response to the PDF comment kind of misread the point (probably purposelly like my teenage son does all the time). It wasn't about PDFs vs other formats, it was questioning whether there have been real deployments. I have to say that there have been real deployments, and there are real products shipping today which support the protocols. There is even a conformance program for certifying conformance with the protocols.
I would suggest that one trying to solve the SSO problem look at the SAML2 Specifications and if they have questions about how to ratchet it down (select the minimal feature set) for their particular environment, send a note to the saml-dev mailing list (link further down on the same page).