Re: Verifiable Claims Lifecycle document

On 13/06/2017 23:27, Stone, Matt wrote:
> Thanks for the work on this document.  I have a couple of lines of
> comments.  
> 
> 1) the background on identity is good reading for all of us to think
> about, but it seems to overwhelm the titular content of VC lifecycle. 
> We may want to split this content into 2 documents, as Identity is a
> beast unto itself.  We constantly walk the line between recognition of
> the importance and complexity of identity discussions while being
> careful not to try to "solve identity on the web" in this group.
> 
> 2) I'm really interested in the content in point 9 of the Lifecycle
> section, "If the verifiable claim has an expiry time, then when this is
> reached, the holder should discard the claim"

This is because
a) an inspector is very unlikely to accept an expired VC (though may do
at its discretion) and
b) the holder should be able to easily ask the issuer for a new VC.
Thus there is little point in holding an expired VC if a new one can be
obtained automatically by client code.

> 
> ​The working group will probably take on a significant portion of this
> details in this discussion, but I think it's an opportunity for us to
> have another terminology debate --  related to the "expiry time" of
> a verifiable claim.  In many cases with claims that represent professional 
> credentials,
> ​ the credential has a validity period and an issuer has some business
> rules that require inspectors to verify authenticity in a shorter
> sliding window.

All long lived VCs will need some revocation mechanism. The example you
give below is an alternative to issuing revocation lists, and is very
similar to OCSP Stapling, where the 60 day letter is equivalent to an
OCSP status report. So the VC is valid for 5 years, but inspectors need
to know that it has not been revoked since it was issued. The letter
provides this evidence.

> 
> For example, an OB/GYN may earn board certification through ABOG which
> is valid for 5 years.  As an issuer, ABOG would issue a verifiable claim
> to the physician who becomes the holder of the board certification
> claim. As long as the physician holds the claim, they might share it
> with hospitals, as they apply for privileges and insurance companies, to
> get preferred rates.  According to the lifecycle document, these
> inspectors may exercise 
> discretion 
> ​whether​
>  to "
> accept the claim without validating it, or may perform either partial
> validation or full validation of the VC at its choice
> ​" [point 7]​.
> 
> ​In today's information economy, the
> issuer
> ​ defines the period that the claim may be respected w/out updating
> validation, and this expiration seldom coincides with the expiration of
> the underlying credential.  In the non-verifiable claims world ABOG
> might write a notarized credential verification letter, indicating that
> 1) the physician is in good standing and is certified w/ the board, 2)
> the board certification is valid until 12/2020, 3) the letter may be
> used as verification for 60days.   
> In this scenario, the verifiable
> ​letter
>  may be used many time
> ​s​
> (not
> ​ "n"​
> use
> ​s​
> ), but after 60days is useless
> ​​.  
> 
> ​Verifiable Claims are a digital representation of the letter and
> cryptographic signatures serve the role of the notary's seal.  My
> concern is with terms that include "expire" or "
> expiry 
> ​period" as it relates to a verifiable claim.  I recommend we introduce
> a term that won't be conflated with the expiration period of the
> underlying credential or attribute attestation.  Personally, I like a
> term form the world of DNS that's been around forever, Time To Live (TTL).  

the semantics of TTL and expiry time are somewhat different.

 expiry time = start time plus TTL.

It is probably more sensible to have expiry time (say as UTC time)
rather than make the inspector compute it from start time and TTL.

> 
> In this case, the VC has a TTL of 60days, before 60d,

It has 60 days from some start time, not 60 days from whenever the
inspector receives it.

 as long as the VC
> is cryptographically sound, the inspector can simply accepted its
> content, without escalating to the issuer for shallow or deep
> validation. After 60d the inspector system​ might still read the
> content, but a VC protocol would require the inspector system to ask the
> issuer for a renewal, at which point the TTL (could/would?) be refreshed
> to 60 days from now.  
> 
> Our documentation and discussions to date haven't included much nuance
> on the differences between an expiring claim and an expiring credential
> that it represents.  Issuers will want clarity on this topic.

It is up to the issuer to decide between
a) issuing short lived VCs of 60 days duration, or
b) issuing long lived VCs of 5 years and having some revocation mechanism.
There is no right answer to this, and it all depends upon the value of
the VC and the risk of the inspector. As a general rule I would guess

i) high value, high risk VCs should be short lived and not revocable
ii) low value, low risk VCs should be long lived and may or may not be
revocable
iii) medium value, medium risk VCs should be long lived and revocable.


> 
> Of course, the inspector is always free to do a full validation from the
> issuer at anytime based on the "risk model adopted by the inspector"

and of course, to do no validation!

David
> 
> -stone
> 
> 
> 
> 
> =====
> Matt Stone
> 501-291-1599
> 
> 
> On Mon, Jun 12, 2017 at 4:25 PM, Kim Hamilton Duffy
> <kim@learningmachine.com <mailto:kim@learningmachine.com>> wrote:
> 
>     Hi all,
>     David Chadwick has written up a clear and informative document on
>     the Verifiable Claims Lifecycle problem space and scenarios. Please
>     read!
>     https://goo.gl/pBKL08
> 
>     Thanks,
>     Kim
>     -- 
>     Kim Hamilton Duffy
>     Principal Engineer | Learning Machine + MIT Media Lab
>     Co-chair W3C Credentials Community Group
>     400 Main Street Building E19-732, Cambridge, MA 02139
>     12001 N. Central Expy, Suite 1025, Dallas, TX 75243
> 
>     kim@learningmachine.com <mailto:kim@learningmachine.com> |
>     kimhd@mit.edu <mailto:kimhd@mit.edu>
>     425-652-0150 <tel:(425)%20652-0150> | LearningMachine.com
> 
>

Received on Thursday, 15 June 2017 02:41:54 UTC