Summary

  • RFC 5397 defines a protected, per-request property that returns one HTTP(S) URL for a principal resource associated with the current authenticated user, or an explicit unauthenticated value.
  • That URL is a bootstrap pointer. It neither enumerates every representation of the principal nor grants a later read, write or configuration action.
  • Reliable automation preserves separate evidence for authentication, principal discovery, URL consistency, resource reachability, privilege evaluation, operation acceptance and user-visible result.

The green account was only partly known

WebDAV ACL already had a language for access decisions. RFC 3744 represented users and groups as principal resources, described access-control entries and exposed a DAV:current-user-privilege-set property. A client could ask what the currently authenticated user was allowed to do on a resource.

That still left an identity-discovery gap. Knowing that the current request could read one collection did not tell the client which principal resource the server associated with the login. A DAV:principal-match report was not a dependable shortcut: it could return the individual principal and all group principals of which that individual was a member. Search produced a set. The client needed a starting point.

RFC 5397 introduced DAV:current-user-principal for that starting point. On a resource under access control, the property contains either one DAV:href or DAV:unauthenticated. The href identifies a principal resource for the authenticated HTTP user. The client can then query that resource for group membership, alternate identifiers or application-specific home collections.

This is a meaningful receipt. It is also a deliberately bounded one. The property tells the client where to continue discovery. It does not say that every later query will succeed, that the principal has write permission, that the application resource exists or that a business action has completed.

One URL does not mean one identity representation

RFC 5397 refuses an attractive simplification. Several URLs may refer to the same principal resource. Several principal resources may correspond to one authenticated principal. Even when the server has several qualifying resources, the property carries only one HTTP(S) URL.

The server is free to select one of those resources, but it should be consistent for the same authenticated principal. That “should” matters operationally. A client may cache the chosen URL. Audit systems may join events on it. Support tools may treat a change as an account migration. If the server rotates among equivalent resources without a documented reason, all three can mistake representational movement for a change of person.

The opposite error is just as dangerous. A client may elevate the selected URL into a universal subject key and discard the server, request and authentication context that gave it meaning. A relative path such as a principal collection member can be perfectly useful inside one authority while being meaningless in another. Even an absolute HTTPS URL identifies a resource, not an eternal human identity.

The safe record therefore preserves at least the service authority, request time, authenticated account, returned URL, redirect chain, relevant certificate identity and the principal properties later obtained. Canonicalization can improve joins, but it cannot invent equivalence across services.

Per-request computation changes what may be cached

The property is protected because the server computes it. It is computed for each request because its answer depends on the request's authentication state. It is never copied or moved with a WebDAV resource.

That rule prevents a subtle category error. A document can survive a COPY or MOVE; the identity associated with the request that performed the operation is not metadata that travels with the document. If an export or migration serializes DAV:current-user-principal as though it belonged to the resource, it freezes a transient observation and attributes it to later readers.

Caching is not forbidden. RFC 6764 later tells CalDAV and CardDAV clients to cache successful discovery details, including the principal URL, and reuse them. But it also says persistent connection or authentication failure should cause clients to repeat service lookup and account discovery. The cache is a performance instrument with a refresh condition, not a permanent identity registry.

That distinction gives operations teams a clean question during failure: is the cached service endpoint stale, is authentication failing, has the server selected a different valid principal representation, is the principal resource unavailable, or has privilege on the target changed? One red “account” state hides those owners.

Unauthenticated is a result, not an empty field

When authentication has not occurred or has failed, RFC 5397 requires the DAV:unauthenticated pseudo-principal. That is stronger than an absent user string. It lets the server state that the request is being evaluated without an authenticated principal.

Clients should preserve that negative result. Reusing the last successful principal URL after an authentication failure can make a screen look helpful while attaching current activity to the wrong identity. Guessing a URL from the username has the same defect: it replaces a server assertion with a naming convention.

RFC 6764 sharpens the boundary for account discovery. Providers are to force authentication on PROPFIND requests that retrieve the property, so the returned principal URL corresponds to the user making the request. If the property is not returned, a client may need to ask the user for the principal path. Absence is a discovery failure with a defined recovery path; it is not permission to manufacture an answer.

A principal URL cannot answer the privilege question

Identity and authorization are related because access-control entries refer to principals. They are not the same event. The current-principal property locates a resource associated with the authenticated user. The current-user-privilege-set property reports the privileges the server computes for that user on a particular resource.

The resource matters. A user may be able to read a principal record, view one calendar and not alter another. Group membership may contribute to a privilege calculation without turning the group resource into the user's direct principal. A successful principal lookup does not precompute every later access decision.

An application also has work after an allowed protocol operation. It may need to locate a calendar home, select a collection, respect an ETag, submit a change and observe that the intended state is visible. Authentication, identity discovery, privilege discovery, HTTP success and application outcome are five different milestones.

This is why “account ready” is too coarse for serious observability. A green login followed by a green current-principal response may coexist with a stale home-set pointer, an inaccessible collection, a denied write or a lost-update precondition. Each condition has a different owner and remediation.

Later discovery made the small property consequential

RFC 5397 contains one principal property and only a few pages of protocol text. Its consequence grew because later CalDAV and CardDAV discovery flows used the principal URL as a bridge.

RFC 6352 describes a client starting with a user identifier, host name and password, locating a service, performing an authenticated PROPFIND and then following the principal URL to address-book properties. RFC 6764 provides a more explicit service-discovery sequence: locate the service, connect with the required certificate checks, authenticate, request the current principal, query that resource for home collections and cache the successful details.

A short pointer can therefore control a long path. That does not enlarge the semantics of the pointer. It enlarges the cost of measuring it badly. If a monitoring system checks only that the property exists, it can declare discovery healthy while the next resource is unreachable. If it checks only the final address book, it cannot tell whether the failure began at service location, authentication, principal choice, home discovery or authorization.

RFC 5397's value is not that it proves the account works. It gives the receipt chain a named identity-discovery step.

What the evidence should say

A defensible trace records the service endpoint and certificate identity, the request target, authentication result, returned current-principal form, selected URL, any redirect, principal-resource response, home-set properties, target-resource privilege set, attempted method, response and observed application state.

Not every environment needs to retain every payload. The principle is to retain enough structured state to distinguish the questions. Sensitive identity and ACL data require minimization and access controls. Hashes, bounded identifiers, status classes and correlation IDs can preserve sequence without copying complete principal records into every log.

The useful management view is a chain, not a badge: endpoint found; user authenticated; principal located; representation stable or explained; principal resource reachable; application home discovered; privilege evaluated; operation accepted; effect observed.