address clarification that the URI can be used to retrieve data

[kdenhartog]

From feedback on VC Data Model v1.1

* Correction 2, changing "URL" to "URI", moves from a value that can be
fetched to a value that can't necessarily be fetched. The meaning of these
`id` values is undefined both before and after the change, but it moves
from the possibility of defining a general meaning for the fetched
resource, to a need to define the meaning of particular URIs in a table.
That seems like the wrong direction. The WG could cite
https://url.spec.whatwg.org/ if their goal is simply to provide a normative
definition of the "URL" term.

The WG also experienced some frustration in attempting to package the proposed corrections in such a way as to make them more accessible for reviewers. We would have definitely benefited from some additional tooling.
The following contain records of the issue and the WG's conversation which led to the corrections related to the above concerns:

• The issue that drove this correction is URIs or URLs for ids #748
• The PR that proposed the changes is Use URI id for credentialStatus and refreshService #819

---

Preview | Diff

[brentzundel]

minor nit, otherwise lgtm

[brentzundel]

@jyasskin let us know if you feel this PR addresses your concern.

[jyasskin]

Yep, this looks good. In VC 2.0, I hope that these sections will define what machine readable information is available behind these URIs, but I understand that's out of scope for this small update.

[kdenhartog]

Yep, this looks good. In VC 2.0, I hope that these sections will define what machine readable information is available behind these URIs, but I understand that's out of scope for this small update.

Yup, we'll leave open the issue #862 to track that update in the V2.0 work and now I've updated this PR to be the one that gets logged in the errata document as well as the PR details to make it clear what's going on here.

[msporny]

I expect that we are going to be dropping this id requirement in the VC 2.0 work and replacing it with a url field (that may or may not point to machine readable information). Refresh services can be mediated (human in the loop) or unmediated (machine to machine), the url just identifies a place where you can initiate a protocol of some kind. That protocol might just be the software opening a URL to a page that a human then needs to interact with. The protocol might be something that can be automated, with machine-readable information at the url.

So, saying that there is an expectation is probably incorrect... but might be fine for this revision of the specification until we get something a bit more concrete in there.

Here's an example of a spec that is expected to end up in the VCWG in time that specifies a data model and protocol for this property:

https://digitalbazaar.github.io/vc-refresh-2021/

[jyasskin]

FWIW, I think a specification of a "ceremony" like this makes a lot of sense, where the 'url' field might be a navigation target for a human participant rather than just a fetch target for a machine.

[msporny]

where the 'url' field might be a navigation target for a human participant rather than just a fetch target for a machine.

Yep, and speaking specifically to "navigation target for a human participant", one place that's being defined is here:

https://w3c-ccg.github.io/vp-request-spec/#interaction-types

When a Verifiable Credential Verifier wants something from you, they send you (the Holder) a Verifiable Presentation Request. That Verifiable Presentation Request has an interact field, which can instruct software on how it should handle the interaction. Sometimes, that might be by opening a web browser and taking the individual to a website to do some manual process (and they get their Verifiable Credential at the end of that process). Other times, like in the case of vc-refresh-2021 (where refresh can happen automatically), that might be executing some sort of machine-to-machine protocol.

The VC Refresh 2021 spec is just one spec that uses this interaction approach using the Verifiable Credentials API, and the thing that kicks all of that off is the refreshService in the Verifiable Credential.

In any case, more detail on your suggestion -- yes, we're going down that path with at least one of the VC protocols.

[iherman]

The issue was discussed in a meeting on 2022-02-02

• no resolutions were taken

View the transcript

3.2. [Tracking Issue - Proposed Corrections Feedback] URL to URI (issue vc-data-model#862)

See github issue vc-data-model#862.

See github pull request vc-data-model#866.

Brent Zundel: This is another tracking change from URL to URI -- general concern around using URIs vs. URLs. There is a PR to address this..
… This was raised by kdenhartog.

Kyle Den Hartog: Status is that it should be ready to go, pending approval, the Google representative has approved it..
… It looks like we're going to leave this issue open as well, just to track during the v2.0 work..
… We should address this in detail when new WG is formed..

Brent Zundel: We're looking for more review..
… Any questions on response to feedback before we move on to our next topic?.

[brentzundel]

This PR is related to Issue #862

[iherman]

The issue was discussed in a meeting on 2022-02-09

• no resolutions were taken

View the transcript

3. v1.1 feedback.

Brent Zundel: https://github.com/w3c/vc-data-model/labels/V1.1%20feedback.

Brent Zundel: we have addressed the feedback to the best of our ability so far.

Manu Sporny: google are asking us to state that data is expected at the end of these URIs..
… kyle has added this to the feedback.

See github pull request vc-data-model#866.

Brent Zundel: this PR addresses all that we can do non-normatively.

Ivan Herman: we will need a WG resolution to say we will go to final rec at some point in time.
… we need one paragraph to answer google's concern.
… we need to make sure that no further changes are in the final doc to be published (including the proposed editorials).

Brent Zundel: we will have a further resolution to include the editorials after the final version is published.

Ivan Herman: putting editorials in the final version that address the comments of google (and others) is fine. It is other editorials that should be excluded.

Manu Sporny: respec was updated to do linting on the specification and call out for definitions that are not referred to. So when you reference these 13 terms that are defined in the spec, they should be referenced using the specification.
… one option is to leave things as the are.
… the other option is to remove these 13 definitions.

Brent Zundel: +1 to just publishing, raise an issue to track cleanup, imo..

Ivan Herman: I advise we do not make any further changes..
… in version 2 we are free to do whatever we want, but not in v1.1.

Michael Prorock: +1 ivan.

[msporny]

Editorial, multiple positive reviews, no objections, merging.

[iherman]

The issue was discussed in a meeting on 2022-02-16

• no resolutions were taken

View the transcript

1.1. [Tracking Issue - Proposed Corrections Feedback] URL to URI (issue vc-data-model#862)

See github issue vc-data-model#862.

See github pull request vc-data-model#866.

Kyle Den Hartog: +1 to merging now.

Brent Zundel: proposal to merge now.

Manu Sporny: this needs to be squashed and merged.