- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Fri, 16 Dec 2022 09:28:22 +0100
- To: Leonard Rosenthol <lrosenth@adobe.com>, Christopher Allen <ChristopherA@lifewithalacrity.com>
- Cc: W3C Credentials Community Group <public-credentials@w3.org>
On 2022-12-15 15:26, Leonard Rosenthol wrote: > Anders – this COTX proposal is very much in line with that we do in C2PA (http://c2pa.org <http://c2pa.org>) with respect to custom extensions to our various CBOR grammars, though we didn’t think to fully structure it as you did. We simply require that each key name be the full URI, since we don’t currently have a lot of them. But I’ll bring yours up as something worth moving to. Thanx Leonard! Combined, the JSON-2-CBOR "conversion" scheme has rather far-fetching consequences which is better described in the most recent update: - Single external mime-type: application/cbor - Single decoder/multiple object types handling - Challenging COSE... Naturally, each feature is optional. What's maybe not so obvious is that these features combined, represent a viable alternative to HTTP signatures [*]. The core benefit is that signed HTTP requests may be expressed as self-contained objects. I have exploited this in a design where received signed request data is embedded in a counter-signed envelope and then returned to the requester. In this particular design, the returned object functions as an "attested token request" which may have other uses than the payment scenario I dealt with. By embedding the request, the resulting token may potentially be stateless. Anders *] Such a scheme would obviously need to copy the handling of HTTP header data, but the result would be put in the CBOR (message) body. > > Thanks! > > And, obviously, we are also fully on the CBOR (and COSE) train for all the reasons that you and Christopher mention. > > Leonard >
Received on Friday, 16 December 2022 08:28:35 UTC