Re: [OAUTH-WG] JSON Payload signature (re: draft-richer-oauth-signed-http-request-01.txt)

Phil Hunt <phil.hunt@oracle.com> Wed, 07 May 2014 00:34 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0411A071D for <oauth@ietfa.amsl.com>; Tue, 6 May 2014 17:34:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HedMTIJUPSag for <oauth@ietfa.amsl.com>; Tue, 6 May 2014 17:34:04 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEE31A072A for <oauth@ietf.org>; Tue, 6 May 2014 17:34:03 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s470XvPj019800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 May 2014 00:33:58 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s470Xu3B002234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2014 00:33:57 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s470Xu1D015969; Wed, 7 May 2014 00:33:56 GMT
Received: from [10.255.54.0] (/64.71.18.60) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 May 2014 17:33:56 -0700
References: <172266CC-2A8C-4724-9D89-F79D290B1E48@oracle.com> <97A10407-119B-4443-99C4-6AEE1DDF85A0@mitre.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <97A10407-119B-4443-99C4-6AEE1DDF85A0@mitre.org>
Content-Type: multipart/alternative; boundary="Apple-Mail-F02643CC-B162-4794-8CEF-B5968FEAFE4A"
Content-Transfer-Encoding: 7bit
Message-Id: <E947A040-F511-4581-944C-50509D53C2C4@oracle.com>
X-Mailer: iPhone Mail (11D167)
From: Phil Hunt <phil.hunt@oracle.com>
Date: Tue, 06 May 2014 17:33:56 -0700
To: "Richer, Justin P." <jricher@mitre.org>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JSjw3L4TahpYSpxGHPbQVYuziPY
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] JSON Payload signature (re: draft-richer-oauth-signed-http-request-01.txt)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 07 May 2014 00:34:06 -0000

Well...

In the case of scim which takes json requests and gives json responses, it would be nice to have signed transactions including json payload from http body. This could be easily layer on top of scim without required any change to scim. 

If however someone wants a json body like a jwt assertion (where both are in the same json structure) thats a different thing isn't it. :-)

Phil

> On May 6, 2014, at 17:19, "Richer, Justin P." <jricher@mitre.org> wrote:
> 
> Seems like a reasonable extension to me, in that it shouldn't break things, really. Is the suggestion to define a particular member for "other stuff" or to state that you're allowed to add other stuff inside the payload object?
> 
> But on the other hand, I'm wondering why other parts of the protocol (like hashing the HTTP body) wouldn't cover it? Or why you wouldn't want to just use a JOSE container for your entire protocol? Basically, within a given protocol you could easily put whatever additional stuff you like inside the protected JOSE payload without disrupting things, but I don't see the use case why you'd want to do that and not something else.
> 
>  -- Justin
> 
>> On May 6, 2014, at 6:54 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>> 
>> Justin,
>> 
>> Any discussion on including JSON payloads in the signed requests?  Had an interesting conversation with Bill and I think this would be a useful optional feature.
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>> 
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>