Hi Azat and Songbo, Azat, thank you for the report, and for the care that went into it. The suite on main is still the file you ran, so the result holds for the current version.
For §6.5, here's the intent I had in mind for -02: - C1: a header with duplicate members should be rejected, for the same reason as claims, as your implementation does. - C3: agreed, it doesn't change any verdict. - C5: aat_aud is a single string, as Table 5 says. The pointer to aud is about what it means, not its form. - C6: a root signed by the shared key passes under either one of the issuers. What the enforcement point trusts is the key, and 3k only checks that the root names an issuer that key is trusted for. - C8: a well-formed public key for a signature algorithm, under its kty's rules (RFC 8037 for OKP). And you're right that J.24.10 expects a narrower step than its own description allows. - C10: absolute-URI, as in RFC 3986. C2 is a good catch. I'm looking at addressing all ten in -03, and I'll reply on the issues you opened as well. Of the four points still open from -01, B12 and B15 work the way your aat-02 profile has them: an exact comparison, and sub ignored. B9 and B18 are by design. Songbo, thanks for the C6 cases. All seven fit the reading I described above. Your paired control is in the suite as J.21.22, a root with the first anchor's iss signed by the second anchor's key. The suite on main has no case yet where two anchors share a key or an issuer, since its two anchors differ in both. Adding those is on my list for -03, along with cases for C1 and C5. Best, Niki On Tue, Nov 3, 2026 at 1:03 AM Azat Davliatshin <[email protected]> wrote: > Hi Songbo, > > Thank you very much, both for rerunning the verifier against the > AAT-02 corpus and for the C6 cases. I checked the bundle against > d813114 and got the same 13/13 and identical anchor-results.json. The > paired negative control (issuer and key in different anchor records) > is exactly the case the existing vectors cannot reach, since all their > anchors have distinct keys. > > Yes, they would be useful. Could you open them as a pull request from > a fork of github.com/azatdavliatshin/aat? That way the authorship and > the Apache-2.0 contribution stay in the history, and I can review and > merge there. > > One correction to the context: the draft authors are not aware of C6 > yet. I have not filed it with them so far; I plan to open an issue on > tenuo-ai/tenuo today and will post the link to this thread. Until they > answer, the tests document this implementation's interpretation, as > your README already says. > > If you agree, I would also like to acknowledge your rerun and the C6 > tests in the next revision of the report. > > Best, > Azat > > вт, 3 нояб. 2026 г. в 05:39, Songbo Bu <[email protected]>: > > > > Hi Azat, > > > > I reran your verifier at d813114 against the bundled AAT-02 corpus. All > 229 vectors agree in the existing presentation/array checks, including the > denial-step and tracked replay-state checks. This uses the bundled oracle, > not a separate implementation. > > > > For C6, I added seven small issuer/key-pair regressions. They cover a > shared key under two issuer names in both orders, wrong-issuer and > wrong-key controls, and a key-rotation ordering. The paired negative > control places the correct issuer and the verifying key in different anchor > records; it denies at 3k rather than combining them. > > > > All seven pass without changing the verifier. The small attached bundle > contains the test, patch, results and reproduction instructions. > > > > Would these be useful as regression coverage for your stated > interpretation while the draft authors clarify C6? > > > > Best, > > Songbo > _______________________________________________ > WIMSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Niki Aimable Niyikiza Tenuo
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
