Attribute Validation

Created by

Remus Golgot

Last updated Jan 17, 2019

I. Attribute Validation Request (AVR)

  • The validation request cannot have as validator the owner of the attribute

  • A validation request cannot expire

  • A validation request cannot be created for an expired attribute

  • A validation request cannot be created for an <attribute,validator> pair if another PENDING_APPROVAL validation request already exists for that pair

  • The validator of any validation request cannot be changed once the request has been created

  • Cancellation of a validation request

    • Can only be performed by the owner of the request

    • Action is available once the validation request is created, and before it is Approved or Declined ( in other words, whenever the request is in PENDING_APPROVAL status )

  • Approve/Decline answer for the validation request

    • The validator has the option to either Approve or Decline any validation request that was created with him/her as validator

    • Since the Approve/Decline action is triggered by the validator, he/she must have the necessary funds to pay for the transaction fees required to create the blockchain transaction

  • State Transitions :

    • AVR is created → PENDING_APPROVAL status

      • AVR is approved → APPROVED status

        • Can subsequently be completed by the validator
      • AVR is declined → DECLINED status

        • (?!) Because the transition between PENDING_APPROVAL and DECLINED requires a transaction ( and fee), it is unlikely this will ever be used by the validator, since he/she has no incentive to pay the decline transaction fee for something they will never be rewarded in the future

        • This means zombie requests might exist in the system → will it make sense to clean them up somehow ?

      • AVR is canceled → CANCELED status

    • AVR is IN_PROGRESS status

      • AVR is notarized → COMPLETED status

      • AVR is rejected → REJECTED status

        • (?!) Because the transition between IN_PROGRESS and REJECTED requires a transaction ( and fee), it is unlikely this will ever be used by the validator, since he/she has no incentive to pay the reject transaction fee for something they will never be rewarded in the future
  • A validation request cannot be created for a non-document attribute that is not associated to any other document type attributes

    • No reason for a validation process to even be triggered for an attribute that has no underlying proof of its value ( inside the system )
  • State Transition Table :

Status\Action APPROVE DECLINE NOTARIZE REJECT CANCEL
PENDING APPROVAL IN PROGRESS DECLINED ERROR ERROR CANCELLED
IN PROGRESS ERROR ERROR COMPLETED REJECTED ERROR
DECLINED ERROR ERROR ERROR ERROR ERROR
COMPLETED ERROR ERROR ERROR ERROR ERROR
REJECTED ERROR ERROR ERROR ERROR ERROR
CANCELLED ERROR ERROR ERROR ERROR ERROR