It's from these documents that the Technical Expert Group worked (and often cursed), the use cases and derived requirements guiding us in the development of protocol specifications that met the requirements. So, for instance, you can see a 1-to-1 correspondence between the sections of the WSF 2.0 MRD and the spec'd out People Service and Subscription functionality.
The MRDs make for interesting reading. One use case from the WSF 1.0 MRD stands out for me. In Section 220.127.116.11:
An SP may wish to provide basic personalization services to its visitors/customers without requiring them to have an account at the SP or even identify themselves at the SP. Hence a user may anonymously share certain attributes with such SPs. For example, an SP may not require any sign-in by the user on their initial visits. Nor does the SP require the user to have an account at the SP. Yet, the SP may want to provide basic personalization based on attributes such as preferred language, gender, geo-location, time zone, etc. The user, when visiting the SP, may see content personalized to the user's preferences. Such personalization is the value-add provided by such SPs to attract customers and increase airtime and online time usage.This use case, the derived requirements, and the resultant support in WSF may not fit the image of "hard-coded federations" that some seem to have about the Liberty Alliance's architecture.
Note the anonymity is intended to protect the identity of the user. The SP never gets an identifier for the user, not even a repeatable pseudonym. Therefore, even if the user re-visits the SP a minute later, the SP would not know if it is the previous user visiting again. However, such anonymity (privacy) does not exist if the user willingly gives the permission to anonymously share his/her PII (Personally Identifiable Information) such as social security numbers, driver's licenses, passport numbers, etc.