Expression of expiry conditions

[dimi-schepers]

A Consent can be limited in time, e.g. you are allowed to view my monthly income until 2021-12-31. However, more complex expiry conditions can also be imagined, e.g.

• frequency (e.g. 5 times)
• periodically (e.g. once every month)
• event-based (e.g. until I switch jobs)
• etc.

It is an open question how to model these heterogeneous kinds of expiry conditions and whether a suitable expression language already exists.

[michaelgeamanu]

GConsent uses hasExpiry to define an instant, duration or time period. Similarly to this expiration is being used in the model.

Additionally, expiryCondition is used to facilitate defining the expiry in a more general way. Yet, the vocabulary in which this can be done is still to be found.

[michaelgeamanu]

During the 3rd thematic workshop the group discussed the option to not use any event-based expiry conditions and focus on time, frequency and/or cadence to define an expiry instead. Hereby we put the responsibility with the requester to define a clear timeframe in which the consent is needed or plan a renewal of the consent to make sure it is still valid.

Here again it is still an open discussion, but during the 4th thematic workshops we will use some use cases to test this way of defining the expiry of a consent.

[michaelgeamanu]

During the last workshop this topic was addressed again. Everyone agreed that if an expiry is legally expressible by using quantifiable attributes this should be used, but whenever the expiry conditions are more subtle, it would be ideal to use criterions to define the expiry.

To do so the class Expiry will be added as a subclass of CCCEV:Criterion. This makes it possible to combine both options within one class. And so, make it more overseeable.