W3C home > Mailing lists > Public > public-credentials@w3.org > May 2016

Re: Expiry time in Data Model

From: David Chadwick <d.w.chadwick@kent.ac.uk>
Date: Sat, 21 May 2016 19:59:50 +0100
To: "Stone, Matt" <matt.stone@pearson.com>
Cc: Jason Weaver <jweaver@parchment.com>, Eric Korb <eric.korb@accreditrust.com>, Credentials Community Group <public-credentials@w3.org>
Message-ID: <5a9bfb60-2096-dd67-3a6f-e18c2af0c96a@kent.ac.uk>
Let me give you two real world examples of a recipient ignoring the
issuer's policy.
i. Supermarket A gives me a (paper) coupon saying that I will be given
£3 discount if I spend £30. The terms and conditions say that this is
only valid in Supermarket A if spent before date X. I take the coupon to
Supermarket B and they honour the coupon and give me the discount. This
happens today in the UK.
2. UK supermarkets also honour manufacturer's discount coupons that have
expired e.g. 10p off a bottle of Z's washing up liquid.

One can easily imaging these paper coupons becoming electronic
credentials sent to mobile phones.



On 20/05/2016 22:04, Stone, Matt wrote:
> On Fri, May 20, 2016 at 2:35 PM, David Chadwick <d.w.chadwick@kent.ac.uk
> <mailto:d.w.chadwick@kent.ac.uk>> wrote:
>     However the recipient is still the one doing the trusting, and
>     it can decide to trust a credential without following the issuer's
>     policy. 
> it feels a little funny for the "trusting party" to have discretion​ to
> ignore the issuers policy about a caching the validation and when to
> force a re-verification.  In an automated system, wouldn't this be
> automatic?  We want this ecosystem to understand that a verification is
> itself out of date and no longer valid for use (the verification is out
> of date, not the claim).  In the over 18 example, the issuer would
> probably make TTL be infinite or unset. If TTL is set, it can't be
> ignored otherwise the veracity of the verification is undermined and is
> open to fraud and misuse; the value of the credential is at risk in the
> market place.
> =====
> Matt Stone
> 501-291-1599
Received on Saturday, 21 May 2016 19:00:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:29 UTC