- From: Eric Korb <eric.korb@accreditrust.com>
- Date: Fri, 20 May 2016 14:43:12 -0400
- To: "Stone, Matt" <matt.stone@pearson.com>
- Cc: David Chadwick <d.w.chadwick@kent.ac.uk>, Jason Weaver <jweaver@parchment.com>, Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAMX+RnA5F3xwJhZ60-yOYMwhLjJ2zEyOFLuzRUy0CUMBSGRdeQ@mail.gmail.com>
I believe the Web Payments Task Force is addressing this for "payment processing." Manu? Dave? Eric <https://mail.google.com/> On Fri, May 20, 2016 at 2:19 PM, Stone, Matt <matt.stone@pearson.com> wrote: > 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:43:59 UTC