Re: Expiry time in Data Model

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.

regards

David


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