Subject: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions

From: "Donald F Coffin" <[email-masked]>
Date: Wed, 20 Feb 2013 16:09:20 -0800

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:       [email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 21 Feb 2013 09:12:30 +0100

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" <[email-masked]>:

> 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.
>

---

From: "Donald F Coffin" <[email-masked]>
Date: Thu, 21 Feb 2013 07:42:20 -0800

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

Phone:      (949) 636-8571

Email:        <mailto:[email-masked]> [email-masked]

From: Torsten Lodderstedt [mailto:[email-masked]] 
Sent: Thursday, February 21, 2013 12:13 AM
To: Donald F Coffin
Cc: <[email-masked]>; Anne Hendry; Dave Robin; Edward Denson; Jay Mitra; John Adkins; John Teeter; Lynne Rodoni; Marty Burns; <[email-masked]>; Ray Perlner; Scott Crowder; Uday Verma
Subject: Re: draft-ietf-oauth-revocation-05 Questions

Hi Donald,

regards,

Torsten.

Torsten,

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

---

From: Justin Richer <[email-masked]>
Date: Thu, 21 Feb 2013 11:01:57 -0500

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
>
> <mailto:[email-masked]>
>
> *From:*Torsten Lodderstedt [mailto:[email-masked]]
> *Sent:* Thursday, February 21, 2013 12:13 AM
> *To:* Donald F Coffin
> *Cc:* <[email-masked]>; Anne Hendry; Dave Robin; Edward Denson; Jay 
> Mitra; John Adkins; John Teeter; Lynne Rodoni; Marty Burns; 
> <[email-masked]>; 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.
>
> Am 21.02.2013 um 01:09 schrieb "Donald F Coffin" 
> <[email-masked] <mailto:[email-masked]>>:
>
>     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.
>
>     <mailto:[email-masked]>
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Donald F Coffin" <[email-masked]>
Date: Thu, 21 Feb 2013 08:21:27 -0800

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

Phone:      (949) 636-8571

Email:        <mailto:[email-masked]>
[email-masked]

From: Justin Richer [mailto:[email-masked]] 
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'; [email-masked]; 'Edward Denson'; 'Jay
Mitra'; 'Uday Verma'; 'Ray Perlner'; 'Anne Hendry'; 'Lynne Rodoni';
[email-masked]
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

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

Phone:      (949) 636-8571

From: Torsten Lodderstedt [mailto:[email-masked]] 
Sent: Thursday, February 21, 2013 12:13 AM
To: Donald F Coffin
Cc:  <mailto:[email-masked]> <[email-masked]>; Anne Hendry; Dave Robin;
Edward Denson; Jay Mitra; John Adkins; John Teeter; Lynne Rodoni; Marty
Burns;  <mailto:[email-masked]> <[email-masked]>; 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. 

regards,

Torsten.

Am 21.02.2013 um 01:09 schrieb "Donald F Coffin"
<[email-masked]>:

Torsten,

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

---

From: Justin Richer <[email-masked]>
Date: Thu, 21 Feb 2013 11:40:10 -0500

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
>
> *From:*Justin Richer [mailto:[email-masked]]
> *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'; [email-masked]; 
> 'Edward Denson'; 'Jay Mitra'; 'Uday Verma'; 'Ray Perlner'; 'Anne 
> Hendry'; 'Lynne Rodoni'; [email-masked]
> *Subject:* Re: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions
>
> 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
>
>     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
>
>     *Cc:* <[email-masked]> <mailto:[email-masked]>; Anne Hendry; Dave
>     Robin; Edward Denson; Jay Mitra; John Adkins; John Teeter; Lynne
>     Rodoni; Marty Burns; <[email-masked]>
>     <mailto:[email-masked]>; Ray Perlner; Scott Crowder;
>     Uday Verma
>     respective portal belonging to the AS. There the AS provides a
>     list of all valid authorization grants in its database.
>
>     <[email-masked]
>     <mailto:[email-masked]>>:
>
>         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
>         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
>     [email-masked]  <mailto:[email-masked]>
>

---

From: "Donald F Coffin" <[email-masked]>
Date: Thu, 21 Feb 2013 10:02:12 -0800

Thanks for the clarification.

I was not envisioning the end-user directly referencing the token revocation
endpoint.  The question is how does the end-user know the client did in fact
revoke a token using the token revocation endpoint. 

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

Sent: Thursday, February 21, 2013 8:40 AM

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

Justin,

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

 -- Justin

Torsten,

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

Hi Donald,

regards,

Torsten.

Torsten,

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571