WEB / WEB-13.01

Session identifiers and Browser transport

Inspect how a small Browser-carried handle binds to a verified server identity through creation and lookup.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Known handle

The next request is prepared
The Browser prepares input sid-duru-fixture for this case. sid-duru-fixture is a teaching alias; its appearance does not establish a subject or tenant. The request has not reached the Application.
Browser · cookie jar
sid-duru-fixture
Application · session resolver
Request not received
Same process · trusted record
Active record: Duru / Atlas
The session request arrived
The Application received the request. Cookie presence supplies transport input only; the Browser waits. The trusted record is a logical component in the same application process.
Browser · cookie jar
Awaiting check outcome
Application · session resolver
Handle received; lookup pending
Same process · trusted record
Active record: Duru / Atlas
The trusted record was evaluated
The recognized handle resolves to the existing active record. Duru and Atlas come from the server record, not the alias text or a client role assertion.
Browser · cookie jar
Awaiting check outcome
Application · session resolver
Accepted: Duru / Atlas
Same process · trusted record
Active record: Duru / Atlas
The resource boundary remains separate
Even a recognized session does not evaluate object/action permission for a particular book here. Without a trusted subject, authenticated resource processing is withheld; no protected body is produced.
Browser · cookie jar
Awaiting check outcome
Application · session resolver
Session accepted; resource policy required
Same process · trusted record
Active record: Duru / Atlas
The check outcome is prepared
The Application prepares accepted / trusted_active_record. The Browser has not received it yet. SessionRef serves correlation only; the raw handle is not shown in the illustrated response or general logs.
Browser · cookie jar
Awaiting check outcome
Application · session resolver
Response ready: trusted_active_record
Same process · trusted record
Active record: Duru / Atlas
The session outcome reached the Browser
Only now does the Browser know the session-check outcome. This response adds no book body, resource grant, password/MFA verification or identifier-entropy measurement.
Browser · cookie jar
Session accepted; resource permission separate
Application · session resolver
Response ready: trusted_active_record
Same process · trusted record
Active record: Duru / Atlas

Handle absent

The next request is prepared
In this case the Browser prepares a request without a Cookie handle. The Application has not received it; the existing Duru/Atlas record does not establish an authenticated subject for this request without a handle.
Browser · cookie jar
No Cookie
Application · session resolver
Request not received
Same process · trusted record
Active record: Duru / Atlas
The session request arrived
The Application received the request. Cookie presence supplies transport input only; the Browser waits. The trusted record is a logical component in the same application process.
Browser · cookie jar
Awaiting check outcome
Application · session resolver
No Cookie; no lookup expected
Same process · trusted record
Active record: Duru / Atlas
The trusted record was evaluated
Without a handle, lookup is not performed. Subject, tenant and sessionRef remain null; a client assertion does not create an authenticated record.
Browser · cookie jar
Awaiting check outcome
Application · session resolver
Rejected: no_handle; subject=null
Same process · trusted record
Active record: Duru / Atlas
The resource boundary remains separate
Even a recognized session does not evaluate object/action permission for a particular book here. Without a trusted subject, authenticated resource processing is withheld; no protected body is produced.
Browser · cookie jar
Awaiting check outcome
Application · session resolver
Authenticated processing withheld
Same process · trusted record
Active record: Duru / Atlas
The check outcome is prepared
The Application prepares rejected / no_handle. The Browser has not received it yet. SessionRef serves correlation only; the raw handle is not shown in the illustrated response or general logs.
Browser · cookie jar
Awaiting check outcome
Application · session resolver
Response ready: no_handle
Same process · trusted record
Active record: Duru / Atlas
The session outcome reached the Browser
Only now does the Browser know the session-check outcome. This response adds no book body, resource grant, password/MFA verification or identifier-entropy measurement.
Browser · cookie jar
Session rejected; subject=null
Application · session resolver
Response ready: no_handle
Same process · trusted record
Active record: Duru / Atlas

Unknown handle

The next request is prepared
The Browser prepares input unknown-fixture-label for this case. sid-duru-fixture is a teaching alias; its appearance does not establish a subject or tenant. The request has not reached the Application.
Browser · cookie jar
unknown-fixture-label
Application · session resolver
Request not received
Same process · trusted record
Active record: Duru / Atlas
The session request arrived
The Application received the request. Cookie presence supplies transport input only; the Browser waits. The trusted record is a logical component in the same application process.
Browser · cookie jar
Awaiting check outcome
Application · session resolver
Handle received; lookup pending
Same process · trusted record
Active record: Duru / Atlas
The trusted record was evaluated
Lookup returns not_found. The existing Duru record is not bound to the unknown alias; subject, tenant and sessionRef remain null and no record is created.
Browser · cookie jar
Awaiting check outcome
Application · session resolver
Rejected: no_trusted_record; subject=null
Same process · trusted record
Active record: Duru / Atlas
The resource boundary remains separate
Even a recognized session does not evaluate object/action permission for a particular book here. Without a trusted subject, authenticated resource processing is withheld; no protected body is produced.
Browser · cookie jar
Awaiting check outcome
Application · session resolver
Authenticated processing withheld
Same process · trusted record
Active record: Duru / Atlas
The check outcome is prepared
The Application prepares rejected / no_trusted_record. The Browser has not received it yet. SessionRef serves correlation only; the raw handle is not shown in the illustrated response or general logs.
Browser · cookie jar
Awaiting check outcome
Application · session resolver
Response ready: no_trusted_record
Same process · trusted record
Active record: Duru / Atlas
The session outcome reached the Browser
Only now does the Browser know the session-check outcome. This response adds no book body, resource grant, password/MFA verification or identifier-entropy measurement.
Browser · cookie jar
Session rejected; subject=null
Application · session resolver
Response ready: no_trusted_record
Same process · trusted record
Active record: Duru / Atlas

Creation trace

The identity precondition is supplied
For creationTrace seq=1, identityVerified=true and the Duru/Atlas precondition are supplied. No real password or MFA check runs here; the Browser has no new handle yet.
Browser · cookie jar
No new handle
Application · session resolver
Verified identity supplied
Same process · trusted record
No new binding
The server binding is created
At seq=2, record_created binds ledger-duru to Duru/Atlas context. Application and record are logical components within the same process; local creation is not a network message.
Browser · cookie jar
No new handle
Application · session resolver
Set-Cookie can be prepared
Same process · trusted record
ledger-duru: Duru / Atlas; active
The Set-Cookie instruction is prepared
The Application prepares the illustrated __Host-hd_session header. At the seq=3 sending snapshot, browserHasNewHandle=false remains; server binding is not automatically copied to the Browser.
Browser · cookie jar
No new handle
Application · session resolver
Set-Cookie ready; no receipt
Same process · trusted record
ledger-duru: Duru / Atlas; active
The cookie response reached the Browser
The header reached the Browser. In this selected example, Browser cookie policy accepts storage; at seq=4 cookie_arrived, browserHasNewHandle=true. HttpOnly does not require frontend header reading or script access.
Browser · cookie jar
New handle in jar; identity not in cookie
Application · session resolver
Instruction sent
Same process · trusted record
ledger-duru: Duru / Atlas; active
The later Cookie request is ready
In an eligible same-origin context, the Browser selects the new handle for the later Cookie request. Selection depends on lifetime, scope and Browser policy; it grants no resource permission.
Browser · cookie jar
Cookie input prepared
Application · session resolver
Later request not received
Same process · trusted record
ledger-duru: Duru / Atlas; active
The later request reached the Application
Cookie input reached the Application; the Browser awaits the check outcome. Handle transport does not itself establish a trusted subject; server lookup is required.
Browser · cookie jar
Awaiting check outcome
Application · session resolver
Lookup pending
Same process · trusted record
ledger-duru: Duru / Atlas; active
The subject is resolved from the server record
The active record supplies the Duru/Atlas subject. A check outcome can be prepared; book object/action policy remains separate. The Browser has not learned this result yet.
Browser · cookie jar
Awaiting check outcome
Application · session resolver
Accepted check response ready
Same process · trusted record
ledger-duru: Duru / Atlas; active
The binding outcome reached the Browser
The Browser received the accepted session-check result. The trace separates creation, cookie receipt and lookup; no stage alone proves book-resource permission or real credential verification.
Browser · cookie jar
Session accepted; resource policy separate
Application · session resolver
Accepted check response ready
Same process · trusted record
ledger-duru: Duru / Atlas; active

ACTORS · STATE · DATA FLOW

How is login bound to the next request?

Duru signs in to the Atlas library and then opens another book page. Where does the later request obtain its authenticated subject? Sending the text “Duru” on each page is not identity evidence. The Application establishes a controlled binding between an earlier verified identity and later requests.

This lesson uses an opaque server-side session model. The Browser carries a small handle, while the server record identifies its identity, authentication state and lifecycle. A session is the managed lifetime of that binding. Cookie is our selected transport mechanism; a cookie and a session are different objects.

The identifier is a handle to a record, not the identity itself

sid-duru-fixture is an instructional alias pointing to Duru’s authenticated record, not a usable credential. It does not encode “Duru” or “Atlas.” Store lookup supplies that meaning; a Browser role or tenant assertion does not establish it.

The audit sessionRef=ledger-duru has another purpose: correlating events without secrets. The Application does not accept it for authentication. Separate the Browser handle, store lookup/verifier representation and audit reference; calling all of them session IDs can hide their different roles.

An identity may have sessions on multiple Browsers/devices. Handles independent of identity allow separate generations and lifetimes. A valid record does not permit every book resource; authorization follows as a separate decision.

Creation starts from a trusted identity result

The Application first verifies identity through its trusted authentication process. identityVerified=true is a supplied precondition in this fixture, not a claim that real password/MFA verification ran. The server generates a handle using its session mechanism and binds its own Duru/Atlas context to the authenticated record.

After preparing the store record, the Application sends Set-Cookie. The Browser does not have the new handle before response arrival. Once it accepts storage, a later eligible request can carry the handle in Cookie. Server creation and Browser receipt remain separate state changes.

A session can also hold anonymous state, but giving an anonymous handle identity authority requires a distinct transition. WEB-13.03 covers login/privilege rotation and previous-generation acceptance. This lesson focuses creation and binding rather than duplicating lifecycle detail.

Entropy is not string length

A production identifier must be unpredictable. Prefer an appropriate framework’s session generation; if custom generation is necessary, OWASP recommends a CSPRNG with at least 128 bits and uniqueness checks. This is not one universal policy for every token type.

Entropy differs from visible character count. A fixed prefix, account name or counter can add length without the same amount of randomness. Encoding changes representation. Keeping meaningful user/tenant data out of the identifier also reduces disclosure and mistaken authority interpretation.

The fixture’s fixed sid-duru-fixture and SYNTHETIC_OPAQUE_HANDLE values are deliberately nonrandom. They do not measure production entropy, collision probability or cryptographic strength. We follow ownership and lookup rather than distributing real credentials.

The Browser carries the handle; scripts need not read it

The synthetic HTTPS response shows __Host-hd_session=SYNTHETIC_OPAQUE_HANDLE; Path=/; Secure; HttpOnly; SameSite=Lax. An eligible Browser includes this cookie on suitable requests. Frontend code does not need to read its value through document.cookie and manually construct a header for this flow.

WEB-12.02 develops inclusion rules. An eligible cookie can accompany a same-origin fetch; cross-origin fetch separately considers credentials mode and Browser/SameSite policy. HttpOnly can hide the handle from scripts without excluding it from eligible requests. Do not generalize this to all cross-site requests.

Putting session handles in URLs, general diagnostic logs or shared screenshots spreads credentials to unnecessary surfaces. Observe cookie names, scope/flags and noncredential sessionRef instead of raw values. Good transport does not remove the Application’s acceptance checks.

Binding is checked again when the request arrives

The Application takes the supplied handle from the designated exchange mechanism. This model accepts no URL fallback or arbitrary client field. If the recognized record is active and valid, its server-owned Duru/Atlas context supplies an authenticated subject for subsequent resource policy.

A missing handle creates no subject. An unknown handle also does not invent an authenticated record. Both rejections can be benign: Browser policy may omit the cookie, or earlier client state may refer to a removed record. Different reasons do not create identity evidence.

A real store may use hashed/verifier or other lookup representations. Drawing handle→record does not claim the raw token is stored verbatim in a database. WEB-13.02 covers store concurrency, TTL and distributed consistency; WEB-13.03 covers expiry/logout transitions.

Read every scenario without motion

Known handle

Handle transport is ready
The browser carries alias sid-duru-fixture for this inert branch. It is not a usable credential; subject or tenant information is not inferred from its appearance.
Browser
sid-duru-fixture ready
Session resolver
Lookup not performed
Resource gate
No resource permission
The session check reached the application
An ordinary check reached the application. Cookie transport supplies input only; establishing an authenticated subject requires the defined server binding mechanism.
Browser
Awaiting check outcome
Session resolver
Handle received; lookup pending
Resource gate
No resource permission
The trusted binding was resolved
The recognized alias resolves to active record ledger-duru. Subject Duru and tenant Atlas come from the server record, not a name supplied by the browser.
Browser
Awaiting check outcome
Session resolver
Accepted: Duru / Atlas
Resource gate
No resource permission
The resource decision was kept separate
Session acceptance establishes Duru/Atlas context, but does not establish object authorization for a particular book action.
Browser
Awaiting check outcome
Session resolver
Session accepted
Resource gate
Authorization remains required
The check outcome was prepared
The application prepares accepted / trusted_active_record. Observation uses a noncredential audit reference rather than copying a raw handle into general logs.
Browser
Awaiting check outcome
Session resolver
Session-check outcome ready
Resource gate
Object outcome not shown
The binding outcome reached the browser
The browser received the accepted session outcome. The scene adds no resource-body delivery, actual login or entropy measurement; the alias only illustrates the binding boundary.
Browser
Session accepted
Session resolver
Session-check outcome ready
Resource gate
No resource-body evidence

Unknown handle

Handle transport is ready
The browser carries alias unknown-fixture-label for this inert branch. It is not a usable credential; subject or tenant information is not inferred from its appearance.
Browser
unknown-fixture-label ready
Session resolver
Lookup not performed
Resource gate
No resource permission
The session check reached the application
An ordinary check reached the application. Cookie transport supplies input only; establishing an authenticated subject requires the defined server binding mechanism.
Browser
Awaiting check outcome
Session resolver
Handle received; lookup pending
Resource gate
No resource permission
Session binding not found
Lookup returns not_found. No authenticated record is created for an unknown alias; subject, tenant and sessionRef remain null.
Browser
Awaiting check outcome
Session resolver
Rejected: no_trusted_record
Resource gate
No resource permission
The resource decision was kept separate
Without a trusted subject, authenticated resource processing does not proceed in this branch. An unknown handle alone is not evidence of malicious intent.
Browser
Awaiting check outcome
Session resolver
Session rejected
Resource gate
Authenticated processing withheld
The check outcome was prepared
The application prepares rejected / no_trusted_record. In this branch subject, tenant and sessionRef remain null; the observation is identified by case=unknown. A raw handle is not copied into general logs.
Browser
Awaiting check outcome
Session resolver
Session-check outcome ready
Resource gate
Object outcome not shown
The binding outcome reached the browser
The browser received the rejected session outcome. The scene adds no resource-body delivery, actual login or entropy measurement; the alias only illustrates the binding boundary.
Browser
Session rejected
Session resolver
Session-check outcome ready
Resource gate
No resource-body evidence

ASSUMPTION · BOUNDARY · CONTROL

Server binding gives a handle its authority

A valid handle normally reaches authenticated context established earlier by the server. The broken assumption is that client-supplied subject/role text or an audit reference can establish equivalent authority. A well-shaped identifier is not authentication evidence.

Validate the input through the designated session mechanism and derive the subject from a trusted record. Impact remains bounded by that session’s identity and permissions. Our unknown/missing cases are supplied benign selectors, not instructions for trying real identifiers or targeting another system.

Unpredictability and confidentiality address different risks

High entropy does not magically protect a disclosed value, and HTTPS does not add randomness to weak generation. Generation, transport, Browser/script access and log hygiene are different control surfaces.

Exposure of a bearer handle can increase risk to authenticated actions, while action impact depends on application policy and additional checks. Making a string longer is not the full durable control: assess the session mechanism, constrained transport, store access and invalidation together. WEB-13.03 develops rotation/expiry.

Read every scenario without motion

Arrival record

The creation-trace scope was selected
This branch reviews all four creationTrace records together. Coverage is preserved when assessing what the browser could have learned.
Creation records
binding-create: seq 1–4
Binding review
Creation not correlated
Receipt conclusion
Jar evidence unknown
The identity precondition was separated
identity_verified is a supplied trusted precondition here. Presence of seq 1 does not mean that an actual password or MFA operation ran in this scene.
Creation records
binding-create: seq 1–4
Binding review
seq 1: identity_verified
Receipt conclusion
Jar evidence unknown
Store creation was correlated
Seq 2 record_created correlates ledger-duru with the same requestId=binding-create. The audit sessionRef is neither a browser handle nor an authentication credential.
Creation records
binding-create: seq 1–4
Binding review
seq 2: ledger-duru created
Receipt conclusion
Jar evidence unknown
Sending was not treated as receipt
At seq 3 set_cookie_sent, browserHasNewHandle=false. The server sent an instruction; browser acceptance and storage state cannot be inferred from that event.
Creation records
binding-create: seq 1–4
Binding review
seq 3: instruction sent
Receipt conclusion
Receipt not yet established
Arrival coverage was assessed
Seq 4 records cookie_arrived and browserHasNewHandle=true. Arrival is known within this fixture; a later lookup or resource permission is not yet shown.
Creation records
binding-create: seq 1–4
Binding review
Creation and sending known
Receipt conclusion
Arrival known
Binding evidence was not broadened
Creation, browser receipt and accepted lookup are separate evidence. This trace explains receipt, but does not complete identity or object outcomes for a later protected request.
Creation records
binding-create: seq 1–4
Binding review
SessionRef is correlation only
Receipt conclusion
Lookup evidence remains required

Receipt missing

The creation-trace scope was selected
This branch reviews only the first three creationTrace records. Coverage is preserved when assessing what the browser could have learned.
Creation records
binding-create: review of seq 1–3
Binding review
Creation not correlated
Receipt conclusion
Jar evidence unknown
The identity precondition was separated
identity_verified is a supplied trusted precondition here. Presence of seq 1 does not mean that an actual password or MFA operation ran in this scene.
Creation records
binding-create: review of seq 1–3
Binding review
seq 1: identity_verified
Receipt conclusion
Jar evidence unknown
Store creation was correlated
Seq 2 record_created correlates ledger-duru with the same requestId=binding-create. The audit sessionRef is neither a browser handle nor an authentication credential.
Creation records
binding-create: review of seq 1–3
Binding review
seq 2: ledger-duru created
Receipt conclusion
Jar evidence unknown
Sending was not treated as receipt
At seq 3 set_cookie_sent, browserHasNewHandle=false. The server sent an instruction; browser acceptance and storage state cannot be inferred from that event.
Creation records
binding-create: review of seq 1–3
Binding review
seq 3: instruction sent
Receipt conclusion
Receipt not yet established
Arrival coverage was assessed
This review contains only seq 1–3, so cookie_arrived is not included. That does not prove arrival never occurred; the supplied receipt evidence is incomplete.
Creation records
binding-create: review of seq 1–3
Binding review
Creation and sending known
Receipt conclusion
UNKNOWN: receipt
Binding evidence was not broadened
Creation, browser receipt and accepted lookup are separate evidence. Missing receipt does not justify one success or failure verdict; jar and check observations must be obtained separately.
Creation records
binding-create: review of seq 1–3
Binding review
SessionRef is correlation only
Receipt conclusion
UNKNOWN: browser receipt

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Creation, delivery and lookup need separate evidence

Creation evidence describes server-record preparation; Set-Cookie describes a sent instruction; jar inspection describes Browser storage; a protected decision describes lookup. Observing one does not prove completion of all the others.

seq, event, sessionRef, requestId, result and reason are application-owned teaching fields, not genuine framework event names or an existing SIEM schema. A fixture input named identityVerified does not validate real credential checking.

Correlate lookup decisions without session values

Audit uses a separate sessionRef instead of the raw handle. Missing and unknown cases retain a null subject; inferring userId from cookie presence would be incorrect correlation. Missing can reflect Browser policy, and unknown can reflect store/cache lifecycle; neither is automatically an alarm.

XPath /sessionObservations/check[@result="accepted" and @subject=""] searches the fixture XML for accepted observations with no subject. The supplied three cases should return none. An integrity fixture adding an accepted/empty-subject row should return it; that is not a real-world authentication-bypass test.

A missing log or incorrect sessionRef join is not enough to conclude that binding is absent. Validate how creation and lookup paths generate references, deliver events and map schemas in the real application.

Record-based identity, separate resource policy

In manual observation, compare the creation identity, noncredential Browser metadata and the resolved subject of an accepted check. If the record says Duru/Atlas while the UI shows another tenant, inspect the state source that changed; do not “fix” the example by deriving identity from client fields.

Make the framework session mechanism and accepted exchange surface explicit, without undocumented automatic URL fallbacks. Keep sensitive values out of observation exports. Design store availability failure so protected processing does not assume authentication, while retaining an understandable user fallback.

NOW APPLY IT TO THE CASE

Where does carrying a browser handle establish identity?

sid-duru-fixture is a teaching alias only. Duru/Atlas binding is resolved from the server record; creation, receipt and lookup are separate observations.

Find separate observations for the case handle, server binding and session lifetime. Does a retained browser value establish current server admission by itself?

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Opaque handle, trusted record and audit reference: three separate fields

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "authenticationPrecondition": {
    "identityVerified": true,
    "subject": "Duru",
    "tenant": "Atlas",
    "scope": "supplied trusted-event fixture; no password/MFA implementation"
  },
  "creationTrace": [
    {
      "seq": 1,
      "event": "identity_verified",
      "requestId": "binding-create",
      "subject": "Duru"
    },
    {
      "seq": 2,
      "event": "record_created",
      "requestId": "binding-create",
      "sessionRef": "ledger-duru"
    },
    {
      "seq": 3,
      "event": "set_cookie_sent",
      "requestId": "binding-create",
      "browserHasNewHandle": false
    },
    {
      "seq": 4,
      "event": "cookie_arrived",
      "requestId": "binding-create",
      "browserHasNewHandle": true
    }
  ],
  "setCookieIllustration": "__Host-hd_session=SYNTHETIC_OPAQUE_HANDLE; Path=/; Secure; HttpOnly; SameSite=Lax",
  "handleAlias": "sid-duru-fixture",
  "storeRecord": {
    "sessionRef": "ledger-duru",
    "subject": "Duru",
    "tenant": "Atlas",
    "authenticationState": "authenticated",
    "state": "active",
    "handleRepresentation": "omitted; implementation-dependent lookup/verifier",
    "createdAt_s": 10,
    "validAt_s": 70
  },
  "cases": [
    {
      "id": "recognized",
      "suppliedHandleLabel": "sid-duru-fixture",
      "lookup": "recognized",
      "result": "accepted",
      "subject": "Duru",
      "tenant": "Atlas",
      "sessionRef": "ledger-duru",
      "reason": "trusted_active_record"
    },
    {
      "id": "missing",
      "suppliedHandleLabel": null,
      "lookup": "not_performed",
      "result": "rejected",
      "subject": null,
      "tenant": null,
      "sessionRef": null,
      "reason": "no_handle"
    },
    {
      "id": "unknown",
      "suppliedHandleLabel": "unknown-fixture-label",
      "lookup": "not_found",
      "result": "rejected",
      "subject": null,
      "tenant": null,
      "sessionRef": null,
      "reason": "no_trusted_record"
    }
  ],
  "observationXML": "<sessionObservations><check case=\"recognized\" result=\"accepted\" subject=\"Duru\" sessionRef=\"ledger-duru\"/><check case=\"missing\" result=\"rejected\" subject=\"\"/><check case=\"unknown\" result=\"rejected\" subject=\"\"/></sessionObservations>",
  "localXPath": "/sessionObservations/check[@result=\"accepted\" and @subject=\"\"]",
  "expectedSelectedCases": []
}

authenticationPrecondition: A previously verified identity fixture; client username text does not establish authenticated state.
handleAlias / SYNTHETIC_OPAQUE_HANDLE: Fixed secrets-free instructional labels, not random generation or working credentials.
storeRecord.subject / tenant: Application-owned binding context, not arbitrary cookie identity claims.
storeRecord.handleRepresentation: No assumption of raw token database storage; lookup/verifier implementation is outside the drawing.
sessionRef: Audit correlation reference, never accepted as a credential substitute.
creationTrace.seq / browserHasNewHandle: Separate server-record creation, sent response and Browser arrival.
cases.lookup / result / reason: Supplied recognized/missing/unknown cases, not session enumeration results.
observationXML / localXPath: Synthetic accepted/subject consistency selection, not a complete verifier or multi-host correlation.

The fixture runs no password/MFA check, token generator, verifier or real store. Fixed aliases provide no access to real identities. Cookie flags are an inert HTTPS example; Browser and lab runtime evidence is separate.

Two reality checks

A longer-looking session identifier necessarily has higher entropy.

Fixed or predictable parts can add length without equivalent randomness. Assess the generation source and effective entropy.

Sending a session cookie proves request identity and permission to every resource.

The server first checks binding to a trusted valid record. Resource/action authorization is a separate subsequent decision.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

We are at seq=3 in creationTrace. The set_cookie_sent record explicitly shows browserHasNewHandle=false. At this stage, has the Browser stored the new handle?

No. At this stage browserHasNewHandle=false.
Yes; browser state changes as soon as the server prepares a header.

Read the explained answer

No. At this stage browserHasNewHandle=false. — The sent snapshot in CreationTrace does not change remote jar state; cookie_arrived is the later completed boundary.

Are the sid alias and ledger-duru reference the same kind of credential?

Selected lesson artifact fields; teaching example

handleAlias: sid-duru-fixture
storeRecord.sessionRef: ledger-duru
storeRecord.authenticationState: authenticated

Putting the ledger reference into a Cookie establishes the same authenticated binding.
No; the ledger reference is for observation correlation, not a browser handle.

Read the explained answer

No; the ledger reference is for observation correlation, not a browser handle. — SessionRef is the trusted record audit reference; the actual handle representation is omitted and implementation-dependent.

Why is an unknown supplied handle rejected with subject=null, and why does an accepted session still not provide resource permission?

Read the explained answer

No trusted record exists for the unknown label, so Duru identity is not created from a client assertion. The recognized case binds to an active trusted record, but object/action/context authorization remains separate. AuthenticationPrecondition is a supplied trusted event here, not proof of password/MFA testing.

□ I did not create identity from an unknown handle.

□ I separated session recognition from resource permission.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

RFC 6265 — HTTP State Management Mechanism4.2 Cookie · 4.2.2 Semantics · 8.4 Session Identifiers
OWASP — Session Management Cheat SheetSession ID Entropy · Session ID Content (or Value) · Built-in Session Management Implementations · Used vs. Accepted Session ID Exchange Mechanisms · Session ID Generation and Verification: Permissive and Strict Session Management · Logging Sessions Life Cycle
MDN — Using HTTP cookiesWhat cookies are used for: sign-in sequence · Creating, removing, and updating cookies
MDN — Set-Cookie headerAttributes: HttpOnly, Secure · Cookie prefixes
WHATWG — Fetch Standard2.2.5 Requests: credentials mode · 3.3.5 CORS protocol and credentials

YOUR NOTES / THIS BROWSER

Session identifiers and Browser transport

1. Core · Mechanism

Known handle

Handle absent

Unknown handle

Creation trace

How is login bound to the next request?

The identifier is a handle to a record, not the identity itself

Creation starts from a trusted identity result

Entropy is not string length

The Browser carries the handle; scripts need not read it

Binding is checked again when the request arrives

2. Red · Trust & Impact

Known handle

Unknown handle

Server binding gives a handle its authority

Unpredictability and confidentiality address different risks

3. Blue · Secure development & defense

Arrival record

Receipt missing

Creation, delivery and lookup need separate evidence

Correlate lookup decisions without session values

Record-based identity, separate resource policy

Where does carrying a browser handle establish identity?

Two reality checks

We are at seq=3 in creationTrace. The set_cookie_sent record explicitly shows browserHasNewHandle=false. At this stage, has the Browser stored the new handle?

Are the sid alias and ledger-duru reference the same kind of credential?

Why is an unknown supplied handle rejected with subject=null, and why does an accepted session still not provide resource permission?

Sources and scope