Eran's point about the definition of a client is an important one. There are two breeds of OAuth clients: (1) general purpose and (2) purpose-built for a specific OAuth service.
When discussing interop, something to consider about OAuth is that discovery is not part of the core spec, which IMHO leads to many special purpose clients for a particular web service. This fits well with many OAuth use cases and isn't a bad thing, simply something that distinguishes OAuth apart from protocols like OpenID, where it is a design goal for all clients to be compatable with all OpenID identity providers. With the current OAuth landscape, to me it seems reasonable to say that clients SHOULD support both mac and bearer access token types, but MAY choose to support any access token types needed to achieve compatability with the desired server(s). Regards, Andre DeMarre On Wed, Nov 2, 2011 at 2:04 PM, John Bradley <[email protected]> wrote: > I could probably live with the client needing to support both token types if > we quite narrowly define client as a general purpose library designed to > support multiple protocols using OAuth for authorization. > > That however is not the general use of the term in OAuth 2.0. > > Many clients will be optimized to work only with Bearer + TLS knowing in > advance that the protocols they are used with only require Bearer. > > John B. > > > > On 2011-11-02, at 5:47 PM, Eran Hammer-Lahav wrote: > >> The problem is centered on the definition of a client. If it is a service >> specific implementation which is merely using OAuth for access, there isn't >> any interop requirements other than making sure the client and server are >> compatible. But if the client is a general purpose OAuth library or generic >> client (e.g. CURL), then the MTI becomes critical for any real interop. >> >> I don't have a strong prefernece here, but we should clearly define the >> client characteristics in this discussion since an OAuth client isn't >> usually similar to an HTTP client in its interop reality. >> >> I am not sure how to craft this language into spec form, but we might want >> to list such a MTI requirement in terms of a 'client designed to work across >> multiuple providers such as a general purpose library'. >> >> EHL >> >> ________________________________________ >> From: Stephen Farrell [[email protected]] >> Sent: Wednesday, November 02, 2011 1:45 PM >> To: John Bradley >> Cc: Eran Hammer-Lahav; [email protected] >> Subject: Re: [OAUTH-WG] AD review of -22 >> >> So perhaps this is the interesting point of difference. >> >> On 11/02/2011 08:37 PM, John Bradley wrote: >>> It is up to the server to decide what formats it will support. >> >> With IETF protocols, its IETF consensus that decides this in >> almost all cases that affect interop and it is therefore not >> up to the specific server deployment admin what the server >> code will support. >> >> I think this case affects interop. and should be treated >> as for any other IETF protocol. Am I wrong? >> >> S > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
