- From: David Chadwick <d.w.chadwick@kent.ac.uk>
- Date: Fri, 20 May 2016 20:42:50 +0100
- To: "Stone, Matt" <matt.stone@pearson.com>
- Cc: Jason Weaver <jweaver@parchment.com>, Eric Korb <eric.korb@accreditrust.com>, Credentials Community Group <public-credentials@w3.org>
On 20/05/2016 19:19, Stone, Matt wrote:
> this is an expiration on the credential, itself, right? something like
> this: certified in xyz, effective 1/1/2012, expiring 1/1/2013.
yes
>
> 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.
This is a separate issue. A claim may not have expired, but it may have
been revoked. Therefore going back to the issuer is a something the
recipient/relying party will have to decide to do based on its risk
threshold.
A second parameter of a credential should be whether it is revocable or not.
regards
David
>
> -stone
>
>
> =====
> Matt Stone
> 501-291-1599
>
>
> On Fri, May 20, 2016 at 12:04 PM, David Chadwick
> <d.w.chadwick@kent.ac.uk <mailto: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>
> <mailto:jweaver@parchment.com <mailto:jweaver@parchment.com>>
> > direct 480.719.1646 <tel:480.719.1646> <tel: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>
> <http://www.parchment.com/>
> >
> >
> > On Fri, May 20, 2016 at 7:17 AM, Eric Korb <eric.korb@accreditrust.com <mailto:eric.korb@accreditrust.com>
> > <mailto: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>
> <mailto: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 19:43:24 UTC