Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection)

Justin Richer <jricher@mit.edu> Sat, 16 January 2016 16:14 UTC

Return-Path: <jricher@mit.edu>
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 A11311A8A51 for <oauth@ietfa.amsl.com>; Sat, 16 Jan 2016 08:14:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 egP-KeuZLyAQ for <oauth@ietfa.amsl.com>; Sat, 16 Jan 2016 08:14:27 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311D61A8A4F for <oauth@ietf.org>; Sat, 16 Jan 2016 08:14:26 -0800 (PST)
X-AuditID: 1209190c-f79c96d00000038e-a0-569a6c61e75c
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 91.80.00910.16C6A965; Sat, 16 Jan 2016 11:14:25 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u0GGEOMd014282; Sat, 16 Jan 2016 11:14:25 -0500
Received: from [107.16.90.107] ([107.16.90.107]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u0GGEMBZ012216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 Jan 2016 11:14:24 -0500
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9C540280-AD4D-4875-B74B-C139927DF1AA"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5.2
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <569A69A5.7020006@connect2id.com>
Date: Sat, 16 Jan 2016 11:14:22 -0500
Message-Id: <A1C1786C-BE13-4D0F-9541-BEAE4DB8F284@mit.edu>
References: <CA+k3eCSpWFwyvk=XHP4b_zxzu-zrMYsS-axF6csO90-ahmkueQ@mail.gmail.com> <BY2PR03MB4423033D5604E9E36B20C23F5CA0@BY2PR03MB442.namprd03.prod.outlook.com> <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <ade5692aa1afa2d9d79b8ac7a55bf150@lodderstedt.net> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEKsWRmVeSWpSXmKPExsUixG6nrpuYMyvM4OcbOYuTb1+xWbx794HR gclj/ucWVo8lS34yBTBFcdmkpOZklqUW6dslcGU0H/7NVvBItmLR3q0sDYw/JboYOTkkBEwk 7m5pZoOwxSQu3FsPZHNxCAksZpL4dHwulLORUeLwnu0sEM5aJonWdV9ZQFqEBVwlrj08yQxi 8wroSby6dZkVpIhZYAqjxMMdf4ESHEBzpSRm7BcAqWETUJWYvqaFCcTmBKpfNq0XbDULUHzV tiuMIOXMAuoS7SddIEZaSVx/+B7qiIPMEi/X/WEFSYgIGEg8fn2eGeJsWYndvx8xTWAUnIXk jFnIzgBJMAtoSyxb+BrKNpB42vmKFcKWl9j+dg5U3FJi8cwbLBC2rcStvgVMELadxKNpi1gX MHKsYpRNya3SzU3MzClOTdYtTk7My0st0jXUy80s0UtNKd3ECIoeTkmeHYxvDiodYhTgYFTi 4d3gODNMiDWxrLgy9xCjJAeTkijvd85ZYUJ8SfkplRmJxRnxRaU5qcWHGFWAdj3asPoCoxRL Xn5eqpIIb2skUB1vSmJlVWpRPkyZNAeLkjjvt8opYUIC6YklqdmpqQWpRTBZGQ4OJQnezdlA jYJFqempFWmZOSUIaSYOzkOMEhw8QMOVQWp4iwsSc4sz0yHypxgVpcR5nUESAiCJjNI8uF5Q 0ssWiMp+xSgO9JYw71aQKh5gwoTrfgU0mAloMG/AdJDBJYkIKakGRi3nFvd5emZx/G7H2jY2 3dLefeT7WYlIS9ZKpgOuzNsT7Gbd70wK3bDeaFHVou/frxlHGGanvXFgWzsrpFLv+PQ//3pk L8Qu/ZM+MSUsduM6CY+vP4Ryak9dkdM4GD3trEQpZ6etc+R5+76rr6dGCq36v5CzUr3M6iND 6kyXc+7mHMY/ZxafUWIpzkg01GIuKk4EAGW5WopVAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/WsnKZszCpljls5W5XTzmblimA-E>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection)
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, 16 Jan 2016 16:14:29 -0000

All the values in the token introspection response are optional, except for “active”. If you don’t have anything to say about a particular aspect of the token, or can’t say it to the software that’s asking, then you generally leave it out of the response.

 — Justin

> On Jan 16, 2016, at 11:02 AM, Vladimir Dzhuvinov <vladimir@connect2id.com>; wrote:
> 
> 
> 
> On 15/01/16 15:47, Sergey Beryozkin wrote:
>> Hi John
>> 
>> Thanks, looks like it was a last minute change because Introduction
>> does not explain why would clients want to use the introspection
>> endpoint to effectively 'unwrap' the opaque token representations.
>> 
>> I have another question. How to report the expiry time in cases when
>> the tokens do not expire ? I'm aware of some deployments where access
>> tokens are only manually deleted and otherwise would not expire.
>> 
>> Perhaps not reporting the expiry time is equivalent to the token never
>> expiring ? Or may be reporting 0 or -1 works ?
> 
> The core OAuth 2.0 spec seems to imply the former:
> 
> http://tools.ietf.org/html/rfc6749#section-5.1
> 
> Using a zero or negative integer may not be a good idea, as clients may
> just take the value as it is and add it to the current system time,
> concluding that the token has expired :)
> 
> 
> Cheers,
> 
> Vladimir
> 
> 
>> 
>> Thanks, Sergey
>> On 15/01/16 13:32, John Bradley wrote:
>>> Some people wanted the client to be able to use introspection.
>>> 
>>> The ability to pass a refresh token is a legacy of that.    A RS
>>> would never have a refresh token unless it is acting as a client.
>>> That is correct.
>>> 
>>> John B.
>>> 
>>>> On Jan 15, 2016, at 5:34 AM, Sergey Beryozkin <sberyozkin@gmail.com>;
>>>> wrote:
>>>> 
>>>> Hi All,
>>>> 
>>>> I'm reviewing RFC 7622 as we are going ahead with implementing it.
>>>> I have a question:
>>>> 
>>>> 1. Token Hint in the introspection request.
>>>> The spec mentions 'refresh_token' as one of the possible values. But
>>>> a protected resource does not see a refresh token (ever ?), it is
>>>> Access Token service which does.
>>>> When would a protected resource use a 'refresh_token' hint when
>>>> requesting an introspection response ?
>>>> 
>>>> Thanks, Sergey
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> --
> Vladimir Dzhuvinov
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth