Jim, MikeM, Jim wrote:
>> It would be good to know: a) what of the above is already done or
>> being actively worked on, b) who is able to and interested in
>> collaborating on any of the points above.
>
>On 'a', I am working on 2-9. Although I am weak in the area of
>IdAS/ContextProvider, and may go straight to LDAP as an intermediate step.
Rather than going
straight to LDAP, consider using me or Tom as your IdAS slave -- we'll do
whatever it takes to help you integrate with IdAS. In fact, if you want
to just point me at the STS code where the integration needs to happen, or
where you would do your own "straight to LDAP" thing, I'm more than
happy to provide code.
>As for as "b",
I suspect this should be discussed with Tony N, Paul T, and
>Mary R.
Ok, Tony, Paul,
Mary: Is there anything we need to do in order to collaborate on this other
than what we're doing (communicating via email, phone, and irc)? Are
there resources that are available to be officially focused on any parts of
this?
On “b”:
1) I’ve been following this thread with great
interest. I’m 100% behind this effort and think it will do the Higgins and Bandit causes a lot of good.
2) Valery(Parity) and his team are working in parallel
on relevant components (e.g. the I-Card Registry, etc). I’ve been encouraging
them to try to engage with this thread where possible, and will continue to do
so. The 6 hour time shift doesn’t help of course, but #higgins is a great
resource.
3) As for my personal efforts to help, Jim’s
email on Friday prompted me to flesh out a number of pages over the weekend on
the wiki including:
a. http://wiki.eclipse.org/index.php/I-Card
- a description of the I-Card concept
b. http://wiki.eclipse.org/index.php/I-Card_Interfaces
- a refactoring of earlier work into one base interface (I-Card) and a set of
optional, composable interfaces (including most importantly to this thread
TokenIssuerCard and IdASCard)
c. http://wiki.eclipse.org/index.php/I-Card_Provider
- WRT to this thread, see especially the section entitled “CardSpace-compatible
I-Card Provider”. It implements three interfaces: I-Card, TokenIssuerCard
and IdASCard. Among other things, the intent of the design is to show that a CardSpace-compatible
I-Card holds BOTH (i) the metadata necessary to leverage the STS and (ii) the
IdAS metadata necessary to retrieve the Digital Subject attribute/claims, etc.
(As the wiki explains (and as this diagram now
shows), attribute/claim mapping (sometimes a no-op) is technically the
responsibility of an I-Card Provider, but in practice usually left to an IdAS
Context. My thought was that we should get some experience with the simple
design that a CardSpace compatible I-Card manages the STS and the IdAS
relationships, and worry about adding specific “mapping Contexts”
(or more generally chains of Context transformations) later.
4)I have not been specific (yet) about the gritty
details of exactly how the I-Card Provider either (i) retrieves the DS
attributes and “pushes” them to the STS, or (ii) pushes its IdAS
metadata to the STS and leaves it to a Token Provider to “pull” the
attributes from IdAS. We’ll figure out whichever seems more expedient and
do that, no doubt.
5) Unfortunately, I spend too much of my time trying
to evangelize Higgins and find
financial resources to support it. This week is no exception and I’m out
all week on the west coast ending up in Seattle
on a panel with Kim. But I’ll try to help out where I can.
6) I’d suggest that this Thursday’s call
should focus on “what can we all do to help this Dec 2 demo effort?”