Re: The "CBOR Everywhere" Project

+1 Steve

Mike Prorock
mesur.io

On Fri, Dec 16, 2022, 03:08 Steve Capell <steve.capell@gmail.com> 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..
>
>
> 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
> >
> >
>
>