From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org Fri Dec 23 09:22:58 2022 Return-Path: X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16818C1516E9 for ; Fri, 23 Dec 2022 09:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mit.edu Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9tIpdrlHBV0 for ; Fri, 23 Dec 2022 09:22:50 -0800 (PST) Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3AC2C1516E0 for ; Fri, 23 Dec 2022 09:22:49 -0800 (PST) Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1p8lke-002nAS-Nv for ietf-http-wg-dist@listhub.w3.org; Fri, 23 Dec 2022 17:22:32 +0000 Resent-Date: Fri, 23 Dec 2022 17:22:32 +0000 Resent-Message-Id: Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1p8lkc-002n9V-LP for ietf-http-wg@listhub.w3.org; Fri, 23 Dec 2022 17:22:30 +0000 Received: from outgoing-exchange-5.mit.edu ([18.9.28.59]) by titan.w3.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1p8lka-00F8Wb-5S for ietf-http-wg@w3.org; Fri, 23 Dec 2022 17:22:30 +0000 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 2BNHMGcD024966; Fri, 23 Dec 2022 12:22:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1671816137; bh=3BVBfXs2lB+hPTKDMdehU63zNOnZGRNfyYCm+1Xsyww=; h=From:To:Subject:Date:References:In-Reply-To; b=MzBUwpndPvvFAVELiGvb8KaQfJfUYMz9R3IRfZn6zCaGx0z3Dv3U2CUwGwDtr33+E PjFM03JxGBEPjIfUSChj5REZ+3HM2GeclXapV6DQ/gE2Ghuf+12cv0BdNN3FcIYMgE fcfPY5zQovO0OAv1Fcz+bS64Ax1EscZCujBofytCZ7gdzUjZ6JXeHP9PwBU/AhkUCk xNgyC4o2LKcs0dzVByy7JRjVww5e4NH3zUmfXKK1vQrvx3PwiqsBvRqdBuWR8Irhlp 4WnE9n2c6ke49Urp2Gnv8JL0GvOoRx611Oo4PRZ8mnvwIuEMXOhIdxJ/kH/d6IKmS1 dgJZghvfjHaWA== Received: from oc11expo9.exchange.mit.edu (18.9.4.14) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Fri, 23 Dec 2022 12:21:59 -0500 Received: from oc11exhyb5.exchange.mit.edu (18.9.1.110) by oc11expo9.exchange.mit.edu (18.9.4.14) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Fri, 23 Dec 2022 12:22:16 -0500 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (104.47.74.40) by oc11exhyb5.exchange.mit.edu (18.9.1.110) with Microsoft SMTP Server (TLS) id 15.0.1497.42 via Frontend Transport; Fri, 23 Dec 2022 12:22:15 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i3/uy0ECaveRaP7SZp+eB1WWA5xQMQGJvtRIQJiQ1IgD5WKFSud6VJ/t4krJ6uDXZNS5uIHhbBHZsivbCFld79o0BnJcIOBR29gshTPtEXLzw4Ley5tmu9OdMYt4JFgma/xr9en4RzbiwasYsssI2Tmr0YideykJAbBCGTm1F39JwYIFRyZiUl+r1XEQuW2GYg7DzFWdiZonKz06YsQYuwZ5wdrq+/rPCfBEEGphPL9EVbdoGsGWzm9kgkWT5UZAssgb05XZnPyc0KOrwXgps/KG4veQIJrd/ebZdBA4SY+yZkOyWwZgCT0XRg5rU8pP1DcwsdQ92Q69bUu/5K2cKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3BVBfXs2lB+hPTKDMdehU63zNOnZGRNfyYCm+1Xsyww=; b=D+kvrNWP3HbH0QmrmxYJmL++rFdD7K+trAV7dE8eI90MqRT5UQZ8VW3VF2G2VKO1kiiVOLQtwb9WyAbVUHnvo9+ssHE3Y4/OFyi5zVWKO4Pp9PbOcCz5bseXpgFfVWbzgTTdeTin0BhkyN+10dWaCP4YyJ/kl4XdODlhsAlM0Qwi0FC7u3/gda3ap8wZqCtEw3g9I8IAv9SECo4GZZoBszq57avumSebNbxXkyLL3lwN5f8Sod6syyyJCYaerdm7KHuTb1E2UBXDQedaedApJR3LK1xJ8mNxQUBHwmrm6rP17Ir5Lcnth5Hq3A9P6f2NrnOW7u5KKqTQY7IiZmPFfw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass header.d=mit.edu; arc=none Received: from DM6PR01MB4444.prod.exchangelabs.com (2603:10b6:5:78::15) by SN6PR01MB5104.prod.exchangelabs.com (2603:10b6:805:b8::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5924.16; Fri, 23 Dec 2022 17:22:14 +0000 Received: from DM6PR01MB4444.prod.exchangelabs.com ([fe80::62:d23d:3d8d:88d3]) by DM6PR01MB4444.prod.exchangelabs.com ([fe80::62:d23d:3d8d:88d3%5]) with mapi id 15.20.5924.016; Fri, 23 Dec 2022 17:22:14 +0000 From: Justin Richer To: Anders Rundgren , HTTP Working Group Thread-Topic: CBOR versus HTTP Message Signature Thread-Index: AQHZE3FhLQmH685owE2q35UtFr+WSa57fuHTgAAoAACAABaC9Q== Date: Fri, 23 Dec 2022 17:22:14 +0000 Message-ID: References: <9A670797-BEF3-41A5-A73F-3715F1617EF0@amazon.com> <930cc3b5-7d12-16cb-3538-d31545de8f54@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=mit.edu; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM6PR01MB4444:EE_|SN6PR01MB5104:EE_ x-ms-office365-filtering-correlation-id: bd68df0d-1861-45c1-1887-08dae50a3bc6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hxsArNBnLjAayvcjm0sTc1hvgj6EUb9mNYPU7WxKkLjGgmhaoPsdJ1JH4/xoEaShLVL+J8ZZvlEuo+ncF3vidqYb7T1tuLuFhdCAE0Gp5Decq3man+tm8MuZfHQ9Sua93FCemq6vgimNHi+wfWH4OAWqPSHI2RIoDzgYtS67zKlsNJ7OV8dGnb9dyFpN3jxidhvRlznpyAEB1l3IhcTuSBKG2I8CiE8b9JZq8Csk8MrElgl/mCiFXiQ5NPJJ8hrV0Zkl4v5bNsRruBNZtk1YWcvSEQ9nKWB6ZqY6Jgq/CoM2vAxkDonGeDnIc0q071wduhQrbN4dkNHUqADbIkUJ4tU55bRMFRG5WxR1cyFNQCVaV8soTp/wVj4CzOdvYjFH1KCBjKB6RSZsnrqAShhXCmApXjarrwp0exbf0/ajibpDC3fj9B1PrNl8Y6g0OV/JAHuzCLEPrXSOhnai5D6u4s4OC40q0QUtWxgAynfRCutkkGfClG8JygtlhjwqwmJgIjDEz5KxqPpZkBTzePGyXbBWur9xIGksRwRePMpnILfAbTCyC2c3Lz17/ICUMQ4bbR+b786QdkbolNEZRZY89MwVu+ySnRqiOi9lgehssmnHeXY5jumEjFuYMGkL0YOTw8bkb1oO52ck+DRo67WNDb6XaKdVrz0PaEj36SAofd0TGlGAJ7HsSbsciUKFrat4X5p1sHnWF8qbzjG8qAOtVfdR5gR5CscAWxfyoCiegRs= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR01MB4444.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(39860400002)(376002)(366004)(136003)(396003)(346002)(451199015)(71200400001)(6506007)(38070700005)(166002)(7696005)(75432002)(2906002)(9686003)(478600001)(26005)(83380400001)(33656002)(966005)(38100700002)(122000001)(66574015)(55016003)(86362001)(186003)(76116006)(4001150100001)(5660300002)(8936002)(52536014)(66446008)(66556008)(66476007)(8676002)(64756008)(66946007)(41300700001)(53546011)(91956017)(316002)(786003)(110136005)(15650500001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?moFJPeDCtyQRNhbRkKdH5UH9BKqHnZqw+tWmGXESIVwmOUvcJ9hcs3yP57QN?= =?us-ascii?Q?WllgshOjbFq7m5bFfLhjGIcNStrk/7o7nHozrc3AVxVdvmp+O+WITQPf38UR?= =?us-ascii?Q?pYdGZHUKzDQgW1lafG54CrQcbn1DjEWO4GLBW87Y7G2hffnyUadxbYkg73qm?= =?us-ascii?Q?IcZvRv7BmdDkN+l7ATEtA1Dp7AoozeouJWrxkNZIJTQPv6QPkSrpolOcZibN?= =?us-ascii?Q?4c7JXmq86W6M6/oirFRgNGZWzDm3mCaK6tL8gEo2kxoOOnv09a5aLAfT2CVq?= =?us-ascii?Q?u/uCWOtyiFzH+O2SOzq8+hgg+9LqeMa2zPwmrHN/NxjnRTfOEgrfz5iaiNZz?= =?us-ascii?Q?usoKneaQvOhdUYFWncUP6vNLw6fmLT5bwfkH9ERST8aGACp6Jjnukd8X9Ax4?= =?us-ascii?Q?grFN+5OD6Qtd84ZkHCKaesxSbCLUnzy3hrapqTOd+dVmrWMOlEANXgqDPark?= =?us-ascii?Q?EouKJQnS/VWG1z4XbUkxNOM/6vYQlW2gilJEGdDffjNw5iGcUii5alcM8qaQ?= =?us-ascii?Q?de2IfsOATpAUPXoJZ4tVBM0vq9WTMDYTrGGNbWE8FyjgBOB3OMoP2vWxuFWr?= =?us-ascii?Q?v8cGBSCzmTgMNE4rt9PgvIjORjo1qeb01jct8XWTO526+r9s/+L/fyYUM8LV?= =?us-ascii?Q?JIh/WMkfM0svvk12KuJuy5a+6diGyxFAZ8xng/11cbuVoNoMs6dK69CBvE5p?= =?us-ascii?Q?ipKXITyjcxE16et0g9NsCqn54kWl0YcR8CkXeRy+01I4InDkPgIK5rZpM70x?= =?us-ascii?Q?O0DNNNXTcChUpYon2aZJ7HsGG4ZiBNqN1mlKqsSgfD3VD7eJ3sh1vETcEPRb?= =?us-ascii?Q?tTLt+SIXpBM9hEaw+6ho9d0DpciPnbmoRNhvQkNACHeKXnB9evrOe6rAzrcL?= =?us-ascii?Q?TogYkdJcgUpBby+iFFLpDKCqsWfYR4drcHRBrWBEvEb1dbnU22VLvu/3Y/0I?= =?us-ascii?Q?48EXEDL5NFTVJEiwMJis0Sez3OwBzmX/VGVObf+N+sTc0G47NeLdayI24z8y?= =?us-ascii?Q?iM0sRfVDNTr8fExg+KDg+z4oS7CGNUSHF6++k0nwhVoFSGrHyxhbuZLg0zsA?= =?us-ascii?Q?zrbJjlqUnvWyKAFp6VAdExTIsSV/kB7DOOfMMoq9tbG99Fc9PF824vOpU6YP?= =?us-ascii?Q?HZL0vxfF7YUCRzgsY8SzythLjBpeD+EmryTcNay8h44frG2mioAeFltlNQZQ?= =?us-ascii?Q?KkigacI/LJ0K5YgjMNk2TqcwoRhLgYNZx81R802RJKR49GPc/HVZQNTR7Ghm?= =?us-ascii?Q?2BeX0jv1XWphmi7Xbazu/kcgFzAv7FyG+hyj8UTS/fKMYtBx0AgFFvxprLa+?= =?us-ascii?Q?O87AZYoEvn7u0X+C8o7l8uSSCohlcsoOShC7oaEk5jc6gnZ+MDG98kgAXHHW?= =?us-ascii?Q?pm7KAsXL5lHkYqlGc9QOBWcuBFxBv19a326iy817CZTakT5uBzdEJf81g0Xf?= =?us-ascii?Q?DiTjvxnIdEhjkk0CbVxmy7lyZkNKdYeUlPOkiBgxVY75+ATnUaMkFCmeaGpb?= =?us-ascii?Q?cXfwXUNfdeEHJY4UFMaWNRvyAF2vOHnJYTqBWiQ9yeV7MsX1s0rUKwkh7o5w?= =?us-ascii?Q?rbP29inhVdcvb+8eM/c=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR01MB44448F6E36796A6B794940FBBDE99DM6PR01MB4444prod_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR01MB4444.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: bd68df0d-1861-45c1-1887-08dae50a3bc6 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2022 17:22:14.0993 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HTeI1bza0Ltn+uo7R2il1La+CMWK0xmcmAzaZ6POC84NRlyy2PYGkA95o6MS2rkc X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB5104 X-OriginatorOrg: mit.edu X-W3C-Hub-DKIM-Status: validation passed: (address=jricher@mit.edu domain=mit.edu), signature is good X-W3C-Hub-Spam-Status: No, score=-7.4 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1 X-W3C-Scan-Sig: titan.w3.org 1p8lka-00F8Wb-5S 14b101a448ccdbf75355c89a0422730e X-Original-To: ietf-http-wg@w3.org Subject: Re: CBOR versus HTTP Message Signature Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/40664 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --_000_DM6PR01MB44448F6E36796A6B794940FBBDE99DM6PR01MB4444prod_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you For that. One of the biggest problems with a fully self contained= signature format like this is that it necessitates copying information fro= m the transport layer into the payload area. For example, you'd need to cop= y the method and header values and effectively transfer them twice, while a= lso needing to make sure they matched. About a decade ago, I deployed a system that did exactly that but using jos= e. This was for a healthcare exchange. We found the process to be awkward a= t best, and at worst it easily lends itself to lazy developers not checking= the consistency of the message components between the HTTP Message itself = and the cryptographic payload. This leads to a whole family of problems tha= t the HTTP spec avoids by using a completely detached mechanism. Plus we we= re limited to JSON messages, and had to replace all our processors to handl= e only Jose payloads. In fact, it was my experience deploying this system t= hat largely led to my favoring the detached approach in practice. Both have= tradeoffs but having done both, I'd pick the detached method every time. -Justin ________________________________ From: Anders Rundgren Sent: Friday, December 23, 2022 10:54 AM To: Justin Richer ; HTTP Working Group Subject: Re: CBOR versus HTTP Message Signature Hi Justin, I fully support the WG item. What I did found out though, is that for designs standardizing on CBOR as d= ata interchange format, there are alternatives like the one I provided in t= he sample. - In the RATS WG, "objectId" has been defined through the combination of 1)= parameterized content-type, 2) CBOR tags 3) profile URI. However, the XML= /XSD world (including the ISO 20022 folks), managed just fine with a single= URI which also became a part of the object data itself, effectively decoup= ling objects from their transport. - To not leave HTTP headers in the dark, I'm suggesting copying the this pa= rt from your excellent draft. - Finally, by building on CBOR deterministic serialization, bstr/B64 "armor= ing" of data becomes redundant, enabling enveloped signatures at no additio= nal cost or risk. Although object serialization is probably a no-issue for most designs, it i= s a pretty useful feature for systems creating attested (and potentially st= ateless) tokens. This is the origin of this concept. Anders On 2022-12-23 14:37, Justin Richer wrote: > The HTTP Message Signatures draft is not specific to JSON or any other da= ta encoding format, so I'm not sure what you're trying to say here. Are you= saying that cbor/cose would be a replacement for a general purpose HTTP si= gning mechanism? But: You don't need any JSON processing to implement the s= pecification. That was one of the smaller goals of the spec, the larger asp= ect being that it should live natively in HTTP space and not be tied to API= or data use cases. > > Yes, there are lots of other ways to sign things, and they've got differe= nt properties that make sense in different environments. I suppose if you'r= e doing something entirely in cbor already, something else might make sense= , but that isn't the goal here. > > - Justin > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ----------------- > *From:* Anders Rundgren > *Sent:* Monday, December 19, 2022 1:12 AM > *To:* HTTP Working Group > *Subject:* CBOR versus HTTP Message Signature > > Dear List, > I hope you don't mind me elaborating a bit on an alternative to the curre= nt IETF WG item. > A decode ago I converted from XML/XSD to JSON. > Now I have converted to CBOR for many reasons including support for a wid= er set of data items, and last but not least deterministic serialization. > > If you put all these things together you can obtain similar results as wi= th HTTP Signatures, but in a package that may better match the rest of a ty= pical system. > > https://github.com/cyberphone/cbor-everywhere#signed-http-requests > > > There are probably not many who are prepared scrapping their huge investm= ents in JSON based systems. JSON also remains the [currently] only viable = alternative for browser based applications. > > Cheers, > Anders > --_000_DM6PR01MB44448F6E36796A6B794940FBBDE99DM6PR01MB4444prod_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank you For that. One of the biggest problems with a fully self cont= ained signature format like this is that it necessitates copying informatio= n from the transport layer into the payload area. For example, you'd need t= o copy the method and header values and effectively transfer them twice, while also needing to make sure they = matched. 

About a decade ago, I deployed a system that did exactly that but usin= g jose. This was for a healthcare exchange. We found the process to be awkw= ard at best, and at worst it easily lends itself to lazy developers not che= cking the consistency of the message components between the HTTP Message itself and the cryptographic payload. = This leads to a whole family of problems that the HTTP spec avoids by using= a completely detached mechanism. Plus we were limited to JSON messages, an= d had to replace all our processors to handle only Jose payloads. In fact, it was my experience deploying this= system that largely led to my favoring the detached approach in practice. = Both have tradeoffs but having done both, I'd pick the detached method ever= y time.

-Justin
From: Anders Rundgren <a= nders.rundgren.net@gmail.com>
Sent: Friday, December 23, 2022 10:54 AM
To: Justin Richer <jricher@mit.edu>; HTTP Working Group <ie= tf-http-wg@w3.org>
Subject: Re: CBOR versus HTTP Message Signature
 
Hi Justin,
I fully support the WG item.

What I did found out though, is that for designs standardizing on CBOR as d= ata interchange format, there are alternatives like the one I provided in t= he sample.

- In the RATS WG, "objectId" has been defined through the combina= tion of 1) parameterized content-type, 2) CBOR tags 3) profile URI.  H= owever, the XML/XSD world (including the ISO 20022 folks), managed just fin= e with a single URI which also became a part of the object data itself, effectively decoupling objects from their transpor= t.

- To not leave HTTP headers in the dark, I'm suggesting copying the this pa= rt from your excellent draft.

- Finally, by building on CBOR deterministic serialization, bstr/B64 "= armoring" of data becomes redundant, enabling enveloped signatures at = no additional cost or risk.

Although object serialization is probably a no-issue for most designs, it i= s a pretty useful feature for systems creating attested (and potentially st= ateless) tokens. This is the origin of this concept.

Anders

On 2022-12-23 14:37, Justin Richer wrote:
> The HTTP Message Signatures draft is not specific to JSON or any other= data encoding format, so I'm not sure what you're trying to say here. Are = you saying that cbor/cose would be a replacement for a general purpose HTTP= signing mechanism? But: You don't need any JSON processing to implement the specification. That was one of t= he smaller goals of the spec, the larger aspect being that it should live n= atively in HTTP space and not be tied to API or data use cases.
>
> Yes, there are lots of other ways to sign things, and they've got diff= erent properties that make sense in different environments. I suppose if yo= u're doing something entirely in cbor already, something else might make se= nse, but that isn't the goal here.
>
> - Justin
> ----------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= --------------------
> *From:* Anders Rundgren <anders.rundgren.net@gmail.com>
> *Sent:* Monday, December 19, 2022 1:12 AM
> *To:* HTTP Working Group <ietf-http-wg@w3.org>
> *Subject:* CBOR versus HTTP Message Signature
>
> Dear List,
> I hope you don't mind me elaborating a bit on an alternative to the cu= rrent IETF WG item.
> A decode ago I converted from XML/XSD to JSON.
> Now I have converted to CBOR for many reasons including support for a = wider set of data items, and last but not least deterministic serialization= .
>
> If you put all these things together you can obtain similar results as= with HTTP Signatures, but in a package that may better match the rest of a= typical system.
>
> https://github.com/cyberphone/cbor-everywhere#signed-http-requests= <https://github.com/cyberphone/cbor-everywhere#signed-http-requ= ests>
>
>
> There are probably not many who are prepared scrapping their huge inve= stments in JSON based systems.  JSON also remains the [currently] only= viable alternative for browser based applications.
>
> Cheers,
> Anders
>

--_000_DM6PR01MB44448F6E36796A6B794940FBBDE99DM6PR01MB4444prod_--