| RE: [higgins-dev] Happenings and ideas around HBX, ISS UI, ISS, and ICard Registry |
|
Abhi, what does “we
were planning to work on making it work for cardspace…” mean? Do you
mean making the “ISS Web UI” _javascript_ code (to be merged with
HBX) have a card-picking UI somewhat similar to cardspace’s “identity
selector” (in addition to the idemix-related UI)? -Paul From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of abhi shelat I am waiting for an ok from our lawyer to commit the ISS/RPPS/HBX code
that we have written. it demonstrates a use case using idemix credentials. (the part from
RPPS to HBX is rough still) nonetheless, the design decisions were to write ISS and RPPS in
java---basically following the architecture that is documented on the wiki. the HBX is written in _javascript_ and
XUL and it now uses the SOAP mechanisms exposed by the firefox engine to communicate with the RPPS. in the meantime, i will try to make a video or get approval to commit
by this thursday's meeting. we were planning to work on making it work for cardspace in the next
two weeks. -- the question of writing the ISS UI as a separate C# application
which is invoked entirely depends on the importance you place on being
contextual vs. presenting an experience exactly like the cardspace ceremony. abhi On Feb 24, 2007, at 7:14 AM, Jim Sermersheim wrote:
All, 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. Browser Extension Being coded with _javascript_, XUL Consists of a launcher (built with code from Perpetual Motion) Roles: - Browser plugin - 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) ISS UI 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): - Presents cards to user - Allows all cards to be listed - Presents cards which match selection policy - allows for cad management (creation, deletion, etc.) Interacts with ISS (XML-RPC) ISS 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 ICard Registry Also being coded in C++ (see above) Roles: - 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. Jim _______________________________________________ higgins-dev mailing list |