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

Sergey Beryozkin <sberyozkin@gmail.com> Mon, 18 January 2016 16:43 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 59B0F1B399C for <oauth@ietfa.amsl.com>; Mon, 18 Jan 2016 08:43:35 -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 enua5CdDq7Nu for <oauth@ietfa.amsl.com>; Mon, 18 Jan 2016 08:43:33 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 8AC931B3999 for <oauth@ietf.org>; Mon, 18 Jan 2016 08:43:32 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id r129so58610816wmr.0 for <oauth@ietf.org>; Mon, 18 Jan 2016 08:43:32 -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=VG5dO+aNNXx9LxNbufqmEQnv5wHR27P2EmQdHN2rDeE=; b=xfu6kv6/a91XqDlTQMfMPeLbwAYEb/+//7VaqY5ZajjWaiRoDxFaksEuXbg2WHpzoo pRPIT6z9Qr/8mY0bviIwOJYBzXegozY9Q4G7P0+NN7p8SrlUWAXH1d3owSj/v97FwlpY DsVepYgc6dIr7AG5UQ9C0OqM6cnDASJAkL2ObxEoOgF7t5TVW+nJmBj1HvLs7pHalrUo SxqTsF+/uJvRolfWq97YPVnflDnKOjCaEIzNGKG6aEx1/1xiD/djq6u9FWfYUSLBclXV C3wwHhyxNTLC11kYgxpPi1nnBiFHeKQNMx+hkbpn7ACb2RiPrBnHYt+yoIha+aNiX6tB xlPQ==
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=VG5dO+aNNXx9LxNbufqmEQnv5wHR27P2EmQdHN2rDeE=; b=EfsMqRjMmJEGIucsG1Qm4PQ9ua1XNplyvtNA8dxf8xOsJ2a0rhoJXfJHXkGeIkkgRL slVJscXZn1FzyAbgWz/RbleEE//kyVK61V3ipDdYQ4/KuIWoRib2iqA7M84mUnrLUzKk 602ZhT1Ze1OZR5VX/WKwoPZ0YPpquMmExg98tWya+ahxlo5V0metdqAxhySTEgbfLF8U HVxRref4C09qj52R1bGTQzh2SUzMUXc5kBWxn4qkA1RmJ2TlI/C5TwqnJLrhg1kCRvf5 odxzHds6zfCutKsiHVeJ3vzKNoS1eHuY4WcpTrHXN6UfVkz4X7FB2vWPcakh6kkM836/ 8mfw==
X-Gm-Message-State: AG10YOTqtDKgRU8zsAdwIVQD9noODOD6ZCXX+zGv/BfWzaEukZt6A5RiLbn0T8sSYuZyeQ==
X-Received: by 10.28.45.207 with SMTP id t198mr15090590wmt.32.1453135411156; Mon, 18 Jan 2016 08:43:31 -0800 (PST)
Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id xx3sm24608679wjc.32.2016.01.18.08.43.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 08:43:29 -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>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <569D1631.4030705@gmail.com>
Date: Mon, 18 Jan 2016 16:43:29 +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: <569D1297.2000805@mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/WDUSFVLfhFcUBO_rS8Slyh-Vz-0>
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: Mon, 18 Jan 2016 16:43:35 -0000

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
>>>>>
>>>>
>>>>
>>>
>>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/