Enforce a stricter implementation of Spiffe spec

[lenin-jaganathan]

I am going through the current implementation of SpiffeId in this library and noticed a couple of deviations from the spec.

1. The scheme validation seems to strictly enforce lower-case during the parse operation, whereas the spec seems to treat the scheme to be case-insensitive for parsing. (same goes for the trustdomain, though it must be lower-case, I guess, as per spec, the parsing should be case-insensitive)
2. Maximum Spiffe Id length seems to enforce the URI to be atmost 2048 and host to be atmost 255 characters, but the implementation seems to enforce this. (The spec uses "MUST", hence this question)

If these are design choices or if I missed something, apologies. Also, happy to contribute if these are some of the valid concerns.

[maxlambrecht]

hey @lenin-jaganathan, thanks for raising this and for taking the time to review the implementation carefully.

On case handling, you are correct that the current parser is stricter than the SPIFFE-ID spec. Today it requires a lowercase spiffe:// prefix and lowercase trust domain input, rather than accepting case-insensitive input and normalizing it. That is a real spec-alignment issue.

On maximum length, I do not believe the current implementation is violating section 2.3 of the spec. That section says implementations MUST support SPIFFE IDs up to 2048 bytes in length and SHOULD NOT generate IDs longer than 2048 bytes. It does not say that parsers must reject IDs longer than that. Similarly, while the spec notes that RFC 3986 defines a maximum host length of 255 characters, this library does not currently implement that as a hard validation rule.

So, as the code stands today, the lack of explicit maximum-length rejection for SPIFFE IDs or trust domains is not, by itself, a spec violation. The gap there is really test coverage: we do not currently have explicit tests demonstrating support for long valid IDs near those limits.

So I think the actionable issue from your report is the case-handling behavior. The maximum-length item looks more like a possible test improvement than a parser bug.