On 2 December 2011 03:20, Barry Leiba <barryle...@computer.org> wrote: > Stephen is thinking that code will be reused. Perhaps there'll be a > limited number of coded toolkits, and their code will be used to > implement various authorization servers, etc. That's the way a lot of > Internet code is done today. In that case, Stephen posits, if we tell > the toolkit writers that they MUST implement X, then at least when X > is being used, implementations based on the different toolkits can > always interoperate. Lacking that directive, a toolkit that only > implements X will be unable to interoperate with a toolkit that only > implements Y.
My $0.02 (tl;dr: I agree with Barry): Libraries are the point of code re-use for OAuth at the moment. If two libraries (e.g., "Ruby OAuth" and "Java OAuth") implement all the necessary bits of OAuth, then people using those libraries can expect (or hope for) interop. We cannot force compliance, but we can mandate it. If a service provider chooses to allow only a subset of OAuth's functionality, and a general-purpose tool (i.e., NOT a library, though perhaps written using a library) doesn't support that subset, then obviously the implementations are not interoperable. However, more likely than not, tools are designed to be used against specific service providers OR other standards (which would in either case mandate the way(s) in which to use OAuth). SO, having Mandatory to Implement schemes in the general sense is pointless. BUT, having BOTH Bearer and MAC be Mandatory to Implement for general-purpose libraries IS useful, and will help interop (assuming library authors bother to follow the spec). b. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
