Inline: On Wed, Jul 19, 2023, 8:12 PM Michael Richardson <[email protected]> wrote:
> > 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. > This argument makes sense to me. > >> >> 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 :-) > VC 1.1 example (2.0 is in progress now): { "vc": { "@context": [ "https://www.w3.org/2018/credentials/v1"; ], "type": [ "VerifiableCredential", "UserInfoCredential" ], "credentialSubject": { "id": "did:jwk:eyJrdHkiOiJFQyIsInVzZSI6InNpZyIsImNydiI6IlAtMjU2Iiwi eCI6InFpR0tMd1hSSm1KUl9BT1FwV09IWExYNXVZSWZ6dlB3RHVyV3ZtWkJ3 dnciLCJ5IjoiaXA4bnl1THBKNU5wcmlaekNWS2lHMFR0ZXFQTWtyemZOT1VR OFl6ZUdkayIsImFsZyI6IkVTMjU2In0", "sub": "248289761001", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "preferred_username": "j.doe", "email": "[email protected]", "picture": "http://example.com/janedoe/me.jpg";, "phone_number": "+1 202 555 1212" } }, "iat": 1667575982, "exp": 1668180782, "iss": "https://server.example.com"; } > >> 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? > Yep, same use case as the APIs for decoding protected header and claimset in JOSE APIs. You can process header, or claimset values without verifying the token... But you have to be careful when doing so. > > 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. > I fear whatever you are referring to regarding RFC3999. > -- > 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
![http://example.com/janedoe/me.jpg"](http://example.com/janedoe/me.jpg"){kind=link}