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

[Sergey Beryozkin <[e-mail]>]

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
>>>>>> <[e-mail]> 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
>>>>>>>>> <[e-mail]>
>>>>>>>>> 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
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>> --
>>>>>> Vladimir Dzhuvinov
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>
>>>>
>>>
>>
>


-- 
Sergey Beryozkin

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