Re: [OAUTH-WG] draft-hunt-oauth-client-association-00

Hannes Tschofenig <> Fri, 01 November 2013 20:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C557911E814F for <>; Fri, 1 Nov 2013 13:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bQsTlYbgpD4b for <>; Fri, 1 Nov 2013 13:23:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 07B2D11E811D for <>; Fri, 1 Nov 2013 13:23:12 -0700 (PDT)
Received: from masham-mac.home ([]) by (mrgmx003) with ESMTPSA (Nemesis) id 0Lta9E-1VkHF50rTA-010upz for <>; Fri, 01 Nov 2013 21:23:11 +0100
Message-ID: <>
Date: Fri, 01 Nov 2013 21:23:09 +0100
From: Hannes Tschofenig <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Phil Hunt <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:I/SwcaWOxsn6b7bnhuLajkd1bWy84f8bEH/2mRpiLxIXLheJmFm B3tuhMBEcN8MUk5DJWGd8L3N3W+5ukHaBZe7Z8RZ7hf7FiCIpyinkVCOUlaO/e/jPfYjmvc uCXJHI/wZ7SxF56ysMfIFShVKblLEq1af0e+uWW5mOnVvLZiOSk+iVVyDdYA9sTT9TXaKNF Cy1nd6+XE9npmlSb1oI6g==
Cc: " WG" <>
Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Nov 2013 20:23:16 -0000

Hi Phil,

We definitely have to figure out how the differentiation is made so that
a developer (or someone who deploys the technology) understands the
scenario they are in and what the implications are. At the moment I
would struggle a bit.

Using examples is certainly a good idea, like you did below. There are,
however, quickly challenges. For example, in the JavaScript case below
you can imagine a developer of a smart phone app who uses JavaScript but
then packages the application (using PhoneGap), which makes it behave
very much like a native app.

And, as you say below, the notion of whether the endpoint is configured 
upfront (during development time) or dynamically configured may not 
necessarily matter.

It definitely makes sense to discuss this during the meeting and 
real-world examples may help.


Am 01.11.13 20:56, schrieb Phil Hunt:
> Hannes,
> Great timing!
> This is an aspect that I think deserves more discussion. One of the
> challenges was to draw a clear line of distinction between transient
> and dynamic.
> Transient clients are really meant for javascript clients that decide
> to connect to a particular end-point on the fly.  Note you can still
> have "static" javascript clients that are hard coded to connect and
> have already received a client_id through an out-of-band process.
> Phil
> @independentid
> On 2013-11-01, at 12:01 PM, Hannes Tschofenig
> <> wrote:
>> Hi Phil, Hi Tony, Hi all,
>> I re-read the document and I believe the most important concept it
>> introduces is the classification of different associations, namely
>> into 'static', 'dynamic', and 'transient'. This is certainly
>> something worthwhile to discuss during the meeting and to ensure
>> that it is well understood, and that there are only these three
>> classes (rather than two or four).
>> The description in the introduction makes the differentiation
>> between the three concepts mostly based on how the endpoints are
>> configured in the application.
>> With the static association the endpoint is hard-coded into the
>> software during the development time. It cannot be changed. With
>> the two other cases the endpoint can be changed. As such, the
>> difference between the 'dynamic', and 'transient' association seems
>> to be in the terms of how long the lifetime of the association.
>> Now, what exactly is the lifetime of an association? Is the
>> lifetime of the association understood as the lifetime of the
>> configured endpoint identifier?
>> Then, when I re-read the text in Section 1 again then I suddenly
>> get the impression that the lifetime of the association actually
>> does not matter but instead the difference is rather whether the
>> client is public or confidential. Is that true?
>> If it isn't true that this is the feature that makes the
>> distinction between 'dynamic', and 'transient' then the notion of
>> "public" vs. "confidential" client isn't too important for the rest
>> of the document.
>> Ciao Hannes
>> _______________________________________________ OAuth mailing list