| [higgins-dev] Re: Redirecting Bandit STS efforts to Higgins |
|
Mike,
I should have also replied about the following:
I also am waiting for the change to the IdAS described here:
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg01601.html This is the request that we allow managedCardID+PersonalCardPPID+modulus+exponent to be the auth material for a self-issued token. I had some reservations, which I expressed in followup e-mails. My 2nd-to-last email asked whether you meant managedCardID or managedCardPPID, and I pointed out problems with managedCardPPID. ... I guess I just wanted clarification that you really meant managedCardID, not managedCardPPID. ... I was under the impression that we still needed to have everyone accept the proposed idea. I'm not sure where Jim and Tom are on the idea -- I will discuss it with them today to see what they think. As I recall, they didn't chime in on the thread. Daniel
>>> "Daniel Sanders" <dsanders@xxxxxxxxxx> 2/23/2007 8:38 AM >>> Thanks Mike. -- I did have a followup question on #2 (PPID claim handling). This should be independent of SAML provider, so I'm not sure what you mean here. All providers should do it this way, should they not? Am I misunderstanding what you mean by SAML provider? Could you clarify this?
I am also putting this particular e-mail out on the dev list - minus the other discussion about contributing to the STS.
Thanks,
Daniel
>>> Michael McIntosh <mikemci@xxxxxxxxxx> 2/23/2007 8:22 AM >>> "Daniel Sanders" <dsanders@xxxxxxxxxx> wrote on 02/22/2007 03:45:49 PM: > The term "fully implemented" implies a lot more than you are > allowing for. It includes major and minor bug fixes, reliability > fixes, scalability fixes, etc., etc. It's stuff that benefits ALL > users of the STS. There is a lot of stuff in the STS that people > are VERY interested in, that ought to be in the STS, that is not > going to be specified in a high-level WS-Trust document. We need to > collaborate about these things, including submitting patches and/or > committing changes, bug fixes, etc. directly. We would like to be > able to help with these things. We would like a task list or to-do > list that everyone can help out with - as is common with most other > open source projects. > > Examples of things that have recently been requested are as follows: > > 1) Some restructuring of the code modules. See my e-mail, and > Mike's response - both out on the higgins-dev list if you are watching it: > http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg01607.html Allow 1 STS Core to be used by N STS Bindings - this is checked in today (you can now pass a configured STS instance into the binding configure method and get the configured STS instance from a binding). > 2) A change in how PPID claims are handled. See http://wiki. > eclipse.org/index.php/Milestone_0.7 under the heading "IIW Reference > Application Post Mortem" PPID handling - this has been how the SAML provider works since the F2F. > 1. The STS needs to give special handling to the > privatepersonalidentifier claim. The document, A Guide to > Integrating with Information Cards and Windows CardSpace v1.0, says > the following: "To enable an identity provider that supports the > PPID claim type to be able to always produce a consistent claim > value, Windows CardSpace includes the extension element ic: > ClientPseudonym/ic:PPID in the RST request. It contains the result > of applying a hash function to a relying party identity and optional > user-supplied entropy to produce an opaque yet consistent reference > for the relying party. If the issued token contains the PPID claim, > this value is to be used as the basis. The IP/STS may use this value > as is or as an input seed to a custom function to derive a value for > the PPID claim." The STS should look for this ClientPseudonym/PPID > element whenever the RST requests the personalprivateidentifier > claim, and at the very least, return that value for the claim. > 3) A change in how the STS determines what claims to ask for from IdAS. See: > http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg01541.html. Ask for specific claims when calling getDigitalSubject - this is checked in today (I still feel that this is an LDAPism and would like to discuss whether getDigitalSubject is expected to provide dynamic read-write access via an to the DigitalSubject or whether its expected to provide a static cached copy of the Digital Subject. > > Mike may have already worked on some of these, perhaps all of them. > I haven't checked for the past few days. I am just showing you that > there are things that need tweeking, adjusting, refactoring, etc. - > that have little or nothing to do with the high-level WS-Trust > architecture. These kinds of requests come up somewhat regularly, > and we anticipate that more will happen. I also am waiting for the change to the IdAS described here: http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg01601.html > Daniel Sanders <snip rest of discussion...>
|