Re: [OAUTH-WG] A question on token revocation.

Prabath Siriwardena <prabath@wso2.com> Wed, 06 February 2013 15:13 UTC

Return-Path: <prabath@wso2.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8665421F85B2 for <oauth@ietfa.amsl.com>; Wed, 6 Feb 2013 07:13:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.67
X-Spam-Level:
X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snfADvYaAaAx for <oauth@ietfa.amsl.com>; Wed, 6 Feb 2013 07:13:50 -0800 (PST)
Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 39A8721F8481 for <oauth@ietf.org>; Wed, 6 Feb 2013 07:13:50 -0800 (PST)
Received: by mail-ee0-f45.google.com with SMTP id b57so817712eek.4 for <oauth@ietf.org>; Wed, 06 Feb 2013 07:13:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=v1fiQGs3MW7kv+NOT0Q6EEnN4bcCfxewcndUoUWMpwk=; b=kaIuNye531kZoxCxrGGTgPO4SSpvyl0osz/t8YDu+BdaVw+1wdTqJ9R6dtgZFhQhV5 Rgvx/1oTaLKsTDusvBRJyqt2zKIgHM4/H816jazfMZngfK1XIO4Yp+XzMh/eGVUdF7CT MrxVGeYzNqbOXZXi12Dcn7XdaoWFodiAPlt3T4hufmhL9LMXU1Q/jM07iHiigUO1OFbM maQW7wpR3h3hPFPdbCuFt0rLJUBkTpwZsMul7drSiR3vxHvqGGZH/vUpm840S1L5jnrH Ea+h4mhaqzh/CfkFFZ5di5xmQoRbhcsMKAqlyl6iUo0Sl6+rc9V1DDSKFuhAHsAxInQm MAOw==
MIME-Version: 1.0
X-Received: by 10.14.203.3 with SMTP id e3mr98137999eeo.9.1360163629175; Wed, 06 Feb 2013 07:13:49 -0800 (PST)
Received: by 10.223.175.134 with HTTP; Wed, 6 Feb 2013 07:13:49 -0800 (PST)
In-Reply-To: <51126D65.2090707@mitre.org>
References: <CAJV9qO8UgLV6SdegZSk4KT3Qyb-M2KmPFPV9xDht_WjibeUWrg@mail.gmail.com> <51126D65.2090707@mitre.org>
Date: Wed, 06 Feb 2013 20:43:49 +0530
Message-ID: <CAJV9qO-ZNVcbzNvb---CmXv+vo0jZHKQaDon8OqrPJCfAXKTRQ@mail.gmail.com>
From: Prabath Siriwardena <prabath@wso2.com>
To: Justin Richer <jricher@mitre.org>
Content-Type: multipart/alternative; boundary="047d7b343b2af413b204d50fc53b"
X-Gm-Message-State: ALoCoQk7j08RjbURYWtYyJUp+wECuhXLaTtjs+MENg//BYVsO3tMwe+pmc3U4yCWeRs5Tjefnl/r
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Feb 2013 15:13:51 -0000

On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <jricher@mitre.org> wrote:

>  These are generally handled through a user interface where the RO is
> authenticated directly to the AS, and there's not much need for a
> "protocol" here, in practice.
>

Why do you think leaving access token revocation by RO to a proprietary API
is a good practice ? IMO this an essential requirement in API security.

IMHO token revocation done my RO is more practical than token revocation
done by the Client.


> There are larger applications, like UMA, that have client and PR
> provisioning that would allow for this to be managed somewhat
> programmatically, but even in that case you're still generally doing token
> revocation by a "client" in some fashion. In UMA, though, several different
> pieces can play the role of a "client" at different parts of the process.
>
> Revoking a scope is a whole different mess. Generally, you'd want to just
> revoke an existing token and make a new authorization grant with lower
> access if you don't want that client getting that scope anymore. If you
> just want to downscope for a single transaction, you can already do that
> with either the refresh token or token chaining approaches, depending on
> where in the process you are. The latter of these are both client-focused,
> though, and the RO doesn't have a direct hand in it at this point.
>

Why do you think it a mess. If you revoke the entire token then Client
needs to go through the complete OAuth flow - and also needs to get the
user consent. If RO can  downgrade the scope, then we restrict API access
by the client at RS end and its transparent to the client.

Thanks & regards,
-Prabath


>
>
>  -- Justin
>
>
> On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:
>
> I am sorry if this was already discussed in this list..
>
>  Looking at [1] it only talks about revoking the access token from the
> client.
>
>  How about the resource owner..?
>
>  There can be cases where resource owner needs to revoke an authorized
> access token from a given client. Or revoke an scope..
>
>  How are we going to address these requirements..? Thoughts appreciated...
>
>  [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04
>
>  --
> Thanks & Regards,
> Prabath
>
>  Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>


-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com