[OAUTH-WG] draft-ietf-oauth-assertions-06

"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Mon, 08 October 2012 12:12 UTC

Return-Path: <hannes.tschofenig@nsn.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 91CF221F86A3 for <oauth@ietfa.amsl.com>; Mon, 8 Oct 2012 05:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.474
X-Spam-Level:
X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVoCCAkejDaK for <oauth@ietfa.amsl.com>; Mon, 8 Oct 2012 05:12:51 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id BAEE121F855B for <oauth@ietf.org>; Mon, 8 Oct 2012 05:12:50 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q98CCiLY012461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <oauth@ietf.org>; Mon, 8 Oct 2012 14:12:46 +0200
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q98CCg0c008894 for <oauth@ietf.org>; Mon, 8 Oct 2012 14:12:44 +0200
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Oct 2012 14:12:43 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDA54E.37D9B20D"
Date: Mon, 08 Oct 2012 15:12:42 +0300
Message-ID: <999913AB42CC9341B05A99BBF358718D01EF152F@FIESEXC035.nsn-intra.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-oauth-assertions-06
Thread-Index: Ac2lTjeC5hTo8lQZRfqm39VCg/m1yw==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: oauth@ietf.org
X-OriginalArrivalTime: 08 Oct 2012 12:12:43.0440 (UTC) FILETIME=[384FD300:01CDA54E]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 6031
X-purgate-ID: 151667::1349698367-00006DFC-0D5A0939/0-0/0-0
Subject: [OAUTH-WG] draft-ietf-oauth-assertions-06
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: Mon, 08 Oct 2012 12:12:51 -0000

Hi all, 

I took a look at version -06 of the assertions draft to see whether some
of the discussions had been reflected in this recent draft update. 

I was hoping that there is a bit more explanation of the use case that
motivates the work. Unfortunately, the update does not contain anything
along these lines. 
For example, the use cases could clarify the following aspects: 
*	Why we need these new client authentication mechanisms? This is
not necessarily a way in which SAML is used (at least not to my
knowledge). If I understood it correctly then the new client
authentication mechanism is only used between the client and the
authorization server but not with the resource server. Did I correctly
read the document?  
*	Then, there is the assertion usage for authorization grants.
There, one could argue that the use case is to interwork with existing
SAML infrastructure. The same argument does not apply for the JSON based
format since there is no transition need (IMHO at least).

Ciao
Hannes

PS: For the shepherd write-up I have to attach information about the
implementation and deployment experience. Is there anything I could
mention? Has this specification been part of the OpenID Connect interop
tests? If so, what specifically had been tested?