Return-Path: <pmhsfelix@gmail.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 D485F21F853E for <oauth@ietfa.amsl.com>;
 Sun,  3 Feb 2013 09:51:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5
 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 ospa0JkuSfpj for
 <oauth@ietfa.amsl.com>; Sun,  3 Feb 2013 09:51:23 -0800 (PST)
Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com
 [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6A621F8539 for
 <oauth@ietf.org>; Sun,  3 Feb 2013 09:51:23 -0800 (PST)
Received: by mail-qa0-f49.google.com with SMTP id o13so993333qaj.1 for
 <oauth@ietf.org>; Sun, 03 Feb 2013 09:51:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:x-received:date:message-id:subject:from:to
 :content-type; bh=Em4dHXmmp16VUVvScOqvC2n+Imi9qht4imBDuxCk7E0=;
 b=Kuuo7M8uK9qN0CqV0FBtn65IyUsj+iLhuS89/g3MDpW/2vtB2NMcCt7M7nPHVThTCE
 3pXWLW6Tn3v4s32js6e5Rv7P9P0S+cRPQe7HQYl6ORh9qJtw+OlD36VLXfF4uegVk+5I
 qX6GWNAK4YgrHvzQelyDCF2UNVtgIftsHBZL2JKRz7XSi3GqY/rlQhL2/evxCpUBujCK
 qxXW2ivQJDvmiHezo3NHUymMK/l9UXWlsJdFHJovgYjnFy+RQ9V5VbJI7E1Kn3hQKFau
 TqUBb33AWJoXgyLVdfwbfmONB/1K3o4vp4nBzWcTtrj3oqN89Wmm8dhCYG5HFbUK4Bhn OXDQ==
MIME-Version: 1.0
X-Received: by 10.224.216.9 with SMTP id hg9mr16963958qab.44.1359913882727;
 Sun, 03 Feb 2013 09:51:22 -0800 (PST)
Received: by 10.49.61.102 with HTTP; Sun, 3 Feb 2013 09:51:22 -0800 (PST)
Date: Sun, 3 Feb 2013 17:51:22 +0000
Message-ID: <CAD+AFDsv59F5ksa73Gg=mmj8X8-5iC3GRExzd+9sRL+yO2_aiA@mail.gmail.com>
From: Pedro Felix <pmhsfelix@gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=20cf300512fee7b46d04d4d59fce
Subject: [OAUTH-WG] Best practices to use JWT tokens as access tokens
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: Sun, 03 Feb 2013 17:51:23 -0000

--20cf300512fee7b46d04d4d59fce
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I'm considering using JWT tokens as access tokens in a scenario where the
AS is rather decoupled from the RS. Namely, the same AS with manage the
authorization for multiple RSs.
Using JWT for short-lived non-revocable access tokens means that the RS is
able to obtain all the authorization grant information without contacting
the AS or using a shared store.

My plan is to encode in the JWT token all the relevant authorization grant
information, namely:

1) The authorizing user (RO) claims
2) The authorized client information - at least its client_id, but there
can be more client info available
3) The authorized scopes

Are there any guidelines on how to represent this information as claims of
a JWT token? Namely, how can we group this info such that there are no
collisions between user claims and client claims?

Thanks
Pedro

--20cf300512fee7b46d04d4d59fce
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div style>I&#39;m considering using JWT=
 tokens as access tokens in a scenario where the AS is rather decoupled fro=
m the RS. Namely, the same AS with manage the authorization for multiple RS=
s.</div>
<div style>Using JWT for short-lived non-revocable access tokens means that=
 the RS is able to obtain all the authorization grant information without c=
ontacting the AS or using a shared store.</div><div style><br></div><div st=
yle>
My plan is to encode in the JWT token all the relevant authorization grant =
information, namely:</div><div style><br></div><div style>1) The authorizin=
g user (RO) claims</div><div style>2) The authorized client information - a=
t least its client_id, but there can be more client info available</div>
<div style>3) The authorized scopes</div><div style><br></div><div style>Ar=
e there any guidelines on how to represent this information as claims of a =
JWT token? Namely, how can we group this info such that there are no collis=
ions between user claims and client claims?</div>
<div style><br></div><div style>Thanks</div><div style>Pedro</div><div styl=
e><br></div><div style><br></div></div>

--20cf300512fee7b46d04d4d59fce--