Add informative reference workflow step processing appendix - #701
Add informative reference workflow step processing appendix#701PatStLouis wants to merge 3 commits into
Conversation
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>
Carry-over from #626 / #596 review feedbackThis PR is meant to supersede #626 while keeping the review asks addressed: TallTed (#626 inline) — Deeper overhang / hanging indents on the TallTed (#596) — Grammar (“information is”) and clearer nesting Manu (#596 + meeting) — Non-normative, appendix, protocol-agnostic, algorithm #626 editorial — Balanced parentheses; implementation-specific max step count MAY TallTed (conversation) — Retry PR Preview No further code changes planned for these items unless reviewers want lettered outline numbering instead of the nested algorithm counters. |
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>
f5b8404 to
27532b9
Compare
|
Rebased onto updated #700 (includes list-of-maps matching + deterministic |
| 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>. |
There was a problem hiding this comment.
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.
| <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>. |
There was a problem hiding this comment.
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.
Summary
ol.algorithmstyle (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.<pre>-based approach in #626.Stack: Branched from #700 (
OpSecId:docs/qbe-matching-and-json-pointers). This PR currently targetsmain, so the GitHub diff may also show #700 commits until that PR merges—review the tip commitdocs: add informative reference workflow step processing appendixfor this change. After #700 merges, rebase this branch ontomain.Closes #596
Supersedes #626
Test plan
ol.algorithmnumbering renders.mainand confirm the diff is appendix-only.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:
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.