Hi Jeff, I am not, nor have I been involved in OAuth specification writing, but I do spend a lot of time supporting people who are writing consumer / client applications and have been following the work done on both WRAP and OAuth 2.0 so hopefully I can be of some help (answers inline).
On 2010-02-03, at 12:30 PM, Jeff wrote: > My group is evaluating OAuth as a possible technology. I need some > information though. Some of the questions I think I know the answer to, but I > want to hear it from people active in the community. > > * Version 1.0a is the current standard. 2.0 is in the wings. When? Will it be > backwards compatible to 1.0a? Version 1.0a is the current specification. Note that Eran Hammer-Lahav has rewritten it as an IETF draft available here: http://tools.ietf.org/html/draft-hammer-oauth draft-hammer-oauth is generally more well written, but you can certainly get by with the 1.0a specification as it stands. draft-hammer-oauth uses slightly different terminology, and eases some of the requirements for people using SSL and plaintext signature methods, but otherwise it is the same protocol. OAuth 2.0 is in active development but I am not aware of any timelines. I understand that it will not be backwards compatible with 1.0a, but you may want someone involved in OAuth 2.0 to confirm this. > * Also, from what I gather it will either include WRAP or something like it. > Is 2.0 intended to have any compatibility with WRAP at all? Should we ignore > WRAP and wait for 2.0? As I understand it (and please, if someone involved in either community wants to correct me, do!) OAuth 2.0 will take the use cases addressed by WRAP into consideration but will not be compatible with WRAP. I would suggest ignoring WRAP unless you specifically need to support the use cases it addresses (different profiles, separation of authorization server from protected resource server, etc). > * The reference implementations we have looked at are Java, Python and Perl. > These are used widely and have been adopted by the community at large. > Correct? I have spoken to many people using the Java and Python reference implementations, but not the Perl one (likely just because I don't end up speaking to a lot of people using Perl these days). At FreshBooks (my employer), we decided to write our own SP implementation instead of relying on the PHP one, but that was because at the time the PHP implementation didn't meet our needs... there have since been many more developed, including a PEAR module and one that ships with the Zend Framework I believe. Anyway, the Python and Java implementations definitely seem to work for people. FreshBooks have a good number of integration partners that use them with our service. > * If so, these implementations will be maintained for future releases of the > OAuth spec., right? If not, what will replace them? As I understand it, the reference implementations are maintained by various people in the community. They may be updated with future versions of the spec, or new implementations may be developed. I suspect it will be the latter. > Since this is security, it is always a selling point if we can point to > people using the reference impls. in production environments. Any large names > that depend on these? If not, again, why not? Unfortunately I'm not aware of what implementations are in use by what service providers. I mentioned what we do at FreshBooks, someone else may chime in if they're using a reference implementation. Cheers, Paul -- 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.
