Re: Expiry time in Data Model

I like the idea of allowing an expiration date on the webcredential (though
it should be optional--default should be no expiration in my view). This is
independent of the expiration of the claim.

On the expiration of a claim, this may be out of scope for this discussion,
because we don't want to reach too deeply into specifying what claims can
contain, though it's good to point out that if it's the claim that expires,
expiration should be a property of the claim.

Revocation would probably make more sense to live outside the claim, as a
capability of the webcredential (though that's open for discussion). If so,
I second Matt Stone's suggestion that the ability to check with the issuer
whether a claim has been revoked is important for some claims. Some issuers
will choose to build systems without taking advantage of revocation though.
This ability to understand current validity status should be at the
fingertips of every consumer for claims that use it though. Stone, don't
necessarily agree with you on the point that consumers will always need to
know current validity status - sometimes it's enough to know it once was
valid. Credential historians etc!
On May 20, 2016 2:06 PM, "Stone, Matt" <> wrote:

> On Fri, May 20, 2016 at 2:35 PM, David Chadwick <>
> 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 Monday, 23 May 2016 19:38:16 UTC