...
NEW emerging design principle: Complexity: Complexity should be moved to borne by the AM endpoint vs. the host or requester, if possible. Comment: We anticipate dozens of AMs (maybe lots more if corporations have them), hundreds of thousands of hosts, and hundreds of millions of requesters.
...
Referrals are transient; their only purpose is to correlate a host's view of a requester's identifier with the AM's view of that same requester. Once the link is made, the referral stuff can go away. (The host and AM can happily manage that state separately afterwards.) The ID provided by the host can be the user ID, the session ID, or whatever is handy.
ISSUE for later: How and whether to request the "protected status" of a resource: To answer this question, a host would pretty much have to go through the same dance as for a request for actual access! It might be protected against requester A but not requester B, or protected with a real-time user consent loop, etc. We'll wait to see what real scenarios arise that need to be solved, and perhaps it will turn out that they can tolerate imprecision/latency. Before a host gives out the 401, it already knows intrinsically whether the resource is protected by some AM, and it has the ability to tell the requester this (whether this is a good idea or not we don't know yet). It just doesn't yet know whether the requester is going to be authorized to access it.
Since we're now out of the authentication business, keep in mind that whatever the host does in response to the initial approach of the requester is up to it. It can assign a pseudonymous form of identifier (possibly literally using a cookie-based method), or really anything. If the host needs to protect the privacy of the requester according to its own policies or applicable laws or whatever, it's up to the host to choose an ID wisely. We don't really care about protecting the requester's privacy, however; the whole point of letting the authorizing user control access is to let them do so on whatever criteria, and as part of that process the requester is simply going to have to authenticate, even if weakly.
OAuth (the subject of our design principle #2) actually brings two different use cases to the table: service authentication and a "read/write" framework for service access. Both are valuable to us.
NEW emerging design principle: Authentication: We want to stay out of the authentication business as much as we can. Comment: There are many technology choices here, and we want to be agnostic as to the right one for the job. Some scenarios may need stronger authentication and they should be free to use the right mechanism for the job. And setting up all pairwise relationships may be subject to some trust framework (e.g., some AMs might get blacklisted).
...