Deactivating registrations

[elf-pavlik]

This issue should be considered along #278

In most cases registrations shouldn't be deleted but marked as deactivated.

Access Authorization

We need a clear way to deactivate authorizations. Since they are immutable, it most likely should be an Access Authorization which states that access was rejected. (related to #278)

Agent Registration

While Application Registration always should have an Access Grant, it is not required for Social Agent Registration.
I think we should answer if we only need an Access Grant that reflect mentioned above Access Authorization which gives not access. Possibly we want to make the whole registration as inactive, this could be used in #138 where user needs to select agents they want to grant access to. The deactivated ones would not appear in the list.

Data Registration

This one probably needs some clear use cases. I'm not sure what deactivating data registration would mean. Also what would happen if access is requested for shape tree registered in deactivated data registration.

[elf-pavlik]

I'm going to implement interop:deactivatedAt this week

[elf-pavlik]

We had initial working session today, starting from Access Authorization and Access Grant generated from it.

Discussed grantedAt and deniedAt timestamps felt less ergonomic than other discussed alternative.

• createdAt - when the authorization gets created (no matter granted or denied)
• granted - boolean (safer than denied boolan which in case of missing value might default to denied: false)
• hasDataAuthorization (or Grant) - only present when granted: true

Please let me know what do you think

@angelaraya tomorrow we should wrap it up and make PRs to all the appropriate implementation repositories

---

There is also a question if we need a case where access is not granted (denied) but agent registration is not deactivated. How does it differ from case where agent registration is activated (assuming that this would always go in pair with denied authorization & grant)

---

We also currently plan to treat initial deny / rejection #278 the same as cases which have some previous positive grant.
History should be always available but in the current state (snapshot) I don't think there is a need for treating initial deny as some special case.