Re: [OAUTH-WG] RFC 7009

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) <phil.hunt@oracle.com> 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 <jricher@mit.edu <mailto:jricher@mit.edu>> 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 <Brig.Lamoreaux@microsoft.com <mailto:Brig.Lamoreaux@microsoft.com>> 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:jricher@mit.edu <mailto:jricher@mit.edu>] 
>>> Sent: Tuesday, June 6, 2017 2:46 PM
>>> To: Brig Lamoreaux <Brig.Lamoreaux@microsoft.com <mailto:Brig.Lamoreaux@microsoft.com>>
>>> Cc: <oauth@ietf.org <mailto:oauth@ietf.org>> <oauth@ietf.org <mailto:oauth@ietf.org>>
>>> 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:jricher@mit.edu <mailto:jricher@mit.edu>] 
>>> Sent: Tuesday, June 6, 2017 9:12 AM
>>> To: Brig Lamoreaux <Brig.Lamoreaux@microsoft.com> <mailto:Brig.Lamoreaux@microsoft.com>
>>> Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailto:oauth@ietf.org>
>>> 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 <Brig.Lamoreaux@microsoft.com <mailto:Brig.Lamoreaux@microsoft.com>> wrote:
>>>  
>>> Hi,
>>> 
>>> What is the specified timeout period to invalidate the token?
>>>  
>>> Brig Lamoreaux
>>> Data Solution Architect
>>> brig.lamoreaux@microsoft.com <mailto:brig.lamoreaux@microsoft.com>
>>> 480-828-8707
>>> US Desert/Mountain Tempe
>>>  
>>>  
>>> <image001.jpg>
>>>  
>>>  
>>>  
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> 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
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> 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=> 