Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

address clarification that the URI can be used to retrieve data #866

Merged
merged 2 commits into from
Feb 16, 2022
Merged

address clarification that the URI can be used to retrieve data #866

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5a7c23c
address clarification that the URI can be used to retrieve data
kdenhartog Jan 26, 2022
56c0663
Update index.html
kdenhartog Jan 27, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 10 additions & 7 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1847,7 +1847,8 @@ <h3>Status</h3>
<code>type</code> <a>property</a>, which expresses the <a>credential</a> status
type (also referred to as the <a>credential</a> status method). It is expected
that the value will provide enough information to determine the current status
of the <a>credential</a>. For example, the object could contain a link to an
of the <a>credential</a> and that machine readable information needs to be
retrievable from the URI. For example, the object could contain a link to an
external document noting whether or not the <a>credential</a> is suspended or
revoked.
</li>
Expand Down Expand Up @@ -2627,13 +2628,15 @@ <h3>Refreshing</h3>
<dl>
<dt><var>refreshService</var></dt>
<dd>
The value of the <code>refreshService</code> <a>property</a> MUST be one or
more refresh services that provides enough information to the recipient's
software such that the recipient can refresh the <a>verifiable credential</a>.
Each <code>refreshService</code> value MUST specify its <code>type</code> (for
The value of the <code>refreshService</code> <a>property</a> MUST be one or more
refresh services that provides enough information to the recipient's software
such that the recipient can refresh the <a>verifiable credential</a>. Each
<code>refreshService</code> value MUST specify its <code>type</code> (for
example, <code>ManualRefreshService2018</code>) and its <code>id</code>, which
is the <a>URI</a> of the service. The precise content of each refresh service is
determined by the specific <code>refreshService</code> <a>type</a> definition.
is the <a>URI</a> of the service. There is an expectation that machine readable
information needs to be retrievable from the URI. The precise content of
Comment on lines +2636 to +2637
Copy link
Member

@msporny msporny Jan 28, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

each refresh service is determined by the specific <code>refreshService</code>
<a>type</a> definition.
</dd>
</dl>

Expand Down