1/OPENAC: tracking — verifier-side profile boundary clarifications

[cc03668]

This issue was originally opened as privacy-ethereum/zkspecs#22. It is preserved here verbatim because cross-org issue transfer required permissions the original author doesn't hold. The original issue has been closed with a pointer back to this one.

Context

This issue tracks open verifier-profile questions for 1/OPENAC
(added in privacy-ethereum/zkID#88; supersedes the earlier draft at zkspecs#21).

The OpenAC spec defines proof-bundle handling and a current
SD-JWT-P256 profile. While reviewing the implementation surface, several
verifier-facing semantics appear to be implicit in the PoC, delegated to
the caller, or not yet specified as normative rejection rules. If these
are not made explicit, different verifier integrations could accept
different presentations, interpret the same public inputs differently,
or accidentally accept presentations that are cryptographically valid
but semantically unsafe.

This issue collects each item so we can decide, per question, whether it
belongs in 1/OPENAC, the SD-JWT-P256 profile, or deployment policy.

cc @oskarth @vplasencia

Checklist

• 1. Core vs profile vs deployment policy. What exactly belongs
  in OPENAC, SD-JWT-P256, and application/deployment code?
  Risk: App developers may think the SDK performs full verifier
  validation when it only verifies proofs.
• 2. Issuer trust and JOSE validation. Does the profile require
  alg=ES256, reject alg=none, resolve kid, and bind issuer keys
  to iss / credential type / trust policy?
  Risk: A verifier may prove the credential was signed by some key,
  not a trusted issuer key.
• 3. Audience / verifier binding. Is the challenge bound to a
  verifier identity, audience, origin, session, or policy hash?
  Risk: Verifier A could forward a holder's valid presentation to
  Verifier B.
• 4. Challenge freshness / replay. What are the minimum nonce
  entropy, TTL, single-use, and replay-cache requirements?
  Risk: Verifiers may accept stale, reused, or predictable challenges.
• 5. ECDSA encoding and malleability. Are signatures required
  to be raw r || s? Is DER rejected? Are high-S signatures accepted
  or rejected?
  Risk: Different libraries/verifiers may disagree on whether the
  same presentation is valid.
• 6. Disclosure digest and ordering. Are disclosure digests
  computed over exact raw disclosure bytes? Does disclosure ordering
  affect claim slots?
  Risk: Implementations may hash different bytes or assign claims to
  different slots.
• 7. Claim slot mapping. How does the verifier know that
  claimRef = 0 means a specific claim name/path?
  Risk: A proof may show that some scalar satisfies a predicate, but
  not that the intended credential claim does.
• 8. Claim normalization. Are bool, uint, iso_date, roc_date,
  and string parsing rules normative for SD-JWT-P256?
  Risk: Different SDKs may normalize the same credential differently.
• 9. compareValue and valueBits. Are comparisons unsigned 64-bit
  integer comparisons? Are overflow, negative values, and unsupported
  type/operator pairs rejected?
  Risk: Circuit comparisons may not match application-level semantics.
• 10. Challenge hash vs circuit scalar. Is
  SHA-256(UTF8(challenge)) mod q_P256 only the circuit scalar
  encoding, distinct from the ECDSA signing input?
  Risk: Implementers may sign/verify different bytes than the circuit
  expects.
• 11. Proof validity vs policy acceptance. Does the SDK return
  proof validity separately from expression_result / authorization
  result?
  Risk: Apps may treat "proof verified" as "policy satisfied."
• 12. Device public key exposure. Is exposing deviceKeyX/Y
  intended long-term behavior or only a current implementation artifact?
  Risk: A stable device public key may become a verifier-observable
  tracking identifier.
• 13. Version semantics. Does version identify
  profile/proof-bundle semantics, not SDK release metadata?
  Risk: Verifiers may use the wrong verifying key, circuit params,
  or profile semantics.
• 14. Conformance / negative tests. Can we add negative verifier
  fixtures for malformed JOSE headers, wrong issuer binding,
  stale/reused challenge, wrong audience, DER/high-S signatures, wrong
  claim slots, invalid normalization, and overflowed compareValue?
  Risk: Downstream integrations will each invent their own verifier
  behavior.

Acceptance

For each item, the resolution should classify it as one of:

• CORE: normative in 1/OPENAC
• PROFILE: normative in SD-JWT-P256 profile
• POLICY: explicitly delegated to deployment, with required
  fail-closed behavior in the SDK when the policy input is missing

Items resolved as CORE or PROFILE land as PRs against specs/1-openac/.
Items resolved as POLICY land as documentation/SDK changes elsewhere.

[cc03668]

Originally posted by @cc03668 on 2026-05-11 in zkspecs#22. Re-posting here to preserve discussion history through the cross-repo move.

Some ideas for the solutions to these issues:

1. Core vs profile vs deployment policy. What exactly belongs in OPENAC, SD-JWT-P256, and application/deployment code?
   Define three layers explicitly:

• OPENAC: proof verification, Prepare / Show linking, proof-bundle semantics.
• SD-JWT-P256: JOSE rules, claim normalization, challenge encoding, ECDSA encoding, claim-slot semantics.
• Deployment policy: issuer trust, replay storage, revocation, business authorization.

2. Issuer trust and JOSE validation. Does the profile require alg=ES256, reject alg=none, resolve kid, and bind issuer keys to iss / credential type / trust policy?
   SD-JWT-P256 should require:

• alg = ES256
• reject alg = none
• reject unsupported/unknown critical headers
• resolve kid through an explicit issuer resolver
• bind issuer key to iss and credential type through verifier policy
  The SDK should not accept arbitrary issuer public keys without an explicit trust policy hook.

3. Audience / verifier binding. Is the challenge bound to a verifier identity, audience, origin, session, or policy hash?
   The profile should require the challenge to include or bind to:

• verifier identity / audience
• nonce
• profile identifier
• optionally policy hash
  If this is left to transport/session binding, the spec should say so explicitly and define the verifier’s responsibility.

4. Challenge freshness / replay. What are the minimum nonce entropy, TTL, single-use, and replay-cache requirements?
   Define minimum verifier requirements:

• at least 128 bits of unpredictable nonce entropy
• single-use challenge
• bounded TTL, for example profile-defined default
• replay cache scoped by verifier identity, profile, and nonce
  The SDK should expose a challengeStore / replay-check interface.

5. ECDSA encoding and malleability. Are signatures required to be raw r || s? Is DER rejected? Are high-S signatures accepted or rejected?
   For SD-JWT-P256 , define signature encoding as fixed-width raw r || s , 32 bytes each, big-endian.
   Also define malleability behavior:

• device signatures should preferably require low-S
• issuer JWT signatures can either require low-S or explicitly accept both high-S/low-S for compatibility
  The important part is that verifier and circuit behavior must match.

6. Disclosure digest and ordering. Are disclosure digests computed over exact raw disclosure bytes? Does disclosure ordering affect claim slots?
   Disclosure digest should be computed over the exact raw disclosure string bytes.
   Rules:

• no JSON reserialization before hashing
• duplicate disclosures rejected
• disclosure order should not affect digest validity
• disclosure order should not implicitly define claim slots unless explicitly standardized

7. Claim slot mapping. How does the verifier know that claimRef = 0 means a specific claim name/path?
   Introduce a profile-defined claimSlotTable
   Example:

[
  { "slot": 0, "claim": "birthdate", "format": "iso_date" },
  { "slot": 1, "claim": "country", "format": "string" }
]

claimRef should refer to this table, not to arbitrary disclosure order.
If applications define their own slot table, the SDK should require it explicitly.

8. Claim normalization. Are bool, uint, iso_date, roc_date, and string parsing rules normative for SD-JWT-P256?
   Keep normalization profile-specific.
   For SD-JWT-P256 , define exact parsing/rejection rules for:

• bool
• uint
• iso_date
• roc_date
• string
  Invalid dates, negative integers, overlong strings, unsupported characters, and ambiguous encodings should be rejected before proof verification.

9. compareValue and valueBits. Are comparisons unsigned 64-bit integer comparisons? Are overflow, negative values, and unsupported type/operator pairs rejected?
   Define comparisons as unsigned bounded integer comparisons unless a format says otherwise.
   For current profile:

• default valueBits = 64
• reject negative compareValue
• reject compareValue >= 2^valueBits
• range-check claim values and compare values
• reject unsupported operator/type pairs, such as LE over string unless explicitly defined

10. Challenge hash vs circuit scalar. Is SHA-256(UTF8(challenge)) mod q_P256 only the circuit scalar encoding, distinct from the ECDSA signing input?
    Use separate terms:

challenge_bytes
challenge_digest = SHA-256(challenge_bytes)
challenge_scalar = OS2IP(challenge_digest) mod q_P256

Make clear that challenge_scalar is only the Show-relation field encoding. It should not redefine how external ECDSA libraries sign or verify messages.

11. Proof validity vs policy acceptance. Does the SDK return proof validity separately from expression_result / authorization result?
    SDK verifier result should separate:

{
  proofValid: boolean,
  linked: boolean,
  expressionResult: boolean,
  policyAccepted: boolean
}

A proof with expressionResult = false may still be cryptographically valid, but must not authorize the user.

12. Device public key exposure. Is exposing deviceKeyX/Y intended long-term behavior or only a current implementation artifact?
    Treat deviceKeyX/Y exposure as a current implementation artifact, not a long-term core requirement.
    Core should require proof of possession of the bound device key, but should not require exposing a stable verifier-observable device identifier unless the profile explicitly accepts that privacy tradeoff.

13. Version semantics. Does version identify profile/proof-bundle semantics, not SDK release metadata?
    Define version as protocol/profile/proof-bundle semantics, not SDK release metadata.

Verifier should bind accepted versions to:

• verifying key
• circuit parameters
• profile identifier
• claim normalization rules
• challenge encoding
• public input layout
  SDK version should not be used as protocol version.

14. Conformance / negative tests. Can we add negative verifier fixtures for malformed JOSE headers, wrong issuer binding, stale/reused challenge, wrong audience, DER/high-S signatures, wrong claim slots, invalid normalization, and overflowed compareValue?
    Add verifier conformance tests, especially negative fixtures.
    Minimum useful cases:

• alg = none
• wrong alg
• unknown kid
• wrong iss binding
• stale/reused challenge
• wrong audience
• DER signature when raw is required
• high-S signature if low-S is required
• duplicated disclosure
• wrong claim slot
• invalid date/string/uint normalization
• negative or overflowing compareValue
  This turns verifier-profile behavior into testable SDK behavior instead of integration-specific assumptions.
  Author: cc03668
  Created: 2026-05-14T17:38:10Z

Heads-up: transferring this tracker to privacy-ethereum/zkID so it lives alongside the spec it tracks (privacy-ethereum/zkID#88).

The URL will change after the transfer, but the issue body and comment history are preserved. I'll edit the body afterward to point at 1/OPENAC and the new PR.

[vplasencia]

1. Agree with your answer.

2. Agree with your answer.

3. I don't think we have this implemented.

4. It's a single use challenge and there will be a new nonce with a new request.

The important part is that verifier and circuit behavior must match.

Agree

duplicate disclosures rejected

Duplicate disclosures can be accepted. Some credentials might have duplicate claims and it should be fine.

disclosure order should not affect digest validity

I think disclosure order is important and should always be the same.

Claim slot mapping. How does the verifier know that claimRef = 0 means a specific claim name/path?

Verifiers should know the credential format and can ask directly for the value. We can also work on devex and make it easier for them.

8. Agree. We should keep normalization profile-specific.

Define comparisons as unsigned bounded integer comparisons unless a format says otherwise.

Correct.

It should not redefine how external ECDSA libraries sign or verify messages.

Agree

Does the SDK return proof validity separately from expression_result / authorization result?

No, the verifier using the SDK should use the expression_result value (which is part of the proof) and decide what to do when the predicate was not satisfied.

12. Agree with your answer

expressionResult = false will still be a valid proof. Verifiers should decide what to do when the predicate was not satisfied.

SDK version should not be used as protocol version.

Correct, they should be related but not the same.

Conformance / negative tests

Yes, we can add more negative tests.

We can add a validation layer for these in the SDK.

[cc03668]

All 14 items resolved in #88 commit 98be1f6.

Classification outcome (where each item landed in the spec):

#	Item	Classification	Spec location
1	Layer split	CORE	README "Layering"
2	JOSE / issuer trust	PROFILE + POLICY	README "JOSE Header and Issuer Trust", "Issuer Trust Resolution"
3	Audience binding	POLICY (SDK warning)	README "Audience Binding"
4	Challenge freshness / replay	PROFILE + POLICY	README "Challenge Freshness and Replay"
5	ECDSA encoding	PROFILE	README "ECDSA Signature Encoding"
6	Disclosure digest / order	PROFILE	README "Disclosures" (duplicates accepted, order significant)
7	Claim slot mapping	not a normative table	README "Disclosures" (verifier-side resolution)
8	Claim normalization	PROFILE	README "Profile-Specific Claim Normalization"
9	compareValue / valueBits	PROFILE	README "Predicate Encoding"
10	Challenge hash vs circuit scalar	PROFILE	README "Challenge Encoding"
11	Proof validity vs policy acceptance	SDK	README "Verifier Requirements", SOURCE-MATRIX §7
12	Device-key handling	PROFILE	README "Show Public Outputs", SOURCE-MATRIX §2
13	Version semantics	CORE	README "Versioning"
14	Conformance / negatives	PROFILE + SDK	README "Conformance Test Vectors"

Leaving this issue open in case follow-up items emerge while #88 is in
review.