Does the spec need normative statements for the Verifiable Presentation Request?

[aljones15]

https://w3c-ccg.github.io/vc-refresh-2021/#unmediatedrefresh2021-protocol

In UnmediatedRefresh2021 Protocol Section 3.2 Step 6:

Use an HTTP client to perform an HTTP GET on url. The response from the server MUST be a Verifiable Presentation Request [VP-REQUEST] as defined by the Presenting section of the [VC-API] specification.

1. The presenting section of the linked spec contains multiple different types of presentations
2. The implied return type is a VP with a credentialQuery
3. The credentialQuery in turn should query for the Vc being refreshed, but how is not specified
4. The examples query for didAuth and then byExample

So I think we need a normative statement here:

7. The Verifiable Presentation Request MUST included a query that finds the Verifiable Credential being refreshed by an unique id in addition to any other queries required for authentication or other reasons.

This removes ambiguity, but retains the open design of the specification.

[msporny]

7. The Verifiable Presentation Request MUST included a query that finds the Verifiable Credential being refreshed by an unique id in addition to any other queries required for authentication or other reasons.

An Issuer App is not guaranteed to know who is making a call to it, so it cannot always know what ID to ask for.

Some, but not all VCs have a unique ID, IIRC, so we can't make that a normative statement.

We might be able to do something to this effect:

The Verifiable Presentation Request MUST include a query that a client can use to provide information needed to refresh the credential.

There are cases where you might never need to send anything to do a credential refresh as the refresh URL is unique to your account? So, the MUST might need to change to a SHOULD?

What we probably need to do is at least provide a DIDAuth flow and more clearly outline the query by example specs.

[aljones15]

Another possibility would be the holder remembers which Vc it's making the refresh request for. My biggest concern here is that VP Query from the server might be vague enough to result in a refresh of Vcs that weren't intended to be refreshed. An example would be I have 3 Vcs representing memberships at different climbing gyms all issued by the same issuer and using an identical refreshService. I only want to refresh one of those memberships and let the other 2 expire. So if the holder remembers which one then they can supply that Vc provided it meets the query's specifications. Alternatively, the refreshService url could contain the vc id when issued making the refreshService request specific for a single Vc.