In your example, how is an “agent” different from a regular group member? It seems to me that your scenario cannot work without the target system being able to determine a) I am who I say I am and b) that I am a technician from vendor X. You can’t skip that first part - you have to be able to identify technicians even if their rights are only defined via their membership of a group. it’s not enough for audit records to just say “an anonymous technician from X did this”. Is mentioning accountability too enterprise-y?

In any case I don’t want to see these two models as alternatives. Instead I think they are quite complementary, such that an individual acting as an agent for some principal can be given group memberships, access control, and so on, based on the agency. eg “technicians from vendor X can connect to all of our equipment which are under support agreement from that vendor” would define access for a group of agents (”technicians from vendor X”) without requiring identity of those technicians.

I for one, don’t want to publish to a “where”. Publishing to a “where” is where we are now. You publish to a personal Internet-readable blog. You publish to a corporate (Intranet) blog. You’d like to use a blog-style interface to publish private information for yourself and perhaps “syndicate” it to various audiences later. I’d like to separate the idea of audience from the idea of “where” and jettison the “where” notion entirely.

That said, I think your monitoring example does suggest a case where the principal needs to say on whose behalf they are working. Maybe something like agency is needed for these cases. I could imagine a case where there is a pre-existing relationship between the customer and the organization - in which case the customer becomes another object and their are rights and quotas associated with that relationship - but I might work for two organizations with the same customer so ultimately someone or something has to disambiguate - and that someone would be me (and you have to take my word for it as far as I can tell :-) )

I still think the key to this is some kind of “federated group membership”, it would definitely deal with all of the “content ownership” problems which (I feel) are the core issue (the “new content” case I mention can be disambiguated by where I want to publish the content, BTW.)

Turn aside from WikiGood for a moment. Let’s think about Skype. Jessica has a (personal) Skype account that she’s funded with real dollars to make PSTN calls in/out. Imagine that as part of her responsibilities at NowYouSeeIt she spends lots of time on the phone, so NowYouSeeIt provides her with a Skype account. Two accounts, funded by two principals, with two very different usage volumes. There is a difference in quality and quantity of service between these two roles that Jessica assumes.

The Skype example feels very different to me than mere access control. While we could argue that the “funding account” is just another “object” that can be access controlled, I think that’s an oversimplification. In the WikiGood example it was pretty easy to argue that all we needed to do was limit access to shared objects based on group membership. But in the Skype example it feels like we’d have to replicate many of the structures associated with each user — and link those structures under a single identity.

Also think of the “monitoring” stuff that corporations want/need to do. Again in the Skype example think of the familiar “this call may be monitored for customer service”. Jessica wouldn’t accept that for her personal calls — but NowYouSeeIt may demand it for calls made on their behalf.

PS: the entity that gets to say whether an individual is working on behalf of someone else is not that individual - it’s the “someone else”. That will not change however much I want to control my identity.

I do not like giving my personal information to web applications. I agree that a web application provides a great “universal” way of accessing/managing data, but I am more interested in what they can do with my data than in them having my data.

The trick is to ensure that the data associated with each principal is clearly identified, and that sounds mostly like a usability problem. You’d probably want the system to warn if you were leaking data from one agency to another (eg replying to a work email with your home address), for example.

Also, the association of an individual to many agencies is highly private information. In an extreme example, I may not want anyone to know that I am both an agent for Exxon as well as an environmental activist. In other words the system should allow conflicts-of-interest and I think you alluded to this in the article above (”perhaps you could work for more than one principal at a time”).

I think I disagree with Mark’s comments above - what you are proposing is for individuals to be (largely) in control of their identities. This is not the case with enterprise identity models.