I'll start with the IPR question. The IETF has a very simple set of rules with regard to its IPR policies. The full rules are available at: https://datatracker.ietf.org/ipr/about/. In general, everyone is an individual, and most of the IPR requirements are about copyrights. There is a disclosure requirement for patents, which in general says that if you are aware of any patent related to the work being done, you must disclose it. This is a personal requirement, not for your company. Most companies do not require strict review before IETF participation. But you should check with your employer.
An important note about IETF work (usually an RFC) is that it is only guaranteed to give you some copyright license. There is no requirement for RFCs to be free (and some actually have royalties associated with them). It is the decision and responsibility of the editors to apply a licensing policy. With regard to OAuth at the IETF, I plan to duel license it under the IETF rules and the OWF license once it is ready. I hope it will be ready before the IETF WG charter is finished so that it can be stated clearly. If you are active on this list, you should have no problem joining the IETF list. --- It is hard to tell what will be in scope for the IETF version of OAuth. I expect the spec to be cleaned up, made easier to read, and mostly address interoperability and security issues. I am not expecting much in terms of new features, at least not as part of the core charter. The most important thing is that we are going to break backward compatibility in some places to accommodate stronger security requirements. We are also going to make the protocol somewhat less flexible, such as removing support for URI query parameter (just an example, not a proposal or decision). Right now OAuth is more of a framework than a truly interoperable specification. There are just too many options. Another example is the fact that the HTTP methods of the three calls are not explicitly defined (should be a POST). Strictly speaking, OAuth allows all these changes since it has many extension and deviation points built in as part of its design. So you could think of the IETF version as being a fully-compliant sub-type of OAuth, that is more restrictive. The importance of this work is that it will have impact on those implementing it, assuming they will want to support the newer version. So the interest in this work is as important as it was in the original specification. I'll put it this way: if you care about the details, you need to join the new effort. EHL --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
