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