URI validation in AttrPath

[tomsik68]

Hello,

first of all thank you very much for your hard work on this project!

TLDR: Is it intentional that URN must not contain dashes?

Context

I'm building a SCIM server that supports a custom user extension with the following URI: urn:tomsik68:scim:schemas:extension:a-b-c-d:1.0:User. CreateUser request works just fine. PatchUser request validates and parses the Path of each operation.

Here's what my minimal PatchUser request looks like:

{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "Add",
      "path": "urn:tomsik68:scim:schemas:extension:a-b-c-d:1.0:User:customAttribute"
    }
  ]
}

The path validation fails with the following error:

parse conflict [00:001]: expected op.Or or[and[func func{0:1}] func] but got "ur"

I believe this is due to the way we parse URI in uri.go. The URI validator seems to restrict all URIs to only consist of something like ([a-zA-Z0-9.]+:)+. In RFC-7644, a "URI" is defined per Appendix A of [RFC3986]. Following the ABNF, I believe a dash can be a part of a URN: URI -> hier-part -> path-rootless -> segment-nz -> pchar -> unreserved -> "-". The RFC-3986 validator also reports that the URN is valid.

My question is: Is it intentional that the validator rejects dashes in the URN?

Thanks for any response!

[q-uint]

Hey @tomsik68! No, this is not intentional, and thank you for providing such a detailed breakdown.

You’re absolutely correct, dashes are permitted within URNs as part of the unreserved character set, meaning your URN urn:tomsik68:scim:schemas:extension:a-b-c-d:1.0:User is indeed valid. It looks like the current validation in uri.go is overly restrictive and doesn’t fully account for this.

I may not be able to address this immediately, but your insights have clarified the issue well. I’d be happy to review any PRs if you’d like to contribute a fix, or otherwise, I’ll try to circle back when possible.

Thanks for helping improve the project!

~ Quint

---

See RFC 8141 - Section 2