- 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