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)
Subject: [OAUTH-WG] draft-ietf-oauth-assertions-09
Precedence: list

Hi guys,=20

Thanks for updating the assertion document and for incorporating the =
comments received on the mailing list.=20

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.=20

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).=20

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). =46rom 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.=20

Note that there are two documents that provide input to this problem =
space, namely:
http://tools.ietf.org/html/rfc6125
http://tools.ietf.org/html/draft-iab-identifier-comparison-07

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)?

Ciao
Hannes