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 [stephen.farr...@cs.tcd.ie] > Sent: Wednesday, November 02, 2011 1:45 PM > To: John Bradley > Cc: Eran Hammer-Lahav; oauth@ietf.org > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
