User talk:Latha Serevi/OGP trust proposal based on secure groups

Is this equivalent to property-language?

Having a somewhat different cognitive style :) I tend to think of this in terms of properties rather than groups. Would it be equivalent to say that we want to be able to ask a given entity E whether or not a given subject S has property P? (Where P is E-relative in the general case.) And to be able to ask E for a list (if it's willing to provide it) of all subjects S that have property P? Does that leave anything out?

Not to say that this is a better way of modeling it; just want to confirm that it's expressing the same basic function.

In either case what we're left with is deciding which groups / which properties each entity / controller in the system ought to support. I'm perfectly willing to let people talk in group-language or property-language or any other semantically equivalent language they want to talk in. That out of the way :) we can start talking about the next level of semantics: which queries the AD needs to support, which queries the RD does, etc. -- Dale Innis 06:37, 10 September 2008 (PDT)

 -- It sure sounds equivalent to me!  Maybe I even prefer property language. -- Latha Serevi

Nittier comments and questions

"A group may or may not be its own entity, in which case NAME is null": can you give an example of use-case for NAME being null? Not immediately obvious to me what you're thinking of here.

 ---- I was trying to allow for the model "many groups living on an AD" (so NAME is the group name)
      and also for the model "each group has its own entity" (so NAME is superfluous and probably null).   --Latha

"A group is defined as a set of (entity, character string) pairs who are called the "members" of the group. Often NAME is null." I assume by "NAME" here you mean the "character string" element of the pair? What does it mean when NAME is non-null? Again I'm not sure of the use-case. Can I join a group as ( Dale-Innis-UUID, "M Linden" )?

 ---- I was trying to allow a bit of extra flexibility.  Most groups would probably ignore the character string (NAME) 
      and have members be entities.   None of this is overly well thought-out.   --Latha

"querying CONTROLLER supplying NAME and CANDIDATE": Not sure what the datatypes are here. I guess NAME here is the group-name? And CANDIDATE is the "entity" field of the group-member ordered pair?

"If our group is "open membership", any entity can add itself to our whitelist via an add-me query": This is the only place the "add-me query" is mentioned. What are its parameters and possible returns? And it's not really a "query", is it?

For SL-like-Resident-Groups purposes, presumably there also has to be a way to find out whether or not a group is open membership? And for that matter stuff like who its leader is and so on? And for groups that aren't open membership (like trust groups, for instance), do we need a way to determine who is allowed to perform group membership updates? And who is allowed to query the membership list? I think there are a number of issues here: for instance if some agent entity E in the domain of AD AD1 is in a group controlled by controller C, it seems like AD1 should be allowed to tell C "E has deregistered and no longer exists, so please remove em from the group", whereas it should not be allowed to take that same action for a different entity that is in some other AD. Would this sort of operation need to be part of the basic group functionality, or is it an add-on on top of that?

 --- Good questions; those all seem necessary sometimes, but I do think that some of this could be beneficially separated out 
     from the core functionality of securely maintained groups (properties).  --Latha