As you point out, with definer's rights the only user that needs to be authorized is the definer. However, that user does still have to be authorized, and the general mechanism that applies also to invoker's rights and transient objects (SQL statements) is used.

But if the dependent object were a view or a stored procedure, for example, it wouldn't validate that the user has the ability to touch the tables and/or calls accessed by the compiled object, would it? If that were true, then you would have to grant execute on the parent procs and/or tables that the view touched to the user calling the view or stored proc (which isn't generally the case), right? Or is this used for invoker-type scenarios (which would make sense for table and view dependencies, but not execution since invokers-rights can't stop a caller from executing a stored procedure specified in the dependent object)

No, that's not quite right. ACCESS$ records the access permissions needed by a dependent object on its dependencies. This information is cached in the library cache with the definition of the object, and is used to check whether users have the required permissions on the dependencies before each user's first attempt to use the object.

For SQL statements, the access permissions required are determined when the statement is parsed and then cached in the same way. Authorizations are cached in the library cache with the object definition, which is why the access permissions only need to be checked once per user as long as the object definition itself remains cached.

Thank you very much for your reply. So if I'm understanding you correctly, ACCESS$ is basically used by the database to quickly map/determine the highest-level of privileges that the dependent object has against the parent object (by eliminating the steps required to map the dependent object back to its owner# and then querying for object grants on the parent objects for that owner#)?