Agree, and this was discussed at the time of 7662’s ratification but there was no agreement on a delivery mechanism. I’d like to see a SECEVENT with a 7662 payload, which would take care of a large number of use cases, including “token revoked” and “new token issued” being delivered downstream to RS’s. It’s a good compliment to the callback-based mechanism in 7662.
— Justin > On Jun 6, 2017, at 6:31 PM, Phil Hunt (IDM) <[email protected]> wrote: > > This is why i expect a secevent token revocation event to be defined to > complement 7009 once secevents moves further along. > > We want to be able to know in near real time when a token is revoked to avoid > constant checks to see if a token is still good. > > Phil > > On Jun 6, 2017, at 3:18 PM, Justin Richer <[email protected] > <mailto:[email protected]>> wrote: > >> That really depends on the nature of your tokens and how you manage their >> internal validity. It’s really as soon as possible, isn’t it? If you can >> invalidate it immediately, do that. In our implementation, we delete it from >> the data store as soon as the revocation request comes in, which invalidates >> it. Downstream RS’s might have cached introspection (RFC7662) results so >> they’ll find out once their caches expire. If you’ve got some other >> synchronization method that takes some time to propagate, then that’s going >> to be the answer. All of this is dependent on your implementation and not on >> the revocation protocol, but in all cases I see no reason to *wait* any >> amount of time to revoke a token that’s been requested for revocation by a >> client, for any reason. The client is effectively saying “if you see this >> token again it isn’t from me”, which should be a good enough indication to >> throw it out as soon as possible. >> >> This all falls apart if you’re using self-contained tokens — there’s not a >> good way to invalidate a self-contained token without using some kind of >> lookup service. RFC7662 defines such a service for OAuth, but then your >> tokens aren’t really fully self-contained anymore and you’re simply stuck >> waiting for the compromised token to expire. >> >> — Justin >> >>> On Jun 6, 2017, at 6:11 PM, Brig Lamoreaux <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> This is where we have the question around timeouts. If the client thinks >>> its token is compromised, how long should 7009 take to invalidate. >>> >>> >>> <> >>> From: Justin Richer [mailto:[email protected] <mailto:[email protected]>] >>> Sent: Tuesday, June 6, 2017 2:46 PM >>> To: Brig Lamoreaux <[email protected] >>> <mailto:[email protected]>> >>> Cc: <[email protected] <mailto:[email protected]>> <[email protected] >>> <mailto:[email protected]>> >>> Subject: Re: [OAUTH-WG] RFC 7009 >>> >>> 7009 doesn't, really. If the client thinks its token is compromised, it can >>> revoke it using 7009. If the server decides the token is compromised, it >>> invalidates it on its own, not involving 7009. The client finds out the >>> token isn't good anymore the next time it tries to use the token -- OAuth >>> clients always need to be prepared for their token not working at some >>> point. Good news is that the remedy for having a token that doesn't work is >>> to just do OAuth again. >>> >>> -- Justin >>> >>> >>> On 6/6/2017 5:43 PM, Brig Lamoreaux wrote: >>> Thanks for the reply. How do the RFC address a token that has been >>> compromised? >>> >>> From: Justin Richer [mailto:[email protected] <mailto:[email protected]>] >>> Sent: Tuesday, June 6, 2017 9:12 AM >>> To: Brig Lamoreaux <[email protected]> >>> <mailto:[email protected]> >>> Cc: <[email protected]> <mailto:[email protected]> <[email protected]> >>> <mailto:[email protected]> >>> Subject: Re: [OAUTH-WG] RFC 7009 >>> >>> OAuth doesn’t specify and specific timeout period, it’s up to the AS that >>> issues the token to determine how long the token is good for. RFC7009 isn’t >>> about timeout periods, it’s about the client proactively telling the AS >>> that it doesn’t need a token anymore and the AS should throw it out, likely >>> prior to any timeouts. >>> >>> — Justin >>> >>> On May 25, 2017, at 12:23 PM, Brig Lamoreaux <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi, >>> >>> What is the specified timeout period to invalidate the token? >>> >>> Brig Lamoreaux >>> Data Solution Architect >>> [email protected] <mailto:[email protected]> >>> 480-828-8707 >>> US Desert/Mountain Tempe >>> >>> >>> <image001.jpg> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Foauth-26data-3D02-257C01-257CBrig.Lamoreaux-2540microsoft.com-257C538020425e8a411a106408d4acf6ca32-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636323623328232170-26sdata-3DUHQOwegm2k8MbWPCYHR3a4ted39xMFlfjil4FdJqyA8-253D-26reserved-3D0&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=7yMIczBrZnmQ14Nkf4MBGaIHnxRyiLGXB1Xhuxp1Ur0&s=mGIUcqB4BzW6-s_7X9QmZ5qldZNN__gUjCG209QWW4c&e=> >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=7yMIczBrZnmQ14Nkf4MBGaIHnxRyiLGXB1Xhuxp1Ur0&s=TaKHdPgtEPkCV_YuOHlkoXRZJjf0k8Y4-yowD3YbhPw&e= >> >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=7yMIczBrZnmQ14Nkf4MBGaIHnxRyiLGXB1Xhuxp1Ur0&s=TaKHdPgtEPkCV_YuOHlkoXRZJjf0k8Y4-yowD3YbhPw&e=> >>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
