Question: Using Refresh Service Property to update a credential when Credential Subject has a new field

[solidnerd]

The holder and issuer agree through an external governance process of updating their commit CredentialSchema.

Mostly this points me to a Description in the Spec:

The issuer can include the refresh service as an element inside the verifiable credential if it is intended for either the verifier or the holder (or both), or inside the verifiable presentation if it is intended for the holder only. In the latter case, this enables the holder to refresh the verifiable credential before creating a verifiable presentation to share with a verifier. In the former case, including the refresh reference inside the verifiable credential enables both the holder and the verifier to perform future updates of the credential.

Possible Solutions that I can see here:

1. The Issuer will create new credentials with the updated CredentialSchema 1.1 How to track that a Credential has a new version?
2. The holder or verifier can request the refresh service to start to get a new credential

[iherman]

The issue was discussed in a meeting on 2021-09-15

• no resolutions were taken

View the transcript

6.4. Question: Using Refresh Service Property to update a credential when Credential Subject has a new field (issue vc-data-model#820)

See github issue #820.

Kyle Den Hartog: Sweet. Looks like we have one minute left...
… last one is #820 - a new one that just popped up
… I haven't had a chance to read it...
… I don't even know how to address this...

Brent Zundel: On first reading it doesn't seem like they are requesting changes
… to the specification, just asking for clarity
… I believe we can label it as a Q

Kyle Den Hartog: I believe this may be similar to David Chadwick's PR... I'll take a look

Brent Zundel: In the meantime, I've put the label.
… Thank you everyone for your hard work, especially these last few weeks.
… I look forward to seeing I think one more PR Kyle from you, then we'll make a static version, vote on as a group that we want to submit it as a revised recommendation, and that begins the 60 day review period.
… So we are still on track. Thank you everyone. Thanks Charles for scribing.

---

[msporny]

Using Refresh Service Property to update a credential when Credential Subject has a new field

I'm having a hard time being sure about what the question is asking, so please forgive me if I end up answering a different question.

The short answer to your question is that the issuer can do whatever it wants to for a re-issued credential. That is, it can add fields, remove fields, change the @context entirely, issue a completely different VC, etc. The holder has no power over this, though there are social expectations... if I want to refresh my driver's license, I will be surprised if I get a plumbing license in return.

The Issuer will create new credentials with the updated CredentialSchema, 1.1 How to track that a Credential has a new version?

This is an excellent question and we don't have a standard mechanism designed yet. The general approach here seems to be that the issuer would revoke the old credential, which would then trigger the holder software to check the refreshService to see if a new VC is available. The same can be done if the VC has expired. Any detection that the VC is no longer valid will result in the refresh service being called.

The holder or verifier can request the refresh service to start to get a new credential

Yes, and it is expected that the VC API will be used to perform this flow: https://w3c-ccg.github.io/vc-http-api/

[iherman]

The issue was discussed in a meeting on 2021-09-29

• no resolutions were taken

View the transcript

2.3. Question: Using Refresh Service Property to update a credential when Credential Subject has a new field (issue vc-data-model#820)

See github issue #820.

Wayne Chang: I think we do have time for one more issue...

Manu Sporny: The question he's asking is a bit difficult to parse so I took a perspective, don't know if it's right. When you use a refresh service, the issuer can do whatever they want to.
… The expectation that the holder/requester has is they have an expired/revoked VC and they hit the refresh service. The issuer could say "No, you can't have another" or "here's a new one with a new expiration date" or "here's a new one and some contents have changed" or "here's a whole new VC with a new credential schema" or "here's something totally different".
… All of those are valid, but none are standardized. Probably expanding on that is a v2 discussion. We're having active discussions in the VC API meetings around how refresh works.
… In general, that's where we are now, their question probably won't be formally addressed until v2 work starts.

Wayne Chang: I think we can defer to v2 to have a discussion about it.
… Ok, we can defer to v2 so we can have a deeper discussion about it.

Dave Longley: +1 to defer to v2

Brent Zundel: +1

Wayne Chang: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Av1.1+sort%3Aupdated-asc

[bumblefudge]

NB @solidnerd -- this might help! https://github.com/w3c-ccg/vc-api/issues/245

[bumblefudge]

The holder or verifier can request the refresh service to start to get a new credential

Issuer-initiated refreshes are... unpopular proposals within the CCG community (slippery slope!) but holder-initiated refreshes and holder-consented custodial refreshes are less controversial. Verifier-initiated... somewhere in between?

[msporny]

@solidnerd -- this (just released) might also help: https://digitalbazaar.github.io/vc-refresh-2021/

[solidnerd]

Hey @msporny @bumblefudge thanks for pinning me. I'll reread through all your provided information and coming back with questions.

[alenhorvat]

Concern with The holder or verifier can request the refresh service to start to get a new credential

In addition, now holder needs to "communicate to the issuer" that a given "verifier" is authorised/mandated for the use of the refresh service to "refresh a VC"; furthermore, when the user would exercise a "right to be forgotten" with the "verifier" she would need to communicate this also to the issuer; In addition, "SSI" tried to break the link between issuer-verifier, now we can simply use what already exists (OIDC/OAuth, other delegated "authentications")

[msporny]

The holder or verifier can request the refresh service to start to get a new credential

Yeah, verifier initiated refreshes are very much frowned upon. Anything that takes the Holder (really, the subject) out of the loop are frowned upon. OIDC, as deployed, often takes the holder out of the loop making communication directly issuer->verifier, which is again, frowned upon when we're talking about giving the holder/subject more agency than typically exists in OIDC.

Note that there is now a proposed spec for this: https://digitalbazaar.github.io/vc-refresh-2021/#refresh-protocol

... and that spec does not support verifier-initiated refreshes, on purpose.

[TallTed]

the Holder (really, the subject)

Please don't re-blur that line.

The Subject has no control over the VCs of which they are Subject, and may not even know those VCs exist, unless they happen to also be the Holder.

The Issuer, Holder, and Verifier each have (different) controls over VCs.

Yes, sometimes the Subject is also the Holder, but there are MANY counterexamples (as we've discussed rather a lot) which cannot be understood nor addressed properly without keeping these roles distinct. There is minimal confusion caused by treating the Subject role as different than the Holder role -- even when the same entity is serving in both roles in a given situation -- if the clear distinction is maintained throughout.

[alenhorvat]

Thank you for the clarification.