Clarification on when a credentialRefresh service should be used

[morgatron]

It's stated on the third paragraph here that:

"The refresh service is only expected to be used when either the credential has expired or the issuer does not publish credential status information."

To me this sounds like refreshing should be used:

• when a credential is expired (clear enough)
• When a credential is not revocable
• At no other time

Apart from finding this confusing, I see conversation elsewhere, including on issues on this repo, where other uses are considered. So I'm presumably misunderstanding something. Perhaps I"m not the only one confused by this.

[Sakurann]

I think refreshService Property should be removed from v2 specification. Issuance/refresh happens between the Issuer and the Holder, so this should be covered by whichever Issuance protocol used to issue the credentials. Verifier does not need to know issuer's issuance/refresh endpoint. and if the Holder got Credential Issued once, it would know issuer's issuance/refresh endpoint already, without this property.

[TallTed]

if the Holder got Credential Issued once, it would know issuer's issuance/refresh endpoint already

I question this assertion, especially if the Issuer's issuance endpoint(s) differ from their refresh endpoint(s). It seems to me refreshService should be retained.

[David-Chadwick]

@TallTed Don't you think that the issuer can inform the holder the endpoint for refreshing the VC that it is currently issuing during the issuing process? Or even by some out of band means? Why should the verifier be able to learn the refresh endpoint? This seems to me to be an example of allowing the verifier to call home.

[jandrieu]

The paragraph cited seems to be incorrect. Refresh != status, so I'm not sure why these two would be conflated.

[Sakurann]

pending close since the original question has been responded to. please also see the outcome of #1082

[iherman]

The issue was discussed in a meeting on 2023-04-11

• no resolutions were taken

View the transcript

1.2. Clarification on when a credentialRefresh service should be used (issue vc-data-model#1020)

See github issue vc-data-model#1020.

Kristina Yasuda: "Clarification on when a credentialRefresh service should be used" - this is a question with some attempts at an answer.
… is this suitable for pending close tag? or is discussion still going on.

Manu Sporny: on the fence about this - have a proposal to move credential refresh to a property - will assert two implementations.
… maybe we do something about this if credentialRefresh stays in specification.
… PR is #1082.

[iherman]

The issue was discussed in a meeting on 2023-04-11

• no resolutions were taken

View the transcript

1.2. Clarification on when a credentialRefresh service should be used (issue vc-data-model#1020)

See github issue vc-data-model#1020.

Kristina Yasuda: "Clarification on when a credentialRefresh service should be used" - this is a question with some attempts at an answer.
… is this suitable for pending close tag? or is discussion still going on.

Manu Sporny: on the fence about this - have a proposal to move credential refresh to a property - will assert two implementations.
… maybe we do something about this if credentialRefresh stays in specification.
… PR is #1082.

[TallTed]

@David-Chadwick

@TallTed Don't you think that the issuer can inform the holder the endpoint for refreshing the VC that it is currently issuing during the issuing process? Or even by some out of band means? Why should the verifier be able to learn the refresh endpoint? This seems to me to be an example of allowing the verifier to call home.

The current holder may not have been the original holder (a/k/a the issuee), so no, I don't "think that the issuer can inform the holder the endpoint for refreshing the VC that it is currently issuing during the issuing process" nor "by some out of band means".

I do agree that this might be "an example of allowing the verifier to call home", so it seems the credentialRefresh should be metadata of the VC (not an assertion within it), which the holder/presenter MAY (SHOULD? MUST?) omit from the presentation.

[David-Chadwick]

@TallTed I agree with you that the refresh property should not be metadata of the credential, but rather metadata of the verifiable credential. This means that the issuer can provide it to the issuee via the issuing protocol (which could be in the VP if the VP construct is used) but otherwise as a parameter of the issuing protocol. We agree that the property must never be inside the VC. The issuee may pass this metadata to a subsequent holder at its own discretion by inserting it into the VP that it creates.

[brentzundel]

Though comments have been added, no objections to closing have been raised since being marked pending close, closing.