Re: Expiry time in Data Model

On 21/05/2016 17:03, Nate Otto wrote:
> I like the idea of allowing an expiration date on the webcredential

great

> (though it should be optional--default should be no expiration in my
> view). 

I dont think it should be optional. We need issuers to consider a
realistic value for this. However, we could allow a value of infinity to
be set - but as I said earlier this actually places a large burden on
the issuer ad infinitum.


> This is independent of the expiration of the claim.

Agreed. It could be omitted (default), shorter (if multiple claims are
in one longer lived credential) or longer (perhaps to indicate that
newer credentials will most likely be issued in future)

> 
> On the expiration of a claim, this may be out of scope for this
> discussion, because we don't want to reach too deeply into specifying
> what claims can contain, though it's good to point out that if it's the
> claim that expires, expiration should be a property of the claim.

I am not sure that I fully appreciate from a chronological perspective
the difference between a claim and a credential that expire at the same
time. From the recipient's perspective wouldn't they be treated in the
same way?


> 
> Revocation would probably make more sense to live outside the claim, as
> a capability of the webcredential 

Agreed. It is the credential that is being revoked, which can be for a
variety of reasons that may or may not have to do with the validity of
the claim.

regards

David

(though that's open for discussion).
> If so, I second Matt Stone's suggestion that the ability to check with
> the issuer whether a claim has been revoked is important for some
> claims. 

Agreed. This could be signalled in the revocation reason.

> Some issuers will choose to build systems without taking
> advantage of revocation though.

Agreed. If the cost of the revocation system is greater than the loss
from a should-have-been-revoked-but-cannot-be credential then issuers
will build unrevocable systems (such as SAML).

> This ability to understand current
> validity status should be at the fingertips of every consumer for claims
> that use it though.

Unfortunately this is not always the case today e.g. with browsers and
PKI certs.


> Stone, don't necessarily agree with you on the point
> that consumers will always need to know current validity status -
> sometimes it's enough to know it once was valid. Credential historians etc!
> 
> On May 20, 2016 2:06 PM, "Stone, Matt" <matt.stone@pearson.com
> <mailto:matt.stone@pearson.com>> wrote:
> 
> 
>     On Fri, May 20, 2016 at 2:35 PM, David Chadwick
>     <d.w.chadwick@kent.ac.uk <mailto:d.w.chadwick@kent.ac.uk>> wrote:
> 
>         However the recipient is still the one doing the trusting, and
>         it can decide to trust a credential without following the issuer's
>         policy. 
> 
> 
>     it feels a little funny for the "trusting party" to have discretion​
>     to ignore the issuers policy about a caching the validation and when
>     to force a re-verification.  In an automated system, wouldn't this
>     be automatic?  We want this ecosystem to understand that a
>     verification is itself out of date and no longer valid for use (the
>     verification is out of date, not the claim).  In the over 18
>     example, the issuer would probably make TTL be infinite or unset. If
>     TTL is set, it can't be ignored otherwise the veracity of the
>     verification is undermined and is open to fraud and misuse; the
>     value of the credential is at risk in the market place.
> 
> 
> 
>     =====
>     Matt Stone
>     501-291-1599 <tel:501-291-1599>
>

Received on Tuesday, 24 May 2016 08:58:25 UTC