RESTful authentication and dealing with form-based auth

Early experiences with OSLC CM 1.0 indicate that discovery of authentication model of some service providers is needed, especially if form-based authentication is used. I'm doing some searching, research and analysis of various approaches to solving this problem in a consistent manner.
Some options include:

1. Prohibit the use of form-based authentication
   This involves requiring at a minimum Basic or Digest authentication schemes. This may have some implications to some applications as they may not be well suited to make this change.
   
2. Standardize the use of form-based authentication
   Since HTTP's WWW-Authenticate header is extensible, it could be possible to indicate the needed meta data either in the header and/or response body for the consumer to perform the authentication.

I'm curious if anyone has any experience with these and prefered approaches or drawbacks of other approaches.

A short pause, now on to 2.0

After recently finalizing the OSLC CM 1.0 specifications, a call for participation is out for the next wave of CM specifications (calling CM 2.0). We hope to have this group fired up soon and specifications nailed down by the end of 2009. If you are interested in contributing to the working group, please let me know.

Again, the specifications will be driven by the working group's determination of scope based on supported scenarios. Some work has already gone into key aspects of scenarios needed to support integrations with applications like Mylyn. These scenarios appear to raise the need for schema information in order to drive Mylyn's task editor and off-line support. Ease of adding attachments also comes out of these scenarios.

Some other areas that we'd like to tackle are (in no order, details will come later):

• alignment with other standards
  
• Better handling of differing authenication models
• saved/pre-defined queries
• various presentation modes: dialog vs full window

Hopefully we'll be able to accomplish these but again it depends on the priorities as defined by the members of the WG.

Some things that would most definitely fall outside the scope of the 2.0 work would be things like communicating state model and dependencies, standard link types, to name a couple.

Time to make it happen.

Change Management 1.0 specs complete - thanks team

On May 28, 2009 the OSLC CM Working Group completed the 1.0 round of specifications. I wanted to just quickly recognize the great work that was done by this team and their extended teams.

First off from IBM, Steve Abrams (Rational CTO Team, OSLC Lead Architect), Andre Weinand (Jazz WorkItem Component Lead) and I spent many hours together per week hashing out technical challenges and coming up with solutions that fit within the spirit of the loosley coupled approach to interoperability and the 1.0 specs. Also Scott Bosworth (Rational CTO Team) provided help in any way to ensure the group was successful. There are many others that supported us in this effort: Samit Mehta, Joe Toomey, ....

From Tasktop, Mik Kersten (Founder, CTO) and Robert Elves provided great feedback and background based on their experiences with many change management systems and vairous API implementations. They also provided direct feedback as an implementer (consumer) of the specs.

Lastly from Accenture, Randy Vogel and Gary Dang who provided great input and feedback from their experiences providing enterprise class integrated tools solutions.

A little bit about me and OSLC

Open Services for Lifecycle Collaboration (or just OSLC) was first introduced at the June 2008 Rational Software Developer's Conference in Orlando. It was launched in part with various activities around the Jazz initiative and started with a set of sample specifications and reference implementation.

I started my role as Change Management domain lead in October 2008. I was given the mission to coordinate, facilate and participate in a working group that would define a set of OSLC specifications that solved some specific integration scenarios (more on that another day).

My day job was also to produce a service provider implementation for Rational ClearQuest and assist in the one for Rational Team Concert, which both will be available in the next week.
I have a fairly diverse background as development leads for various change management tools, as well as have worked in many standardization efforts.

I plan to use this blog for various items. To post what is going on in OSLC in more than 140 characters, what has happened and how we got there as well as current topics in the works (and hopefully getting some additional feedback).