Re: [OAUTH-WG] draft-hunt-oauth-software-statement-00

Phil Hunt <phil.hunt@oracle.com> Fri, 01 November 2013 19:55 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 A068F11E81A4 for <oauth@ietfa.amsl.com>; Fri, 1 Nov 2013 12:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.268
X-Spam-Level:
X-Spam-Status: No, score=-6.268 tagged_above=-999 required=5 tests=[AWL=0.331, 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 3G-Nbg75MpGM for <oauth@ietfa.amsl.com>; Fri, 1 Nov 2013 12:55:03 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 86DFC11E811D for <oauth@ietf.org>; Fri, 1 Nov 2013 12:55:03 -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 rA1JsxPv010601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Nov 2013 19:55:00 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1Jswex004678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Nov 2013 19:54:59 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1Jswef025962; Fri, 1 Nov 2013 19:54:58 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:54:58 -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: <5273FD6F.3070404@gmx.net>
Date: Fri, 1 Nov 2013 12:54:48 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7CBADC8F-E81D-453B-92FA-CADFDA0AD37D@oracle.com>
References: <5273FD6F.3070404@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-software-statement-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:55:08 -0000

See below...
Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2013-11-01, at 12:13 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

> Hi Phil, Hi Tony, Hi all,
> 
> regarding this document I believe there are the following questions the group may want to think about:
> 
> a) Is the lifecycle of software development (Figure 1) common accross several companies?

We are trying to be generic. What we are trying to do is take the old model where a developer would register with a Facebook, a Google, whatever and apply it to what happens to open source API and commercial API scenarios where software is deployed in many locations (not just a single cloud provider).
> 
> b) The document defines a number of attributes. Are those attributes also used in other deployments? Is their semantic clearly defined so that meaningful actions can be taken when receiving those?

The attributes come from Dynamic Registration.  Only thing new here is software_id and software_version. 
> 
> c) Is the proposed approach for conveying the software statement acceptable for the group?
> (currently the information is conveyed as a bearer token encoded as JWT).

John Bradley's JWT token is similar, but I think they have different characteristics in the way they are used.  I'd like to here John present this at the meeting before I attempt to try and compare them.  This is something I'd like to work on together.
> 
> What would be good to have is two things:
> 
> * Examples
> 
> * Text that describes what decisions can be made by the introduction of the software assertions. This text could go into the introduction to provide a motivation about why to use it.

I am open to a lot of change her. If anything, my feeling is that if anything we should cut the drafts back down to the raw normative text.  It is my feeling there is too much explanatory text that drives the perception that the proposal is complex.  Yet this boils down to 3 methods:

Static - do what you are doing now if that works.
Dynamic - Swap a software statement (shared by all instances of the same app) for an individual client assertion (assertion swap)
Transient - just pass your software_id (or maybe it should be software statement) as you client_id

> 
> Ciao
> Hannes
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth