Paul,
> Back to
the main topic
Sergey (Lyakhov), what do you think of Jims suggestion
>
of using an
IdAS Context for internal persistence of an I-Card? How are we doing it
now?
I've implemented I-Card provider
stored in both encrypted file and in IdAS context (in non-encrypted
form). However I did not yet join the file-based provider with the
I-Card regesrty.
Sergey Lyakhov
----- Original Message -----
Sent: Wednesday, February 28, 2007 4:06
AM
Subject: RE: [higgins-dev] I-Card
Registry's use of IdAS
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 didnt is the ability for
the user to specify the physical location of the backing datastore (e.g.
thumbdrive, cloud, harddrive, etc.).
[BTW:
Theres even one more that Ive 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. (Ive learned that
mistake before). Nevertheless Ive done just that in the Higgins project so
far because I felt it would slow the project down too much. Its related to
the transactional quagmire that were trying to skirt
around.]
Back to the
main topic
Sergey (Lyakhov), what do you think of Jims 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 wed 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 >
|