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

John Bradley <ve7jtb@ve7jtb.com> Thu, 19 April 2012 09:51 UTC

Return-Path: <ve7jtb@ve7jtb.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 A912221F858F for <oauth@ietfa.amsl.com>; Thu, 19 Apr 2012 02:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level:
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 z9GWp1ZJTzOI for <oauth@ietfa.amsl.com>; Thu, 19 Apr 2012 02:51:47 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC78021F8568 for <oauth@ietf.org>; Thu, 19 Apr 2012 02:51:42 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so5685090wgb.13 for <oauth@ietf.org>; Thu, 19 Apr 2012 02:51:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=wnCvuUe2lZHGKN74eu61GEW1JyxiXi9OfXUZHjurFy8=; b=EL4K6dmSNofSndqA+UVgsDC+BXCHq8aq3jmdlfIUm1RCVl/G97Fq36x+6sFPkBFJhy kL9bgd0ge/j+ntcy/0mrl2QZZbrh7qd47OaulBO7y4uztPyWyPT5GAgRf408pbwTZgHf 7wPFdsge3pcjIuClgLOwkulswQQFQyIs/RE86sWL0wbL46bgvdn6Czv/0HQjideT5VdQ XWvfZ2OuFQmqqWkaKzrSYoJbrF/+Hio3IO6qKxV6ItKrBVliLzqutSNgS/XFcMU0TbMs GqcIppRG+k+X4pLXRDi9CNTVEhiWDRG/D67tRZX9Qm6hWW2BDInV5lGdKc3Ah4k/6qy9 oy9w==
Received: by 10.180.78.40 with SMTP id y8mr24721981wiw.15.1334829101238; Thu, 19 Apr 2012 02:51:41 -0700 (PDT)
Received: from [10.6.1.77] (nat-VI.gw1.ush2.tnib.de. [86.110.65.2]) by mx.google.com with ESMTPS id w10sm6628533wiy.3.2012.04.19.02.51.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 02:51:36 -0700 (PDT)
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>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/signed; micalg="sha1"; boundary="Apple-Mail-6F00A1D5-1F63-482B-81FF-CA0EC9E77961"; protocol="application/pkcs7-signature"
Message-Id: <5992B241-D477-4CE2-835A-F163A66AF9D9@ve7jtb.com>
X-Mailer: iPad Mail (9B176)
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Thu, 19 Apr 2012 11:51:58 +0200
To: Justin Richer <jricher@mitre.org>
X-Gm-Message-State: ALoCoQn0+brjGL2+TcINYWm1l85t9fRxuQj31PxcBDIPn1l5SIGI7hzCj65LlJZjuL2PiAdX0xIV
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 09:51:54 -0000

Some of the use cases I have discussed with people also involve returning SAML tokens in the response for dealing with some existing systems.

In principal if the RS is authenticated to the AS  (perhaps with OAuth) then the correct response format RS can be provided.    

We need to decide what parts of this get standardized. 

I am hoping for a interesting discussion on this at IIW that can inform an update to the Ping ID and used as a input for a eventual WG item.

John B.

Sent from my iPad

On 2012-04-18, at 10:23 PM, Justin Richer <jricher@mitre.org> wrote:

> 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 mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth