Re: [higgins-dev] Sameness of Contexts

[Nataraj Nagaratnam <natarajn@xxxxxxxxxx>]

Treating Context to be about the attribute
service (and not other contexts like temporal contexts, protocl, etc..),
let me brain storm wrt certain viewpoints i.e not necessarily an answer,
but questioning if we need it, and if so what scope. 

Using the examples below, maybe.. let
me try 'process of elimination' first (we can then circle back and say
what is).

In one set of scenarios, I can think
of one set of arguments: 
I tend to think the authn cred is about
'how one connects to' Contexts, and not 'what the context' is. So, that
shouldn't taken into consideration for some type of equality. I would possibly
say the same for protocol as well.  Note - I agree creds, protocol,
etc may dictate what the end result of a query to a Context is. But it
doesn't change the fact 'what' constitutes a Context. Also, different ContextProviders
maybe used to access the same Context. So, things like LDAPFactory etc
would be more of ContextProvider discussion vs Context discussion.

This leaves out ... host, base dn. While
host is about 'where' information is, and not 'what information is about',
we still need a scoping mechanism to define a Context - baseDN is relative
to a given information source. The challenge is going to be in dealign
with replicated hosts, etc.

There are situations I can imagine,
 where 
        protocol
or cred may need to be factored in not only for access, but to define what
is being exposed at the end point.

All that said, when would we need to
deal with equality/sameness of Contexts - it is likely in the eyes of the
entity dealing with Contexts. So, instead of trying to think about a universal
uniqueness, we should probably leave it to be defined within the scope
of a given IdASEndPoint.  One approach maybe is to allow usage of
some distinguishing attributes for a Context that makes comparisons to
be done (so that different Contexts .. ldap, db2, etc may have different
ones). aka... Context have a method to test equality and that is dependent
on Context semantics, implementation, etc...

In other words, we should possibly not
assume what makes Contexts equal. Maybe add operations to allow for some
checks within IdASEndPoint to make this check possible? 

thanks,
Raj

"Jim Sermersheim" <jimse@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

07/21/2006 06:46 PM

Please respond to
"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

To	"'Higgins (Trust Framework) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
cc
Subject	[higgins-dev] Sameness of Contexts

We've mentioned the notion of two providers being used
to access the same Context a number of times. It makes me ask myself what
constitutes sameness among contexts.
 
Referring to the context examples at the bottom of this
mail, I don't know which are the same context, and which are different:
 
ex1 and ex2 both use LDAP, both start at the same place
in the LDAP server's tree, both use the same AuthN materials. Difference
is vendor. Let's say the IBM provider maps attributes quite differently
than the Novell provider, and the Novell provider follows referrals whereas
the IBM provider cannot, thus it's view of the tree is chopped. These may
look quite different from the IdAS consumer's POV.
 
ex2 and ex3 differ only in protocol. Let's say both present
the data model exactly the same and have the same capabilities.
 
ex4 uses different AuthN materials, with the implication
being that a different set of data will be exposed (anon cannot see privileged
data).
 
ex5 points to a different host. It's assumed that this
host is a replica of eDirLDAPServer.com. The only problem is that replication
between these two hosts is loosely consistent. There's no guaranty that
the data is ever exactly the same among replicas.
 
Maybe we're saying a context is defined by its Context
Reference (URI). So, whatever the URI contains or points at must be what
constitutes a context. If that's the case, we're back to the "what's
in the URI?" question
 
 
ex1:
Provider Implementor = IBM
Factory = IBM LDAP factory
Protocol = LDAP
Host = eDirServer.com
Base = ou=employees.dc=ibm,dc=com
AuthN = superuser and credentials
 
ex2:
Provider Implementor = Novell
Factory = Novell LDAP factory
Protocol = LDAP
Host = eDirServer.com
Base = ou=employees.dc=ibm,dc=com
AuthN = superuser and credentials
 
ex3:
Provider Implementor = Novell
Factory = Novell NDAP factory (NOTE: different protocol,
same backing data)
Protocol = NDAP
Host = eDirServer.com
Base = ou=employees.dc=ibm,dc=com
AuthN = superuser and credentials
 
ex4:
Provider Implementor = Novell
Factory = Novell LDAP factory
Protocol = LDAP
Host = eDirServer.com
Base = ou=employees.dc=ibm,dc=com
AuthN = anon
 
ex5:
Provider Implementor = Novell
Factory = Novell LDAP factory
Protocol = LDAP
Host = eDirServer2.com
Base = ou=employees.dc=ibm,dc=com
AuthN = superuser and credentials_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev