Re: [OAUTH-WG] AD review of -22

[Eran Hammer-Lahav <[e-mail]>]

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 [[e-mail]]
Sent: Wednesday, November 02, 2011 1:45 PM
To: John Bradley
Cc: Eran Hammer-Lahav; [e-mail]
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