From: Maxim Kopeyka [mailto:maxim@xxxxxxxxxxxxx]
Sent: Monday, February 26, 2007
12:17 PM
To: Paul Trevithick
Cc: 'Higgins (Trust Framework)
Project developer discussions'; 'Valery Kokhan'; 'abhi shelat'
Subject: Re: [higgins-dev]
Happenings and ideas around HBX, ISS UI, ISS,and ICard Registry
In
order to achieve some further integration and show some interesting use cases,
for the past week or so, we've been prototyping implementations of the modules
in the subject line. For (mainly time-related) reasons , we're having to
quicky put these together right now (the implementors barely have time to
breathe, let alone time discussing on-list), but we do need to carve out time
to get the ideas on-list so we can try to do this in a way that furthers
Higgins goals (so I'll try to facilitate that).
It's
probably best to start by describing the modules, their roles, and how we're
trying to build them, and then move the conversation toward how these
roles/goals mesh with the existing Higgins architecture, and then map
out how to best converge and ensure efforts can be funneled into
Higgins.
Being
coded with _javascript_, XUL
- Recognizes
CardSpace objects on page
-
Launches ISS UI when CardSpace button is pressed
-
Configurable to launch different selectors (uses XPCOM to launch)
-
Using token returned from selector, posts it back to the RP server.
Interacts
with ISS UI (XPCOM)
Being
coded in C# (because implementor is able to re-use existing code of his --
time-to-delivery is a factor here)
Roles
(this is the presentation layer only):
-
Allows all cards to be listed
-
Presents cards which match selection policy
-
allows for cad management (creation, deletion, etc.)
Interacts
with ISS (XML-RPC)
Being
coded with C++ (seen by the implementor as best choice for deployment as
dependencies can be delivered ala RPM thus side-stepping IP issues with
dependencies. Also runs as a daemon, and implementor felt C/C++ was a
better fit for this)
Depends
on OpenSSL, LibXML2, XMLSec
Roles
(Uses ICard Registry to achieve many of these):
-
Enumerate all cards (via registry)
-
Interact with STS (RST / RSTR)
-
Performs selection policy matching
-
Performs card management (via registry)
Interacts
with ICard Registry
Also
being coded in C++ (see above)
-
Provides an abstraction over numerous card stores
-
Allows enumeration of card stores
-
Allows enumeration of cards in each store
-
Card retrieval / management
-
Pluggable architecture for future card stores.
Note
that we're thinking about how IdAS could be used as the pluggable metaphor here.
I
think a good direction for this discussion to move from here is how these goals
compare and contrast with the existing Higgins goals. Note that the Higgins
goals (as stated on the component pages) were a primary consideration in
designing these. Then we could start talking about how best to converge
efforts.