Redfish Session Handoff: Account Changes and Independent Connections

Identify the Session resource and its separate credential

DMTF's Redfish Specification DSP0266 v1.20.1, dated 3 April 2024, distinguishes the Session resource address returned through Location from the authentication credential supplied through X-Auth-Token. One identifies a manageable session; the other authenticates subsequent requests. The references below use this named published normative edition.

For a handoff discussion, the useful reference is the particular session whose fate the supplier is explaining. A statement about an account can otherwise leave the affected session unnamed. The customer can receive a correlated result through its approved private records without putting the authentication credential into a general handoff pack.

The distinction also changes how to read an access claim. A session identifier gives the parties something specific to discuss; it does not demonstrate the session's present state or permission to perform a particular operation. Ask the appointed platform owner to connect the reported result to the actual equipment and software version covered by the offer.

References: [RF1]

Read session lifetime as request activity

Section 13.3.4.3 describes an activity timeout: requests more frequent than the timeout period keep the session and its authentication token valid; a timeout automatically terminates the session.

A report that the session was created earlier therefore leaves an important question unanswered. Its age alone cannot substantiate the proposed closeout. Nor can a supplier replace a session result with an unexplained assurance that enough time has passed. The explanation needs the relevant activity and session outcome, rather than an expiry rule borrowed from a different credential system.

If the supplier promises to account for an existing session at handover, ask which part of that result it has actually substantiated. A stated timeout describes a lifetime rule; the buyer still needs an answer about the covered session.

References: [RF2]

An account-property change leaves the session result to establish

Section 13.5.2 says a service MAY close that account's open sessions and require reauthentication when account properties change.

The permission matters when a supplier reports a password change as its handoff result. The account change can be an identified deliverable while the existing session outcome remains unresolved. The clause supports neither an automatic closure guarantee for every implementation nor a claim that every implementation leaves sessions open.

Compare the supplier's wording with the requested result. If the purchase calls for an account-property change, evidence of that change addresses the named task. If it also calls for closure of an existing session, the supplier has a further result to substantiate. Credit for one deliverable should not silently become completion of both.

References: [RF3]

Independent connections have their own disposition

Section 13.3.4.4 says session termination SHALL NOT affect independent connections originally established by that session for other purposes. Its examples include server-sent event connections and image transfer for the update service.

This boundary concerns those independently established connections. It is not a claim that every request or every piece of work has an independent lifetime. Identify the activity the offer actually covers before applying the distinction.

For a buyer asking whether an event stream ended, a session-termination result answers a different question. The independent stream needs its own disposition. Equally, the rule does not promise uninterrupted delivery, useful progress or completion: another cause can end a stream or prevent useful work. An observed stop would need its own explanation rather than being attributed automatically to the ended authentication session.

References: [RF4]

RF-HANDOFF: follow account U, session S1 and stream E1

RF-HANDOFF is a wholly fictional comparison. Account U has one identified Redfish session, S1. A distinct independent server-sent event connection, E1, was originally established through S1. That independence is an explicit premise, not something inferred merely because a display shows events.

The first supplier report says that U's password changed. For this example, accept the reported account change as established. It gives the buyer a result for U but leaves S1 unresolved. The buyer cannot yet credit the supplier with ending S1, and cannot conclude that S1 remains valid either. If the promised handoff includes a result for S1, the appointed platform owner still owes that result. E1 has no separately returned disposition at this stage.

Later, explicitly stipulate that the supplier establishes S1 has terminated. This settles the example's session question. The buyer can now recognize the specifically promised S1 closure, rather than keeping it unresolved solely because E1 is a separate activity. It still does not establish cancellation of E1, or an outcome for another session, account or access path outside this example.

The offer's treatment of E1 now makes a practical difference. If the agreed transition includes continued observation of E1 by a receiving team, the handoff needs to identify that team's responsibility and the separately supplied stream result. If the agreed outcome instead requires E1 to have ended, the supplier still has that outcome to substantiate. Neither objective follows from the S1 result.

Finally, stipulate a separate report establishing that E1 ended. That supplies the previously missing E1 disposition. It does not establish why it ended, whether all expected events arrived or whether any associated work completed. The buyer's closeout should say which of those results was required and actually returned. A stream-state observation should not acquire additional claims simply because it appears beside a session-closure result.

References: [RF3][RF4]

Choose a handoff claim the returned results can support

A supplier saying account updated has described a narrower result than one substantiating the disposition of the affected sessions. Where the requested closeout also includes independent activity, the buyer needs that separately covered outcome. Compare the included work and responsibility before accepting an unexplained claim that access was removed.

A narrowly scoped session handoff can be complete for its agreed purpose while separately assigned activity remains open. A broader promise covering both the session and a named connection needs both results and an owner for anything still unresolved.

Use the related management-cabling explanation for physical endpoint records and the resource-authorization explanation for the wider decision-and-enforcement relationship. They help the receiving teams relate this Redfish-specific discussion to the surrounding equipment and access responsibilities.

Connect the handoff to a separate physical cabling scope

Where the equipment also needs physical connection work, Leviathan's Structured Cabling & Fiber Installation service is the relevant next step. Use the linked service and project inquiry to discuss a nonconfidential outline of approved equipment endpoints, routes, requested cabling work, labeling and the team receiving the physical records.

The physical package can give the appointed operating team traceable connections to relate to its management records. Account administration, session disposition, stream operation and security acceptance remain with separately appointed platform and security owners; this educational explanation does not offer those services.