James McGovern writes about how relationships must include authorization:
Anyway, the notion of relationship is something that belongs to the identity provider and entities such as the Liberty Alliance are defining standards around it. Check out their notion of the people service. The key though is that relationships sometimes require authorization. For example, just because my son can order an insurance card from Amica doesn't mean he is also allowed to cancel the policy for the entire family. Relationship needs authorization especially in domains having to do with medical interactions.
While I like his good words about the Liberty Alliance, I take exception with some of his conclusions.
First off, I don't think that relationships should or must belong to the Identity Provider. This is especially important in a world where my relationships cross the boundaries to many different Identity Providers. Within Liberty's People Service, we took great pains to ensure that the protocols support both a) the People Service be able to be provided by a party other than an IdP (just as LinkedIn provides this type of service to their customers) and b) the relationships contained within a user's People Service must be able to cross identity domains while still protecting the privacy of the users. The latter requirement lead to some rather complex protocol sequence requirements when establishing a connection.
Secondly, I look at authorization as being associated with the object being accessed (where the input parameters may include individuals and/or group memberships) and not with the relationship itself. So in the example provided by James, James would introduce his son to Amica (using the People Service) and then set the associated rights at Amica, not within the People Service. The primary driver for this is that only Amica understands the objects available to Jim and the associated access permissions that may be possible for those objects.
The one place where I see the People Service (and/or any other relationship tracking service) getting involved in authorization is where the user controls what another may do with his relationship (e.g. I can allow Paul to see my relationships (and the fact that I long ago had a coolness link to the ever-cool Joni)).