[Openid-specs-ab] OpenID4VCI: JSON-LD processing of request and metadata fields

Thu Feb 23 15:55:18 UTC 2023

Ah, yes, I responded to a wrong thread. It was meant to be for "Issue #1831: OpenID4VCI: W3C data model based formats and the use of "types" vs "type" (openid/connect)", to which torsten just responded to. Apologies for the confusion.

A PR for this thread , is here: https://bitbucket.org/openid/connect/pull-requests/463.
(at least in my mind) the intension was never to require JSON-LD processing for anything other than the actual Credential expressed using JSON-LD, so no JSON-LD processing requirements for Credential Offer, Credential Issuer Metadata, etc.

Best,
Kristina

From: Brian Campbell <bcampbell at pingidentity.com>
Sent: Thursday, February 23, 2023 5:30 AM
To: Kristina Yasuda <Kristina.Yasuda at microsoft.com>
Cc: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] OpenID4VCI: JSON-LD processing of request and metadata fields

In this email thread Judith had suggested that any requirements regarding JSON-LD processing of metadata or request parameters are not appropriate and should be removed. That made sense to my (admittedly limited) understanding of the discussion and intent of the spec. And was what I was hoping wouldn't get lost. I don't think that PR touches on that at all.

On Wed, Feb 22, 2023 at 8:28 PM Kristina Yasuda <Kristina.Yasuda at microsoft.com<mailto:Kristina.Yasuda at microsoft.com>> wrote:
There is a PR addressing this topic: https://bitbucket.org/openid/connect/pull-requests/461/changed-types-claim-to-type-to-comply-with<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fpull-requests%2F461%2Fchanged-types-claim-to-type-to-comply-with%3Flink_source%3Demail&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cca8d3de7cdce43aeba3908db15a216e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638127558170791878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gZECI18AOWmVYYrzf2oT0hbsjWs6hGWM71YUzfMVb7g%3D&reserved=0>
Please review.

The issue documenting the insights would be great too :)

Cheers,
Kristina
________________________________
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>> on behalf of Brian Campbell via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
Sent: Wednesday, February 22, 2023 3:28:38 PM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
Cc: Brian Campbell <bcampbell at pingidentity.com<mailto:bcampbell at pingidentity.com>>
Subject: Re: [Openid-specs-ab] OpenID4VCI: JSON-LD processing of request and metadata fields

Thanks for the insights Judith,
Please do open an issue - I worry that the mailing list discussion will get lost in the noise and passage of time. Or not even seen by the document editors.

On Sat, Feb 18, 2023 at 2:18 AM Judith Kahrer via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:
Hi David,
Thanks for sharing your point of view and confirming some assumptions. I fully agree with you. The statement is not my opinion but was a quote from the current specification that did NOT refer to any verifiable credential but required JSON-LD processing for a metadata field and request parameter (see E.1.3.2<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-4-verifiable-credential-issuance-1_0.html%23server_metadata_ldp_vc&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cca8d3de7cdce43aeba3908db15a216e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638127558170791878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4TGIGeR8btfLHlOOGxcPvtD8CbF8yHiI2cByMtIPehY%3D&reserved=0> and E.1.3.3<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-4-verifiable-credential-issuance-1_0.html%23section-e.1.3.3&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cca8d3de7cdce43aeba3908db15a216e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638127558170791878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=v0aJdhQNwfTrEGxzDxCY8SO5CZ5IAFGog09XWrKIpi4%3D&reserved=0> in Appendix E of the current draft). I also think, that metadata and protocol defined in OpenID4VCI should be pure JSON and not JSON-LD. Consequently, the requirements regarding JSON-LD processing for credentials_supported and credential_definition should be removed as those are part of the metadata and request respectively. They are not, once more, any credential (such can only be found in credential responses).
Following that, any @context-field in an object that is NOT a credential, should be removed as well. I'll open an issue with suggested changes.

Regards, Judith
On Sat, Feb 18, 2023, 08:59 David Chadwick via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:

Hi Judith

thankyou for your excellent response. I agree with most of what you say, but not the following "This object MUST be processed using full JSON-LD processing". It is my understanding that the protocol and metadata are pure JSON and should not be referred to as JSON-LD. Thus the current text is wrong if it either states or implies this. OTOH, the retrieved object may be a W3C Conformant VC (in which case it MUST contain the @context property) but this does not mean that the wallet has to perform any JSON LD processing on it. On the contrary pure JSON processing is sufficient if the semantics of JSON-LD are not required and JWT proofs are being used (I am not sure if the same is true for LD proofs). Interworking between JSON-LD processing and pure JSON processing issuers and wallets has already been adequately demonstrated (in the JFF plugfest). So I do not believe having an @context property in a credential is an issue that OID4VCI should be concerned with. Personally I do not think that our protocol should be supporting non-standard credential formats (i.e. any type of JWT) and should only support ISO mdl and W3C VCs either JWT or LD-proofed (but I think I am in a minority here). However, the W3C VC F2F this week has now agreed that verifiable credentials must have an @context property. Other serialisations that do not contain an @context property may be specified, but mapping rules from these to W3C VCs must be defined for them to be accepted in the W3C VC v2 recommendation. The mapping may be one way (from serialisation X to W3C VCs) or bi-directional and lossless. However, no examples of serialisation X have been fully specified so far, so until they are I do not think OID4VCI should include them (which currently it does).

Kind regards

David
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-ab<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cca8d3de7cdce43aeba3908db15a216e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638127558170791878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zSVPzQ%2FbbzityCgph3USYcZpO6ZadXnJGMJzro%2Byv%2FY%3D&reserved=0>

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230223/70b1fcfe/attachment-0001.html>