IdAS Update Proposals

The current way Digital Subjects are updated in IdAS is seen as cumbersome. Here we explore other options. First we list the options, then use cases, then apply the use cases to the different options.

Option 1: Current methodology

In order to make any modifications to a Digital Subject's attributes or metadata, one calls IContext.updateSubject. This takes a set of UpdateOperation objects. Each UpdateOperation specifies what is being updated (an attribute or metadata), How it is being updated (add, delete, replace), and the value(s) being updated.

• Pros
  • It's very clear to the CP what is being asked by virtue of all updates being specified in the single call.
  • Rules of atomicity apply to all updates within the operation.
    • This allows for test/set types of functionality. One can specify a value to be removed and another to be added. If the value to be removed does not exist, the entire operation fails.
  • The CP doesn't have to track state as Attributes / Metadata are being manipulated.
• Cons
  • In order to modify a part of a complex attribute, one must pass a delete (specifying the entire old complex value) and an add (specifying the entire new complex value)
    • This could be very problematic in situations where multiple people are editing different parts of the same complex value. There may be situations where the specified old value chronically causes the updateSubject call to fail due to a constantly changing complex value.
  • Users have to fetch and clone existing values in order to specify which value they are changing.

Option 2: Live updates on attributes and metadata

This proposal would allow attributes, metadata, and their values to be updated by introducing methods like:

• IDigitalSubject.addAttribute
• IDigitalSubject.deleteAttribute
• IDigitalSubject.addMetadata
• IDigitalSubject.deleteMetadata
• IAttribute.addValue
• IAttribute.deleteValue
• IMetadata.addValue
• IMetadata.deleteValue
• IComplexValue.addProperty
• IComplexValue.deleteProperty
• etc.

This gives the consumer the ability to directly edit the object which is intended to be changed. There is no notion of multi-change transactions.

• Pros
  • Very easy for the consumer
• Cons
  • Causes many small operations to be applied by the CP
    • This is especially bad if the context is backed by data over a network connection, as each operation constitutes a wire hit.
  • Leaves objects in invalid states.
    • Due to certain data constraints, this option would be impossible for certain CPs to implement because there's no way to bundle up a set of changes (which by themselves would invalidate constraints, but taken together fit within constraints). For example, a subject must have either a parent or a guardian attribute but never both. I cannot delete one prior to adding the other, nor can I add another without deleting one.

Option 3: Committed updates on attributes and metadata

This is similar to Option #2, except that we introduce a commit method where appropriate. This allows the consumer to perform unnecessary add/delete operations on data elements and follow it with a commit method. No changes are applied to the backing data until the commit method is called, and when it is called, all updates are committed as an atomic operation.