Update "refreshService" example to VCDM2.0

[peacekeeper]

This example currently seems to be based on VCDM 1.1.

---

Preview | Diff

[w3cbot]

iherman marked as non substantive for IPR from ash-nazg.

[msporny]

While it is true that the example is a v1 example, the group also decided to use real world / representative examples. The credential refresh example (which is what the TruAge example uses) only uses v1, not v2 and upgrading it to v2 would result in an example that isn't grounded in the real world.

I suggest we keep this as-is for now until we can get confirmation from the US convenience retail industry on their plans to upgrade to v2.0 for their credential refresh mechanism. AFAIK, they have no plans to start the upgrade process (which will take 2-3 years once started) until v2.0 is out.

[iherman]

I suggest we keep this as-is for now until we can get confirmation from the US convenience retail industry on their plans to upgrade to v2.0 for their credential refresh mechanism. AFAIK, they have no plans to start the upgrade process (which will take 2-3 years once started) until v2.0 is out.

I do not think I agree. The example in the document must be along the line of this specification, and having a v1 example can become extremely confusing. It may not be a good idea for a new CR2 version, which is meant to be the Proposed Rec...

One possibility is to add a note making what you describe explicit, ie, that the example does not represent current deployment 100% because the US convenience retail industry has not yet upgraded to V2. (I guess that would require to use an imaginary https://w3id.org/age/v2 as a context file as well.)

A suboptimal solution is to leave things as is but add a note which makes it explicitly that the example is incorrect V2 and should be updated to V2 when the time comes. But that still is confusing if people try to learn from examples and do not really read the spec... Hence suboptimal.

[chaals]

I agree with Ivan's thinking here. People do copy examples and work from them, instead of carefully reading the spec, and it is important that the spec itself at least encourages that to work out right.

Explaining why an example isn't practising what the spec preaches helps, but is suboptimal, and leaving an example that doesn't match without very clear explanation of that is IMHO a Bad Idea™.

One approach might be to show the example from reality, noting the situation, and accompany it with an example of how it would look when updated.

(I do think it's good to have examples from reality, even though they represent a snapshot from the past by the time you publish them. But making that a strict test for anything labeled example is IMHO not the most helpful way to apply the principle.)

[msporny]

Another option that we should definitely not do right now is to define refresh services in the WG... but that can wait for v2.1. :)

@peacekeeper, would you mind modifying this PR to add a warning about the example as @iherman and @chaals have suggested (even though it's suboptimal)?

[brentzundel]

I would rather not have an example than have an example that doesn't conform to the specification, regardless of how realistic the example is.
I would rather have a completely invented example that conforms to the specification than a real-world example that doesn't.

Keeping the refreshService example as is would be a disservice to implementers, even with a warning.

[selfissued]

I agree with @brentzundel that either the example should match THIS spec or it should be deleted.

[iherman]

I would rather have a completely invented example that conforms to the specification than a real-world example that doesn't.

Yes.