Orie Steele <[email protected]> wrote: >> > +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.
If the debugger goes right to left, and does not speak jwt, then it would
have stop there. The presence of +json does not help it at all.
This my rational for just writing +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?
>>
> Tldr, open id connect calls ISO mDoc ( a digital credential format used
> for drivers licenses and vaccination proof) verifiable
I was thinking you'd paste some JSON blob :-)
>> 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.
Ah, okay, interesting.
A debugger would do this?
> 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
Agreed, we need to remove that ambiguity.
I also think that we might need an RFC3999 experiment here.
--
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
