We ended up taking an approach conceptually similar to 2-legged OAuth. For SOAP, we're using the consumer key, and a secret in a standard WS UserName token.
One thing we did slightly different than 2 legged OAuth was to use a derived secret. In essence, we use a value calculated off a token secret combined with a consumer secret. This is slightly more complex than 2 legged OAuth, but it allows us to be less paranoid when issuing token secrets. This works well for our particular use cases, as our ISVs actually need to manage many credential sets with us due to our B2B market and multi-tenency model. Let me know if you have any questions or want to get more specific. - cmort On Jul 3, 7:03 am, Moritz Maisel <[email protected]> wrote: > Hi, > > On Feb 1 2008, 11:17 pm, "Chuck Mortimore" > > <[email protected]> wrote: > > Similar to what we had in mind....currently we've been looking at 2 profiles > > > 1)OAuth+ WS-Security using XML DSIG for the signature aspects > > 2) CustomOAuthheader that parallels theOAuthHTTP Authorization header > > > We'll spec out both and post for review. > > Was there any progress on this? Maybe someone still working on it? > > Greetings > Moritz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" 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/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
