search

decentralized-identity / credential-manifest

Format that normalizes the definition of requirements for the issuance of a credential
https://identity.foundation/credential-manifest/
Apache License 2.0
30 stars 22 forks source link

suggest decoupling presentation_submission and credential_application #66

Closed Sakurann closed 2 years ago

Sakurann commented 3 years ago

when the user presents credentials (assuming VCs) in presentation_submission, based on the presentation_definition in the credential_manifest, they need to be replay protected, so that I am not replaying complete VCs that belong to someone else.

To do that it makes sense to have a flow like 1/ holder tells which credential it wants issued; 2/ issuer gives the wallet a challenge (server provided nonce for example); 3/ holder presents input VCs in presentation_submission bound to that challenge.

I think that would mean decoupling presentation_submission and credential_application.

Aries seems to be taking a similar approach: https://github.com/hyperledger/aries-rfcs/blob/main/features/0511-dif-cred-manifest-attach/README.md#propose-credential-attachment-format

dtmcg commented 2 years ago

with in the credential application there is an UUID value for the ID this ID for a given holder can be used to protect against reply attacks. Will update in line. { "credential_application": { "id": "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d",

decentralgabe commented 2 years ago

Closing, as the identifier @dtmcg mentioned serves as replay-attack prevention.