Re: Verifiable Claims expiration

Moses,

Thanks for bringing these topics up. I explain my thoughts a bit better here: https://w3c-ccg.github.io/verifiable-news/sketchpad.html#issuance-and-statement-assertion-intervals .


Best regards,
Adam

From: Adam Sobieski<mailto:adamsobieski@hotmail.com>
Sent: ‎Sunday‎, ‎September‎ ‎17‎, ‎2017 ‎5‎:‎54‎ ‎PM
To: Joe Andrieu<mailto:joe@joeandrieu.com>, public-credentials@w3.org<mailto:public-credentials@w3.org>, Moses Ma<mailto:moses.ma@futurelabconsulting.com>

Moses,

For clarity, there are at least three temporal intervals in the context of digitally-signed statements:

Issuance Time – the start and duration of the validity of a digitally-signed thing; this is a cryptographic or systems security topic.
Assertion Time – the start and duration of the intended assertion of a statement; an instant or interval of time during which an assertion is occurring.
Statement Time – the start and duration of that which is asserted, if that which is asserted has a temporal aspect; an instant or interval of time during which some stated matter is occurring.


Best regards,
Adam

From: Moses Ma<mailto:moses.ma@futurelabconsulting.com>
Sent: ‎Sunday‎, ‎September‎ ‎17‎, ‎2017 ‎3‎:‎19‎ ‎PM
To: Joe Andrieu<mailto:joe@joeandrieu.com>, public-credentials@w3.org<mailto:public-credentials@w3.org>

I tend to design standards "defensively" rather than "logically", ie, I assume that mere mortals and not coding geniuses will use the system incorrectly, and these incorrect usages should not accumulate into unexpected consequences. Assuming the default for not entering an expiration date is infinity could lead to lots of entries that should actually be forced to have a default TTL.Therefore, I believe that one year is a better default than never expire, and that never expire should be an explicit request.

Also, I like the idea of a time to live, so we can more easily expire or renew VCs and do a sort of garbage collection every so often, so the system doesn't get bloated.

Moses


On 9/17/17 12:02 PM, Joe Andrieu wrote:
If you force an expiry date, issuers who don't want one will use an arbitrary future date, e.g., 9999/12/31. The largest such number that fits the typical inspector-verify test suite will rapidly become the de facto setting for "no expiration".

Trying to force policy into the data model just wastes bytes.

-j


On Sat, Sep 16, 2017, at 11:55 PM, David Chadwick wrote:
And from a security perspective this is flawed, since no cryptography
will last for ever

On 17/09/2017 01:07, Manu Sporny wrote:
On 09/16/2017 03:34 PM, Adam Sobieski wrote:
I thought that omission of the expires property
(https://w3c.github.io/vc-data-model/#expiration) results in an
open-ended or non-expiring claim or statement.

This is correct.

We'll want to correct the spec text if it doesn't already say this.

-- manu



--
Joe Andrieu, PMP
joe@joeandrieu.com<mailto:joe@joeandrieu.com>
+1(805)705-8651
http://blog.joeandrieu.com




--
[cid:part3.977EDA71.1C8FDD86@futurelabconsulting.com]

Moses Ma | Partner

moses.ma@futurelabconsulting.com<mailto:moses.ma@futurelabconsulting.com> | moses@ngenven.com<mailto:moses@ngenven.com>

v+1.415.568.1068 | skype mosesma


FutureLab provides strategy, ideation and technology for breakthrough innovation.

earn more at www.futurelabconsulting.com<http://www.futurelabconsulting.com>.


Or whet your appetite by reading Agile Innovation<http://www.amazon.com/Agile-Innovation-Revolutionary-Accelerate-Engagement/dp/B00SSRSZ9A> and Soulful Branding<http://www.amazon.com/Soulful-Branding-Unlock-Hidden-Company/dp/1515114414> by FutureLab experts.

Received on Sunday, 17 September 2017 23:52:01 UTC