Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 19 April 2012 18:31 UTC
Return-Path: <torsten@lodderstedt.net>
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 65D7011E80B6 for <oauth@ietfa.amsl.com>; Thu, 19 Apr 2012 11:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 BR4DgJ1xEyDm for <oauth@ietfa.amsl.com>; Thu, 19 Apr 2012 11:31:17 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by ietfa.amsl.com (Postfix) with ESMTP id 70C9111E808A for <oauth@ietf.org>; Thu, 19 Apr 2012 11:31:17 -0700 (PDT)
Received: from [79.253.16.77] (helo=[192.168.71.36]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1SKw8Q-0004x3-V1; Thu, 19 Apr 2012 20:31:15 +0200
Message-ID: <4F9059F5.1050705@lodderstedt.net>
Date: Thu, 19 Apr 2012 20:31:17 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Justin Richer <jricher@mitre.org>
References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> <4F885BF9.2080307@mitre.org> <4E1F6AAD24975D4BA5B1680429673943664668FF@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F88713C.6070309@mitre.org> <sjm62cz33zo.fsf@mocana.ihtfp.org> <4F8C6D43.2030701@mitre.org> <4F8F1B9F.1040302@lodderstedt.net> <4F8F1D94.4090208@mitre.org> <4F8F1F9C.7020008@lodderstedt.net> <4F8F22C4.6000900@mitre.org>
In-Reply-To: <4F8F22C4.6000900@mitre.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: Derek Atkins <derek@ihtfp.com>, "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
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: Thu, 19 Apr 2012 18:31:18 -0000
Hi Justin, In my opinion, the OpenID Connect introspection/checkid endpoint is a convenience function for clients (not resource servers) unable to decrypt id tokens and validate their signatures. I'm not convinced this function is needed, that's why I proposed to drop it. The AS-PR endpoint servers a different purpose, as it allows to implement handle-based token designs. The AS just creates simple token (e.g. a random number), which is very small and does not need to be encrypted or signed. This might result in simple designs. On the other hand, the PR needs to lookup authz data as part of the request implementation, which might have a negative impact on performance and scalability. That's where self-contained tokens, such as JWT have their merits. I don't think one would combine self-contained tokens with an AS-PR endpoint. Or is this the case in any existing implementations? The point I wanted to make is: no matter how the resource server acquires authz data (as token content/JWT or via request to another AS-PR endpoint), the authz data will be the same. And as part of the JWT standardization, we will identify this data and specify a JSON format to represent it. The same representation could be used at the AS-PR endpoint as well. regards, Torsten. Am 18.04.2012 22:23, schrieb Justin Richer: > I think we might be crossing wires about input to the token > introspection endpoint vs. output from it. > > In OpenID Connect, you send a JWT in, and get back a JSON object that > represents the Claims bit of the JWT. > > In our implementation (and I think both Ping and AOL's), you send in > an arbitrary token (with no proscribed format) and get back a JSON > object with different pieces in it. Ours included a list of scopes and > an expiration timestamp, others did different things, like audience > and issuer, as part of the return. > > The point I was trying to make is that the information returned from > the AS-PR interface isn't necessarily embedded inside of the token > used to call that interface. In OpenID Connect, it is, and the CheckID > endpoint just unwraps the JWT for you. In the larger case, what's > really going on is that the PR presents a token that it's not sure > what it's good for and gets back something that answers that question. > Since a JWT Claims section can be an arbitrary JSON object (for all > intents and purposes), you could use a JWT as the output of the > introspection endpoint as well. > > -- Justin > > On 04/18/2012 04:10 PM, Torsten Lodderstedt wrote: >> Hi Justin, >> >> I refered to the data format used at the AS-PR interface. According >> to your description, you use JSON objects there. What data does such >> an object contain? Is this any different from a JSON Web Token >> (leaving aside digital signatures and encryption)? >> >> regards, >> Torsten. >> >> Am 18.04.2012 22:01, schrieb Justin Richer: >>> Not all implementations in the field that do this are using JWTs as >>> the tokens. Ours in particular used a random blob with no structured >>> information in it. The endpoint returned a JSON object. >>> >>> -- Justin >>> >>> On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote: >>>> Hi all, >>>> >>>> is there enough experience in the field with such an interface to >>>> standardize it? >>>> >>>> I would expect such an endpoint to return the same payload, which >>>> is carried in a JSON Web Token. So once we designed the JSON Web >>>> Tokens content, designing the AS-PR interface could be the next >>>> logical step (after the next re-charting). >>>> >>>> regards, >>>> Torsten. >>>> >>>> Am 16.04.2012 21:04, schrieb Justin Richer: >>>>> >>>>>>> OK, but with SWD and discovery off the table, can this now be >>>>>>> considered to be within that manageable number instead? >>>>>> We wanted to keep the # of WG items to approximately 5. Once we >>>>>> finish >>>>>> some of these items and get them off our plate we could roll new >>>>>> items >>>>>> onto the plate, theoretically. >>>>>> >>>>> >>>>> That's definitely true going forward, but what I was saying is >>>>> that the number of items under consideration is now down to 4, >>>>> with SWD moving to the Apps group. I was proposing that the whole >>>>> introspection endpoint and general AS-PR connection could be this >>>>> group's fifth starting document. >>>>> >>>>> -- Justin >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >
- [OAUTH-WG] Updated Charter to the IESG (this week… Hannes Tschofenig
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Eran Hammer
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Paul Madsen
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Igor Faynberg
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Mike Jones
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Justin Richer
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Mike Jones
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Justin Richer
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [OAUTH-WG] Updated Charter to the IESG (this … John Bradley
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Brian Campbell
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Derek Atkins
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Justin Richer
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Torsten Lodderstedt
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Justin Richer
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Torsten Lodderstedt
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Justin Richer
- Re: [OAUTH-WG] Updated Charter to the IESG (this … John Bradley
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Torsten Lodderstedt
- Re: [OAUTH-WG] Updated Charter to the IESG (this … Eve Maler
- Re: [OAUTH-WG] Updated Charter to the IESG (this … John Bradley