Question: is error_empty_id meant to reject an empty challenge id?
While validating a set of MPP implementations against this suite's vectors, we hit a divergence on the www-authenticate vector error_empty_id and wanted to check the intended canonical behaviour, because the suite, one of the listed SDKs, and the IETF draft don't all agree.
What the vector expects: parsing WWW-Authenticate: Payment id="", realm=..., method=..., intent=..., request=... (empty id) should fail with a parse error.
But mppx (a validated SDK in this suite) accepts it. mppx@0.5.5's challenge id schema allows "" (no minimum length), so it parses the empty-id challenge successfully and would not reject it as error_empty_id expects. So the suite's golden vector and one of its own validated SDKs disagree here.
And the spec doesn't clearly require rejection. In draft-httpauth-payment-00:
id is REQUIRED (Section 5.1.1, "Unique challenge identifier ... MUST bind"), so a missing id must be rejected (every SDK does).- But the ABNF (
auth-param = token BWS "=" BWS ( token / quoted-string ), Section 5.1 / Appendix A) permits a parameter value to be a quoted-string, and an empty quoted-string "" is grammatically valid. There's no explicit prose that an empty id is invalid or "MUST be rejected".
So an empty id is grammatically valid and not explicitly forbidden, yet the conformance vector requires rejecting it.
Question: is error_empty_id's reject expectation the intended canonical behaviour?
- If yes, it might be worth (a) a normative clarification in the spec that
id MUST be non-empty (e.g. 1*tchar / non-zero-length), and (b) tightening mppx to reject it, so the suite, the spec, and the SDKs line up.
- If no (empty
id is acceptable per the grammar), the vector could be relaxed.
Happy to send a PR either way once the intended direction is clear. We're aligning our implementations to this suite and would rather match the canonical intent than guess. Thanks!
Question: is
error_empty_idmeant to reject an empty challengeid?While validating a set of MPP implementations against this suite's vectors, we hit a divergence on the
www-authenticatevectorerror_empty_idand wanted to check the intended canonical behaviour, because the suite, one of the listed SDKs, and the IETF draft don't all agree.What the vector expects: parsing
WWW-Authenticate: Payment id="", realm=..., method=..., intent=..., request=...(emptyid) should fail with a parse error.But
mppx(a validated SDK in this suite) accepts it.mppx@0.5.5's challengeidschema allows""(no minimum length), so it parses the empty-id challenge successfully and would not reject it aserror_empty_idexpects. So the suite's golden vector and one of its own validated SDKs disagree here.And the spec doesn't clearly require rejection. In
draft-httpauth-payment-00:idis REQUIRED (Section 5.1.1, "Unique challenge identifier ... MUST bind"), so a missingidmust be rejected (every SDK does).auth-param = token BWS "=" BWS ( token / quoted-string ), Section 5.1 / Appendix A) permits a parameter value to be aquoted-string, and an empty quoted-string""is grammatically valid. There's no explicit prose that an emptyidis invalid or "MUST be rejected".So an empty
idis grammatically valid and not explicitly forbidden, yet the conformance vector requires rejecting it.Question: is
error_empty_id's reject expectation the intended canonical behaviour?idMUST be non-empty (e.g.1*tchar/ non-zero-length), and (b) tighteningmppxto reject it, so the suite, the spec, and the SDKs line up.idis acceptable per the grammar), the vector could be relaxed.Happy to send a PR either way once the intended direction is clear. We're aligning our implementations to this suite and would rather match the canonical intent than guess. Thanks!