- From: Jason Weaver <jweaver@parchment.com>
- Date: Fri, 20 May 2016 12:39:19 -0500
- To: Eric Korb <eric.korb@accreditrust.com>
- Cc: David Chadwick <d.w.chadwick@kent.ac.uk>, Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CADyYZ_WpuAZwj7-T7YFWwWZMiPQhyc7MzBMEz-70vYrQ_TZvQg@mail.gmail.com>
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 direct 480.719.1646 ext. 1017 6263 North Scottsdale Road, Suite 330, Scottsdale, AZ 85250 *Parchment *| Turn Credentials into Opportunities www.parchment.com On Fri, May 20, 2016 at 7:17 AM, Eric Korb <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> > 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 17:42:10 UTC