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
<vladi...@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
<sberyoz...@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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
