[OAUTH-WG] JWS JWT Access Tokens and resource audiences

Sergey Beryozkin <sberyozkin@gmail.com> Thu, 11 August 2016 22:16 UTC

Return-Path: <sberyozkin@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 A862B12D1DD for <oauth@ietfa.amsl.com>; Thu, 11 Aug 2016 15:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 bPcUK-H6Ux7J for <oauth@ietfa.amsl.com>; Thu, 11 Aug 2016 15:16:21 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4BF712D0AA for <oauth@ietf.org>; Thu, 11 Aug 2016 15:16:20 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id q128so2379606wma.1 for <oauth@ietf.org>; Thu, 11 Aug 2016 15:16:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=TPzN+3mCUQNMgpf5ZbmmDsuGS5Tp5BlTomZUEZYdwMI=; b=Cd+P2EoX96BZ6oG3kKWFrvSLxAXIRXi6t4JgTHSECH0V4NjYEGGkdf2wrscG9lhxJL WgLIm9WETlCJY3BSuzV2DbT8qBBxsjU05G+aBxAEiqNH1vitOvfwkdl7MsByNEwH57kd 4+z+K75nP8pcL5tgPzNsh8pW4jFYBUCbRVBiLSwnAj4CcOQkIXJ5vYFuVthNwE4j3R2E Z5NxCcmc/E6/xS9eQdtptkvQSLF/hNIfTBh9vhEJ6Q9+IWwKHaXUhUmOzBIAIOarfwhA mR8v6Gll/65uTEfmrAIb7DQl2sWw3FhlhZYfs5Nv1qNwAGNM89hRqNb9xQ2IYdK2X53h Hf4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=TPzN+3mCUQNMgpf5ZbmmDsuGS5Tp5BlTomZUEZYdwMI=; b=E33foLIx2YloByvRDREXqUIUXcDs8F1VCAyrPtOxN/M8OxDo8fT4MX6mQCf9yBkkgI ftlMsa+GpLR1W9bv51eE6IZ+TNMHHChr1/8PgtmaZlpWhfChzIz1liC6TnJNrEWyYY0y gmzptb62nshg2HbVmbWp/NpbQtyWJ0m1uVoR6zy85hlX7wVJ5Soj6mIWW6irv4FRRx/T UmQ1/T+vV6MeumZuVDQ53Uc87wcB/4LQBTGQjXMviUfxh6qEM3dSqjfDGCVhOlxLOiGg GSwWPxKDSZhobc1JWozz7qoVRa21+KZ8sgtNfJhio4+oSQQtGWLsGaiu6jcFyyPPh1gL B6lg==
X-Gm-Message-State: AEkoouufrhkwabpfwzuZMYp1DCeLLgubUnlQzF8ue2GsyAcJh8eGduUEolUCslJ359bX6A==
X-Received: by 10.194.123.228 with SMTP id md4mr11470778wjb.91.1470953779197; Thu, 11 Aug 2016 15:16:19 -0700 (PDT)
Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id va3sm4624536wjb.18.2016.08.11.15.16.17 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Aug 2016 15:16:18 -0700 (PDT)
To: "oauth@ietf.org" <oauth@ietf.org>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <8472e581-1382-a364-a232-07ce6eeb0115@gmail.com>
Date: Thu, 11 Aug 2016 23:16:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5k3yQg-h-6T7odSBX3rMt2Xt6Y0>
Subject: [OAUTH-WG] JWS JWT Access Tokens and resource audiences
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 11 Aug 2016 22:16:22 -0000

Hi All

Awhile back I was asking why would self-contained JWS JWT access tokens 
would be used (as opposed to JWE JWTs), my concern was that anyone with 
a JWT library can read this token's content - but as I was explained 
that should not be a problem if such a JWS JWT token contains 
non-sensitive information. Besides, in some cases, it gives RS an option 
to validate this JWS JWT locally, without having to make a remote 
validation call.

So I've started experimenting and the immediate question I have is this 
one: which claim should one use to represent a resource server audience 
to get the most inter-operable RS level validation logic ?

For example, a given RS may talk to different 3rd party authorization 
servers, say AS1 (vendor1) and AS2 (vendor2), and either AS1 or AS2 JWS 
JWT tokens that this RS validates locally should ideally use the same 
claim to represent a resource audience. RS validation logic is written 
independently (without using AS1 or AS2 aware validation libraries).

We do expect such requirements coming in our deployments. AS1 & 
independent validation logic is already in use. Just a matter of time 
before AS2 is introduced.

So JWT has a standard 'aud' claim - but I believe this should be a 
'clientId' of the client a token is issued to, similarly to the way the 
'aud' is treated in IdToken.

So I've prototyped the code where JWT has these claims:

"aud" = clientId
"resource" = 'http://myResourceServer'

where 'resource' is borrowed from OAuth2 Resource Indicators draft and 
represent a specific RS target address, the resource server audience.

Am I on the right path ? How would others do it when facing a task of 
including a resource audience in a self-contained JWS JWT access token ?

Many thanks, Sergey