[higgins-dev] Re: Redirecting Bandit STS efforts to Higgins

[Michael McIntosh <mikemci@xxxxxxxxxx>]

The SAML Provider is the only implemented provider that gets claims from 
IdAS right now. Eventually other providers will need to do the same thing.
That is why I'd architected it the way it was before (framework gets the 
DigitalSubject without specifying specific claims - then specifying all 
known claims when that stopped working - now framework does not get the 
DigitalSubject, then provider does).




"Daniel Sanders" <dsanders@xxxxxxxxxx> wrote on 02/23/2007 10:38:22 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...>