Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-06

Brian Campbell <bcampbell@pingidentity.com> Mon, 04 November 2013 18:25 UTC

Return-Path: <bcampbell@pingidentity.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 4104821E8240 for <oauth@ietfa.amsl.com>; Mon, 4 Nov 2013 10:25:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.89
X-Spam-Level:
X-Spam-Status: No, score=-5.89 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
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 e9OAGfvg-77n for <oauth@ietfa.amsl.com>; Mon, 4 Nov 2013 10:25:28 -0800 (PST)
Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6CE21E817E for <oauth@ietf.org>; Mon, 4 Nov 2013 10:25:24 -0800 (PST)
Received: from mail-ie0-f170.google.com ([209.85.223.170]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKUnfmi3vmzmnXg5o5b4M8cGoHMyzqSyvR@postini.com; Mon, 04 Nov 2013 10:25:24 PST
Received: by mail-ie0-f170.google.com with SMTP id at1so13394569iec.29 for <oauth@ietf.org>; Mon, 04 Nov 2013 10:24:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ySBvfhYjB8uJYN6kwTSmIfyDI6lY6tmb+YE5lrpIICA=; b=e+fcGyTlJfXn+C6miAvAnNjPyUyu6XrUJyXiOkldK+U1Q8+QLoPlXfvjKH18ehQWOd l/TljL5jpgyFSQXUZ72pxfrmJsXvflXMW/kCek3ePe4OPVnHEGcrrIWjEmfEvMogz65y vAmAOT9i8cC85tc8x5gfu2Pn3BwMP1FpUw9LcjWEUi+bIPJmxVdRA6Fqr8OhbbQHY+eZ DhThZfF8EW5EfC3MOEcGSBQYel+9/2/e70J0ZC8Omh4TTT0KGX+rYd/LjAVNDifzXtb5 C/ggkyj70VUP0goGHZ3QG0WA1d86njL6DcPtedOCD0dJYD5NvIy6bDKQMlSaigSj/PrK bwzA==
X-Gm-Message-State: ALoCoQl1mMBGaAqx6UtHEXQ2U896q9CCecmZamI9uyt/qAfNzZfoVseRXHOm2fMlcEO5DFELej+kJONn6VlHEN+/b/2ehAYj8Z6XTR3bxrv9tzXrIt2lDah7W9sntbFAntp4ruzKt73zkZy3Z0FbnGXoDvtCsGw0HA==
X-Received: by 10.50.110.74 with SMTP id hy10mr12989360igb.0.1383589493553; Mon, 04 Nov 2013 10:24:53 -0800 (PST)
X-Received: by 10.50.110.74 with SMTP id hy10mr12989355igb.0.1383589493472; Mon, 04 Nov 2013 10:24:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 10:24:23 -0800 (PST)
In-Reply-To: <52741472.8020405@gmx.net>
References: <52741472.8020405@gmx.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 4 Nov 2013 10:24:23 -0800
Message-ID: <CA+k3eCTD6jOUJT54Qf14-EQf883+RGY8VpZPjx6tVo39f_B2qg@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-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, 04 Nov 2013 18:25:33 -0000

Thanks for the review and feedback Hannes.

There are a number of different items here and I think it'll be more
productive to discuss them individually, so I'll partition this into a
different threads for each general topic. I plan to do the same thing
for your review of draft-ietf-oauth-saml2-bearer-17 from
http://www.ietf.org/mail-archive/web/oauth/current/msg12230.html

On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:
> Hi Mike, Hi all,
>
> I read through draft-ietf-oauth-jwt-bearer-06 in an attempt to find out
> whether I would be able to produce an interoperable implementation from this
> document.
>
> A few minor things came to my mind:
>
> Section 3:
>
> You write:
> "
>    1.   The JWT MUST contain an "iss" (issuer) claim that contains a
>         unique identifier for the entity that issued the JWT.  Issuer
>         values SHOULD be compared using the Simple String Comparison
>         method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless
>         otherwise specified by the application.
> "
>
> What is not stated here is what are the two values that are compared against
> each other. One value is the issuer claim from the JWT and the other value
> is the, I guess, an entry from a whitelist of trusted issuers.
>
>
>
> You write:
> "
>    2.   The JWT MUST contain a "sub" (subject) claim identifying the
>         subject of the transaction.  The subject MAY identify the
>         resource owner for whom the access token is being requested.
>
>         A.  When using a JWT as an authorization grant, the subject
>             SHOULD identify an authorized accessor for whom the access
>             token is being requested (typically the resource owner, or
>             an authorized delegate).
>
>         B.  For client authentication, the subject MUST be the
>             "client_id" of the OAuth client.
> "
>
> Should this rather read:
>
> "
>    2.   The JWT MUST contain a "sub" (subject) claim identifing the
>         principal that is the subject of the JWT. Two cases need to
>         be differentiated:
>
>         A.  For the authorization grant, the subject
>             SHOULD identify an authorized accessor for whom the access
>             token is being requested (typically the resource owner, or
>             an authorized delegate).
>
>         B.  For client authentication, the subject MUST be the
>             "client_id" of the OAuth client.
> "
>
> Why isn't the SHOULD under (A) actually a MUST? Then, the current text in A
> is so fuzzy that it actually doesn't allow someone to create a test case to
> test whether an implementation is interoperable or not. With B the situation
> is different. Is there something else we can say for A?
>
> You write:
>
> "
>  3.   The JWT MUST contain an "aud" (audience) claim containing a
>         value that identifies the authorization server as an intended
>         audience.  The token endpoint URL of the authorization server
>         MAY be used as a value for an "aud" element to identify the
>         authorization server as an intended audience of the JWT.  JWTs
>         that do not identify the authorization server as an intended
>         audience MUST be rejected.  Audience values SHOULD be compared
>         using the Simple String Comparison method defined in Section
>         6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the
>         application.
> "
>
> If the endpoint URL of the AS is not used then what else? Wouldn't it be
> useful to say "The token endpoint URL of the authorization server
>         MUST be used as a value for an "aud" element to identify the
>         authorization server as an intended audience of the JWT."?
>
> Then, I have a suggestion for re-phrasing this sentence from :
> "
>         Audience values SHOULD be compared
>         using the Simple String Comparison method defined in Section
>         6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the
>         application.
> "
> to:
>
> "
> In the absence of an application profile standard specifying
> otherwise, a compliant JWT Bearer application MUST compare the audience
> values using the Simple String Comparison method defined in Section
>         6.2.1 of RFC 3986 [RFC3986].
> "
>
> The same can actually be applied to the issuer claim as well.
> Given that the JWT had been updated to align it with the JOSE work I suspect
> that this document also requires an update.
>
>
> Section 5 about "Interoperability Considerations" says:
>
> "
> Specific items that require agreement are as
>    follows: values for the issuer and audience identifiers, the location
>    of the token endpoint, and the key used to apply and verify the
>    digital signature or keyed message digest over the JWT.
> "
>
> I believe that this list is not correct.
>
> What is needed is:
>
>  * At the authorization server there needs to be a whitelist of trusted
> issuers. For a succesful protocol run the JWT needs to be created by an
> issuer who is in the whitelist.
>
>  * Along with the entry in the whitelist of trusted issuers needs to be a
> key.
>
> There is no new endpoint URL defined by this document. As such, I wouldn't
> mention those.
>
> I also do not think that the audience identifier needs to be agreed if you
> define it as the token endpoint URL of the authorization server (as I
> suggested above).
>
> Ciao
> Hannes
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth