docs(applet): refresh stale comments referring to deleted INS_EXCHANGE stub

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
michael
2026-06-11 11:04:05 -07:00
parent ebefc4e358
commit 87065b0e15
2 changed files with 9 additions and 9 deletions

View File

@@ -880,10 +880,11 @@ public class AliroApplet extends Applet {
// Aliro.a errors out when bits 0 + 2 are clear and AD is provisioned
// -- it expects "AD present" to be advertised. The bits are
// informational about capabilities anyway, not enforceable
// commitments, so 0x0005 satisfies the vendor library while we still
// 6D00 / 9000-stub any EXCHANGE/ENVELOPE that actually arrives.
// Revisit when real Step-up lands or when we test against more
// readers and can lean on the spec literally.
// commitments, so 0x0005 satisfies the vendor library. AliroApplet
// now returns 6D00 for any post-AUTH1 INS like 0xC9 -- StepUpApplet
// at ACCE5502 handles ENVELOPE and EXCHANGE properly per spec §10.2
// + §8.4. Revisit when we test against more readers and can lean on
// the spec literally.
short bitmap = 0;
if (store.hasAccessDocument()) {
bitmap |= 0x0001; // bit 0

View File

@@ -53,11 +53,10 @@ import javacard.framework.Util;
* implantable target but document the limitation.</li>
* </ol>
*
* <p>Also when this lands, revisit {@link AliroApplet}'s {@code INS_EXCHANGE}
* stub: with real Step-Up at this AID, the stub becomes either (a) unused
* if {@code signaling_bitmap} bit 2 stays set and spec-conformant readers
* route EXCHANGE here, or (b) replaceable with a proper "Reader Status
* sub-event" reply if X-CUBE-ALIRO's vendor bug persists.
* <p>The {@code AliroApplet.INS_EXCHANGE} stub was retired once StepUpApplet
* landed handling for 0xC9 directly — spec-conformant readers (X-CUBE-ALIRO
* included, once the upstream crypto interop is right) route EXCHANGE here
* after the step-up AID SELECT per §10.2.
*/
public class StepUpApplet extends Applet {