Attribute Update

Created by

Remus Golgot

Last updated Jan 17, 2019

The following document details the chosen design of the attribute update mechanism and the drawbacks of alternative approaches.

Proposed Solution

  • Prerequisite

    • The system should support multiple attributes of the same type for a given owner

      • If the user wants to keep using his old attribute value as well as the new one, he should create a new attribute, not update the old one
  • Requirement :

    • Either the attribute value or the attribute expireTimestamp must change in order for an update to take place

      • If the update request contains both the value and the expireTimestamp the same as the existing ones, nothing is being done

        • Thus it prevents the unnecessary spending of an updateAttribute fee for an update that actually does nothing
  • Flow :

    • updating an attribute overrides the old value of that attribute with the new given value

    • updating an attribute overrides the old expireTimestamp value of that attribute with the new expireTimestamp

    • after an attribute is updated

      • It becomes inactive → can no longer be used in any of the identity use or consumption flows

      • The incomplete validation requests made before the update are discarded and their validation is impossible, as well as any other action

    • if the attribute gathers 1 new validation within a calendar year, it becomes active and can be used in all the flows

      • Only validations made based on requests that came after the last update are considered

PROs

  • Only one pair of <owner, attribute_type> is saved in the blockchain for a given attribute ( reduced complexity )

  • The support for multiple attributes of the same type is still permitted. It can be useful for attributes like emails, phone numbers, etc.

Alternative solutions ( discarded )

Keeping the old value

  • Updating an attribute means creating a new attribute instance, which does not affect the existing attribute

    • if the old attribute is active, it remains so and can still be shared, consumed, etc.
  • When the new attribute gathers the required validations, the old one is effectively replaced

PROs

  • User can still use the old attribute ( if active and not expired ) before gathering all the validations of the new one

CONs

  • Required validations may vary between services and providers

  • Harder to implement support for multiple attribute types per owner

    • After the replacement of the old value, the user will no longer be able to use that attribute ( which may still be active/not expired )

    • If the old attribute it is not replaced after it expires, but instead kept in the system, then the blockchain will store redundant data

      • Cleanup of this redundant data may be possible, and who would pay the fees for this hypothetical cleanup ?

Attribute Type based decision

  • A combination between the proposed solution and Keeping the old value, where the decision on whether or not to keep the old value is made based on the attribute type

  • Has all the CONs of Keeping the old value, with additional ones :

    • The cyclomatic complexity is bigger, now a check for the attribute type is also necessary

    • Harder to extend/maintain

    • Loss of cohesion and consistency

Attribute State based decision

  • A combination between the proposed solution and Keeping the old value, where the decision on whether or not to keep the old value is made based on the attribute state

    • If the attribute is inactive or expired, the proposed solution is followed ( attribute is replaced )

    • If the attribute is active and not expired, Keeping the old value is followed

  • Has all the CONs of Keeping the old value, with additional ones :

    • The cyclomatic complexity is bigger, now a check for the attribute state is also necessary

    • Harder to extend/maintain

    • Loss of cohesion and consistency