Feature request description/rationale
From an end-user perspective, upon receiving an apply, offer, or agree, the user should be able to spurn those, so the original sender can understand why a credential flow was terminated, for example:
- a holder receives a presentation request (apply) and rejects it with a message
- an issuer receives a request for credential issuance (appy) and rejects it with a message
- etc.
There are no tests or implementation I could find in signify-ts or KERIA, but they are in KERIPY.
Feature request description/rationale
From an end-user perspective, upon receiving an apply, offer, or agree, the user should be able to spurn those, so the original sender can understand why a credential flow was terminated, for example:
There are no tests or implementation I could find in signify-ts or KERIA, but they are in KERIPY.