Imagine you are a process, with very little memory or history.
A network connection is coming in.
If you like an analogy, imagine you are in a science fiction movie like "Cypher" where you get dropped in an office you don't know with no history, and a telephone that rings.
You pick it up.

What is coming in?

You know that there is something at the other end of that connection, be it a human or a machine, and it is trying to communicate with you.
That is all you know at this point.

The only hook you have to identify the other end is the connection handle you have.
Identify literally means: to give an identity, and now the connection handle is that identity.
In real life this is the actual telephone device, in an operating system process it is probably a file descriptor.
It is almost as if the phone has become the person at the other end.
Right now, you know little about them.
Associated with that may be a caller ID on the phone, or a remote IP address for a network connection.
But both are additional information coming from somewhere else, and they may be a lie.

You tend to assume that there is some consistency in the other end.
There will be some behavior that you can rely on.
In other words, there is a promise lurking in there on future behavior.

This is not a universal promise, for example if you drive around a city looking at the Wi-Fi networks that your phone sees, there will be little consistency in that, and nothing to depend on.

Now let's imagine you are a login process (I know, this is a blatant anthropomorphization).
In order for you to be able to make some promises to the entity on the other end, you need some proof that the other end will keep up their promises.
That proof typically comes in the form of the other end sending you 'credentials', be they passwords, one-time tokens, or whatever.
These credentials can be looked up by you in some directory,
and to you the credentials act like a promise on the identity picture that you are building of the other end.
The directory makes the promise that the entity's promise is legitimate, and can be trusted.
You could say that a promise is now extended, transferred, or bestowed on the entity at the other end.

At this point you have more reason to believe that the other end has a consistent identity, and will keep up promises that come with that.
That belief is derived from something that is common to you and the other end: a directory.
That is a great example of a shared service (or infrastructure).

You and the other end now look like two players in an iterated prisoner's dilemma game (which we'll discuss later): they trust each other as long as they don't betray each other, and trust grows with the length of a successful interaction.

At the same time, this give you very little basis to give the other end some "agency", some power to create effects.
For that you might look at other directories, directories that hold authorization information.
That is another source of promises on the behavior of the other end.

Only you decide when this escalating set of promises is enough dependable promise for you.