Re: The "CBOR Everywhere" Project

I believe the IETF first came into the discussion because some (including myself) feel the W3C/CCG are too narrowly focused on "Web 2.0/3.0" technologies when they think of decentralized specifications. ...very different and more important than looking for more compact representations for VCs.

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Steve Capell <steve.capell@gmail.com>
Sent: Friday, December 16, 2022 3:07:15 AM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Cc: Anders Rundgren <anders.rundgren.net@gmail.com>; Leonard Rosenthol <lrosenth@adobe.com>; Christopher Allen <ChristopherA@lifewithalacrity.com>; W3C Credentials Community Group <public-credentials@w3.org>
Subject: Re: The "CBOR Everywhere" Project

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..


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/


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>) 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
>
>