From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of David Kuehr-McLaren
Sent: Monday, May 07, 2007 1:58 PM
To: Higgins
(Trust Framework) Project developer discussions
Subject: Re: [higgins-dev]
Proposed updates to Higgins
Architecture diagram perAustin F2F discussions
Paul,
I
am afraid my recollection of the whiteboard diagram is a bit fuzzy. Does the
i-Card provider plug-in need to access the i-Card store plug-in. If so, does it
go through the I-Card Registry?
I don’t remember us resolving this. We’d need a
registry of i-card store providers. Which leads to our discussions of
generalized “Configuration” and “Discovery” Components.
Not
related to the new additions, but related to the IdAS API/SPI discussion:
Should the links from the Token Provider and the I-Card Provider be "Local
or Remote" instead of "Local" only?
Ah thanks. I’ve just changed it here.
David
David Kuehr-McLaren
Tivoli Security
919.224.1960
"Paul
Trevithick" <paul@xxxxxxxxxxxxxxxxx>
Sent
by: higgins-dev-bounces@xxxxxxxxxxx
05/07/2007 01:08 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] Proposed updates to Higgins Architecture diagram per
Austin F2F discussions
|
|
I
have made three changes to the Architecture diagram v37 (attached):
1) Added another extension point: "i-card
store provider." This harmonized
Novell's C++ work in this area with the overall Higgins architecture.
2) Added a new (cross-cutting) Component:
"Configuration". Per discussions
at the F2F in Austin we need a Higgins-wide
Configuration component that
will have interfaces that most Higgins Components implement. We will build
on Mike's code created to configure the Token
Service.
3) Added a new (cross-cutting) Component:
"Discovery". Per discussions at
the F2F in Austin
(an parallel with #2 above) we realized that proposed IdAS
Context Registry and IdAS Context Provider
Registries described in [1] could
be generalized to be a discovery Component/service
to discover things
besides Contexts and Context Providers. Namely,
i-card store providers, and
perhaps even i-card stores themselves. And other
things in the future.
Any discussion before I post the attached to the
wiki?
-Paul
[1]
http://wiki.eclipse.org/index.php/IdAS_Registries_Proposal_2B v5
[attachment "higgins-v37c.JPG" deleted
by David Kuehr-McLaren/Raleigh/IBM]
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev