[OAUTH-WG] allowing offline access for native app & its backend server
nov matake <nov@matake.jp> Sat, 21 November 2015 12:55 UTC
Return-Path: <nov@matake.jp>
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 61F781A8A82 for <oauth@ietfa.amsl.com>; Sat, 21 Nov 2015 04:55:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 mhNO1FHC_fFm for <oauth@ietfa.amsl.com>; Sat, 21 Nov 2015 04:55:54 -0800 (PST)
Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 0E4321A8A7E for <oauth@ietf.org>; Sat, 21 Nov 2015 04:55:54 -0800 (PST)
Received: by pacdm15 with SMTP id dm15so144046559pac.3 for <oauth@ietf.org>; Sat, 21 Nov 2015 04:55:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matake-jp.20150623.gappssmtp.com; s=20150623; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=ga9HtTKkv/0DOFrHIO4IiBJlQI7p9nehuGW5Qz/TeMg=; b=BVzO6OYxPBARM+bvw+ZE/VaD1t0IrUa4L62GnY195beOyufVdwX/NxYfFUjPZrIegr RSZMzuvg/M2pSFvsy5UslQ43cnxs+lA+oXTAByDNWLw2xjxI+ASzPy/zUU5+ipxSg6DU leSLO6RTnmbmoQB4pDvp6+S28rlqEGHwy+EeLjm1tDOTZr3VM4D0ybI6mlPk3gHY9HXB B3zkRohWS6UwxlbGPGTZ5kQUFF/diFewIMLxxMbfQU+kEaQMrDvcYdXy4qJDeoMte/NC qfps1gC0QistU8PvU4yrf8ZmvwBgMOpb7/OHLML1h0T9bMqtvIJfwvW4Kd45euIUFOaQ WjsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=ga9HtTKkv/0DOFrHIO4IiBJlQI7p9nehuGW5Qz/TeMg=; b=Bxmrbvq0TRLk5iwdDejKrybh3Vq687RCZpvt/eaATZSNGDj4QbxOAv5vshFyvw4b3B 0HpdAlWcxrnkPrQXr4OFG+lGlnxG9+W0/dexzgad7jVlMRzU7+34fHJ+f23EJ9rXCEAK x8L2LCSCRRZhAB0vYzA/44r4/V059e6zQcSKSo8rfUSXjfA4d7gpcnuJuHOMKE5snjLJ iac2YLmAZpfAs0mFF0MUg+Zu8De6dyQpKV7ugagBYhWm923iWUWyYZF0vGEQ8AXPq440 jU6IY/mT1v0phLH84zyaQxLISz22ps8koaPoe+ukG3WsUFg9jp5SBuaVp/w8RJPvv3Ff ZWIA==
X-Gm-Message-State: ALoCoQkutvhV1uuKLm6jkGfH/Wk0rNlBtXsk2r3shTYVNHcUe3F3RtyjTq/KL9GIqOVbKT3H6eK9
X-Received: by 10.66.163.36 with SMTP id yf4mr25642185pab.145.1448110553687; Sat, 21 Nov 2015 04:55:53 -0800 (PST)
Received: from [192.168.1.16] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id o63sm3165785pfi.77.2015.11.21.04.55.52 for <oauth@ietf.org> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 21 Nov 2015 04:55:53 -0800 (PST)
From: nov matake <nov@matake.jp>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <FB1A52A9-AE47-4123-BFD1-36B58D61FB4A@matake.jp>
Date: Sat, 21 Nov 2015 21:55:49 +0900
To: oauth@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/e63Sw9dqHekj4HO9WkbWH8UX9yY>
Subject: [OAUTH-WG] allowing offline access for native app & its backend server
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: <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: Sat, 21 Nov 2015 12:55:55 -0000
Hi OAuthers, I’m thinking the way to issue refresh tokens both to native app and its backend server at same time. I have 2 ideas currently. 1. including 2 audience in a single authorization code, and allow using the code once per the audience. 2. issuing 2 code one for native app, one for backend server. 1st way means code can be used twice, so it can break RFC6749. 2nd way means defining another code (ex. code_for_backend etc.) Does someone has implementation supporting such use-case? — nov