Skip to content

Add informative reference workflow step processing appendix - #701

Open
PatStLouis wants to merge 3 commits into
w3c:mainfrom
OpSecId:docs/workflow-processing-algorithm-596
Open

Add informative reference workflow step processing appendix#701
PatStLouis wants to merge 3 commits into
w3c:mainfrom
OpSecId:docs/workflow-processing-algorithm-596

Conversation

@PatStLouis

@PatStLouis PatStLouis commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Adds an informative appendix documenting one reference algorithm for walking exchange/workflow steps until client input is needed or a response is ready (#596).
  • Uses ol.algorithm style (same approach as Data Integrity / ECDSA cryptosuites and #700); includes protocol hooks (prepareStep, inputRequired, isStepComplete, etc.) so the loop stays agnostic to VC-API / OID4VP / OID4VCI / invite bindings.
  • Cross-links from Workflows and Exchanges. Supersedes the <pre>-based approach in #626.

Stack: Branched from #700 (OpSecId:docs/qbe-matching-and-json-pointers). This PR currently targets main, so the GitHub diff may also show #700 commits until that PR merges—review the tip commit docs: add informative reference workflow step processing appendix for this change. After #700 merges, rebase this branch onto main.

Closes #596
Supersedes #626

Test plan

Made with Cursor


💥 Error: 500 Internal Server Error 💥

PR Preview failed to build. (Last tried on Aug 11, 2026, 6:57 PM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Spec Generator - Spec Generator is the web service used to build bikeshed/ReSpec specs

🔗 Related URL

Error output:

EISDIR: illegal operation on a directory, open 'uploads/uVOIek/'

This seems to be an issue with the Spec Generator service. PR Preview doesn't manage this service and so has no control over it. If you've identified an issue with it, you can report the issue to the maintainers of Spec Generator directly. Please be courteous. Thank you!

If you don't have enough information above to solve the error by yourself or if the issue doesn't seem related to Spec Generator, you can file an issue with PR Preview.

Add normative QueryByExample credential matching (w3c#574) and conversion of
example objects to selective-disclosure JSON pointers (w3c#545), using
vc-di-ecdsa algorithm style. Fixes @context prefix matching and
acceptedIssuers against the current property table.

Co-authored-by: Cursor <cursoragent@cursor.com>
@PatStLouis

Copy link
Copy Markdown
Collaborator Author

Carry-over from #626 / #596 review feedback

This PR is meant to supersede #626 while keeping the review asks addressed:

TallTed (#626 inline) — Deeper overhang / hanging indents on the <pre> numbered list
→ Resolved by replacing the <pre> with nested <ol class="algorithm"> lists and the existing VCALM algorithm CSS counters (1), 1.1), …), which is also what Manu asked for in the 26 May 2026 discussion.

TallTed (#596) — Grammar (“information is”) and clearer nesting
→ Intro rewritten (that phrase is gone); nesting handled by ol.algorithm rather than lettered outline tiers (a. / i.), so we stay aligned with Data Integrity / ECDSA algorithm style used elsewhere in this stack (#700).

Manu (#596 + meeting) — Non-normative, appendix, protocol-agnostic, algorithm ol markup
→ Informative appendix (class="appendix informative"), protocol hooks kept underspecified, ECDSA-style “Required inputs… produced as output” + ol.algorithm.

#626 editorial — Balanced parentheses; implementation-specific max step count MAY
→ Retained in the algorithm prose.

TallTed (conversation) — Retry PR Preview
→ Process note only; this new PR can be previewed on its own when preview is available.

No further code changes planned for these items unless reviewers want lettered outline numbering instead of the nested algorithm counters.

PatStLouis and others added 2 commits August 11, 2026 14:57
Recurse into maps when matching list elements, and always append /type and
/issuer during example-to-pointer conversion so the MUST output bar matches
the selectivePointers example.

Co-authored-by: Cursor <cursoragent@cursor.com>
Document one non-normative exchange step-processing loop as an appendix,
using ol.algorithm style and protocol hooks, with a cross-link from
Workflows and Exchanges. Addresses w3c#596; supersedes the approach in w3c#626.

Co-authored-by: Cursor <cursoragent@cursor.com>
@PatStLouis
PatStLouis force-pushed the docs/workflow-processing-algorithm-596 branch from f5b8404 to 27532b9 Compare August 11, 2026 18:57
@PatStLouis

Copy link
Copy Markdown
Collaborator Author

Rebased onto updated #700 (includes list-of-maps matching + deterministic /type//issuer mandatory pointers).

@PatStLouis
PatStLouis marked this pull request as ready for review August 11, 2026 18:59
Comment thread index.html
index <var>i</var> from <code>0</code> to the length of
<var>expectedContexts</var> minus one, if
<var>expectedContexts</var>[<var>i</var>] is not strictly equal to
<var>credentialContexts</var>[<var>i</var>], return <code>false</code>.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

It might be nice to provide a human summary of the effect of context comparison, like "Ensure the contexts in the credential match each of the required list of contexts, allowing subsequent contexts in the credential after all required contexts.

Comment thread index.html
<var>credentialTypes</var> to the value of the <code>type</code> property of
<var>credential</var> normalized to a [=list=]. If no value in
<var>expectedTypes</var> is strictly equal to any value in
<var>credentialTypes</var>, return <code>false</code>.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The summary of this comparison is what, that we match ANY of the types that appear in the example. I would have assumed the intent would be more like the other properties in that all of the types that appear in expectedTypes must be present in credentialTypes. I read the current wording as "Any one type that appears in expectedTypes must appear in credentialTypes. If a query includes VerifiableCredential as a type, that would broadly match.

Either we instruct people to not include VerifiableCredential here or we change the wording here to require all expectedTypes entries to appear in credentialTypes not just any.

Or I'm reading this incorrectly, feel free to correct my understanding.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Consider defining normative/non-normative workflow processing algorithm

2 participants