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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Oleg,

OAuth is a framework and we are only using it's concepts in the TURN third party authorization draft. There are vendors who have implemented and deployed OAuth for authentication and authorization. If standardization is required we can have a separate draft for the communication mechanism b/w the TURN server and Authorization server. But only after there is WG consensus that handle token better suites TURN third party authorization problem than self-contained token.

I see good progress happening in the OAuth WG, for any other generic concerns about OAuth it would be fair to include OAuth IETF WG.

Cheers,
-Tiru

From: Oleg Moskalenko [mailto:[e-mail]]
Sent: Tuesday, February 18, 2014 10:42 AM
To: Tirumaleswar Reddy (tireddy)
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt

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]<mailto:[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