- From: Nate Otto <ottonomy@gmail.com>
- Date: Sat, 21 May 2016 09:03:58 -0700
- To: Matt Stone <matt.stone@pearson.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAPk0ugnAQ-nGQVz-e-DPWwNf3chWtD_icsxRc6waot+ZQUKB1Q@mail.gmail.com>
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" <matt.stone@pearson.com> wrote: > > On Fri, May 20, 2016 at 2:35 PM, David Chadwick <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 Monday, 23 May 2016 19:38:16 UTC