Re: [OAUTH-WG] 'Scope' parameter proposal

"Keenan, Bill" <Bill_Keenan@intuit.com> Tue, 27 April 2010 19:40 UTC

Return-Path: <Bill_Keenan@intuit.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 C4CCD3A6A21 for <oauth@core3.amsl.com>; Tue, 27 Apr 2010 12:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.196
X-Spam-Level:
X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 cK66kmfea0JS for <oauth@core3.amsl.com>; Tue, 27 Apr 2010 12:40:00 -0700 (PDT)
Received: from mail2.intuit.com (mail2.intuit.com [12.149.175.12]) by core3.amsl.com (Postfix) with ESMTP id 9699728C12B for <oauth@ietf.org>; Tue, 27 Apr 2010 12:40:00 -0700 (PDT)
DomainKey-Signature: s=default; d=intuit.com; c=nofws; q=dns; h=X-SBRS:X-IronPort-AV:Received:Received:X-MimeOLE: Content-class:MIME-Version:Content-Type:Subject:Date: Message-ID:In-Reply-To:X-MS-Has-Attach: X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:References: From:To:Return-Path:X-OriginalArrivalTime; b=gcc6rey76NUDz42OCmlWemlc/PQq2MMIHFxiYE3OONJikRtgjBSrUatI mAekiacJL5MNOO6uJauUVyiCM4bG9cFrM4xuVQibGvYB5dn4xAHoAj46+ kYRk6ULmx8a1kUB;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intuit.com; i=Bill_Keenan@intuit.com; q=dns/txt; s=default; t=1272397188; x=1303933188; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Keenan,=20Bill"=20<Bill_Keenan@intuit.com> |Subject:=20RE:=20[OAUTH-WG]=20'Scope'=20parameter=20prop osal|Date:=20Tue,=2027=20Apr=202010=2012:39:47=20-0700 |Message-ID:=20<5DEB74B3E9FA574EAA911DB8167C559E04425EF3@ SDGEXEVS12.corp.intuit.net>|To:=20"OAuth=20WG"=20<oauth@i etf.org>|MIME-Version:=201.0|In-Reply-To:=20<i2qcb5f7a381 004271219k6b58114dx1df549847f172edc@mail.gmail.com> |References:=20<C7F1D1FC.32809%eran@hueniverse.com><g2mda f5b9571004221036j5d6837f6z4d7959d69a3cbb2b@mail.gmail.com ><BB02FD4F-071E-4FF5-B3D0-F8D3FA22FEEE@jkemp.net><90C41DD 21FB7C64BB94121FBBC2E723438E5C7FD26@P3PW5EX1MB01.EX1.SECU RESERVER.NET><h2ldaf5b9571004221235tb844eb6ah623955979526 c1b6@mail.gmail.com>=20<90C41DD21FB7C64BB94121FBBC2E72343 8E5C7FD4A@P3PW5EX1MB01.EX1.SECURESERVER.NET><l2idaf5b9571 004221350oa0dbeb11ndeb4cb9147407ba9@mail.gmail.com>=20<25 5B9BB34FB7D647A506DC292726F6E1125793664B@WSMSG3153V.srv.d ir.telstra.com><w2sdaf5b9571004231705jbff1ae6dz70fd966f09 1502b3@mail.gmail.com>=20<4BD731A0.8090105@lodderstedt.ne t>=20<i2qcb5f7a381004271219k6b58114dx1df549847f172edc@mai l.gmail.com>; bh=4XoBYPBCssiW1gIuXNIbGouhZB2dvHf3Pf9b/a22i/c=; b=dvd8nYHmEY91mC4Kq8OrYRjV9/K5/1HCUWZjYdK2w/eKU9uVYqeVOah5 4MJEPXb3PH56Hp8/Mln0lmEOCoP0eTpsIJ6C0uNWPcyZUaHmKTgyyggeX n5wCl6RT9rsvAql;
X-SBRS: None
X-IronPort-AV: E=Sophos; i="4.52,282,1270450800"; d="scan'208,217"; a="180270446"
Received: from sdgexbh03.corp.intuit.net ([172.17.135.77]) by mail2.sdg.ie.intuit.com with ESMTP; 27 Apr 2010 12:39:48 -0700
Received: from SDGEXEVS12.corp.intuit.net ([172.17.135.111]) by SDGEXBH03.corp.intuit.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 12:39:48 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAE641.65836297"
Date: Tue, 27 Apr 2010 12:39:47 -0700
Message-ID: <5DEB74B3E9FA574EAA911DB8167C559E04425EF3@SDGEXEVS12.corp.intuit.net>
In-Reply-To: <i2qcb5f7a381004271219k6b58114dx1df549847f172edc@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OAUTH-WG] 'Scope' parameter proposal
Thread-Index: AcrmPrZ2fdTuhKk1S8ykqbObjjxxswAAFSYg
References: <C7F1D1FC.32809%eran@hueniverse.com><g2mdaf5b9571004221036j5d6837f6z4d7959d69a3cbb2b@mail.gmail.com><BB02FD4F-071E-4FF5-B3D0-F8D3FA22FEEE@jkemp.net><90C41DD21FB7C64BB94121FBBC2E723438E5C7FD26@P3PW5EX1MB01.EX1.SECURESERVER.NET><h2ldaf5b9571004221235tb844eb6ah623955979526c1b6@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E5C7FD4A@P3PW5EX1MB01.EX1.SECURESERVER.NET><l2idaf5b9571004221350oa0dbeb11ndeb4cb9147407ba9@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1125793664B@WSMSG3153V.srv.dir.telstra.com><w2sdaf5b9571004231705jbff1ae6dz70fd966f091502b3@mail.gmail.com> <4BD731A0.8090105@lodderstedt.net> <i2qcb5f7a381004271219k6b58114dx1df549847f172edc@mail.gmail.com>
From: "Keenan, Bill" <Bill_Keenan@intuit.com>
To: OAuth WG <oauth@ietf.org>
X-OriginalArrivalTime: 27 Apr 2010 19:39:48.0331 (UTC) FILETIME=[657B1BB0:01CAE641]
Subject: Re: [OAUTH-WG] 'Scope' parameter proposal
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: Tue, 27 Apr 2010 19:40:05 -0000

The amount of writing done on scope the past few weeks indicates this
concept generates a lot of passion. I hope we will spend some time on it
during IIW X and at our 20-May f2f.

 

For me, delegation is an identity in my system authorizing my system to
issue a toke to an identity, which is not in my system. The rights and
privileges attached to the token will almost never be the same as the
authorizing user. [My colleague, Tom Holodnik, is working on a user
story around tax return data you must share with the financial aid
department at a university your child is applying to.] My current
thinking is to present a set of constraints in the UI presented to the
authorizing user. Our systems would maintain these constrains - others
may choose to encode the constraints into their opaque token. I'm having
a hard time seeing how I can trust the scope parameter passed in by a
delegate. Even if I could trust the passed in scope, it does not help me
with access control of a complex entity model (e.g., tax return). I
still need some other mechanism for access control, and I'm concerned
scope defined in the specification may create unintended conflict cases
with my access control model.

 

BillK

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of John Panzer
Sent: Tuesday, April 27, 2010 12:20 PM
To: Torsten Lodderstedt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] 'Scope' parameter proposal

 

The old AOL Blogs API, which used AOL's OpenAuth service, provided a
url= parameter on WWW-Authenticate: challenges:

 

dev.estage.aol.com/aolblogs_api#mozTocId815750

 

*          If authorization fails, a 401 response is returned with a
WWW-Authenticate: header providing additional details.

WWW-Authenticate: OpenAuth realm="AOLBlogs", status="status",
msg="message", url="url"

 

This is from 2007 ;).

 

On Tue, Apr 27, 2010 at 11:49 AM, Torsten Lodderstedt
<torsten@lodderstedt.net> wrote:

Am 24.04.2010 02:05, schrieb Brian Eaton:

	 

	On Thu, Apr 22, 2010 at 6:11 PM, Manger, James H
	<James.H.Manger@team.telstra.com>  wrote:
	  

	We mustn't drop advertisements (details in 401 responses).
	We mustn't drop the goal of a standard for interoperability.
	    

	I share the goals, I just don't think that a specification is
the way
	to get there.  I think working examples in the wild would help
	enormously.
	
	  

	Defining a scope field in a 401 response is the novel aspect
that "might not actually work". Allowing a 'scope' query parameter in
authz URIs is be quite separate.
	    

	Yeah, I agree with that analysis.
	
	Though I don't know of any providers that are returning
authorization
	URLs in 401 responses right now.  That's novel, too.
	
	  

 

That's novel, yes. But I think no one did it before because there was no
need to do so. BASIC and DIGEST don't require authorization endpoint
coordinates. SPNEGO/Kerberos would be a candidate because of its
architecture, but it uses the standard Kerberos mechanisms (config or
DNS-based discovery via SRV records).

I think there is a need for a standardized way of authorization server
discovery. Using the WWW-Authentication header is better than nothing
from my point of view.

Alternatively, resource servers could publish their supported
authentication servers via XRD or a similar mechanism. The authorization
server in turn could publish its endpoints (and capabilities) the same
way.

regards,
Torsten.



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth