- 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