I'm very disappointed in OAuth 2.0. 1. It doesn't describe what the token is supposed to look like 2. It doesn't describe the authentication protocol between client and provider.
So, what is the point of supporting it when half of the protocol is application/IDP dependent? If you have requirements to filter down that would be cool. SAML has its own HTTP bindings, and we support SAML in Picketlink. I am working on a decentralized auth protocol based on digital signatures: http://bill.burkecentral.com/2011/06/19/decentralized-auth-ideas/ On 7/7/11 10:58 AM, foster wrote: > Hi Bill, > > Could you elaborate a bit more here? We do have plan to use OAuth, so I'm > curious what are the areas we need to pay more attention specifically and add > additional work by ourselves. Also, what's > your plan for full OAuth support? > > Thanks a lot! > > foster > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Resteasy-users mailing list > Resteasy-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/resteasy-users -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Resteasy-users mailing list Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users