Connecting child documents to the correct parent documents via API using Request VC doc blocks

[CyndyMo]

I have a policy that flows as illustrated below, per the IWA dMRV spec. I am using Request VC document blocks within the policy to store the data and support the workflow. When using the UI, documents are correctly associated to one another through the chain of messageID>relationships.

When using the APIs, how do you associate the child document to the correct parent? In the UI, this is managed through how the request VC for the child is located on the same line as the parent in the document grid. However, if per the diagram below, I have data coming in as Ecological Claims 1-4 via API, how do I make sure those VCs have relationships to the correct parent Claim Source document?

[anvabr]

To link the document via API you'd need to pass into the request block ref which contains the parent document together with the value of the document, i.e. the body will look like this:
{ document: ${credentialSubject}, ref: ${parentVCdoc} }

In the created VC document's credentialSubject the will appear a ref, which would contain the credentialSubject.id from the parentVCdoc (see above), and in the case where the parentVCdoc was published in Hedera in the created VC there will also be its messageId in the relationships.

To check the correctness of relationships you could check this in the the created VC document and verify that it contains the messageID of the parent VC document.

https://docs.hedera.com/guardian/guardian/standard-registry/policies/policy-creation/introduction/request-workflow-block#api-parameters

[marko-zeroproxy]

Hi folks, can we unmark this discussion as answered? This remains an open issue that we are still working on. Thanks.

[CyndyMo]

Does the ID of the connected VC mean the messageId or some other identifier?

…

On Thu, Feb 22, 2024 at 11:06 AM Andrey (Envision Blockchain) < ***@***.***> wrote: https://docs.hedera.com/guardian/guardian/standard-registry/policies/policy-creation/introduction/request-workflow-block#api-parameters — Reply to this email directly, view it on GitHub <#3270 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2AORXMNIHPBIHC6P74WPPTYU53LHAVCNFSM6AAAAABDVGNA6KVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKNJZGUZDO> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[anvabr]

Sorry @CyndyMo, accidentally posted the answer before I typed it in properly. Hopeful what is now above answers this?

[CyndyMo]

Maybe? The script I have been using to send to block by tag doesn't consider the credential subject so this is something I will need to experiment with. Thank you for getting back to me!

[AlexIvanHoward]

Hi All. I'm trying this, but with no success.

Attached is a simple policy (just change the '.zip' extension back to '.policy' to import it into your Guardian instance). Steps:

1. Create and submit a Form A via the API.
2. Create and submit a Form B via the API with 'ref' set to the credentialSubject.id of the Form A submitted in step 1.
   My JSON for step 2 thus looks like this:

{
  "document":{
        "addition":12345,
        "division":"Undefined",
        "type":"ef6774fd-30f2-4cef-9307-13e46a291152&1.0.0",
        "@context":"ipfs://bafkreifr6zeudsp6ova6t7vv5muvfnbivkoapzt2lk2ru32clob4ogqql4"
  },
  "ref":"urn:uuid:01192694-ccc4-4f15-8e5c-2328b18e3adf"
}

But for some reason I keep on getting a 500 error with message "Invalid relationships". I've tried passing the value to "ref" without the "urn:" and without the "urn:uuid:", but it it also fails.

I'm using Guardian version 2.21.1.

Please help.

policy_1713185713329.zip

[anvabr]

Just checking, has the 01192694-ccc4-4f15-8e5c-2328b18e3adf document been published? Can I have its IPFS link please?

[AlexIvanHoward]

Sure, here it is:
https://bafkreid7k7b4g45cksogmgih73rwggznwdqghp2zakkmrjnsogmrjkzrkm.ipfs.w3s.link/

[anvabr]

Hi @AlexIvanHoward this issue caused us quite a bit of head scratching, we have not been able to conclusively answer the question but have a theory that you might be experiencing a timing issue. I.e. to use a doc as a ref it needs to have already been saved in the DB. If Form A and Form B are created in a rapid succession it might be that it has not happened yet for the Form A doc. This can happen because requestBlock returns asynchronously while the request is potentially is still being 'served' by the sendBlock.

We verified your policy in dryRun and in full publish mode as per the screenshots below. Please not that urn:uuid: should not be removed.

[AlexIvanHoward]

Thank you for the response, @anvabr . I tried submitting a Form B now linked to a Form A which I submitted already yesterday, and still got the same error, so I doubt it is a timing issue. I will continue looking into it.

[anvabr]

Just a note, to avoid a possible confusion (which we originally thought was the source of the error, but upon closer examination found out it was not) - it needs to be credentialSubject.id.

[AlexIvanHoward]

That's what I've been using, thank you, @anvabr.