[OAUTH-WG] Clarification about compatibility between rfc6750 and rfc7662

Maduranga Siriwardena <maduranga.siriwardena@gmail.com> Mon, 13 February 2017 21:59 UTC

Return-Path: <maduranga.siriwardena@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 2099D12940D for <oauth@ietfa.amsl.com>; Mon, 13 Feb 2017 13:59:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 rWmixHaSCoQ1 for <oauth@ietfa.amsl.com>; Mon, 13 Feb 2017 13:59:41 -0800 (PST)
Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 50FF712941D for <oauth@ietf.org>; Mon, 13 Feb 2017 13:59:41 -0800 (PST)
Received: by mail-it0-x22f.google.com with SMTP id c7so5413283itd.1 for <oauth@ietf.org>; Mon, 13 Feb 2017 13:59:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XFXF14+HwoQthHOldSxouXk3vtzAP1fHuMi2QrZm+fI=; b=a8FZjkH6ngkootFtGkkLaZ1WZentg7diDQDwmKnUQGiahLS2Y35o0vw7kVqfLbtlWI bxfCoMAGnb5GLDdg62bGCiaht1vnURF2gDJEpRB3sljKNfdAziTvRWfuow5zXu+ub6ty J6oGUSn/EnYDLYkJSf+p72ZTyJibIbAUzt6MWdKSd8aXdmpd6hyqec/9QAldRsllFpTB 0AU2/aY5nhjj6nXO96QeBNiKEV+5mOoZ5g149WBPjhnsudC1rlIVLJIZSzAQJ1wtARHh IVXn8EQ69ADVyHlAVx/z4/ZxjdTReg4uMQJCZVmF78qyY4gH2avuiEvViUvcu8FuPWr6 udWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XFXF14+HwoQthHOldSxouXk3vtzAP1fHuMi2QrZm+fI=; b=Cbus01Ix5/C3GGYLU5OJBwMjKipM4tAccrGpcn/8dSQuEeBNNBlec26N+lRH0ErHkA xd0IAtMljE9lI669pY8RI42vf8G/17ks19aVQvc1KHAUm5KpI0f5fSzjMkS9botujpti W4B85pbFFkPCtrwqIRyDmqDNul+pqxrPVKtcUkJYiwnAeTeajhi/EFKgzZxcbJCX4qEu 4AEtY7idmZpjY8cd3Wnn/mCOUm2+RpfZsONj+/39/AGmXqM29cfvoFp62dvddm0hhyrH MdBB3GDCnRBY1QWUNTZplS8pgQuou1BrX082QwJP/yzzDa/vfEoSQIH9nHCnXEsz1a/x 504Q==
X-Gm-Message-State: AMke39l0xxwpD4yiIcqCzGVFCmWiiTLNn8zcJ2iJipbUSofOEO0i+OYY5dr243DSEiQk08mZaNMeGxJKDqRvbg==
X-Received: by 10.107.133.223 with SMTP id p92mr26988999ioi.175.1487023180392; Mon, 13 Feb 2017 13:59:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.44.9 with HTTP; Mon, 13 Feb 2017 13:59:39 -0800 (PST)
From: Maduranga Siriwardena <maduranga.siriwardena@gmail.com>
Date: Mon, 13 Feb 2017 15:59:39 -0600
Message-ID: <CAFxuRFgWVC_bvLXimkoDurjT=b43xkCkmTYHk4sUv=dK50x7JQ@mail.gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a113ed57070d63a05487090b9
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/HHdGVSeuMkoGK8cmM0GtrMNItFk>
Subject: [OAUTH-WG] Clarification about compatibility between rfc6750 and rfc7662
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: Mon, 13 Feb 2017 21:59:43 -0000

Hi All,

While going through [1] and [2] I noticed a small contradiction between the
standards.

Section 3 (The WWW-Authenticate Response Header Field) of [1] provides a
example with WWW-Authenticate header description error description
with "The access token expired".

This error description should have been obtained from the response of
introspection request sent to the authorization server. But according the
section 2.2 (Introspection Response) of [2], it is not recommended to
include any additional information about an inactive token, including why
the token is inactive.

So how these scenarios match with each other?

[1] https://tools.ietf.org/html/rfc6750
[2] https://tools.ietf.org/html/rfc7662

Thanks,
-- 
Maduranga Siriwardena
Software Engineer
WSO2 Inc.