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

[Michael McIntosh <mikemci@xxxxxxxxxx>]

I meant Managed Card ID - thought that was clear.

higgins-dev-bounces@xxxxxxxxxxx wrote on 02/23/2007 11:20:33 AM:

> 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...>_______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev