I will but will replace the scheme and token names with [[tbd]] until the issue is resolved.
EHL On Jan 28, 2011, at 13:40, "Mike Jones" <michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>> wrote: Draft 02 as published registers the parameters in the IANA Considerations section and therefore conforms to draft -12, per your request. Therefore please retain the bearer token examples, as they are useful to implementers. I intentionally made no breaking changes to maintain specification stability. -- Mike From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, January 27, 2011 6:24 PM To: Mike Jones Cc: OAuth WG; 'Manger, James H (james.h.man...@team.telstra.com<mailto:james.h.man...@team.telstra.com>)' Subject: RE: Update required for bearer token spec The bearer draft must include the registration template as done in draft-hammer-oauth-v2-mac-token section 8 including giving the name used for issuing such tokens for the token_type parameter. Every RFC must include an IANA Considerations section and your is currently in violation of -12. If you have an issue with the registration process or language in -12, the appropriate thing to do is to raise those issues on the list. I will remove the bearer token examples from -13 due to my objections to the ‘OAuth2’ scheme name (which makes it an open issue) and lack of registration and token type name in the bearer token draft. I will gladly put those examples back (as they are listed in -12) once these concerns are resolved (or if instructed to by the chairs and area director). I will keep the informative reference in -13, and will only remove the examples which are incorrect. --- As for the open issues: the bearer token scheme name - if it wasn’t clear, I plan to use every mean available to me to block the bearer token draft from using the ‘OAuth2’ scheme name, and will raise this issue in the WGLC, Area Director review, IETF LC, and direct appeal to the IESG if necessary. You might consider this childish, but I consider bearer tokens a disaster waiting to happen and will not allow the weakest form of token authentication to carry the strongest form of endorsement and perception (via the OAuth brand). At the end, you might get the scheme name you want, but it will cost you significant delays in getting that document published as an RFC and with a Proposed Standard designation. So far you have failed to raise any technical justification for your insistence of using that name. The only reason so far is that it will be less confusing. Perhaps. But will be more damaging. After all, why would anyone look at the MAC token specification or other stronger authentication schemes, when you offer them the “official” OAuth 2.0 scheme. I also want to point out that I am not the only one here who made this request. I consent that there isn’t consensus to changing the name, but there isn’t consensus to keeping it either. The “vote” is around 2-4 on each side. If you are willing to spend the next few months arguing over 6 characters in your document, I will gladly oblige. EHL From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Thursday, January 27, 2011 5:15 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: RE: Update required for bearer token spec Once approved, the existing names will be registered, hence no changes are needed to the bearer token draft to comply with these requirements. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, January 27, 2011 2:36 PM To: Mike Jones Cc: OAuth WG Subject: RE: Update required for bearer token spec -12 section 8.1 and 10.1. EHL From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Thursday, January 27, 2011 2:10 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: RE: Update required for bearer token spec Your request below is ambiguous. Please provide the precise new text you’re requesting and the rationale for it. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, January 27, 2011 1:42 PM To: Mike Jones Cc: OAuth WG Subject: Update required for bearer token spec Please update the draft to comply with -12 registration guidelines and requirements asap. EHL
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
