Re: [OAUTH-WG] JSON Web Token (JWT) Profile

Nat Sakimura <sakimura@gmail.com> Tue, 11 March 2014 22:44 UTC

Return-Path: <sakimura@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4AB1A086D for <oauth@ietfa.amsl.com>; Tue, 11 Mar 2014 15:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBxhJ2SD59Qr for <oauth@ietfa.amsl.com>; Tue, 11 Mar 2014 15:44:40 -0700 (PDT)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 371C51A088D for <oauth@ietf.org>; Tue, 11 Mar 2014 15:44:39 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id hr13so6107475lab.17 for <oauth@ietf.org>; Tue, 11 Mar 2014 15:44:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4XjJaCOZ3eoeZxsrZmq8m1uUEKKnmIJKKnE7BGRiK7k=; b=wQNy0RSKbZYFPj5bS7YfvRmqqZd+god1Bwog778NFNctp8hkL4l4NGeG4iriwnw6nT xYgc3kng6m83bLq1hef/GTNeNqdGjCnA4ZRdMLJl83SH6oTJvJuEsu7ijGLsQQpIJRZv CUxib8VgBlXI+Yoew/P2gnk6AtDID20hABL2m5fBaveFiE/cl1I0owlDm1ZcJRIiM+nc u+W8hMvo0TENxXnUHU6OF5mMtizqb4eoBCWJjIm7gA+IPPOJ9Jb1a4tTKLuDc5xo0M3r 74z8Az5vCfZqn3h1YIXttXUZQwvhe9cS3MH6TsoGhjmyAeycI88Dbyd2tPFUDRlnZxkJ Wq4w==
MIME-Version: 1.0
X-Received: by 10.152.37.99 with SMTP id x3mr10345189laj.7.1394577872709; Tue, 11 Mar 2014 15:44:32 -0700 (PDT)
Received: by 10.112.145.226 with HTTP; Tue, 11 Mar 2014 15:44:32 -0700 (PDT)
In-Reply-To: <974419E4-29B9-4EC3-BCA3-91F577495EB8@oracle.com>
References: <3A1BC33F-1AE2-492F-BCE9-CCB9CF4C3C83@adobe.com> <531F1F72.8010805@gmx.net> <5275E1B4-64DD-48FF-A1A9-959C75EA5DE2@adobe.com> <531F234E.90609@gmx.net> <E8EF9394-73F1-413F-A064-C8543C52EAFD@adobe.com> <531F2632.2090204@gmx.net> <DF99C8A6-DD40-40DE-8F01-399C4CB6FFDC@ve7jtb.com> <F3EA5E97-BCC2-40E8-80FB-7170FD7D8BD4@adobe.com> <32BBE66D-883E-465C-91EB-CDB51333F08A@ve7jtb.com> <CC77962D-E341-4358-B320-E4C4D09FD17A@adobe.com> <974419E4-29B9-4EC3-BCA3-91F577495EB8@oracle.com>
Date: Wed, 12 Mar 2014 07:44:32 +0900
Message-ID: <CABzCy2AwyMa96t9onZ7xOrNsE99m8GFSnKv20QZpepdYfAdc-g@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: Phil Hunt <phil.hunt@oracle.com>
Content-Type: multipart/alternative; boundary=089e0158b87cb6eb2204f45c76ef
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/QPHnnU3_Rj7hu2DmEAet2z3EksM
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 11 Mar 2014 22:44:45 -0000

+1. Saving a few bytes in exchange to interoperability and security
possible downgrade does not seem to be a good strategy for me.

Nat


2014-03-12 7:04 GMT+09:00 Phil Hunt <phil.hunt@oracle.com>om>:

> I think that's the wrong perspective. If you intend the issuer to be the
> subject, you need to declare it.
>
> I wouldn't worry that it duplicates issuer. The fields have different
> meaning.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
> On 2014-03-11, at 1:43 PM, Antonio Sanso <asanso@adobe.com> wrote:
>
> > agree, but in some cases the subject is not only same as the issuer but
> simply it doesn't matter.
> >
> > In my example below all it matters is that the assertion signed by app1
> is valid....
> >
> > Continue in my probably not relevant "Google example" if I set the prn
> same as the issuer it would not work (keeping only the issuer without any
> subject gives me back a correct access token instead).
> >
> > Again this is not relevant spec wise. AFIU there is consensus in the
> working group to keep the subject mandatory. Would it make sense at least
> to add a little not that in some situations the issuer and the subject are
> the same?
> > This might clarify at least something to people that do wonder...
> >
> > regards
> >
> > antonio
> >
> > On Mar 11, 2014, at 8:12 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> >
> >> The specification is intended to allow the interoperation of standard
> libraries.
> >>
> >> In some cases the subject and the iss may be the same, however the
> underlying OAuth library may be a general one and always require a subject
> for security processing.
> >>
> >> It is possible that all libraries could have a special rule for when
> sub is not present and use the value of iss as sub.  This will save some
> bytes in the JWT but it is probably not worth creating an extra code path
> in libraries for the size optimization.
> >>
> >> I don't think your saying there is no subject just that it is redundant
> with iss in some cases.
> >>
> >> John B.
> >>
> >> On Mar 11, 2014, at 2:11 PM, Antonio Sanso <asanso@adobe.com> wrote:
> >>
> >>> Ok this is my use case:
> >>>
> >>> - I  am John Doe and going to AS to register my app named app1
> >>> - I then either upload my public key or download a private key
> >>> - at this point I am ready to build my assertion, the issuer claim is
> going to be app1 and should suffice.
> >>>
> >>> is the subject really needed in this use case?
> >>>
> >>> regards
> >>>
> >>> antonio
> >>>
> >>>
> >>> On Mar 11, 2014, at 4:25 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> >>>
> >>>> The missing scheme especially on JWT issued by google is something I
> understand they are working on but need to be careful about breaking
> existing code, so will possibly need new endpoints that are spec compliant.
> >>>>
> >>>> While in this google case the subject and the issuer happen to be the
> same they may well not be even in the self signed case.   In WG discussions
> being consistent in providing the subject was considered to be better for
> interoperability than optimizing for the case where sub or issuer could be
> dropped.
> >>>>
> >>>> John B.
> >>>>
> >>>> On Mar 11, 2014, at 12:05 PM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
> >>>>
> >>>>> Maintaining both information in the JWT is IMHO valuable since it
> gives
> >>>>> you some information about the security properties. Needless to say
> that
> >>>>> there is a substantial difference between a self-created JWT and a
> JWT
> >>>>> from a third party the relying party has some confidence in.
> >>>>>
> >>>>> Why Google has an old implementation and whether they are planning to
> >>>>> update their code remains to be seen.
> >>>>>
> >>>>> More importantly, however, is why you argue that the subject claim
> has
> >>>>> to be optional.
> >>>>>
> >>>>> Ciao
> >>>>> Hannes
> >>>>>
> >>>>> Ps: I also noticed in the examples that all URIs have their URI
> scheme
> >>>>> missing. While that might be OK I am not entirely sure...
> >>>>>
> >>>>> On 03/11/2014 04:08 PM, Antonio Sanso wrote:
> >>>>>>
> >>>>>> On Mar 11, 2014, at 3:53 PM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
> >>>>>>
> >>>>>>> Thanks for clarifying.
> >>>>>>>
> >>>>>>> I took a quick look at the Google API and it seems that in their
> use
> >>>>>>> case the client creates the JWT and consequently the subject and
> the
> >>>>>>> issue would actually be the same. I suspect that this is the
> reason why
> >>>>>>> they omitted the subject.
> >>>>>>
> >>>>>> agreed that is why in my mail I said the subject might overlap with
> the issuer.
> >>>>>> The subject in the google case is still called with its obsolete
> name (prn) and it is actually listed as 'additional claims' hence not
> mandatory.
> >>>>>>
> >>>>>> regards
> >>>>>>
> >>>>>> antonio
> >>>>>>
> >>>>>>>
> >>>>>>> Could you explain why you would like to omit the subject claim in
> the JWT?
> >>>>>>>
> >>>>>>> Ciao
> >>>>>>> Hannes
> >>>>>>>
> >>>>>>> PS: Your feedback on the  draft-ietf-oauth-jwt-bearer-07 spec is
> timely
> >>>>>>> since we are about to finish all three assertion specs.
> >>>>>>>
> >>>>>>>
> >>>>>>> On 03/11/2014 03:56 PM, Antonio Sanso wrote:
> >>>>>>>> hi Hannes,
> >>>>>>>>
> >>>>>>>> I am aware of the 2 documents,
> >>>>>>>>
> >>>>>>>> I might be wrong but
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 is also about
> Authorization Grant Processing (this is the part I do use in my
> implementation ) and not only Client Authentication Processing.
> >>>>>>>>
> >>>>>>>> Just my 0.02 $ but this seems to be a place where different
> implementer have the same issue :)
> >>>>>>>>
> >>>>>>>> regards
> >>>>>>>>
> >>>>>>>> antonio
> >>>>>>>>
> >>>>>>>> On Mar 11, 2014, at 3:36 PM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Manfred, Hi Antonio,
> >>>>>>>>>
> >>>>>>>>> Note that there are two documents that talk about the JWT and
> you guys
> >>>>>>>>> might be looking at the wrong document.
> >>>>>>>>>
> >>>>>>>>> The main JWT document (see
> >>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-18)
> defines
> >>>>>>>>> the subject claim as optional (see Section 4.1.2).
> >>>>>>>>>
> >>>>>>>>> The JWT bearer assertion document (see
> >>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07) does
> indeed
> >>>>>>>>> define it as mandatory but that's intentional since the purpose
> of the
> >>>>>>>>> spec is to authenticate the client (or the resource owner for an
> >>>>>>>>> authorization grant).
> >>>>>>>>>
> >>>>>>>>> The assertion documents are used for interworking with "legacy"
> identity
> >>>>>>>>> infrastructure (such as SAML federations).
> >>>>>>>>>
> >>>>>>>>> So, are you sure you are indeed looking at the right document?
> >>>>>>>>>
> >>>>>>>>> Ciao
> >>>>>>>>> Hannes
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 03/11/2014 03:13 PM, Antonio Sanso wrote:
> >>>>>>>>>> hi *,
> >>>>>>>>>>
> >>>>>>>>>> JSON Web Token (JWT) Profile section 3 [0] explicitely says
> >>>>>>>>>>
> >>>>>>>>>> The JWT MUST contain a "sub" (subject) claim
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Now IMHO there are cases where having the sub is either not
> needed or
> >>>>>>>>>> redundant (since it might overlap with the issuer).\
> >>>>>>>>>>
> >>>>>>>>>> As far as I can see "even Google" currently violates this spec
> [1] ( I
> >>>>>>>>>> know that this doesn't matter, just wanted to bring a real use
> case
> >>>>>>>>>> scenario).
> >>>>>>>>>>
> >>>>>>>>>> WDYT might the "sub" be optional in some situation?
> >>>>>>>>>>
> >>>>>>>>>> regards
> >>>>>>>>>>
> >>>>>>>>>> antonio
> >>>>>>>>>>
> >>>>>>>>>> [0]
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07#section-3
> >>>>>>>>>> [1]
> https://developers.google.com/accounts/docs/OAuth2ServiceAccount
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> OAuth mailing list
> >>>>>>>>>> OAuth@ietf.org
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>
> >>>
> >>
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en