...
We also considered the possibility that the user might want to remain at the host while associating a policy with a resource for lowest possible UX friction, which we called "problem B", and to cancel protection for a particular resource while visiting the AM, which we called "problem C".
Managed vs. unmanaged: We came up with some new terminology and assumptions to help us figure out the connection between protocol features and desirable user experiences. We believe it's likely that a host will want to offer to protect some or all of a user's resources there with the same AM, rather than offering to split the protection of resources among multiple AMs.
[Joseph later observed that migration to outsourced authorization could be a reason why a host would offer to protect only some resources with that single AM.]
Any resources that a host ends up not registering with an AM are what we decided to call unmanaged. An unmanaged resource could be totally public or totally private, for example, and in both cases its existence is entirely unknown to the AM. It's expected that whatever a host does when access is attempted to such a resource, it does not engage in the step-2 "UMA dance" of issuing a 401 and sending the requester to the AM for an access token.
A managed resource could be said to be protected by the AM (in that a 401 with AM info is now in place no matter what), and it is prepared to be selectively sharable, governed by which policy ultimately gets attached to it.