Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)

Justin Richer <jricher@mitre.org> Wed, 18 April 2012 20:24 UTC

Return-Path: <jricher@mitre.org>
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 4759511E8085 for <oauth@ietfa.amsl.com>; Wed, 18 Apr 2012 13:24:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 SzbTSTnYGbbX for <oauth@ietfa.amsl.com>; Wed, 18 Apr 2012 13:24:13 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F203111E8080 for <oauth@ietf.org>; Wed, 18 Apr 2012 13:24:11 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A12A821B02BD; Wed, 18 Apr 2012 16:24:11 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9A26421B02A7; Wed, 18 Apr 2012 16:24:11 -0400 (EDT)
Received: from [129.83.50.12] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 18 Apr 2012 16:24:11 -0400
Message-ID: <4F8F22C4.6000900@mitre.org>
Date: Wed, 18 Apr 2012 16:23:32 -0400
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Torsten Lodderstedt <torsten@lodderstedt.net>
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>
In-Reply-To: <4F8F1F9C.7020008@lodderstedt.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.51]
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: Wed, 18 Apr 2012 20:24:23 -0000

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
>>