Time-Constrained Access

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

Summary

A content holder can share a link to the content user that is used to access the content only within the specified time window.

Context

Access to content should be finite. For example, a user identification process usually lasts for a certain time period. After proving the identity of a party, the presented credential has accomplished its mission and should not be accessed again.

Note that the narrative of this pattern is presented in the context of self-sovereign identities. An identity credential could be generalised to any digital or digitalised content stored on the blockchain.

Problem

After receiving content such as an identity credential, a user/verifier can continue to access, read, and verify certain identity data of the holder. If the credential is long-term or even permanently effective, the verifier can check the holder’s identity data even when there is no legitimate reason to do so. How to prevent access to a credential beyond a specific time interval?

Forces:

Privacy – A holder’s identity information should not be accessed or verified when the current identification process is finished.
Flexibility – Verifiers have their own identification processes, which may take different amounts of time. Also, an identity or its attributes may be accessed multiple times.
Cost – On a public blockchain there is a cost to generate and maintain credentials. Hence, the cost of generating a separate credential for each interaction/relationship is cost-prohibitive.

Solution

First, get the issuer to create a credential and store it in the identifier registry. Second, request a reverse oracle service to keep track of the credential. Third, when the credential needs to be shared with a verifier the holder can generate an identifiable link to the credential with the support of the reverse oracle service. Also, specify a time window where the link remains accessible. Forth, share the identifiable link with the verifier off-chain, instead of the original credential itself. Finally, within the predefined time window, the verifier can visit and verify the credential for identification. Once the link is expired (i.e., the accessible time window is expired), the oracle should deny any requests from verifier to obtain credential content.

Instead of specifying the link valid time window at the reverse oracle, it can be recorded at the identifier registry aganst verifier’s identity. Further, rather than sharing a link, URL of the reserver oracle and credential identifier could be shared with the verifier. This way, the reverse oracle could be made stateless. For example, to retrieve the credential the verifier could send a request to reverse oracle’s URL with the credential identifier and verifier’s identity. To prove the verifier’s identity to either reverse oracle or identifier registry the verifier could sign the request. Further, if exists, the verifier’s identity can be verified against the identity registry too. Subsequently, the reverse oracle can query identifier registry for the given credential identifier and validate whether the given request is from an approved verifier and within the set time window.

This pattern can be generalised to control access to any digital or digitalised content stored on the blockchain.

Benefits

Privacy – A holder can determine the accessible period of the shared link, which ensures that the holder’s identity information can only be fetched within the specified time window. An expired credential cannot be verified again. Consequently, a malicious verifier is unable to further utilised the identity data.
Flexibility – Shared links do not affect the original credential. Consequently, this pattern can be applied to a credential valid for a long time, where links with different accessible periods can be sent to different verifiers.
Cost – Cost is reduced as the credential is created and recorded only once.

Drawbacks

Privacy – A malicious verifier may take a copy of the credential when accessing it. Then it has the credential content even if the shared link is expired. Although the compromised credential cannot reveal up-to-date information of the holder, the attacker still maintains the historical identity attributes of the holder.
Permissioned – This pattern assumes that the verifier cannot access the blockchain directly, instead needs to rely on the service of a reverse oracle.
Cost – If the verifiers and valid time windows are recorded on the identifier registry, the transaction cost to include them in the registry increases.

Related patterns

This pattern can work collaboratively with selective content generation pattern, to generate credentials with fine-grained access specifications.
The one-off access pattern can be seen as a derivative of time-constrained access where access is limited to once.
The identifier registry pattern is used to maintain the credentials registry.
The reverse oracle pattern is required to provide and limit access the credential stored on-chain.

Known uses

Snapchat is a social media messaging solution in which users can share their photos and videos. However, every shared photo or video is automatically deleted after a certain amount of time.
Snappass is a website where users can generate secret information and share it by a URL. A user can set a valid time period to each secret, within which the secret information can be read.