OAuth doesn't get into the business of what the UI for managing grants
is like. Having the user, admin, or resource owner revoke, downscope, or
otherwise alter a grant needs to happen with user interactions that are
going to be different depending on the provider and use case.
-- Justin
On 02/21/2013 10:42 AM, Donald F Coffin wrote:
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: donald.cof...@reminetworks.com
<mailto: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 <mailto: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
<mailto:donald.cof...@reminetworks.com>
_______________________________________________
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
