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

Stephen Farrell <> Fri, 11 January 2013 11:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A57D21F88EA for <>; Fri, 11 Jan 2013 03:31:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.449
X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_EMAIL=2.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VJiBvQ1YyuF2 for <>; Fri, 11 Jan 2013 03:31:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EA87121F88FB for <>; Fri, 11 Jan 2013 03:31:24 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24E9FBE56; Fri, 11 Jan 2013 11:31:02 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UwzCnXUOyYcC; Fri, 11 Jan 2013 11:30:56 +0000 (GMT)
Received: from [IPv6:2001:770:10:203:fc59:2c8:a489:8ef3] (unknown [IPv6:2001:770:10:203:fc59:2c8:a489:8ef3]) by (Postfix) with ESMTPSA id 5EC44BE25; Fri, 11 Jan 2013 11:30:56 +0000 (GMT)
Message-ID: <>
Date: Fri, 11 Jan 2013 11:30:56 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Hannes Tschofenig <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: " WG" <>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Jan 2013 11:31:26 -0000


Since we thought we were done with it, I put this document
on the IESG telechat agenda for Jan 24. Hannes' question
however looks like its a real one that needs an answer.

I'd appreciate it if the WG could figure out if there's any
change needed and either make that change in the next week,
or else tell me to take the draft off the telechat agenda
for now.

If discussion doesn't happen, or happens but doesn't reach
a conclusion, then I'll take the draft off the agenda in a
week's time and we can sort out if any changes are needed

The reason why now+1-week matters, is that that's when
IESG members tend to do their reviews and having 'em all
review a moving target isn't a good plan.


On 01/11/2013 08:18 AM, Hannes Tschofenig wrote:
> 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
> "
>    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, and in a more generic form also in the JWT (Section 4.1.3 of; "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 "*") or only an equality match? Would "" be the same as "" if they resolve to the same IP address(es)?
> Ciao
> Hannes
> _______________________________________________
> OAuth mailing list