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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 11 January 2013 08:18 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3802521F8A50 for <oauth@ietfa.amsl.com>; Fri, 11 Jan 2013 00:18:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.528
X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CJfDs-wUf9wR for <oauth@ietfa.amsl.com>; Fri, 11 Jan 2013 00:18:48 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net []) by ietfa.amsl.com (Postfix) with ESMTP id 4F66021F8A08 for <oauth@ietf.org>; Fri, 11 Jan 2013 00:18:48 -0800 (PST)
Received: from mailout-de.gmx.net ([]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MJHgy-1Tqofd1lHu-002sf4 for <oauth@ietf.org>; Fri, 11 Jan 2013 09:18:47 +0100
Received: (qmail invoked by alias); 11 Jan 2013 08:18:47 -0000
Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO []) [] by mail.gmx.net (mp017) with SMTP; 11 Jan 2013 09:18:47 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19bzFk5MkFbjNHHUSCLFSB7ptLmAEU46AEQNfds5F VU9l2F+xxC8VvZ
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 11 Jan 2013 10:18:46 +0200
Message-Id: <A1DF5DE7-CC32-48CE-A33E-81BC2968DF14@gmx.net>
To: "oauth@ietf.org WG" <oauth@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] draft-ietf-oauth-assertions-09
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, 11 Jan 2013 08:18:49 -0000

Hi guys, 

Thanks for updating the assertion document and for incorporating the comments received on the mailing list. 

There is only one issue that caught my attention. You changed the description of the audience element to the following text (in version -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09):
   Audience  A value that identifies the parties intended to process the
      assertion.  An audience value MAY be the URL of the Token Endpoint
      as defined in Section 3.2 of OAuth 2.0 [RFC6749].

Since the value in the audience field is used to by the authorization server in a comparison operation (see Section 5.2) I believe the current text will lead to interoperability problems. Not only is the comparision operation unspecified but even the value that is contained in the field is left open. The RFC 2119 MAY does not really give a lot of hints of what should be put in there. 

Without having a clear description of what identifier is contained in this field and how the comparison works it is either possible that a legitimate client is rejected by the authorization server (which is annoying) or an assertion with an incorrect assertion is accepted (which is a security problem). 

Btw, the same issue can also be seen in http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 of http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" claim). From the description in the JWT document I was not quite sure whether the ability to carry an array of case sensitive strings for that field is also allowed in any of the assertion documents. 

Note that there are two documents that provide input to this problem space, namely:

So, I would suggest to decide what type of identifier goes into this field and then to point to a document that illustrates how the comparison operation would look like. Possible identifiers are domain names, IP addresses, URIs, etc. Just as an example from RFC 6125 would you allow a wildcard match (like "*.example.com") or only an equality match? Would "www.example.com" be the same as "example.com" if they resolve to the same IP address(es)?