Inline: On Wed, Jul 19, 2023, 6:33 PM Michael Richardson <[email protected]> wrote:
> > 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? > It's not exactly what you are asking, but I hope it answers the question: Given some JSON-LD and an ability to understand JSON, but no ability to understand RDF... It is valuable to know that it is json, and the fact that it is LD might not matter since you don't intend to process it as RDF. In other words, it's valuable to ignore the JSON-LD processing sometimes, and just treat the content as JSON. Of course you could be ignoring processing something that will later throw an error. > > +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. > It's not redundant in the sense that application/json is a content type and application/jwt secures it. The vc+ld+json is a kind of JSON, and it can be secured in various different ways... I do think +json+jwt is redundant... But potentially it's required by structured suffixes... That's what I came here to get clarity on. > >> 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? > Tldr, open id connect calls ISO mDoc ( a digital credential format used for drivers licenses and vaccination proof) verifiable credentials... They also refer to JSON claimset that look like JSON-LD but are never processed as RDF, as verifiable credentials... My point isn't to say that this is right or wrong, just that it's a fact that people call things that are not JSON-LD "verifiable credentials"... > >> 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?) > They might convert the JSON-LD to RDF and import it into a graph data without ever checking any security proofs. > > >> 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? > I think we are agreeing. > > 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? > It wouldn't mean anything. Because it's not a registered media type. If it were registered, a specification would have been required, and that would have to answer this question. We see vc+ld+json being requested. We don't see vc+cbor or just vc being requested. We see vc+sd-jwt being requested. We see vc+ld+jwt being requested, and people challenging that it's a valid interpretation of the multiple suffixes draft... Which is why we are requesting the ambiguity be removed regarding +jwt and +cose We don't understand how the experts will review anything that depends on structured suffixes because that's never happened before... But it seems logical to assume there will be a lot of +jwt and +cose media types in the future, and some of them might require multiple suffixes. > >> 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. > It's possible in the future, there will be some CBOR encoding of RDF, and then +ld+cbor and +ld+json could both be used to represent the same application/n-quads (RDF). Will it be possible to make a COSE secured verifiable credentials then? With media type vc+ld+cbor+cose? Or would it be more accurate to use vc+ld+cose or vc+ld+cwt for that? Additional examples covering structured suffixes other than +ld+json would help make this clear... Otherwise I fear the experts will struggle to interpret the draft when registrations try to leverage it with common suffixes that are used in JOSE and COSE. > > 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 > > > > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
