Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed;
 boundary="Apple-Mail=_9C540280-AD4D-4875-B74B-C139927DF1AA";
 protocol="application/pgp-signature"; micalg=pgp-sha256
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <569A69A5.7020006@connect2id.com>
Date: Sat, 16 Jan 2016 11:14:22 -0500
Message-Id: <A1C1786C-BE13-4D0F-9541-BEAE4DB8F284@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>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/WsnKZszCpljls5W5XTzmblimA-E>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection)
Precedence: list


--Apple-Mail=_9C540280-AD4D-4875-B74B-C139927DF1AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

All the values in the token introspection response are optional, except =
for =93active=94. If you don=92t have anything to say about a particular =
aspect of the token, or can=92t say it to the software that=92s asking, =
then you generally leave it out of the response.

 =97 Justin

> On Jan 16, 2016, at 11:02 AM, Vladimir Dzhuvinov =
<vladimir@connect2id.com> wrote:
>=20
>=20
>=20
> On 15/01/16 15:47, Sergey Beryozkin wrote:
>> Hi John
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Perhaps not reporting the expiry time is equivalent to the token =
never
>> expiring ? Or may be reporting 0 or -1 works ?
>=20
> The core OAuth 2.0 spec seems to imply the former:
>=20
> http://tools.ietf.org/html/rfc6749#section-5.1
>=20
> 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 :)
>=20
>=20
> Cheers,
>=20
> Vladimir
>=20
>=20
>>=20
>> Thanks, Sergey
>> On 15/01/16 13:32, John Bradley wrote:
>>> Some people wanted the client to be able to use introspection.
>>>=20
>>> 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.
>>>=20
>>> John B.
>>>=20
>>>> On Jan 15, 2016, at 5:34 AM, Sergey Beryozkin =
<sberyozkin@gmail.com>
>>>> wrote:
>>>>=20
>>>> Hi All,
>>>>=20
>>>> I'm reviewing RFC 7622 as we are going ahead with implementing it.
>>>> I have a question:
>>>>=20
>>>> 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 ?
>>>>=20
>>>> Thanks, Sergey
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> --
> Vladimir Dzhuvinov
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_9C540280-AD4D-4875-B74B-C139927DF1AA
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJWmmxeAAoJEDPAngkbd+w96rQH/0xORs05BOFWq0VPYpnTJJxA
5ZWOAjsO/d/pj1YuQbBDtLG5/qt2yM3utdcUgQqMQsbHwzZc28nQEINYDw8w6u5J
mCLqN0Pw9m8yeKyETObUy+YuVrAlkxh/nB9R+ydn/IxEgBkR7q8njMFfuUIW4e1g
5n4k4dWASjHbcq7wkquETKGe5JjvQSAha/WqQdtQWkHgtBgVg26DZ/N/F0lePHnL
+qQqhnkasZx1MpjjeH1/V8fNP69H/Ro5WpTmtBQtoxVZD9rfuE4jGSlQcqOsgtQc
n4nmXh0jUT5cu6Bw6uJVeRRy3eN2OYSSBu9u8QJ9SirxLBazqph7LHAn0wB6NxU=
=yLXt
-----END PGP SIGNATURE-----

--Apple-Mail=_9C540280-AD4D-4875-B74B-C139927DF1AA--