Re: Verifiable Claims Lifecycle document

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"

​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.

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).

In this case, the VC has a TTL of 60days, before 60d, 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.

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"

-stone




=====
Matt Stone
501-291-1599


On Mon, Jun 12, 2017 at 4:25 PM, Kim Hamilton Duffy <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 | kimhd@mit.edu
> 425-652-0150 <(425)%20652-0150> | LearningMachine.com
>

Received on Tuesday, 13 June 2017 22:28:27 UTC