You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, there is no good, standard way to interface with issuers and request credential issuance in Veramo
Implementation should include utility functions for creating message types, message handlers for processing / saving messages, and anything required to maintain the "state machines" described in the protocol. This should include any "optional" messages such as "Propose Credential".
Message handlers should support both automated processing of messages (according to a provided policy, like is done in the Coordinate Mediation 3.0 protocol implementation) as well as user-intention processing (e.g. the received message is saved and the next step of the state machine is not initiated until the user reviews it and takes action)
Implementations should respond correctly when receiving an "impossible" message (e.g. one that does not fit into the state machine).
Some implementation details (such as payment decorators) should be considered optional. If not implemented, please leave a //TODO in the appropriate places
This specification originated in the Hyperledger Aires community. If there are any parts of the spec that are unsupported by Veramo, they can be left unimplemented (but leaving a //TODO is apreciated)
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Is your feature request related to a problem? Please describe.
Currently, there is no good, standard way to interface with issuers and request credential issuance in Veramo
Describe the solution you'd like
An implementation of the "Issue Credential 3.0" DIDComm protocol, as described here: https://didcomm.org/issue-credential/3.0/
Implementation should include utility functions for creating message types, message handlers for processing / saving messages, and anything required to maintain the "state machines" described in the protocol. This should include any "optional" messages such as "Propose Credential".
Message handlers should support both automated processing of messages (according to a provided policy, like is done in the Coordinate Mediation 3.0 protocol implementation) as well as user-intention processing (e.g. the received message is saved and the next step of the state machine is not initiated until the user reviews it and takes action)
Implementations should respond correctly when receiving an "impossible" message (e.g. one that does not fit into the state machine).
Implementation should have significant test coverage (i.e. > 90%) and exercise the test vectors specified here: https://github.com/decentralized-identity/waci-didcomm/tree/main/test/vectors
notes
payment decorators
) should be considered optional. If not implemented, please leave a//TODO
in the appropriate places//TODO
is apreciated)The text was updated successfully, but these errors were encountered: