Report Problem for Cloud-Agent Scenarios

[mineme0110]

The Report Problem protocol is defined in the DIDComm Messaging Spec. This protocol describes sending a problem report to another party
When processing any step of any protocol, if something is wrong, the cloud agent tries to:
Log the error in the service logs
Send the problem report message when appropriate

https://identity.foundation/didcomm-messaging/spec/#problem-reports

Custom behavior table

This table defines the expected behavior of the cloud agent in different scenarios not covered by the specifications.

Cloud Agnet	Description	error
Scenario G1	Receive a message for an unsupported protocol	Send a problem report e.p.msg.unsupported
Scenario G2	Receive a message for an unsupported version of the protocol.	Send a problem report e.p.msg.unsupported
Scenario G3	When an internal error or any unexpected error happens	Send a problem report e.p.error
Scenario G4	If the message is tampered or got any crypto errors when decoding	Send a problem report e.p.crypto
Scenario G5	If the DID method is not supported	Send a problem report e.p.did
Scenario G6	If the DID method is malformed	Send a problem report e.p.did.malformed
Scenario G7	A parsing error from the decrypted message.	Send a problem report e.p.msg.<PIURI> if the plaintext message is malformed or if parsing into a specific protocol's data model fails.
Issuance Protocol Role Issuer
Scenario I1	(Holder Binding)The Holder signs the domain and challenge of the credential request using an unknown DID, an incorrect DID, or a mismatched key	Invalid Credential Request Send a problem report e.p.msg.invalid-credential-request
Scenario I2	Credential request is malformed, missing required fields, or fails validation	Invalid Credential Request Send a problem report e.p.msg.invalid-credential-request
Scenario I3	The invitation has expired, and the holder's attempt to send Credential Request is no longer valid.	Expired Invitation Send a problem report e.p.msg.credential-request-from-expired-invitation
Scenario I4	Holder requests a credential format the issuer cannot process.	Unsupported Credential Format Send a problem report e.p.msg.unsupoorted_credential_format
Issuance Protocol Role Holder
Scenario H1	Holder is not satisfied with the offer-credential (e.g., invalid terms, missing attributes).	Invalid Offer Credential Send a problem report e.p.msg.offer-credential
Present Proof Protocol Role Holder
Scenario H2	Holder receives a presentation request demanding over-disclosure, such as revealing DOB.	Invalid presentation Request Send a problem report e.p.msg.disclosure-not-possible
Scenario H3	Holder receives a presentation request demanding VC of type Passport.	Invalid presentation Request Send a problem report e.p.msg.presentation-not-possible
Present Proof Protocol Role Verifier
Scenario V1	Domain challenge binding between holder and credential fails verification	Verification Failure Send a problem report e.p.msg.verification-failed-request
Scenario V2	Credential presented by the holder has expired.	Expired Credential Send a problem report e.p.msg.presentation-from-expired-credential
Scenario V3	The invitation has expired, and the holder's attempt to send Presentation from expired Presentation Request Invitation.	Expired Invitation Send a problem report e.p.msg.presentation-request-from-expired-invitation
Scenario V4	Holder presents a credential that is invalid or does not satisfy the verifier's request criteria.	Invalid Credential Presentation Send a problem report e.p.msg.invalid_credential_presentation

[mineme0110]

I'd like to engage you all in a discussion about the scenarios and behaviors we've outlined for the Report Problem protocol. The current list is quite comprehensive, covering scenarios from unsupported protocol messages to internal error management and beyond

Therefore, I encourage you to weigh in:

• Are there any scenarios that we've missed?
• Do you have a different approach to any of the current scenarios?

Your input will help us make these more robust

[robertocarvajal]

is the idea that the agent replies to the origin party with the error report or to just log it internally? or perhaps forwarding the error to the cloud agent controller wallet?