W3C home > Mailing lists > Public > public-credentials@w3.org > September 2017

Re: Verifiable Claims expiration

From: Matt Stone <matt.stone@pearson.com>
Date: Mon, 18 Sep 2017 16:42:19 +0000
Message-ID: <CA+w1=RTit9d+t_LrwzQP8aHt0vM0X2k263cDeEd2uuoy0HHr+Q@mail.gmail.com>
To: Joe Andrieu <joe@joeandrieu.com>, moses.ma@futurelabconsulting.com, public-credentials@w3.org
We should keep the division (and discussion) between "Time-to-live" f a VC
and the expiation of an underlying claim VERY separate. And a one year
default is a horrible idea that doesn't represent the market truth that
expiration periods for professional credentials are all over the place (we
serve Credential Managment for 50 agencies and have literally hundreds of
rules  in place to calculate an expiration date for a status.)

Having null=never expire is reasonable, from racing an issuer t declare
"never" may also be reasonable, but we can't make up fake data in the spec.

The CG has a good discussion right naming in the sketch pad on this topic.
We should adopt from there.

-stone


On Sun, Sep 17, 2017 at 1:19 PM Moses Ma <moses.ma@futurelabconsulting.com>
wrote:

> 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
> +1(805)705-8651
> http://blog.joeandrieu.com
>
>
> --
>
> *Moses Ma | Partner*
>
> moses.ma@futurelabconsulting.com | 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.
>
>
> 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.
>
-- 

=====
Matt Stone
501-291-1599

FLClogo.png
(image/png attachment: FLClogo.png)

Received on Monday, 18 September 2017 16:42:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:13 UTC