Re: [jose] [COSE] Multiple Suffixes with JOSE and COSE media types

[Orie Steele <[e-mail]>]

Inline:

On Wed, Jul 19, 2023 at 4:48 PM Michael Richardson <[e-mail]>
wrote:

>
> Orie Steele <[e-mail]> wrote:
>     >
> https://github.com/w3c/vc-jose-cose/pull/123#pullrequestreview-1537381740
>     > Summarizing for folks who won't read the above link.
>
> Yeah, that discussion seems allover the place :-(
>
>     > The include:
>
>     > https://github.com/w3c/did-core - requests `did+ld+json`.
>     > https://github.com/w3c/vc-data-model - requests `vc+ld+json`.
>
>     > Also a quick note that the W3C Tag has an open issues related to this
>     > topic: https://github.com/w3ctag/design-principles/issues/239
>
>     > The problem we are having is that it is not clear how multiple
> suffixes
>     > apply to envelope formats, like JOSE and COSE.
>
> Agreed.
>
>     > For example:
>
>     > Should it be `application/vc+ld+json+jwt` or `application/vc+ld+jwt`
>     > (because JWT always secures a JSON claimset and a JSON header).
>
> I'm not even sure I know what the "+ld" part is supposed to imply or
> permit.
>

https://w3c.github.io/json-ld-syntax/#application-ld-json

TLDR; JSON-LD is a syntax for RDF that is both JSON and RDF.

+ld+json is a structured suffix for saying that some JSON is also JSON-LD.


> Are there VCs which are *NOT* LD, but are also still JSON (JOSE)?
>
>
Depends on who you ask...
Speaking for myself and friends who I work with on this stuff at W3C, IETF
and OIDF.... Our answer is YES.

- https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt
- https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc
-
https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-2
-
https://openid.net/specs/openid-connect-userinfo-vc-1_0.html#name-userinfo-vc-verification


>     > Similar question for COSE, should it be
> `application/vc+ld+json+cose` ?
>
> Typo for vc+ld+cbor+cose?  What would the LD mean here?
>
>
It doesn't mean anything today, but it might mean:

https://digitalbazaar.github.io/cbor-ld-spec/

...in the future, which is basically a semantic compression on JSON-LD that
exploits RDF to transform JSON-LD into CBOR.


> To me, there are two things that the media types need to convey.
>
> a) to some tool looking at content from the outside.  Debugger, wireshark,
>    (including humans pasting stuff at each other through chat during an
>    online interop session).
>
> Do I know how to decode this stuff in a useful way?
> For +gz (and a few others) there is a very strong utility here.
> The computer can decompress the content easily, and the human (looking a
> hex-dump or equivalent) can *NOT*.
> {I used to be able to read 6502 machine code in hex, and I know people who
> still can, but I can't decompress anything in my head}
>
> That +jwt is useful because it means that the human being aided by a
> competent debugger can easily see which parts are the signature, and which
> parts are the different headers, payloads, and which need to have their
> base64url encoding removed and reparse.  I don't see any other use.
>
>
Yes I agree, +jwt lets intermediate processors consider the header and
claimset as JSON...

even if they don't know what a "vc" or "dpop" is... see also
https://www.iana.org/assignments/media-types/application/dpop+jwt


> b) Accept: headers tell the responder what kinds of things the requester is
>    willing to accept. Again here, the +gz is very easy to add and cope with
>    at a generic level.
>    The +jwt isn't: you either know you are signing the VC, or you don't
> know
>    what a VC is.
>
>
Not sure I agree, consider an API that issues tokens that comply with
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp-07#section-3.11

POST /token/issue
--content-type application/json
--accept application/dpop+jwt
--accept application/vc+jwt
--accept application/at+jwt

The server might apply different validation to the post body depending on
what the client requested...
for "dpop" it might require "cnf"...
for "vc+ld+json+jwt" it might require `@context` (a JSON-LD thing)...
for "vc+sd-jwt" it might NOT require an `@context` (not all VCs are JSON-LD)
for "vc+ld+json+sd-jwt" it might require an `@context` ... etc...

The content type going in is always application/json...  (or sometimes
application/ld+json)....
...but 400 errors come out when the json is not capable of supporting the
normative requirements associated with a more specific token type...

For example:
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422


> Again, I don't what information "+ld" is conveying. That's probably on me
> though.
>
>
+ld by itself is not conveying anything (unless it was registered)... but
`+ld+json` would convey that the JSON is also some encoding of RDF, see

- https://w3c.github.io/json-ld-syntax/#interpreting-json-as-json-ld
- https://w3c.github.io/json-ld-syntax/#relationship-to-rdf


> Regardless, ANIMA is having similar difficulties as we could easily build
> multiple + into our media-types, and our documents are basically all in
> WGLC
> (because of circular dependancies), and this topic is holding us up.
>
>
IMO, if it's possible to avoid multiple suffixes, it should be avoided...

+sd-jwt could have been +sd+jwt... but there have been a lot of open
questions on multiple suffixes,
I think they made the right call
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-05#name-structured-syntax-suffix-re

The outermost thing is also "debatably" not a JWT, because of it using ~
character in its encoding...

We'd sure like media-man to make some progress.
> There might not be time or the right constituency at IETF117 to do this, so
> maybe a virtual interim and/or wide-ranging design team meeting is in
> order.
>
>
I know @Manu Sporny <[e-mail]> has been doing most of the
work on this, with pretty limited feedback...
I've been trying to raise awareness because of the related work at W3C
which depends on multiple suffixes.

I don't know if his other co-authors are active on the draft, but I agree
that it would be nice to accelerate the development pace if possible.


> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>