|
I'm probably not being very clear in what I'm saying. I'll change the tack:
- getCards is like getSubjects()
- createCard is like addSubject()
- deleteCard is like removeSubject()
- exportCard is like... well, I don't know (what does this do?)
- getDisplayName through getExpiredTime would be implemented as attributes or metadata
- getSupportedSimpleClaimTypes is like reading the schema for a specific card type
- getDisplayContext (need more info on how this works. i.e. what if there's no backing IContext?
- get/setReleasePolicy could either be metadata, attributes, or addressed in a different way in IdAS (there will probably be analogous IdAS use cases requiring this same kind of policy)
- export-related methods are probably also needed in IdAS
- update operations would follow analogous IdAS methods
The requirements below also seem like valid IdAS requirements (IdAS CP's need to exist for many disparate types of stores -- both in terms of location, access method, and security factors)
Do you think the notion of encryption needs to be build into the CP contract? I wonder if there will be other things like that in the future. Maybe for these kinds of things, we'll end up with some kinds of context-config that look common across CP's.
Jim >>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 2/27/07 3:07 PM >>>
I could imagine an I-Card Provider implementation that delegated its storage management to an IdAS Context.
It has become increasingly clear and is now a requirement for Higgins 1.0 that I-Card Providers need to let the user choose where they'd like their cards to be stored (in encrypted form). For example, on a thumb-drive, a hard drive, or in the cloud. This is independent of where the Higgins Service (aka Identity Agent) itself is located. [We're also going to try to make this all easy to manage across different I-Card Provider classes, so the UI is going to have to rely on good defaults.] So. since IdAS Contexts (of various kinds) can be configured as to where their backing store is located, this might be helpful. Encryption would also have to be included as part of the Context Provider.
-Paul
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Tuesday, February 27, 2007 1:14 PM
To: 'Higgins (Trust Framework) Project developer discussions'
Subject: Re: [higgins-dev] I-Card Registry's use of IdAS
So, I agree that it would be best if we could use the same code for the "registry" aspect of I-Card Providers as we do for IdAS Context Providers.
My suggestion was that we go one step further. You say the "responsibility of an I-Card Provider is to provide convenient methods for card creation, retrieval and management."
It happens that IdAS Context Providers have very similar responsibilities. They provide convenient methods for the creation, retrieval, and management of "Subjects". Subjects can be anything -- they're not constrained to represent people. They can just as easily represent an I-Card. So, the proposal would be that an I-Card Provider is simply an IdAS Context Provider which adheres to some schema which included an "I-Card" subject and whatever attribute(s) make sense. Talking about how to break an I-Card into it's constituent parts and represent those as Attributes would be a point of discussion if we decided to pursue this.
Jim
>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 2/27/07 5:47 AM >>>
Hi Jim,
What do you mean by "use IdAS as the I-Card Registry / Abstraction"?
>From my understanding main responsibility of I-Card Registry is to
look up (perhaps using different lookup mechanisms) and instantiate
(perhaps using some provider's specific configuration data) all
available to the system I-Card Providers (card factories, card stores,
whatever you name it).
The responsibility of I-Card Provider is to maintain list of I-Cards and to
provide convenient methods for card creation, retrieval and
management. Each particular I-Card Provider implementor should be able
to make a choice whether to use IdAS as backed store for I-Cards or not.
Current implementation of I-Card Registry uses three different
mechanisms to look up and instantiate I-Card Providers available in
the system:
1. java.security.Security
2. Eclipse extension points
3. javax.imageio.spi.ServiceRegistry
Each of these mechanisms have both benefits and disadvantages so, I
believe we have to support all of them in order to provide flexibility
at deployment time.
BTW, current implementation of IdAS Registry uses only the first
mechanism from the above while implementation of the second one is
provided by the separate IdASRegistryPlugin class. It is not very good
because IdAS consumers needs to know (at development time) which
registry will be used (at deployment time). Especially when it was
decided to use IdAS Registry as singleton. I'd prefer to have single
implementation of the registry while different factory look up /
instantiation mechanisms could be plugged at runtime (depending on
runtime environment and/or deployment configuration).
It seems to me that from factory look up / instantiation perspective
both IdAS and I-Card Registry have a lot in common and could use (be
based on) some common component(s).
Working on I-Card Registry I had some hope that the same look up /
instantiation logic could be useful for IdAS Registry as well. I put
all such logic in a separate project (org.eclipse.higgins.registry).
Current implementation of HigginsRegistry (base class for registries)
uses registry extensions (IRegistryExtension) to look up and
instantiate higgins services (factories, providers, etc.) There are
three base implementations of IRegistryExtension which could be used
to look up services using three different mechanisms mentioned above.
Unfortunately I do not have clear understanding of what we are
doing (going to do) with IdAS Registry right now but I believe we
still could use look up logic implemented in
org.eclipse.higgins.registry there.
--
Thanks,
Valery
Tuesday, February 27, 2007, 2:39:54 AM, you wrote:
>
>
>
> I may be alone in thinking this, but why not use IdAS as the
> I-Card Registry / Abstraction? This would allow the I-Card Registry
> to be backed by different card stores, and hopefully (some day soon)
> we'll already have the registry issues ironed out.
> Jim
>>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 2/26/07 9:39 AM >>>
>
> 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:
>
> 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?. 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. ISS: We should agree and/or discuss whether
> the API described here by Abhi is the one both teams are using.
> I-Card Registry: Valery should update this API documentation as soon
> as possible. The Novell folks should examine this and we should have
> discussion. 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. 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
>
|
