| Re: [higgins-dev] [IdAS] registered Contexts |
|
This seems pretty straightforward. The registry is meant to be accessed as an advertisement/discovery mechanism.
I'm still trying to imagine the practical use cases and what other issues need to be thought of. Scenario #2 implies that there are multiple users which all have access to an IdASRegistry object (presumably they all hold a reference to the same object). If so, we're adding APIs which by nature, we expect to be concurrently used. Do we need to start thinking about threading issues?
Maybe that's not what you're envisioning. Are you thinking an application would take care of concurrent access and users would only interface with the application (not with IdASRegistry directly)?
Jim >>> Greg Byrd <gbyrd@xxxxxxxx> 8/16/06 7:40 AM >>> I wasn't thinking of something so fine-grained. My thought was to make a ContextRef either visible (via the service) or not. In other words, there is a set of ContextRefs that can be viewed by anyone who has access to the service. These are explicitly identified by calling IdASRegistry.registerContext. Only these ContextRefs will be returned when a consumer calls IdASRegistry.getContexts. (We could call it getRegisteredContexts, if that helps.) (I want to defer the discussion of ContextFactory.getContexts for now. The set of registered Contexts may or may not be kept in a list that is separate from the factories' lists.) Scenario #1: User wants to create/open a "private" Context, for which he has a URI. (1) Gets a list of potential factories for this Context (IdASRegistry.getContextFactories(URI)). (2) Chooses one and creates a Context object (factory.createContext) then opens it (context.open). (3) If another user of the service calls IdASRegistry.getContexts, this URI does not appear in the list. Scenario #2: User wants to publish a Context, for which he has a URI. (1) Calls IdASRegistry.registerContext(URI) -- registry will test the URI against the existing factories (factory.canCreate), and will throw an exception if there is no factory that claims to handle this URI. (Note that the user does not need to create or open this ContextRef to register it.) (2) If another user of the service calls IdASRegistry.getContexts, this URI will appear in the list. Considering the case of exposing a particular ContextRef to a certain set of people (e.g., family and friends), I have two options. First, I can just send them the ContextRef through some out-of-band means (in the same way that I them tell how to get to my blog). Second, I can set up an IdAS service that is restricted to those users, and publish the ContextRef there. (Then I have to tell them about the IdAS service....) This two-state policy (registered or not) is simple, and it avoids the need for a complex policy about who can see what. If we find that we need such a policy to govern ContextFactory.getContexts, then I'll recant and say the IdASRegistry.getContexts simply aggregates the getContexts results from all registered factories. I realize that this does not address the desire to enumerate (a) opened contexts, and (b) instantiated contexts. I personally don't think that's necessary for the registry service. I've pushed this issue to the ContextFactory -- I'm also concerned about privacy there, but I'll let someone else justify why we need those enumerations, and then we can figure out how to address the privacy issues. ...Greg Jim Sermersheim wrote: > You're right of course, I skipped tracks there. I need to regroup my > thoughts. > > So we want a way to enumerate contextRefs. Some issues are: > > - Do we want to distinguish between, (a) opened contexts, (b) > instantiated contexts, and (c) potential contexts? > - Of the contextRef's available to be returned (possibly considering > each of the three types above), are some only viewable by certain > identities? > > I don't know how IdAS -- other than config/policy one would restrict > access to (b) or (c) to certain parties. I can see how one could do it > with identities for (a). > > <this is likely something better suited for phone or f2f> > Because I don't understand the deployment scenarios, I still don't > really understand the need to restrict contextRef's at the IdAS level. > I guess your scenario is where there is a public IdAS service (I guess > there would be a protocol fronting this) where anyone can enumerate > all contextRefs (say a and b types), and I happened to do this find > one that contained the text "drug dealers for bgyrd@xxxxxxxx". From > that, I can guess that you have a list of drug dealers. Thus, > (assuming this public IdAS service fronted by some protocol) you'd > like to make your contextRef's private. I guess this also assumes some > kind of session knowledge or something that is used to distinguish > between you and me as we're interacting with this service. > > If this is the scenario you're thinking of, it may be one of those > things we need more tangible use cases/requirements around before > defining. For example, I may want to make some of my contextRefs > available to family members, some others available to friends, some > only to me, and others publically available. > > Jim > > > > >>> Greg Byrd <gbyrd@xxxxxxxx> 8/15/06 3:46 PM >>> > Jim Sermersheim wrote: > > <snip> > > I can't see where it's ever safe to return a context which has been > > open as a different person. That's like logging into one's workstation > > and allowing someone else to take over. I think the sharing of open > > contexts between trusted parties as being beyond the purview of IdAS. > > > But we're talking about ContextRefs, not Contexts. I completely agree > that an open Context should never be passed to someone else. But have a > ContextRef does not give me permission to do anything. It simply gives > me a handle that I can use to create and open a different Context to the > same data source. > > > _______________________________________________ > higgins-dev mailing list > higgins-dev@xxxxxxxxxxx > https ://dev.eclipse.org/mailman/listinfo/higgins > <https://dev.eclipse.org/mailman/listinfo/higgins>-dev > ------------------------------------------------------------------------ > > _______________________________________________ > higgins-dev mailing list > higgins-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/higgins-dev > _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |