- From: Stone, Matt <matt.stone@pearson.com>
- Date: Fri, 20 May 2016 12:19:52 -0600
- To: David Chadwick <d.w.chadwick@kent.ac.uk>
- Cc: Jason Weaver <jweaver@parchment.com>, Eric Korb <eric.korb@accreditrust.com>, Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CA+w1=RSQm_KKhmdnTYtVxKyoMGzJHqhD2hhuKx=T6XKtpUoR2w@mail.gmail.com>
this is an expiration on the credential, itself, right? something like this: certified in xyz, effective 1/1/2012, expiring 1/1/2013. do we have anything like a "time to live" for the claim itself - i'm inspired by TTL in DNS. a secondary server can hold DNS information for a brief period w/out going back to the master for updates. In the repository model, something like this might make for a more resilient and performant system. -stone ===== Matt Stone 501-291-1599 On Fri, May 20, 2016 at 12:04 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote: > HI Jason > > yes that is correct. I think 'expires' should be mandatory on the > credential message and not need to be on the embedded claims (unless > these are different for each claim) > > regards > > David > > On 20/05/2016 18:39, Jason Weaver wrote: > > Hi, Eric, David. > > > > I think the distinction David is making about a requirement on the > > expiration of the claim message, versus the expiration of the claim > > content itself that OB expire refers to and makes optional, correct? > > > > Thank you, > > Jason > > *--* > > > > *JASON WEAVER *| DIRECTOR, DIGITAL CREDENTIALS STRATEGY > > CO-CHAIR, PESC EDUCATION RECORD USER GROUP > > jweaver@parchment.com <mailto:jweaver@parchment.com> > > direct 480.719.1646 <tel:480.719.1646>* *ext. 1017 > > 6263 North Scottsdale Road, Suite 330, Scottsdale, AZ 85250 > > > > *Parchment *|* *Turn Credentials into Opportunities > > www.parchment.com <http://www.parchment.com/> > > > > > > On Fri, May 20, 2016 at 7:17 AM, Eric Korb <eric.korb@accreditrust.com > > <mailto:eric.korb@accreditrust.com>> wrote: > > > > David, > > > > Great question. The JSON-LD model allow us to leverage the > > OpenBadges - "expire" property found in their vocabulary. > > > > , > > "http://w3id.org/openbadges/v1expires": [ > > { > > "@value": "2020-05-05T21:53:01Z" > > } > > ], > > > > Digital Credential validation tools then need to evaluate the > property. > > > > Eric > > > > > ------------------------------------------------------------------------ > > TrueCred™ | Digital Credential Trust™ > > > ------------------------------------------------------------------------ > > > > *Eric R. Korb | Chief Executive Officer | Warren, New Jersey* > > > > > > <https://mail.google.com/> > > > > On Fri, May 20, 2016 at 7:13 AM, David Chadwick > > <d.w.chadwick@kent.ac.uk <mailto:d.w.chadwick@kent.ac.uk>> wrote: > > > > Hi Manu > > > > Can ask why a verifiable claim does not have an expiry time as a > > mandatory component? Whilst the attribute itself may not expire > > e.g. a > > university degree, nevertheless the electronic representation of > the > > claim should have an expiry time due to the inherent weaknesses > in > > cryptographic systems and the need to continually increase key > > sizes, > > improve algorithms etc. > > > > Without an expiry time the issuer may have to keep revocation > > information for ever. > > > > regards > > > > David > > > > > > > > > > > >
Received on Friday, 20 May 2016 18:20:18 UTC