It has no public addressable identity as it doesn’t need one, only the DEE needs the id. Each execution is a one-shot process. The invoker does not come back to interact with the running function (only to await its result if it chooses to).
Any state it has is incidental, enough for the durable execution engine to run it to completion. Thus any state is generally the result of side effects for memoization. The state does not need to be retained beyond the life of the execution (though in practice it might be for observability and auditing).
Example: A payment processing function deployed as a web service or lambda function. It receives order details, checks that the discount is valid, calls a payment gateway API, and returns success or failure. If it crashes mid-execution, the durable execution engine reruns it from the start using memoized results from any completed steps. Either it's a one-way invocation or the caller asynchronously awaits the durable promise (see The Durable Function Tree post). There is no way to query its state or interact with it while running.
Session
A session (or workflow if you prefer) is an interactive process which has a start and an end, which can maintain mutable state. Its public identity is in the form of an execution ID. A session is kicked off by invoking its main function, and can be interacted with via message passing or by invoking secondary functions.