Add refresh status purpose.

[msporny]

This PR is an attempt to address issue #183 by adding a refresh status purpose.

---

Preview | Diff

[iherman]

The new property should be added, I presume, to the bitstring vocabulary document, and to the diagram include therein.

It is o.k. if this is handled in a separate Issue+PR, but it ought to be done. Please raise an issue if you prefer to handle it separately.

Similarly, shouldn't the relevant context file be changed?

(I am happy to do the changes on the vocabulary... eventually. I am not at my computer right now, it would be difficult to do it on my tablet...)

[msporny]

The new property should be added, I presume, to the bitstring vocabulary document, and to the diagram include therein.

Nope, it's not a term, it's an arbitrary string. :)

[PatStLouis]

I think we can have the purpose added and explore discussions around if it needs an additional defined property separately. I think if a new term needs to be defined it would be more towards an associated refreshService, which can live in a separate context.

@msporny Would it be reasonable to add to this text that this refresh status doesn't have an effect on the validity of the current credential, meaning it doesn't become revoked because there's an update available, simply signals that there's an update. Revocation should still be managed by a separate status entry. If there's a "breaking update", the credential would get updated + revoked. If its a "soft" (meaning a minor change) or "additive"(adding a data element) update, the credential gets updated, but the consumer of the credential can still use the non updated version without concern (they don't need to get the updated version). If its also revoked then they would need to get the updated version if they want to continue using the data for their services.

I think just a sentence that the refresh status doesn't invalidate the current credential.

[TallTed]

simply signals that there's an update

Except that it doesn't signal that there's an update. It signals that there's a place to ask for any update that might be available.

[PatStLouis]

@TallTed the purpose is that you would resolve the index of the refresh status, 0 means no update available and 1 means an update is available you MAY hit the refresh endpoint, so it does signal that there's an update available.

The original purpose label was "supersession", meaning 0 means the credential isn't superseded, and 1 the credential has been superseded. The suggestion to make the purpose label refresh is to explicitly signal that this supersession/amendment/update or however we call this be tied to a refreshService instead of being an out of band process (which could still be allowed, but better to tie it to a resfreshService)

A refreshService on its own would do what you describe, the goal of this status purpose is to "notify" any party consuming this credential that an update is available.

[iherman]

The new property should be added, I presume, to the bitstring vocabulary document, and to the diagram include therein.

Nope, it's not a term, it's an arbitrary string. :)

Oops, sorry.

(For some reasons preview does not work, and I have only my ipad with me where I am this week, so it was difficult to see the exact context of the changes. My approval holds :-)

[brianorwhatever]

Something like this to address the comments?

[longpd]

I approve this PR with the amended language it contains.

[msporny]

Normative, multiple reviews, changes requested and made, no objections, merging.