[OAUTH-WG] Open Issue in draft-ietf-oauth-json-web-token-06

Brian Campbell <bcampbell@pingidentity.com> Sat, 29 December 2012 16:21 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 D135621F8442 for <oauth@ietfa.amsl.com>; Sat, 29 Dec 2012 08:21:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level:
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TVD_FLOAT_GENERAL=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzncWcosGKTt for <oauth@ietfa.amsl.com>; Sat, 29 Dec 2012 08:21:32 -0800 (PST)
Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2076B21F8440 for <oauth@ietf.org>; Sat, 29 Dec 2012 08:21:31 -0800 (PST)
Received: from mail-ia0-f197.google.com ([209.85.210.197]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKUN8YiyMKlFSB4gGhaXY+55EWIoOcerf9@postini.com; Sat, 29 Dec 2012 08:21:32 PST
Received: by mail-ia0-f197.google.com with SMTP id x26so33568052iak.8 for <oauth@ietf.org>; Sat, 29 Dec 2012 08:21:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=MpgxqldOujYCPJ9MJ1JN9telz6nhEt972PCqn0WOgFA=; b=Qxi53M3fD+MzNVk8JIilm04jSygglX/wzV4LYfBawsNyhRqnrhw2ygOUvDYuGpDFQE mSr8ROKeHyDC8Az/HcPciVmeb+fnk8Mi/MSMeFcq89gZhQ2QzPp7dMCxiP/7qDXBQj+4 q2KbUAauuykfO6A+CrTR3CcGTRYt9nw3QO7xIby6CwP0aJfsERn+CczZ7IJqW1J2NbXo eScbE5L+KV1E6Si+ggC+udgVKrz4nWJm24+7S+f2rKuUXEi19fyLhYWZdMozM4S+NrVw 0coVTk9jVNJ8qaiPxYDaZuLCR4JyzsRtIhrBw0jXsgWretuFKAt8JOGdwgbfQYuwIemo M0xw==
X-Received: by 10.50.1.169 with SMTP id 9mr26733727ign.101.1356798091423; Sat, 29 Dec 2012 08:21:31 -0800 (PST)
Received: by 10.50.1.169 with SMTP id 9mr26733724ign.101.1356798091250; Sat, 29 Dec 2012 08:21:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.17.134 with HTTP; Sat, 29 Dec 2012 08:21:01 -0800 (PST)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Sat, 29 Dec 2012 09:21:01 -0700
Message-ID: <CA+k3eCRcTGLmM9tXPBtXqX2rXDCmXxbzdNdf+BOiJ1Vy1U_-eg@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="e89a8f50351e42ca1804d2002ca6"
X-Gm-Message-State: ALoCoQmjoVslrKjDaZsKpQAEk9u1kEEKvACxR6Q6dCX31vjQjBduK4TrXmjHKYV+c/CLm25Jib4ibJOuqPG4Nxer7iGq5CMEWdrcIjkZiTipM+CZvck4dYuXQzTVtZRAhjkloAJJx970
Subject: [OAUTH-WG] Open Issue in draft-ietf-oauth-json-web-token-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: Sat, 29 Dec 2012 16:21:37 -0000

I noticed the open issue quoted below while perusing the diffs of some new
I-Ds today and it reminded me that I'd been meaning to comment on that very
issue.

      "Should all claims continue to be required to be understood by
      implementations using them when used in a security-related context
      or should a means of declaring that specific claims may be safely
      ignored if not understood should be defined?  This is related to
      the similar JOSE issue about whether all header fields must
      continue to be understood."

I've been reluctant to weigh in on the similar JOSE discussion for lack of
confidence about the right answer but I do have a lot of experience working
with identity and security type tokens that may be relevant to the issue in
the JWT context. In my experience many consumers of such tokens will
process the special attributes/claims that it knows about (i.e. aud, iss,
exp, etc.) and pass the remaining values to the application layer as (not
necessarily expected but potently useful) additional claims about the
subject. In fact, I recently wrote a JWT/JWS based OAuth access token
implementation that does exactly that (which a colleague of mine
successfully tested with a MS JWT implementation although I don't know what
claims he used).

Maybe that's not the best approach but I believe it's fairly common and, as
such, that must understand requirement in JWT is likely to be ignored by
many, which can result in a neglected spec requirement and/or potential
interoperability issues.

My 2 cents,
Brian