Re: The "CBOR Everywhere" Project

On 2022-12-16 11:07, Steve Capell wrote:
> No - of course we can work on an improved v2 while promoting the implementation of v1
> 
> It was more the narrative about a parallel alternative in IETF that does the same thing but better because it’s more compact etc.  in my view the business benefits of an interoperable verifiable trust architecture are orders of magnitude larger than the cost differences between more compact / less compact implementations that I struggle to understand why I should care.  I’d rather see one standard with defect uptake than two competing ones that hold back uptake because implementers are waiting to see which one wins..

There are unfortunately many and conflicting standard efforts in this space.  HTTP signatures is an example of an extremely complex signature solution which doesn't build on JOSE or COSE.

Canonicalization of JSON data never got proper IETF support.  CBOR doesn't need canonicalization which (if exploited...) may affect just about everything.

Using CBOR it might be possible creating a nimble and still potentially more universal security framework.  CBOR's ability dealing with any data in an efficient way limits the number of options you need in the framework.

Personally, I will stop using JSON except for browser-based applications like WebAuthn.

Anders

> 
> 
> Steven Capell
> Mob: 0410 437854
> 
>> On 16 Dec 2022, at 8:59 pm, Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net> wrote:
>>
>> 
>> Steve, are you against constructive discussion about what needs to be fixed in the current DID and VC specs?
>>
>> I don't believe these discussions impinge on efforts to further adoption of either spec.
>> Adoption can be viewed as almost tangential.
>> For example, here's a link to my efforts to further the cause: https://hyperonomy.com/2022/12/12/welcome-to-web-7-0/ <https://hyperonomy.com/2022/12/12/welcome-to-web-7-0/>
>>
>> Looping back ...are you against constructive discussion about what needs to be fixed in the current DID and VC specs?
>>
>> Michael
>>
>> Get Outlook for Android <https://aka.ms/AAb9ysg>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> *From:* Steve Capell <steve.capell@gmail.com>
>> *Sent:* Friday, December 16, 2022 1:55:47 AM
>> *To:* Anders Rundgren <anders.rundgren.net@gmail.com>
>> *Cc:* Leonard Rosenthol <lrosenth@adobe.com>; Christopher Allen <ChristopherA@lifewithalacrity.com>; W3C Credentials Community Group <public-credentials@w3.org>
>> *Subject:* Re: The "CBOR Everywhere" Project
>> I have to say that I find it a bit distracting and annoying that there is a discussion about how a recently released standard (VC & DID) is imperfect and should be fixed with a new standard
>>
>> Nothing is perfect and adoption is more far far more important than perfection.
>>
>> Steven Capell
>> Mob: 0410 437854
>>
>> > On 16 Dec 2022, at 7:30 pm, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>> > 
>> > 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 <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 10:48:23 UTC