Torsten,
Thanks for the response. What is the “respective portal belonging to the AS”? I haven’t seen anything in the OAuth 2.0 Authorization Framework that describes a “portal” on the AS a Resource Owner can log into to view a valid list of authorization grants. Is this an out-of-band implementation suggestion? Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: <mailto:donald.cof...@reminetworks.com> donald.cof...@reminetworks.com From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Thursday, February 21, 2013 12:13 AM To: Donald F Coffin Cc: <oauth@ietf.org>; Anne Hendry; Dave Robin; Edward Denson; Jay Mitra; John Adkins; John Teeter; Lynne Rodoni; Marty Burns; <pmad...@pingidentity.com>; Ray Perlner; Scott Crowder; Uday Verma Subject: Re: draft-ietf-oauth-revocation-05 Questions Hi Donald, thank you for sharing your thoughts with us. I've never seen revocation as change of scope of the authorization, but it sounds reasonable. The current design handles the issues you raised differently. The AS is involved in the revocation process as it exposes the revocation endpoint. So if the token is revoked (from a technical perspective), it knows it. If the user wants to check whether the application really sent the request, she is supposed to visit the respective portal belonging to the AS. There the AS provides a list of all valid authorization grants in its database. Does this address your issues? regards, Torsten. Am 21.02.2013 um 01:09 schrieb "Donald F Coffin" <donald.cof...@reminetworks.com>: Torsten, A colleague of mine and I were discussing what should occur when a Retail Customer desires to change the existing authorized access of a Third Party. During our discussion they asked “How does the Retail Customer know the Third Party actually issued a Token revocation request? Isn’t there a potential trust issue with the current design”? The current draft provides a Third Party mechanism that “allows a client to invalidate its tokens if the end-user logs out, changes identity, or uninstalls the respective application (sic).” While none of these fit the situation we were discussing they do seem to be based on the assumption a Third Party application will be a good citizen and stop using access tokens. Unfortunately, none of the addressed situations require the participation of a AS for completion, therefore the risk exists that a Retail Customer may believe they have removed a Third Party application from accessing their protected data, but in reality there does not seem to be a mechanism to either force or verify the Third Party can no longer have access to the protected data. A possible modification to the current draft that would correct this potential security risk, is to treat a Token revocation using a message flow similar to the existing authorization_code response type. A Retail Customer requesting a change to the Third Party authorized access would be redirected to an AS endpoint that would allow the Retail Customer to either terminate a relationship completely or modify the existing Third Party access authorization. The successful response from the AS would indicate the Third Party needs to remove the current Token from its Token store. In the event the Retail Customer has changed the Third Party access authorization, the AS response could include an optional “scope” element, which the Third Party would then use to obtain a new access token utilizing an Authorization Code request. There are several other potential implementations that could be developed to protect a Retail Customer from a “rogue” Third Party application that does not inform the AS their authorization to access a Retail Customer’s protected data has been revoked, but the above suggestion meets the current draft’s view that Third Parties should be able to request Tokens be revoked. I look forward to your comments on the above topic. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.cof...@reminetworks.com
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
