| RE: [higgins-dev] Notes from 20070531 Higgins developers call |
|
Jim,
A minor correction to the
minutes:
Instead of" "Brian:
use case: we wanted to set up a CP that is backed by data in two different ldap
servers."
the essence of my use
case was
"Brian: Using one STS
to issue tokens for two communities (e.g HR and IT) where all the user instances are maintained in one LDAP directory but where the
users for each community are located in a different place in the DIT (e.g.
under "ou=HR,dc=bigcorp,dc=com" versus "ou=IT,dc=bigcorp,dc=com"). How
would that situation map to configuring Contexts and Context
Providers?"
Regards,
Brian
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim Sent: Thursday, May 31, 2007 10:42 AM To: 'Higgins (Trust Framework) Project developer discussions' Subject: [higgins-dev] Notes from 20070531 Higgins developers call Attendees
========= Alex Amies - IBM Abhi Schelat - IBM * Andy Hodgkinson - Novell * Brian Carrol - Serena Dale Olds - Novell Daniel Sanders - Novell David Kuehr-Mclaren - IBM * Duane Buss - Novell * George Sanchez - Serena * Greg Byrd - NCSU/IBM * Jeff Broberg CA * Jim Sermersheim - Novell Markus Sabedello Mary Ruddy - Parity/SocialPhysics * Mike McIntosh - IBM * Nataraj Nagaratnam - IBM Paul Trevithick - Parity/SocialPhysics Paula Austel - IBM * Tom Doman - Novell * Tony (The Wolf) Old-McNadalin - IBM Uppili Srinivasan - Oracle * Valery Kokhan - Parity Ukraine -- * Present Agenda ------ * Status of architectural convergence of components implementing HBX through ICard store
** What's the next baby step we can take to move closer to
convergence?
Tony: We need better detailed documentation that describe the HBX
thru ICard store stacks of components we have today. We have two. What are
the roles/responsibilities (now and in the future)? What has each impl
done? Are each applicable to each scenario we have? Do we need one
for each scenario?
Tony: Will foster a wiki page. Will prod Abhi, Andy for information
input. Page will gather the current state and then be used to drive any needed
re-architecture, and finally convergence toward that.
* Proposed Configuration Layout for Context Providers
Tom: Not sure we can resolve anything on the call. Still need to read
last few messages. Need to re-review XRI stuff.
Mike: What's a context?
Tom: All the contexts we can think of require config
Mike: Imagine a context full of data from differing backing
stores
Raj: There's config of a context provider into the framework, then there's
config of a specific CP.
Brian: use case: we wanted to set up a CP that is backed by data in two
different ldap servers.
Tom: use two contexts
Jim: in the future we could also front them with a joining provider
Mike: a CP is nothing more than a unit of code <group
agreement>
<discussion around allowing multiple CP configs for a given CP>
Raj: We need to keep the user experience in mind. Too many config UI panels
will be confusing.
Brian: Where does the abstraction happen? What hides the notion of
objectclass in an LDAP store?
Jim: IdAS. This happens at the IdAS layer and is (should be) handled
in the CP, typically by using rules in the context config.
* IdAS Model: We need to add update ability. Consider using metadata to
convey model.
Jim: Will send email on thoughts Hold over action items * Paul: Review component wiki pages and provide feedback * Mary: Put the agreed weekly IRC schedule up on the wiki * All: Review Paul's updated version of Markus' discovery draft and provide comments * Tony: Itemize needed items not covered by the latest OSP * All Component owners: review their components with respect to discovery needs. * Topic for another call, general process for refactoring packages New action items
* Tony: build a wiki and prod owners for info (see "next baby step"
above)
* Jim: send thoughts on model as metadata. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. |