<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body>

openid/sharedsignals event <br>

<br>

Issue Comment created on issue 211 <br>

Issue Title: Permanence of streams <br>

https://github.com/openid/sharedsignals/issues/211 <br>

<br>

Comment: I'd like to propose that this be added to _vFinal_ instead of _vFuture_. **Reasoning** The main issue is security. Permanent access to data (security events) for PUSH receivers is a potential security hole. We can contrast this with something like

 Oauth grants that are limited in both scope and duration. The duration limit is missing, once the stream is opened by a PUSH Rx, the Tx is expected to continue sending events until the stream gets paused or deleted. This also leads to asymmetry in the PUSH

 and PULL flows, where the PULL Rx is re-authed every time it pulls events, while the PUSH Rx may not communicate again for many years after creating the stream. It would be great to have a way in the spec for Tx that are going to auto-expire streams (currently

 strongly preferred for the Google Tx implementation) to communicate this fact. I'll send out a PR shortly. **Cost Estimate vs ID3** This only affects PUSH streams, and the Rx changes should be minor, considering that most affected Rx will already have an automated

 way of calling Tx methods. Most Tx/Rx pairs will be ID3 backwards compatible. Some Tx will optionally communicate a stream expiry duration, in which case the Rx will periodically perform a stream operation or request a verification event to refresh the expiry.

</body>

</html>