Barry, all,
First, apologies for being so slow responding, various travels got in the way. I hope we can quickly resolve this now. Bit of process first: at the meeting we discussed this and at the end of that discussion, there were quite a few more folks for the "pick one" position. People who favour that outcome and really care about that need to speak up on the list, since the list consensus trumps the sense of the room in the chairs' evaluation of the WG consensus. Second, at the meeting I said that I'd like to see either MAC or bearer picked as MTI, and if not, that I want the draft to say why its ok to have no MTI token type. So the WG either need to pick one, or else explicitly and convincingly justify not picking one. That's the "firm" AD position to which Barry referred. (I didn't properly call out the "if not" part of that in my AD review, sorry.) My own argument for picking one is simple: if every relevant piece of code has to know how to handle one then it becomes easier to get interop. If everyone decides for themselves then interop is less likely since there are currently two choices and may be more in future. I do realise that the background here and current practice is that code tends to be written that is specific to a resource server (or however that's best phrased) but that's maybe where the IETF differs from the community that produced OAuth - here we want two independent implementers who've never talked to produce code that interops even so. I also realise that that's not the full story for getting interop with OAuth and that more is needed. However, this aspect is otherwise fully specified and so I don't buy the argument that this isn't worth doing just because we don't have the full registration story etc. figured out. If we don't sort this out now, then later specs will have to update this one in this respect. possibly making existing code "non-compliant" in some sense, so just going ahead and doing it right now is better. So, pick one (my strong personal preference) or establish and document why you're not picking one seem to me to be the choices available. Regards, Stephen. On 11/17/2011 08:28 AM, Barry Leiba wrote:
Stephen, as AD, brought up the question of mandatory-to-implement token types, in the IETF 82 meeting. There was some extended discussion on the point: - Stephen is firm in his belief that it's necessary for interoperability. He notes that mandatory to *implement* is not the same as mandatory to *use*. - Several participants believe that without a mechanism for requesting or negotiating a token type, there is no value in having any type be mandatory to implement. Stephen is happy to continue the discussion on the list, and make his point clear. In any case, there was clear consensus in the room that we *should* specify a mandatory-to-implement type, and that that type be bearer tokens. This would be specified in the base document, and would make a normative reference from the base doc to the bearer token doc. We need to confirm that consensus on the mailing list, so this starts the discussion. Let's work on resolving this over the next week or so, and moving forward: 1. Should we specify some token type as mandatory to implement? Why or why not (*briefly*)? 2. If we do specify one, which token type should it be? Barry, as chair _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
