[OAUTH-WG] Wrapping access token and codes
Sergey Beryozkin <sberyozkin@gmail.com> Thu, 06 November 2014 12:11 UTC
Return-Path: <sberyozkin@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 5B28F1A1B79 for <oauth@ietfa.amsl.com>; Thu, 6 Nov 2014 04:11:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 AjNPK_5K66CP for <oauth@ietfa.amsl.com>; Thu, 6 Nov 2014 04:11:51 -0800 (PST)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACECC1A1B6C for <oauth@ietf.org>; Thu, 6 Nov 2014 04:11:50 -0800 (PST)
Received: by mail-wg0-f52.google.com with SMTP id b13so1002259wgh.25 for <oauth@ietf.org>; Thu, 06 Nov 2014 04:11:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MVP0vezDpQQPUpTDwAxkIUSz66WGGvc+BMxKwXHZVNw=; b=hfKys2VLtGsnzozX52Al7uojT+4p0T+nexe35zjFyxpbOnipW1fbQpkEfqV34nQZj8 j13VjBP7LDOAkTB0IWSn+lsX0yF9l3Kl4GkWfKG4KWDhWilytvpdswHkzRPQsJP3b9x/ nu94byUoBAdOb+mxs93ZJS+XrFrERISqmPND25vH81w+D5VrqY3/iEnFAWcD2U6GF4Oh q5T2YahPGN1dt+UUtS9wnltdaZaMThvN0Lt47b99ocx7oVTosJBem5CDZAvTjpQCi+hL abKcneEjZKQSnfNf2F2ciNtUrDMYiFBpHJIrHisVP8y7oOFw3Q1ueWjQlHVsa5HwybnY COLg==
X-Received: by 10.194.94.9 with SMTP id cy9mr4857867wjb.117.1415275909432; Thu, 06 Nov 2014 04:11:49 -0800 (PST)
Received: from [192.168.2.7] ([109.255.82.67]) by mx.google.com with ESMTPSA id fq1sm19285778wib.12.2014.11.06.04.11.47 for <oauth@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Nov 2014 04:11:48 -0800 (PST)
Message-ID: <545B6582.2030505@gmail.com>
Date: Thu, 06 Nov 2014 12:11:46 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <545760D7.3090900@surfnet.nl> <CAOyugYZnEz-uhA9M-1bx1m9cVf0UG8cH7aB+-skHiKmwh0Aikg@mail.gmail.com> <0FBFB9F2-508B-495B-9075-E664351C8D96@mitre.org>
In-Reply-To: <0FBFB9F2-508B-495B-9075-E664351C8D96@mitre.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/72F_jPqFaHfYJC5BPXjiRqt7GEI
Subject: [OAUTH-WG] Wrapping access token and codes
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: Thu, 06 Nov 2014 12:11:52 -0000
Hi Does it make sense to consider supporting an access token or code wrapping as part of the standard OAuth2 responses ? For example, if a client has registered its public key with AS then say the access token response would contain the regular {"access_token":"1234345"} except that "1234345" would actually be a JWE RSA-OAEP wrapped opaque token with a client's public key being used. Or a direct key encrypted token if the client and the server only share the client secret allocated to the client during the registration. The net result is that only the registered confidential client would be able to extract the actual opaque access token. The response would actually be {"access_token":"1234345", wrapped:true}. I definitely plan to use this approach as a simple mechanism for making a safer distribution of mac keys as part of access token responses; but IMHO it can be handy for minimizing the possibility of the access/refresh tokens or codes being intercepted... Sergey
- [OAUTH-WG] status of bearer token redelegation dr… Bas Zoetekouw
- Re: [OAUTH-WG] status of bearer token redelegatio… Phil Hunt
- Re: [OAUTH-WG] status of bearer token redelegatio… Richer, Justin P.
- Re: [OAUTH-WG] status of bearer token redelegatio… Bill Mills
- Re: [OAUTH-WG] status of bearer token redelegatio… Phil Hunt
- [OAUTH-WG] Code and token response thumbprints ? Sergey Beryozkin
- [OAUTH-WG] Wrapping access token and codes Sergey Beryozkin
- Re: [OAUTH-WG] Wrapping access token and codes Bill Mills
- Re: [OAUTH-WG] Wrapping access token and codes Sergey Beryozkin
- Re: [OAUTH-WG] Wrapping access token and codes Sergey Beryozkin
- Re: [OAUTH-WG] Wrapping access token and codes Sergey Beryozkin
- Re: [OAUTH-WG] Wrapping access token and codes John Bradley
- Re: [OAUTH-WG] Wrapping access token and codes Sergey Beryozkin
- Re: [OAUTH-WG] Wrapping access token and codes John Bradley
- Re: [OAUTH-WG] Wrapping access token and codes Sergey Beryozkin