Description

When using a relative URI like ./#me or /#me in an ACL file to reference the owner's WebID, it doesn't seem to match the authenticated user's WebID during authorization checks.

Steps to Reproduce

1. Set up JSS with WebID at https://example.com/#me
2. Create root ACL (.acl) with relative agent:

{
  "@context": {
    "acl": "http://www.w3.org/ns/auth/acl#",
    "foaf": "http://xmlns.com/foaf/0.1/"
  },
  "@graph": [
    {
      "@id": "#owner",
      "@type": "acl:Authorization",
      "acl:agent": { "@id": "./#me" },
      "acl:accessTo": { "@id": "./" },
      "acl:default": { "@id": "./" },
      "acl:mode": [
        { "@id": "acl:Read" },
        { "@id": "acl:Write" },
        { "@id": "acl:Control" }
      ]
    }
  ]
}

3. Authenticate as https://example.com/#me
4. Try to PUT a resource

Expected Behavior

./#me in /.acl should resolve to https://example.com/#me and match the authenticated user, granting write access.

Actual Behavior

Returns 403 Forbidden. The wac-allow header shows user="read" (from public ACL) instead of including write permissions.

Workaround

Using the absolute URI works:

"acl:agent": { "@id": "https://example.com/#me" }

Environment

• JSS version: 0.0.72
• Node.js: v22.21.1

Notes

This may be a URI resolution issue where the relative reference isn't being resolved against the ACL document's base URI before comparing with the authenticated WebID.