Liberty Alliance People Service Webcast on January
Interested in social networking and all things identity? The Liberty Alliance is having a webcast on the ID-WSF People Service (I can't believe that that has a TM after it...kind of illustrates the icky feeling people have towards Liberty stuff...) -- 8AM PST, January 11, 2006, ID-WSF 2.0’s People Service: Federated Social Identity, presented by Paul Madsen:
The Liberty ID-WSF People Service™, a key component in ID-WSF 2.0, is the industry’s first comprehensive platform for managing social information within an open federated network environment. People Service allows consumers and enterprise users to manage social applications such as bookmarks, blogging, calendars, photo sharing and instant messaging from a common layer within the ID-WSF 2.0 framework. Liberty People Service has been developed to allow individuals to easily store, maintain, and categorize online relationships so that other socially-aware Web services applications can leverage information based on the consent and privacy controls established by a user in the federated social network. With Liberty Alliance People Service, consumers and enterprise users can now centrally manage all of their online social relationships using a federated network approach with privacy controls built into the system allowing users to leverage the privacy functionality of Liberty Web Services to more easily and securely share social and enterprise information across applications, platforms and service providers. In this Web cast, we’ll overview the functionality of People Service and provide some use case examples. You won’t want to miss this highly informative session.
Lauren gave me a heads up on this, and checked with the organizers: there are over 60 people signed up already, and the organizers will make more slots available if it gets "full"...but you need to RSVP soonish to make sure.
So, I mentioned the feelings that people have towards SAML/Liberty Alliance stuff. The perception is one of complexity, corporate focus, and closed source. The concepts covered in the People Service should definitely indicate that there is the desire to address all the fun non-corporate end-user apps that we're all playing with these days. Talking about the closed source issue, when I started looking into this, the main resource I found was OpenSAML. But, nothing but nasty (complex!) Java and C++ implementations.
If you want adoption of your standard/spec/whatever in wider open source communities, you pretty much need an implementation in one of the main "scripty" languages in the LAMP stack -- PHP, Python, or Perl.
I also just put up a placeholder page for the OS CMS Summit Identity Session [link moved], where we'll be able to discuss a lot of these issues face to face.
Update: the session did fill up completely -- there will be another session on January 25th at 6AM PST. Make sure to register. There is a white paper [PDF] about PeopleService, and here are the session slides [PDF]
Similar
Recently viewed
Comments
Implementation languages should not matter
The language that a tool is written in shouldn't matter (and clearly doesn't matter for Linux, Apache, Perl and probably not for PHP or Python either as at least the first 3 are written primarily with C/C++). Tools like OpenSaml should plug into LAMP in one way or another, but they don't need to be implemented using a scripting language.
They do if you want adoption
*IF* you care about mass adoption from web users likely to use identity services (blogs, wikis, CMS, portal sites, etc.), I would say that the vast majority use tools written in a scripting language. Having an implementation/reference implementation/libraries available in one or more of those scripting language will mean that the system can be integrated into those tools that much quicker.
Adoption had to do with usabilty, not implementation language
The people you are talking about have all adopted Linux (written in C primarily), Perl (C), Apache (C) don't know for sure about PHP, but I would guess it also is written with a non-scripting language.
That said, I think the people you (including me) are talking about want to be able to use these tools without having to resort to writing C or Java. So the tools would need to have either an easy to use administrative interface or be administerable through scripts/config files.
So rather than looking at the implementation language, you should look at how the tools are used/configured.
OK, let me be clearer
Usability includes being easy to install and work with. Most shared webhosts make it very difficult (if not impossible) to mix C/Java installs with the much more typical scripting languages found there.
Dedicated boxes and the LAMP stack could certainly easily work with C. I know that I don't like to have Java running on the same box as, well, anything else.
Implement your standard (any standard...I'm talking very general terms here) in a scripting language and make it easy to install in a shared hosting environment, and it will make it a lot easier to spread rapidly.
Implementation language *does* matter (except perhaps for web services which are accessed remotely) for everything from deployment environment to availability of developers to embrace and extend the codebase.
I completely agree, even
I completely agree, even with 5 years experience in java/j2ee, I didn't manage to find my way through the most complex and annoying product that is Sun Access Manager.
These kind of Liberty implementations are typical heavy weight "Enterprise software", and mass adaptation never goes this path.