Orie Steele <[email protected]> wrote: >> > 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.
okay, let me rephrase.
Given some json-ld, is there any point in knowing that it's JSON, if you
don't also know it's LD?
> +ld+json is a structured suffix for saying that some JSON is also
> JSON-LD.
It just seems redundant. I'd rather see application/vc+ld+jwt.
>> 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
I didn't visit those URLs yet, maybe you could give us a consise example?
>> 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
exactly, so I agree with wanting to say application/vc+jwt.
(I'm undecided if the +ld part belongs yet, but I could accept it.
Tell me what a VC ignorant debugger could do with the +ld part?)
>> 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...
I am not arguing that at all, just that sometimes we might need the extra
specific distinctions just for the accept... maybe we are agreeing though?
> 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...
I'm not arguing anything about the content-type.
What would: "--accept application/vc" even mean then?
>> 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
Then I think that the +json part is redundant.
> I know @Manu Sporny <[email protected]> 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 [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
