...
It should be noted that AMs could offer user preference settings that allow for policies to be mapped to registered resources in some default pattern so that there are no resources that remain unmapped. Also, to the extent that a host does not need to resort to outsourcing token validation at the AM, and to the extent that an access token is long-lived, the AM is not exposed to every single successful access of a managed resource and so its analytics and audit logs might be more coarse-grained; perhaps this is amenable to an AM user preference setting too.
Problem B: Currently, the SMART host sample apps allow a user to click on a "Share" button, which (much like the Picasa-to-Piknik "Edit" flow) redirects the user to a different site, namely the AM site, so that they can associate a policy with that resource before getting redirected back. (The host actually registers the resource with the AM "silently" from the user's perspective before they get redirected.)
It was observed that the portion of this flow that might require the user to log in at the AM (if there's currently no active session there) before doing policy stuff could add to the user's burden. So we went down a path of exploring what it would look like for the AM to do something like "policy registration" at the host, to give it the names of policies that could be associated with that host's resources.
One idea we discussed was somehow using the host's already-existing host access token to help log the user in silently, vs. having the user log in as themselves. But this got hairier the more we thought about it; first of all, the host would be allowing the user to impersonate the host...which after all was delegated its authorization from the user. We found the semantics of this to be ugly. Secondly, the host likely has a subset of the user's rights at the AM, with the user's rights normally totally disjoint from the host's rights. So we gave up on this.
Ultimately we gained rough consensus not to target a solution for problem B in UMA 1.0. Although reducing friction is nice, it felt like premature optimization, which perhaps lots of other efforts (such as various "identity in the browser" efforts) would be trying to solve in a more elegant fashion. Also, this would add a lot of protocol overhead and state management and give hosts lots more responsibility for authorization jobs than we had intended to give them.