Re: The "CBOR Everywhere" Project

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