Remote Credential Registry#571
Conversation
When a multi-format scheme (e.g. AtomicAttribute2023) shares JSON-style claimDescriptions across representations, the ISO mdoc mapping advertised claims as ["given_name"] instead of [isoNamespace, "given_name"]. Namespace-qualify ISO claim paths, skipping paths that already carry the namespace (as metadata-derived ISO schemes do).
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 108c830e6b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
ISO store entries serialized before StoreEntry.schemeIdentifier existed keep that field null. Passing it straight to the input-descriptor evaluator made PresentationExchangeInputEvaluator reject every MSO_MDOC descriptor keyed by docType. Fall back to the credential's own identifier (mdoc docType, SD-JWT vct, or W3C VC type) when the stored field is null.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
VC-JWT credentials commonly carry `type` as an array, while verifiers filter $.type for a single type string. Make the Presentation Exchange matcher treat a scalar const/pattern/enum filter as satisfied when any array element matches, and expose the full VC type array again for legacy store entries. Supersedes the scalar-only fallback with a representation that also matches multi-type VCs.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a1fec15d15
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (this is JsonArray && filter.type != "array" && | ||
| (filter.const != null || filter.pattern != null || filter.enum != null) | ||
| ) { | ||
| return any { it.matchConstraints(filter) } |
There was a problem hiding this comment.
Limit scalar array matching to VC type checks
This relaxation now applies to every constraint field, not just the legacy $.type case described in the comment. A verifier that requires a scalar claim, e.g. $.status with type: "string" and const: "active", will also accept a credential whose selected node is an array such as ["active", "revoked"], even though the field itself does not satisfy the requested JSON type. That can make Presentation Exchange accept credentials that fail non-type scalar constraints; consider moving this special-case to the VC type constraint path or otherwise scoping it to $.type.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
should be easy to cover with a test
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
JesusMcCloud
left a comment
There was a problem hiding this comment.
pending the Codex comment
| if (this is JsonArray && filter.type != "array" && | ||
| (filter.const != null || filter.pattern != null || filter.enum != null) | ||
| ) { | ||
| return any { it.matchConstraints(filter) } |
There was a problem hiding this comment.
should be easy to cover with a test
Finishes the work of #566 and #567 for now.
Metadata documents are available at a-sit-plus/credentials-collection#1
Next up: Integration into Relying Party, Issuing Backend and Valera.