John, I am obviously not making much progress with influencing OpenWFE design and this is getting frustrating...
As a follow up to this email, Let me try again using different words: There are 2 problems to solve with the RESTful API. For the record, those problems have been solved and documented in existing specs. Problem 1: user identification and authentication. Any rail app has that need. Code/pluggins exist to handle that piece. Problem 2: when you want to execute a workflow remotely, you need to identify yourself but then delegate your authority to the workflow to (potentially) allow it to access other web services on other sites... Problem 1 has been solved by OpenID 2.0. There is even room for attributes exchange or AX (for instance: access permissions) if required by the application (but AX is certainly not something that is needed within densha...) Problem 2 has been solved by Oauth 1.0. This problem can be further simplified if you make some other assumptions such as pre-approved transactions. The discovery portion is still tbd at this point but it is not critical. Since the work happens in the headers, there is very little effort (if any) to support it. My main concern is that this project does not seem to foster cooperation nor intends to look at interoperable solutions. If it is "Not Invented Here", let's not use it seems to be the current mantra. We are at the point of having 3 or 4 different "RESTful" APIs that have no legacy nor heritage. There are 2 organizations that are interested in workflow interoperability. This community has a unique opportunity to make a difference. But is there a true intent in building such a community around OpenWFE? Do we want to make it interoperable with other engines that are used for solving real business problems? I cannot answer that question. Rather than being spoon-fed code from various parties, I would like to see everyone interested come to the table and start the documentation process of that API (at least). Then we could go off and implement the various needed components that may or may not be part of core (Densha, Kisha, Fluxr, Matelot...) Since you asked, this is what I think. V/R, Pat. > From: John Mettraux <[EMAIL PROTECTED]> > Reply-To: <[email protected]> > Date: Sat, 5 Jan 2008 11:33:00 +0900 > To: <[email protected]> > Subject: [openwferu-dev] restful authentication (and authorization maybe) > > > Hi List, > > this is a kind of follow-up to > > http://groups.google.com/group/openwferu-dev/t/cf8a95b466b3606e and > http://groups.google.com/group/openwferu-users/browse_frm/thread/b507387b8664e > 36f > > I was checking out "restful_authentication" > http://svn.techno-weenie.net/projects/plugins/restful_authentication/ > and thinking, shouldn't be those restful authentication concerns stuff > be concentrated in a plugin just outside/beside of any densha, kishah, > Taskr4rails ? > > "restful_authorization" as well ? Restful AAS. That could be a > standalone project usable in many domains. > > > What do you guys think ? > > -- > John Mettraux -///- http://jmettraux.openwfe.org > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/openwferu-dev?hl=en -~----------~----~----~----~------~----~------~--~---
