ManualRefreshService2018 - what exactly is it?

[AFlowOfCode]

I hope it is not incorrect to ask this here - if so feel free to delete/close & I'll ask on one of the mailing lists.

The only information I can find anywhere is in the vocabulary: A type of refresh service that must be interacted with in a manual fashion.

However the specificity of the term (particularly the inclusion of the year) to me suggests that this type of refresh service may have a specification hidden somewhere away from search engines. The above definition is extremely open-ended and causes me to wonder why just setting the value to "manual" couldn't suffice.

So to rephrase the title of this issue, does ManualRefreshService2018 imply anything beyond the meaning of the word "manual" (in contrast to "automatic")? I'd like to make sure I'm not misusing this term if I include it in reference to a custom method of refreshing a credential.

Thank you.

[OR13]

I suggest this example be removed until such time as there is a TR or equivalent level of standard to refer to.

This issue should be converted to a request to remove the example.

[msporny]

We could also point to the CCG refresh service mechanism, which would be an editorial change.

[iherman]

The issue was discussed in a meeting on 2023-06-07

• no resolutions were taken

View the transcript

2.7. ManualRefreshService2018 - what exactly is it? (issue vc-data-model#981)

See github issue vc-data-model#981.

Brent Zundel: moving on to 981, assigned to Manu, marked as ready for PR.

Orie Steele: I tried fixing this, Manu need to fix : /.

Dave Longley: +1 for Manu to fix.

Brent Zundel: will leave it for Manu to fix. Editorial so can add post CR label.
… marking issue as post CR.

[iherman]

The issue was discussed in a meeting on 2024-01-17

• no resolutions were taken

View the transcript

2.2. ManualRefreshService2018 - what exactly is it? (issue vc-data-model#981)

See github issue vc-data-model#981.

Brent Zundel: This is assigned to you, manu, is this still an issue?

Manu Sporny: No, unfortunately, it's still in the spec. We do have a CCG credential refresh spec that we can point to.
… I know there are two implementations of the CCG credential refresh mechanism in production around the TruAge program.
… The proposal here would be to use that value because that value is in production, would that be enough to address this issue?

Brent Zundel: Refresh service is a reserved term, not defined?

Manu Sporny: See term definition.

Manu Sporny: We have a section for it, it's marked at-risk.

Brent Zundel: Unless we can get an equivalent set of specs, then we're going to remove it?

Manu Sporny: I'm reading the at-risk marker. This feature is at-risk and removed from the spec if at least two independent implementations don't exist by the end of CR. We do have those right now for the extension point and the feature.
… So it shouldn't be at-risk anymore, unless I'm misunderstanding something.

Brent Zundel: And those are based on the community group thing and what's the status of that?

Manu Sporny: They might be based on the Conexxus retail standard for TruAge.
… Which reuses the CCG spec.
… Uses parts of it.
… I don't know what we want to do here, the CCG spec continues to exist. I don't know what we want to do here. We haven't been very clear here about what the state needs to be.

Brent Zundel: It's my understanding that in order to point normatively to another spec, that spec needs to be recognized as relatively mature, but does need to be stable, needs to have link that isn't going to change, etc.

Jeffrey Yasskin: See normative references in W3C.

Brent Zundel: Bar we set as a group, is we have a number of extension points that we wrote into previous versions of the spec, and it was recognized that those extension points were valuable while things were being incubated, and those difficult to test because there are not normative specs to test extension points are one of the things we're hoping to correct in v2. We've done that w/ securing specs, done w/ JSON schema, done w/ other extension points, whether or not we can claim this appropriate level of interop w/ refresh property is unclear to me.
… Getting a bit far afield -- this is editorial -- broader issue about refresh service, open issue, we'll get there.

Manu Sporny: I don't disagree with any of that. I thought this issue was about the example.
… +1 to what you said, it feels like we need get clarity ... totally agree that credentialRefresh, the CCG spec itself, I don't think you could say it's stable, but the usage is. We would not be able to make any normative reference to the CCG spec at this time. But did we say we had to be able to do that to keep the extension point around in the spec or did we have to just say people are using it in a significant capacity?
… I don't remember what we said the minimum bar was, but having a normative spec is certainly at / above that bar. I don't know if that's required vs. a clear signal it's good enough.
… This is a bit far afield, maybe there's another issue for this.

Brent Zundel: For this particular issue, I think the plan is to modify the example to something other than ManualRefresh2018, Manu's assigned to make that change. If we're ok w/ that course of action, we can move forward.

Jeffrey Yasskin: I think it would be a shame to lose the list of reserved extension points just because you can't normatively refer to specifications for each one. IETF deals w/ this w/ "provisional" registrations. The W3C now has enough processes to have reserved extension points a registry for stuff that's not standardized.

Brent Zundel: I like that suggestion, so let us keep that in mind as we continue having this discussion. We have a number of "at risk" statements that are tracking this for us.

[msporny]

PR #1435 has been raised to address this issue. This issue will be closed once that PR is merged.

[msporny]

PR #1435 has been merged, closing.