[OAUTH-WG] Review of the assertion drafts

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 29 May 2013 19:36 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 670C621F9817 for <oauth@ietfa.amsl.com>; Wed, 29 May 2013 12:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.25
X-Spam-Level:
X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 zGcBY+3aT6vW for <oauth@ietfa.amsl.com>; Wed, 29 May 2013 12:35:56 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0B83521F9816 for <oauth@ietf.org>; Wed, 29 May 2013 12:35:56 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M5rJ1-1UX5xj2z3x-00xuHN for <oauth@ietf.org>; Wed, 29 May 2013 21:35:54 +0200
Received: (qmail invoked by alias); 29 May 2013 19:35:54 -0000
Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.219.140] by mail.gmx.net (mp027) with SMTP; 29 May 2013 21:35:54 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/jXe8+weTjzT70GWTi/1M6rEgWf6vxCYpdVLyFyh fk0TgVmHLq+ACK
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 29 May 2013 22:35:53 +0300
Message-Id: <5A436946-C417-402E-B1ED-327A035363BA@gmx.net>
To: "oauth@ietf.org WG" <oauth@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1085)
X-Pgp-Agent: GPGMail 1.4.1
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Review of the assertion drafts
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: Wed, 29 May 2013 19:36:01 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi assertion document authors, 
Hi all, 

I took a look at the assertion framework draft (draft-ietf-oauth-assertions-11) and the SAML assertion profile document (draft-ietf-oauth-saml2-bearer-16.txt). 

In general, I have to say that they are moving in the right direction. I see progress. 

In the assertion draft I particularly liked the improved clarity about what has to be agreed out-of-band (which relates to interoperability): 
"
           Specific	
 	   items that require agreement are as follows: values for the issuer	
 	   and audience identifiers, supported assertion and client	
 	   authentication types, the location of the token endpoint, and the key	
 	   used to apply and verify the digital signature or keyed message	
 	   digest over the assertion.
"

There are also various places where the number of options have been reduced. Various clarifications in the text seem useful (e.g., the client id to assertion mapping) although I have not checked them in detail. 

I was hoping for more constraints (so that fewer aspects need to be configured out-of-band) but I guess you guys are not willing to sacrifice flexibility. I am sure you have noticed that there are a lot of things that need to be agreed out-of-band. I hope you feel confident that those who deploy the specification are willing to take these steps. But at least the spec is not silent about them and provides the necessary information to the reader. 

I also recognize improvements regarding the SAML assertion document. While the use case description is still missing (that would give a bit more background about what the deployment environment is) there is now a better example available. The example illustrates an assertion grant; do you think it would be useful to also show an example for a client authentication with the SAML assertion? 

I am planning to talk to Barry to see what he thinks about the updated document and in the meanwhile I can read into the detailed changes.  

Ciao
Hannes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJRpliZAAoJEGhJURNOOiAtEI0H/3iAd1FyAwPI+EsLri5rjE+q
Ic7NGknlQSG/wl9w2xGuq32OuPo/PihLTuEpqIsxwoia5O5wKSX0X42wxMR9dLVk
H9bSy5SFj8AoI66KPGeapBB6Lmuzm/7dWknJW9fv1BWIixEkAppY+M08aAYOHW6d
OcOy+fEP2x9sx/CE1l6goaXi2hR7M9witrTiGr3Yf/BYkE9ouaAnnZYP/UMrP78N
L2clRCykdzLMjjSzugNqnD6KJguHoH4JTnlDT3NS6jL+KwxgXUB5dd8OECuYzlbl
1Z3ORCzFrM7ODytH7HC7SCgsOkIyjb1/xFaTElkVFKkVmvR1rnBz/6+ydgJ+pVk=
=vLB5
-----END PGP SIGNATURE-----