Re: [OAUTH-WG] Rechartering
Nat Sakimura <sakimura@gmail.com> Wed, 26 October 2011 22:30 UTC
Return-Path: <sakimura@gmail.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 0C60F21F8B7C for <oauth@ietfa.amsl.com>; Wed, 26 Oct 2011 15:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.765
X-Spam-Level:
X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4H7DGPQrtmW for <oauth@ietfa.amsl.com>; Wed, 26 Oct 2011 15:30:10 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF30021F8B75 for <oauth@ietf.org>; Wed, 26 Oct 2011 15:30:09 -0700 (PDT)
Received: by faas12 with SMTP id s12so2332152faa.31 for <oauth@ietf.org>; Wed, 26 Oct 2011 15:30:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MzhKAfelrewuk0GQwccwj8tTSkW9yHgK9T6CdFsdDFk=; b=uQm0EKZV8+xLNutXNoy4kdu65A2+PuspSOnvPNktwxwEBUJVdkp0WeKxAzacofnFdc hdkB5aL+B9YEyx3cVAw4dj52Gm+TNk3SwgeY83OPzDdJ+LnCTDEDkOGW1vO126YF8Vvn 2hOxQHntUwU+m51ERWo27gcZYIN8srQRusM+0=
MIME-Version: 1.0
Received: by 10.223.62.15 with SMTP id v15mr62113224fah.22.1319668208719; Wed, 26 Oct 2011 15:30:08 -0700 (PDT)
Received: by 10.152.37.201 with HTTP; Wed, 26 Oct 2011 15:30:08 -0700 (PDT)
In-Reply-To: <4EA84E97.3020708@lodderstedt.net>
References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <CABzCy2BLp=Hh3HdyDdOGF4nZ6TMLRdiuRMzWDPvB3T2Y_fcfNA@mail.gmail.com> <4EA84E97.3020708@lodderstedt.net>
Date: Thu, 27 Oct 2011 07:30:08 +0900
Message-ID: <CABzCy2AGRYghf5-7htJ1jg5yDuPDrirc7H=9HrcygMCYn3kg4g@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/alternative; boundary="001517402a2acd59fe04b03b323d"
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Rechartering
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, 26 Oct 2011 22:30:12 -0000
HI Torsten, I and John just refreshed the I-D to be more in-line with what we do with OpenID Connect. http://tools.ietf.org/html/draft-sakimura-oauth-requrl-01 As you point out, this would solve the duplication / non-standard behavior that OpenID Connect requires. Cheers, Nat On Thu, Oct 27, 2011 at 3:16 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Nat, > > I think your proposal would be a useful OAuth enhancement. A JSON-based > request format would allow for more complex requests (e.g. carrying resource > server URLs and corresponding scope values ;-)). > > Please note: I also think the way this mechanism is introduced and used in > the current OpenID connect spec requires OpenID connect clients and servers > to handle OAuth request parameters differently than for standard OAuth > requests. Introducing the JSON based claim request capability to OAuth would > be a way to cope with this. > > regards, > Torsten. > > Am 22.10.2011 16:00, schrieb Nat Sakimura: > > Hi. > > Just a clarification: > > Although my expired draft is 'request by reference', what was proposed > through it at the iiw really is a generalized JSON based claim request > capability. It could be passed by value as JSON or could be passed by > reference. The later is an optimization for bandwidth constrained network as > well as strengthening security in some ways. This capability already exists > in OpenID Connect but it is actually an underpinning transport, so it > probably should belong to OAuth instead. This was the primary reason for the > proposal. > > Nat > > On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi all, >> >> my prioritization is driven by the goal to make OAuth the authorization >> framework of choice for any internet standard protocol, such as WebDAV, >> IMAP, SMTP or SIP. So let me first explain what is missing from my point of >> view and explain some thoughts how to fill the gaps. >> >> A standard protocol is defined in terms of resource types and messages by >> a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and >> used by different but deployment-independent clients. OAuth-based protocol >> specifications must also define scope values (e.g. read, write, send) and >> their relation to the resource types and messages. The different deployments >> expose the standard protocol on different resource server endpoints. In my >> opinion, it is fundamental to clearly distinguish scope values >> (standardized, static) and resource server addresses (deployment specific) >> and to manage their relationships. The current scope definition is much to >> weak and insufficient. Probably, the UMA concepts of hosts, resources sets, >> and corresponding scopes could be adopted for that purpose. >> >> OAuth today requires clients to register with the service provider before >> they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, >> to register with any a-Mail services upfront? So clients should be given a >> way to register dynamically to the authorization servers. This should also >> allow us to cover "client instance" aspects. It is interesting to note, that >> such a mechanism would allow us to get rid of secret-less clients and the >> one-time usage requirement for authorization codes. >> >> We also assume the client to know the URLs of the resource server and the >> corresponding authorization server and to use HTTPS server authentication to >> verify the resource server's authenticity. This is impossible in the >> standard scenario. Clients must be able to discover the authorization server >> a particular resource server relies on at runtime. The discovery mechanism >> could be specified by the OAuth WG, but could also be part of an application >> protocols specification. But we MUST find another way to prevent token >> phishing by counterfeit resource servers. >> >> As one approach, the client could pass the (previously HTTPS validated) >> resource server's URL with the authorization request. The authorization >> server should then refuse such requests for any unknown (counterfeit) >> resource servers. Such an additional parameter could also serve as namespace >> for scope values and enable service providers to run multiple instances of >> the same service within a single deployment. >> >> If the additional data enlarges the request payload to much, we could >> consider to adopt the "request by reference" proposal. >> >> Let's now assume, OAuth is successful in the world of standard protocols >> and we will see plenty of deployments with a bunch of different OAuth >> protected resource servers. Shall this servers all be accessible with a >> single token? In my opinion, this would cause security, privacy and/or >> scalability/performance problems. To give just the most obvious example, the >> target audience of such a token cannot be restricted enough, which may allow >> a resource server (or an attacker in control of it) to abuse the token on >> other servers. But the current design of the code grant type forces >> deployments to use the same token for all services. What is needed from my >> point of view is a way to request and issue multiple server-specific access >> tokens with a single authorization process. >> >> I've been advocating this topic for a long time now and I'm still >> convinced this is required to really complete the core design. We at >> Deutsche Telekom needed and implemented this function on top of the existing >> core. In my opinion, a core enhancement would be easier to handle and more >> powerful. If others support this topic, I would be willed to submit an I-D >> describing a possible solution. >> >> If we take standards really seriously, then service providers should be >> given the opportunity to implement their service by utilizing standard >> server implementations. This creates the challenge to find a standardized >> protocol between authorization server and resource server to exchange >> authorization data. Depending on the token design (self-contained vs. >> handle) this could be solved by either standardizing a token format (JWT) or >> an authorization API. >> >> Based on the rationale given above, my list is as follows (topics w/o I-D >> are marked with *): >> >> - Revocation (low hanging fruit since I-D is ready and implemented in some >> places) >> - Resource server notion* >> - Multiple access tokens* >> - Dynamic client registration >> >> 1) Dynamic Client Registration Protocol >> 4) Client Instance Extension >> - Discovery >> (10) Simple Web Discovery, probably other specs as well >> - (6) JSON Web Token >> - (7) JSON Web Token (JWT) Bearer Profile >> - 8) User Experience Extension >> - Device flow >> - 9) Request by Reference >> (depending resource server notion and multiple access tokens) >> >> regards, >> Torsten. >> Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>: >> >> >> Hi all, >>> >>> in preparation of the upcoming IETF meeting Barry and I would like to >>> start a re-chartering discussion. We both are currently attending the >>> Internet Identity Workshop and so we had the chance to solicit input from >>> the participants. This should serve as a discussion starter. >>> >>> Potential future OAuth charter items (in random order): >>> >>> ---------------- >>> >>> 1) Dynamic Client Registration Protocol >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>> >>> 2) Token Revocation >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>> >>> 3) UMA >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>> >>> 4) Client Instance Extension >>> >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>> >>> 5) XML Encoding >>> >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>> >>> 6) JSON Web Token >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>> >>> 7) JSON Web Token (JWT) Bearer Profile >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>> >>> 8) User Experience Extension >>> >>> Available document: >>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>> >>> 9) Request by Reference >>> >>> Available document: >>> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>> >>> 10) Simple Web Discovery >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>> >>> ---------------- >>> >>> We have the following questions: >>> >>> a) Are you interested in any of the above-listed items? (as a reviewer, >>> co-author, implementer, or someone who would like to deploy). It is also >>> useful to know if you think that we shouldn't work on a specific item. >>> >>> b) Are there other items you would like to see the group working on? >>> >>> Note: In case your document is expired please re-submit it. >>> >>> Ciao >>> Hannes & Barry >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
- Re: [OAUTH-WG] Rechartering Thomas Hardjono
- [OAUTH-WG] Rechartering Hannes Tschofenig
- Re: [OAUTH-WG] Rechartering Hannes Tschofenig
- Re: [OAUTH-WG] Rechartering David Recordon
- Re: [OAUTH-WG] Rechartering Torsten Lodderstedt
- Re: [OAUTH-WG] Rechartering Christian Scholz
- Re: [OAUTH-WG] Rechartering Brian Campbell
- Re: [OAUTH-WG] Rechartering Igor Faynberg
- Re: [OAUTH-WG] Rechartering Justin Richer
- Re: [OAUTH-WG] Rechartering Mark Mcgloin
- Re: [OAUTH-WG] Rechartering Torsten Lodderstedt
- Re: [OAUTH-WG] Rechartering Eve Maler
- Re: [OAUTH-WG] Rechartering Eliot Lear
- Re: [OAUTH-WG] Rechartering Mark Mcgloin
- Re: [OAUTH-WG] Rechartering Anthony Nadalin
- Re: [OAUTH-WG] Rechartering Mike Jones
- Re: [OAUTH-WG] Rechartering Eve Maler
- Re: [OAUTH-WG] Rechartering Eran Hammer-Lahav
- [OAUTH-WG] Rechartering Hannes Tschofenig
- Re: [OAUTH-WG] Rechartering Eran Hammer-Lahav
- Re: [OAUTH-WG] Rechartering Barry Leiba
- Re: [OAUTH-WG] Rechartering Richer, Justin P.
- Re: [OAUTH-WG] Rechartering Hannes Tschofenig
- Re: [OAUTH-WG] Rechartering Eran Hammer-Lahav
- Re: [OAUTH-WG] Rechartering Eran Hammer-Lahav
- Re: [OAUTH-WG] Rechartering Mike Jones
- Re: [OAUTH-WG] Rechartering Eran Hammer-Lahav
- Re: [OAUTH-WG] Rechartering Hannes Tschofenig
- Re: [OAUTH-WG] Rechartering Igor Faynberg
- Re: [OAUTH-WG] Rechartering Torsten Lodderstedt
- Re: [OAUTH-WG] Rechartering Nat Sakimura
- Re: [OAUTH-WG] Rechartering Dan Taflin
- Re: [OAUTH-WG] Rechartering Dave Rochwerger
- Re: [OAUTH-WG] Rechartering Dan Taflin
- Re: [OAUTH-WG] Rechartering Dave Rochwerger
- Re: [OAUTH-WG] Rechartering Eran Hammer-Lahav
- Re: [OAUTH-WG] Rechartering Torsten Lodderstedt
- Re: [OAUTH-WG] Rechartering Igor Faynberg
- Re: [OAUTH-WG] Rechartering Nat Sakimura
- Re: [OAUTH-WG] Rechartering JSON based request. John Bradley
- Re: [OAUTH-WG] Rechartering John Bradley
- Re: [OAUTH-WG] Rechartering JSON based request. Torsten Lodderstedt
- Re: [OAUTH-WG] Rechartering JSON based request. Igor Faynberg
- Re: [OAUTH-WG] Rechartering JSON based request. Igor Faynberg
- Re: [OAUTH-WG] Rechartering JSON based request. John Bradley
- Re: [OAUTH-WG] Rechartering JSON based request. torsten
- Re: [OAUTH-WG] Rechartering JSON based request. Phil Hunt
- Re: [OAUTH-WG] Rechartering JSON based request. Mike Jones
- Re: [OAUTH-WG] Rechartering JSON based request. Phil Hunt
- Re: [OAUTH-WG] Rechartering Multi Token Ressponse. John Bradley
- Re: [OAUTH-WG] Rechartering JSON based request. George Fletcher
- Re: [OAUTH-WG] Rechartering JSON based request. Nat Sakimura
- Re: [OAUTH-WG] Rechartering Dick Hardt
- Re: [OAUTH-WG] Rechartering William Mills
- Re: [OAUTH-WG] Rechartering John Bradley
- Re: [OAUTH-WG] Rechartering Eran Hammer-Lahav
- Re: [OAUTH-WG] Rechartering Anthony Nadalin
- Re: [OAUTH-WG] Rechartering JSON based request. Torsten Lodderstedt
- Re: [OAUTH-WG] Rechartering JSON based request. John Bradley
- Re: [OAUTH-WG] Rechartering Dick Hardt