[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] [IdAS] registered Contexts
|
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
