From: Anthony Nadalin
[mailto:drsecure@xxxxxxxxxx]
Sent: Monday, February 26, 2007
12:59 PM
To: Maxim Kopeyka; Higgins (Trust
Framework) Project developer discussions
Cc: 'Higgins (Trust Framework)
Project developer discussions'; higgins-dev-bounces@xxxxxxxxxxx; Paul
Trevithick; 'Valery Kokhan'
Subject: Re: [higgins-dev]
Happenings and ideas around HBX, ISS UI, ISS,and ICard Registry
and how do you know which one is rouge ? this is one
area that CardSpace does not have issues, we have to be careful here
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Maxim Kopeyka <maxim@xxxxxxxxxxxxx>
|
Maxim
Kopeyka <maxim@xxxxxxxxxxxxx>
Sent by:
higgins-dev-bounces@xxxxxxxxxxx
02/26/2007 11:17 AM
|
Please respond to
Maxim Kopeyka <maxim@xxxxxxxxxxxxx>; Please respond to
"Higgins \(Trust Framework\) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
|
|
|
To
|
Paul Trevithick
<paul@xxxxxxxxxxxxxxxxx>
|
|
cc
|
"'Valery
Kokhan'" <valery@xxxxxxxxxxxxx>, "'Higgins \(Trust
Framework\) Project developer discussions'"
<higgins-dev@xxxxxxxxxxx>
|
|
Subject
|
Re: [higgins-dev]
Happenings and ideas around HBX, ISS UI, ISS,and ICard Registry
|
|
Hi Paul,
I think user should have the opportunity to select card-selector by yourself. I
need some time to investigate how HBX will support Perpetual Motion plugin.
--
Regards, Maxim.
-------- Original Message --------
Subject: Re:[higgins-dev] Happenings and ideas around HBX, ISS UI, ISS,and
ICard Registry
From: Paul Trevithick <paul@xxxxxxxxxxxxxxxxx>
To: 'Higgins (Trust Framework) Project developer discussions' <higgins-dev@xxxxxxxxxxx>
Cc: "'Valery Kokhan'" <valery@xxxxxxxxxxxxx>, "'abhi shelat'" <abs@xxxxxxxxxxxxxx>, "'Maxim Kopeyka'" <maxim@xxxxxxxxxxxxx>
Date: 26.02.2007 18:39
While it is wonderful to have this new energy around these 4
components, we also need to find a way to coordinate the existing _javascript_
& Java efforts by Parity Ukraine on these same 4 components without slowing
down either team too much. Some suggestions:
1. Browser Extension: I suspect that
HBX could be trivially changed to provide an alternative to the Perpetual
Motion plugin (Maxim, please chime
in here). Would this be useful?.
2. ISS [Client] UI: I think
that the “ISS UI” mentioned in Jim’s email is very close to if not the same as
the “ISS Client UI” in the Higgins architecture. Is this true? If so, Abhi should take a first cut at documenting
the API here. So that the Novell folks can react to it and compare it to what
they were thinking.
3. ISS: We should agree and/or discuss whether the API described here by Abhi is the one
both teams are using.
4. I-Card Registry: Valery
should update this API
documentation as soon as possible. The Novell
folks should examine this and we should have discussion.
5. At long last it may be worth one of us (any volunteers?) to
actually try to use the latest GCJ compiler to prove the proposition that the
existing java code for a component, say, ISS, can be compiled to binary and
thus perhaps obviating the need
for having both Java and C/C++/C# versions.
6. Parity Ukraine (esp. Valery)
break its development efforts on the last 3 of these components into finer
grained Eclipse Bugzilla items so
as to publish to others on the higgins team what we’re doing more
transparently.
-Paul
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Saturday, February 24, 2007 1:14 AM
To: higgins-dev@xxxxxxxxxxx
Subject:
[higgins-dev] Happenings and ideas around HBX, ISS UI, ISS,and ICard Registry
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
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
