Yes, that's correct, the actions you've described and the "portal/UI"
components are of band as far as the OAuth 2 protocol is concerned. In
fact, you don't *have* to have anything of the sort, though many
deployments and implementations do have it in some fashion.
To bring it back to the original question: the token revocation endpoint
is meant to service well-meaning clients who want to clean up any tokens
they have in the wild. It's not meant for something end-users or
resource owners would be dealing with directly.
-- Justin
On 02/21/2013 11:21 AM, Donald F Coffin wrote:
Justin,
My response was not meant to ask the UI of the "respective portal
belonging to the AS". The question was where in the various OAuth 2.0
Authorization Framework is such a portal even discussed? Clearly if
it is NOT discussed in any existing OAuth 2.0 Authorization Framework
RFC or existing draft, then it must be an out-of-band customized
implementation.
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:*Justin Richer [mailto:jric...@mitre.org]
*Sent:* Thursday, February 21, 2013 8:02 AM
*To:* Donald F Coffin
*Cc:* 'Torsten Lodderstedt'; 'John Adkins'; 'Marty Burns'; 'Scott
Crowder'; 'Dave Robin'; 'John Teeter'; pmad...@pingidentity.com;
'Edward Denson'; 'Jay Mitra'; 'Uday Verma'; 'Ray Perlner'; 'Anne
Hendry'; 'Lynne Rodoni'; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions
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> <mailto:oauth@ietf.org>; Anne Hendry; Dave
Robin; Edward Denson; Jay Mitra; John Adkins; John Teeter; Lynne
Rodoni; Marty Burns; <pmad...@pingidentity.com>
<mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
