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

Phil Hunt <phil.hunt@oracle.com> Fri, 01 November 2013 19:56 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244CA11E813D for <oauth@ietfa.amsl.com>; Fri, 1 Nov 2013 12:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.278
X-Spam-Level:
X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jWORPiIOEQJ for <oauth@ietfa.amsl.com>; Fri, 1 Nov 2013 12:56:45 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E220521E80E8 for <oauth@ietf.org>; Fri, 1 Nov 2013 12:56:32 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA1JuMhU012189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Nov 2013 19:56:22 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1JuL1K009017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Nov 2013 19:56:22 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1JuLKD009002; Fri, 1 Nov 2013 19:56:21 GMT
Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Nov 2013 12:56:21 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <5273FA71.4000500@gmx.net>
Date: Fri, 01 Nov 2013 12:56:11 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D4A7D8A-A532-4368-B0E0-87B73B57F1EC@oracle.com>
References: <5273FA71.4000500@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1510)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Nov 2013 19:56:50 -0000

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
www.independentid.com
phil.hunt@oracle.com

On 2013-11-01, at 12:01 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth