if there is an error saving the credential to TOB, the Aries agent doesn't return the error to the issuer

[ianco]

I.e.:

• issuer sends a credential
• TOB agent receives the credential and saves it in the wallet (the protocol is automated at each step), and sends the "success" messages back to the issuer's agent
• TOB agent calls the TOB web hooks
• If there is a TOB error at this point, the issuer doesn't get notified

[andrewwhitehead]

In Aries RFC 36 there are acks and problem reports after a credential is issued. We would need to delay that until the credential has been processed by the controller (TOB) and allow it to send back problem details. The issuer should be receiving the problem report and moving the credential exchange to an error state, which would trigger a webhook for its controller.

[nrempel]

@ianco can you share more about what kind of error occurs in tob? Presumably, the credential itself is valid, but it doesn't satisfy something in the issuer registration?

[ianco]

In this specific case I just forced the error (threw an exception on receipt of the credential).

In the past we've had different errors on trying to save the credential - data issues, environment issues, database deadlocks etc.

[nrempel]

Gotcha - I will need to add a new state transition to notify the issuer that the holder has stored the credential so that both agents end with their states as "stored". This will be a final transition that TOB can trigger via the admin API.

In the case of a failure, we will need a way for TOB to notify its agent that there was a problem which will trigger a problem-report.

@andrewwhitehead I don't think we have an admin endpoint yet for triggering a problem report. Do you know if there are any examples elsewhere yet of a controller triggering a problem report?

[nrempel]

Added new issues for this work here for reference:

openwallet-foundation/acapy#96
openwallet-foundation/acapy#95

[andrewwhitehead]

@nrempel No there aren't any examples of that. There's different problem reports at the moment depending on the protocol, including the one used in the new credential protocol. I think it would need a new admin route per module to set the result of the operation and trigger an ack or problem-report. The agent would probably also need a flag to tell it to wait for the processor to complete, as in many cases the result doesn't depend on what the controller is doing.

[nrempel]

@ianco if a credential processing fails, would it be ideal if the indy credential was never stored in the wallet?

If that is the case, perhaps we could add an additional transition after a credential is received but before it is stored. The agent would pause and the controller would instruct it to continue. Does that sound ideal?

[ianco]

Yes ideally the credential registry would return an error status (to the web hook) and then the agent wouldn't store the credential.

[nrempel]

I explored using a response to a webhook to trigger a problem report to the sender but the problem with this is that webhooks need to retry in case of failure.

What I've done is added a new admin endpoint for a controller to trigger a problem report back to the other agent. I also made it so that problem-reports propagate to the agent's controller to notify the backend.

openwallet-foundation/acapy#98

I also added a new state transition so that the holder agent can pause before storing a credential and pass the data to the controller. This way, the org book can do the processing before the agent stores the credential in its wallet.

openwallet-foundation/acapy#97

So the approach will be:

1. Listen for credential_received state in webhook instead of stored

2. Adjust credential registry callback parser to look in raw_credential instead of credential:

raw_credential:

{
  "schema_id": "4QxzWk3ajdnEA37NdNU5Kt:2:string:1.1",
  "cred_def_id": "4QxzWk3ajdnEA37NdNU5Kt:3:CL:19:default",
  "rev_reg_id": null,
  "values": {
    "string": {
      "raw": "1",
      "encoded": "1"
    }
  }
}

credential:

{
  "referent": "05c7be59-0a4b-48f5-9680-55b7e7e61b5d",
  "attrs": {
    "string": "1"
  },
  "schema_id": "4QxzWk3ajdnEA37NdNU5Kt:2:string:1.1",
  "cred_def_id": "4QxzWk3ajdnEA37NdNU5Kt:3:CL:19:default",
  "rev_reg_id": null,
  "cred_rev_id": null
}

3. Once processing completes, call new admin endpoint to instruct the agent to store the credential: /credential_exchange/{id}/store

4: If the processing fails, call /credential_exchange/{id}/problem_report to send a problem report back to the issuing agent.

5. In the issuing agent controller, listen for the problem-report webhook to receive problem notifications

6. Use the thread_id in the webhook to correlate the problem with the credential_exchange that failed

[swcurran]

Isn't this done and can be closed @nrempel?

[nrempel]

Yes, moved to done.