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

Oleg Moskalenko <> Tue, 18 February 2014 05:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D51B91A05B1 for <>; Mon, 17 Feb 2014 21:12:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iDOjfNzE2ViD for <>; Mon, 17 Feb 2014 21:12:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c01::22b]) by (Postfix) with ESMTP id 810FF1A0346 for <>; Mon, 17 Feb 2014 21:12:12 -0800 (PST)
Received: by with SMTP id md12so16250527pbc.2 for <>; Mon, 17 Feb 2014 21:12:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C9W97/Z5pRrf+99KSCqf9V7oenE85f5PI73o1GTV7uE=; b=MJVKX9GvQ9gVQUjP5+H9kRLoddEunonYGrBRIWSahXsus4ow+GpEGj698C1Reim9fB uzSeFMxftIQd4pBiYApPegUrJOEYoYakokCBf3826SctgMJowuoecToZQ3RraoK1/tHk AhIrZQujRvqdUeqj5QWNivcAFrL7KmRlP4V8EqfUMA5dYYbGq3xlnQ7WUFS5r8m4oH9c 2yG9m7MH5XEhYkk9hY6HZItaTJFGi5mVpf0w8XUlM8KveLXgkJDljDu+6W5wcuE8uJb4 jjqB4cI2Rr8uBB66CnLJxMwyW0Lek9qj9PG7f4GAf8M7CugmxaURwFbITtblhyyJudds bL2A==
MIME-Version: 1.0
X-Received: by with SMTP id nl1mr12704632pbc.142.1392700329706; Mon, 17 Feb 2014 21:12:09 -0800 (PST)
Received: by with HTTP; Mon, 17 Feb 2014 21:12:09 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Mon, 17 Feb 2014 21:12:09 -0800
Message-ID: <>
From: Oleg Moskalenko <>
To: "Tirumaleswar Reddy (tireddy)" <>
Content-Type: multipart/alternative; boundary="e89a8ff1c89c6e4c0f04f2a7502b"
Cc: "" <>
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Feb 2014 05:12:15 -0000

Hi Tiru

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

On Mon, Feb 17, 2014 at 10:29 AM, Oleg Moskalenko <>wrote:

> [TR] Drafts in OAuth WG like
> discuss
> the communication mechanism b/w Resource Server and Authorization server.
>  You may also want to look into
> 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:

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 ?