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

Sergey Beryozkin <sberyozkin@gmail.com> Tue, 19 January 2016 11:03 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 E32FB1B2AAC for <oauth@ietfa.amsl.com>; Tue, 19 Jan 2016 03:03:42 -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 jNQR2cqWjx4b for <oauth@ietfa.amsl.com>; Tue, 19 Jan 2016 03:03:36 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 E8A991B2AB4 for <oauth@ietf.org>; Tue, 19 Jan 2016 03:03:35 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id n5so105753156wmn.0 for <oauth@ietf.org>; Tue, 19 Jan 2016 03:03:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=dndxkkr6iwpIJAofjN9onz5g64mMlzctHW13i8QJbBk=; b=H3gBq7Uk0DpbMHuqEd9on1AzpIiZCcEiuNa8YjMjUjQItXgaQkwpWdeTZZPCymERpI 2aQuTKGU27dSeEi4j1d5WMnpQf53nUZkX2kD7bBvEVR2W8Db4MhkWhKDLkq36m0oKK2J Qrbmw+IfzmWUwbqwWHsV2XLozapuZw4IjV8+YKsD+rn8+vC2Sh6stouIxcK5DO0wBtzE qcExRplvYljbPrNpzRXoXm1l8zEZhMElsageGQX+k95pFq9ZIKMetbpyMnYcF/xzmuef c+4ISu754pzZS+bmIMQfb0/vzQ6rNsVc2ApUCZiXZVA1EaQX6gB0T8TIp3S3qhBYHNwV +caA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=dndxkkr6iwpIJAofjN9onz5g64mMlzctHW13i8QJbBk=; b=N4Z59yWV4AhUVRJs+TT4KdM7mLPljjJCSGLKZVhFOe99ixpDr9/9ORbPNGlojnDWxH 741PU66zh6pNnLJpsd6wO4gvEJNWH9XVOksd0amwsqnEg1YJ+TN2kcYi6QohkHtjd2V8 D4xLKZ8r1cJNqD7Y61oK7NekETMyTfoywMN59VdXvsbccu6662zCuch/itnpXcNT/1PC suQqTTBvNuTU1frxBVRJCqDr8FPoUNLj70Tma/IXyVOjIyosy+oAZMsqQNe+hnTVmZEP ExQfj3GvxUyzbi3DqoowXZCc6Ff2Cl9Im2qRjk8+GKh18XwEq5WdcVbD5c2zzBB4abIL nJ9Q==
X-Gm-Message-State: AG10YORRnYoNEU+Hn2wfmydQZXcfKkhfVb88uxbjUffHuhYxl71Dpps3I/3d5WNTRfm4xA==
X-Received: by 10.28.11.77 with SMTP id 74mr19388875wml.36.1453201414517; Tue, 19 Jan 2016 03:03:34 -0800 (PST)
Received: from [192.168.2.7] ([79.97.184.64]) by smtp.googlemail.com with ESMTPSA id gb9sm27984101wjb.26.2016.01.19.03.03.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jan 2016 03:03:33 -0800 (PST)
To: Justin Richer <jricher@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> <A1C1786C-BE13-4D0F-9541-BEAE4DB8F284@mit.edu> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <569E1804.8010803@gmail.com>
Date: Tue, 19 Jan 2016 11:03:32 +0000
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: <569D1631.4030705@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/mT30ILO6utmHLaSbbYFdLSrE5yU>
Cc: 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: Tue, 19 Jan 2016 11:03:43 -0000

Hi Justin

You mentioned a token expiry policy can be that this token will expire 
after a number of uses, in addition to a standard expiry time check.

Is there a standard mechanism to report to AS the token is being used 
(for the purpose of accessing RS resources) ?
I wonder if an actual token introspection request is sufficient to 
indicate to AS that the given token is being used right now to access RS 
- given that the actual client can now also introspect tokens without 
using them to invoke RS services.

is it up to AS Introspection endpoint to figure out the identity of the 
caller, example, if it knows it is RS then it will increase the usage 
count, if a client - won't ?

Thanks, Sergey
On 18/01/16 16:43, Sergey Beryozkin wrote:
> Hi Justin
>
> Sorry I did not copy to the list with my previous response...
>
> That sounds convincing, I was about to suggest that AS may opt not to
> report the expiry time simply because it is an optional property, but I
> guess that would be just an argument for the sake of the argument :-),
> as I guess in practice AS will report the expiry time of the tokens that
> actually expire...
>
> Many thanks, Sergey
>
>
>
> On 18/01/16 16:28, Justin Richer wrote:
>> If the AS doesn't include the expiration then that means that the RS
>> doesn't know anything about the token expiring or not. This can be
>> caused by:
>>
>>   1) The token never expiring from a timestamp (could still get revoked
>> or expire after a number of uses)
>>   2) The RS not being allowed to know if the token expires
>>
>> Either way, the RS doesn't know anything about the token expiring or not
>> and so should treat it as if it hasn't expired since that's all the AS
>> has told it. An RS trying to second guess the AS response here is going
>> to get into trouble.
>>
>> If the token expires "shortly" then there would be an expiration in the
>> response, if the RS is allowed to know that. There's no interoperability
>> issue here, still, and a special value wouldn't fix this.
>>
>>   -- Justin
>>
>> On 1/18/2016 11:10 AM, Sergey Beryozkin wrote:
>>> Hi
>>>
>>> If the only way for AS to indicate the token has expired is not to
>>> report this value, while the other AS does not report the specific
>>> expiry time simply because the expiry property is optional, then RS
>>> working with both of those 2 AS has no way to understand if a given
>>> token expires shortly or never expires at all.
>>>
>>> That is why I'm thinking having no special value indicating the token
>>> does not expire is an interoperability issue (the communication
>>> between RS and third-part AS servers)
>>>
>>> Thanks, Sergey
>>> On 18/01/16 15:55, Justin Richer wrote:
>>>> That's a problem for the RS to figure out in its logs system regardless
>>>> of whether you choose a "special" value for non-expiration or not. I
>>>> don't see how this changes interoperability.
>>>>
>>>>   -- Justin
>>>>
>>>> On 1/16/2016 4:50 PM, Sergey Beryozkin wrote:
>>>>> Hi Justin
>>>>> This is reasonable and it works with the introspection protocol
>>>>> because the text says 'active' means AS must've checked the token has
>>>>> not expired, but even so, it is in a 'conflict' with the
>>>>> interoperability concept.
>>>>> Consider a simple case where RS wants to log "Client uses access token
>>>>> with this ID, the token expiry time - this time/never" and some other
>>>>> RS wants to block the requests with the token which will expire in
>>>>> less then say 5/10 secs.
>>>>> When this RS works with one AS - this AS thinks it should not report
>>>>> the expiry time because it means omitting it indicates the token never
>>>>> expires. The other AS does not report it because: it either does not
>>>>> know how to rep a 'never expires' value. The next AS thinks it is not
>>>>> needed to be reported at all.
>>>>> What should RS do willing to do the above tasks around the expiry time
>>>>> do :-) ?
>>>>>
>>>>> Thanks, Sergey
>>>>>
>>>>> On 16/01/16 16:14, Justin Richer wrote:
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>