Green
From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Wednesday, February 28, 2007
1:20 PM
To: 'Higgins
(Trust Framework) Project developer discussions'
Subject: RE: [higgins-dev] I-Card
Registry's use of IdAS
>I was agreeing with you that an I-Card Provider could,
optionally choose to use an IContext managed by a CP for its persistence.
So,
the response from me is asking why make it optional? Why not just say the
contract _is_ IdAS? Why invent another, very similar abstraction?
- Well, for the data itself we are using the same abstraction
(IContext) so that part is clean.
- Let’s look at the two base i-card
interfaces in turn and compare them to IContext/IdAS…
- The ITokenCard
interface is all about token endpoint references that a generic IContext wouldn’t
know anything about. So that has to be different.
- As for ICard…this
is the generic interface implemented by all
kinds of i-cards (not just URI i-cards). For example CardSpace managed i-cards.
This kind of i-card, for example, only talks to the Token Service and has
no associated IContext. Also, there is a very simple getSupportedSimpleClaimTypes
method that doesn’t burden the I-Card Provider implementer with having
to worry about OWL, schemas, etc. when in fact all the card can support is
MSFT’s simple, linear set of URI claim types.
Later,
you stated:
>Ahh. Then the I-Card Provider has to support the IContext
interface itself.
Yeah, if this is
undesirable it would be interesting to know why.
I-Card Provider must
support the IContext interface (at least in the “displayContext”
method). Some cards (e.g. URI i-cards) will deletegate to a “real”
IdAS IContext impl and some will synthesize the IContext from data retrieved from
a display token from some Token Service.
Jim
>>> "Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx> 2/27/07 7:06 PM >>>
I think you were
clear. I think I must not have been. I was agreeing with you that an I-Card
Provider could, optionally choose to use an IContext managed by a CP for its
persistence. There are a set of interesting requirements most of which you
mention in your email below. Though one that you didn't is the ability for the
user to specify the physical location of the backing datastore (e.g.
thumbdrive, cloud, harddrive, etc.).
[BTW: There's even
one more that I've not mentioned because it is simply too hard (in the general
case) to support. Namely "undo." The I-Card Manager for both
"personal" and "URI" i-cards really should have undo. The
UI can probably "fake it" and provide one level of undo, but
multi-level undo would require support at the IdAS level. Although it is
generally bad design practice decide to postpone worrying about command stacks,
undo, etc. (I've learned that mistake before). Nevertheless I've done just that
in the Higgins project so far
because I felt it would slow the project down too much. It's related to the
transactional quagmire that we're trying to skirt around.]
Back to the main
topic.Sergey (Lyakhov), what do you think of Jim's suggestion of using an IdAS
Context for internal persistence of an I-Card? How are we doing it now?
See also inline
comments below.
-Paul
From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Tuesday, February 27, 2007
7:48 PM
To: 'Higgins
(Trust Framework) Project developer discussions'
Subject: RE: [higgins-dev] I-Card
Registry's use of IdAS
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?)
To export the card into some well known card file format (e.g.
CardSpace managed card .crd file format or CardSpace personal card .crd file
format)
- 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?
Ahh. Then the I-Card Provider has to support the IContext interface
itself. We use IContext here at the I-Card Provider level as an abstraction
just as we do at the IdAS level. Why? Because the UI (especially the I-Card
Manager) only needs to know how to display IContext data (no matter whether it
came from a CardSpace display token or an OpenID OP or from a "real"
IdAS IContext (pointed to by an URI I-Card).
-
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)
Yes.
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.
Good point. This is a great example of context factory config
metadata that we'd need to support.
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
>
|
