Unless I am missing something this is about the HTTP authentication scheme that the protected resource MUST support. Token type is a bit of a misdirection.
While it would be possible to use some profile of bearer with those other protocols, making a specific HTTP binding of MAC or Bearer MTI would preclude ever having a conforming version for SMTP. Not that there aren't other HTTP specific things in the spec that may also be an issue. I don't think that having a MTI token type/http authentication scheme alone gets us interoperability. I don't even know if OAuth 2.0 interoperability between two unrelated systems is a goal. Other specs like OpenID Connect have that goal. If I have to pick one authentication scheme as MTI for the protected resource it would be Bearer. John B. On 2011-11-17, at 6:24 AM, Matt Miller wrote: > Further clarification (-: This is not (or shortly will not be) limited to > HTTP. There is work to use OAUTH over SASL, which opens it up to a much much > broader audience (e.g. IMAP, SMTP, and XMPP). > >> 1. Should we specify some token type as mandatory to implement? Why or why >> not (*briefly*)? > > Yes. I believe it is necessary to provide a baseline for implementors, and > will help make the "80% rule" easier; if "everyone" supports <x> then I will > find client, authorization, and resource software that will "just work". I > think this becomes even more important as OAuth is used with well-established > resource servers (e.g. cloud-based XMPP service). > >> >> 2. If we do specify one, which token type should it be? >> > > I personally am ambivalent. > > On Nov 17, 2011, at 16:32, Mike Jones wrote: > >> Terminology correction: This discussion was actually about HTTP >> authentication schemes (Bearer, MAC, etc.), not token types (JWT, SAML, >> etc.). I've changed the subject line of the thread accordingly. >> >> -- Mike >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Barry Leiba >> Sent: Thursday, November 17, 2011 12:29 AM >> To: oauth WG >> Subject: [OAUTH-WG] Mandatory-to-implement token type >> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > - m&m > > Matt Miller - <[email protected]> > Collaboration Software Group - Cisco Systems, Inc. > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
