Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt

[Oleg Moskalenko <[e-mail]>]

Hi Tiru

I went thru the OAuth interoperability links which you suggested (see
below):


On Mon, Feb 17, 2014 at 10:29 AM, Oleg Moskalenko <[e-mail]>wrote:

> [TR] Drafts in OAuth WG like
> https://tools.ietf.org/html/draft-richer-oauth-introspection-04 discuss
> the communication mechanism b/w Resource Server and Authorization server.
>  You may also want to look into
> http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html which
> discusses such communication mechanism already implemented but for a
> different purpose. I guess it all worked because Resource server and
> Authorization server are developed by the same company but with this use
> case we may have to discuss if standardization is required for the
> communication mechanism.
>
>
The links provide meaningful suggestions - but the drafts did not result in
definite standards. The current situation in OAuth is that it is a pretty
fragmented and balkanized field... and it is not moving toward a definite
interoperability standard.

As of now, OAuth is actually not a standard - it is more a framework. So we
have a logical conflict - the TURN specs are definitely a standard, not a
framework, but we introduce a dependency on something that is just a
framework. That would be inconsistent.

Each OAuth server provider defines its own proprietary API for the Resource
Server. That does not sounds very attractive. In practice, every TURN
server provider will have to provide its own OAuth server, too. That will
lead to further fragmentation.

Overall, OAuth is a heated minefield full of emotions and from the outside,
it seems to be going nowhere in terms of interoperability. The lead
developer of OAuth withdrew himself:

http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

As a TURN server developer, I'd be very hesitant to tie, closely, the
implementation to OAuth. I'd rather suggest to look at other alternatives,
giving the current state of OAuth - or wait till the things will be
clarified and OAuth will get more interoperability.

Of course we can develop our own OAuth server but that would be a rather
unfortunate outcome of the standardization process.

I am not saying that from the technical point of view this draft specs is a
bad idea. The TURN field is ready for something like that; but I see that
OAuth is not ready - and I have concerns on being dependent on OAuth.

Tiru, can you address my concerns ?

Thanks,
Oleg