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

Vladimir Dzhuvinov <vladimir@connect2id.com> Sat, 16 January 2016 16:02 UTC

Return-Path: <vladimir@connect2id.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 C760C1A8A45 for <oauth@ietfa.amsl.com>; Sat, 16 Jan 2016 08:02:48 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 yCJ8Onhx8JMj for <oauth@ietfa.amsl.com>; Sat, 16 Jan 2016 08:02:47 -0800 (PST)
Received: from p3plsmtpa06-05.prod.phx3.secureserver.net (p3plsmtpa06-05.prod.phx3.secureserver.net [173.201.192.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8DA1A8A42 for <oauth@ietf.org>; Sat, 16 Jan 2016 08:02:47 -0800 (PST)
Received: from [192.168.0.112] ([77.77.164.50]) by p3plsmtpa06-05.prod.phx3.secureserver.net with id 6g2l1s00B15ZTut01g2mcD; Sat, 16 Jan 2016 09:02:47 -0700
To: oauth@ietf.org
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>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <569A69A5.7020006@connect2id.com>
Date: Sat, 16 Jan 2016 18:02:45 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <5698F885.3030009@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms090207040008090505070309"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/JeHc2qhJ929V_IzeMne4w5N_0To>
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:02:48 -0000


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