[OAUTH-WG] Token validation and other host/authz communication

Eve Maler <eve@xmlgrrl.com> Fri, 12 March 2010 18:39 UTC

Return-Path: <eve@xmlgrrl.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890123A6821 for <oauth@core3.amsl.com>; Fri, 12 Mar 2010 10:39:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.824
X-Spam-Level: **
X-Spam-Status: No, score=2.824 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_20=-0.74, FH_HOST_EQ_D_D_D_D=0.765, FROM_DOMAIN_NOVOWEL=0.5, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvtpdcYknq8g for <oauth@core3.amsl.com>; Fri, 12 Mar 2010 10:39:25 -0800 (PST)
Received: from mail.promanage-inc.com (static-98-111-84-13.sttlwa.fios.verizon.net [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 57B023A68C9 for <oauth@ietf.org>; Fri, 12 Mar 2010 10:39:25 -0800 (PST)
Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by mail.promanage-inc.com (8.14.3/8.14.3) with ESMTP id o2CIdVea018937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Mar 2010 10:39:31 -0800
From: Eve Maler <eve@xmlgrrl.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-45-201678764"
Date: Fri, 12 Mar 2010 10:39:31 -0800
To: OAuth WG <oauth@ietf.org>
Message-Id: <EAC261A6-00AD-4EB8-A2F6-51FCC1B8ADE7@xmlgrrl.com>
Mime-Version: 1.0 (Apple Message framework v1077)
X-Mailer: Apple Mail (2.1077)
Subject: [OAUTH-WG] Token validation and other host/authz communication
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 12 Mar 2010 18:39:26 -0000

In the recent thread here:

http://www.ietf.org/mail-archive/web/oauth/current/msg01234.html
Subject: "Recent UMA work that may inform this group's deliberations"

...Dick and I had a bit of discussion around UMA's proposal for a back-channel method of token validation that a Protected Resource could use at an Authorization Server.  (In UMA terms, it would be a Host->Authorization Manager interaction, and indeed if this channel is inappropriate for core OAuth 2.0, UMA might define it as a separate subordinate protocol.)

At the UMA F2F held Wednesday, we discussed this proposition in some detail, and continued to find the back channel interesting in our loosely coupled environment.  Below I have reproduced the portion of meeting notes (from http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-03-10 ) where we discussed this. I hope it's useful/interesting.

	Eve


====
Back channel for token validation: Our "token validation URL" proposal is just a strawman. There are quite a few motivations for wanting this back channel, though:

It allows for building a very lightweight host that can do token validation at request-time.
The AM is the best entity to judge the token's suitability.
Once this channel is enabled, the host can use it send audit log data to the AM for more interesting analytics.
Or the AM could (at leisure after step 1 is done) dynamically provision the host with the ability to do local token validation (which ends up looking like a hybrid remote/local means of validation).


Eve Maler
eve@xmlgrrl.com
http://www.xmlgrrl.com/blog