Skip to main content
Jump to: navigation, search

Difference between revisions of "Milestone 1.0M7"

(I-Card Selector Service)
(I-Card Selector Service)
Line 19: Line 19:
 
* IBM Zurich is developing this component (now a sub-component of HBX). [[User:abs.zurich.ibm.com|Abhi]]
 
* IBM Zurich is developing this component (now a sub-component of HBX). [[User:abs.zurich.ibm.com|Abhi]]
  
 +
===RP Protocol Support===
 +
* New operation: create new CardSpace-compatible I-Card (.crd) [https://bugs.eclipse.org/bugs/show_bug.cgi?id=168850 168850] [[User:slyakhov.parityinc.net | SergeyY]]
 
===I-Card Selector Service===
 
===I-Card Selector Service===
 
* Begin initial implementation [https://bugs.eclipse.org/bugs/show_bug.cgi?id=160408 160408] [[User:abs.zurich.ibm.com|Abhi]]
 
* Begin initial implementation [https://bugs.eclipse.org/bugs/show_bug.cgi?id=160408 160408] [[User:abs.zurich.ibm.com|Abhi]]

Revision as of 10:13, 21 December 2006

Milestone 0.7: Feb 15 With this milestone we will have roughed out all major components of the Higgins architecture including a card selector UI. Handy shortcut to create a new Higgins Bugzilla entry. See all open items

Architecture

  • Continue to evolve the Architecture across these broad areas including
    • Integration of idemix (cross-card policy matching) Abhi
    • Integration within HBX of ISS Web UI component
    • IdAS registry and configuration issues Paul
    • STS configuration issues Paul

HBX

  1. Move download URL to Eclipse 155452 Valery
  2. Acquire CardSpace-compatible I-Card (.crd) from webpage 168845 Maxim
  3. Update the HBX doc (e.g. target protocols (e.g. OpenID), non-pluggable assumption)
  4. HBX Startup
  5. OpenID support

ISS Web UI (inside HBX)

  • IBM Zurich is developing this component (now a sub-component of HBX). Abhi

RP Protocol Support

  • New operation: create new CardSpace-compatible I-Card (.crd) 168850 SergeyY

I-Card Selector Service

I-Card Registry

Token Service

  • Interop with live.microsoft.net (in progress) 152872 Mike

Token Providers

I-Card Providers

  • CardSpaceCard - Integrated with STS and IdAS
  • IdASCard

IdAS

  • IdAS API: schema create/retreive methods 160412
  • IdAS unit tests (.higgins.idas.test) [Waiting for factory instantiation mechanism] 153208
  • DEFER: work on remote interfaces

IdAS Context providers

  • Jena-based provider (uses HSQLDB) [80% done] 852856
  • XML file-based provider [in progress]
  • LDAP-based provider [in progress]

I-Card manager

IIW Reference Application Post Mortem

  1. STS Configuration 163618. Mike
    1. The bug doesn't say anything else, but I think it has to do with how the STS is configured to do things like: - insert a claim mapper between itself and the IdAS CP (dependency on claim mapping task below), possibly include a list of allowed CP's, etc.
  2. Mappings Duane
    1. Name mappings.
      1. We used full DN values from the groupMembership. Should have been simple (mapped) names.
    2. Claim/Attribute mapping.
      1. We ended up making the LDAP CP emit attributes which are named just like cardspace claims... We'd like to do this via configuration, or possibly a mapping CP, or something like that.
      2. 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. Update operations in IdAS instead of PHP LDAP. Daniel
    1. All the update operations on the RP use PHP LDAP instead of IdAS.
      1. Need to implement update operations in the LDAP CP first. Tom
        1. Need better design in IdAS for updates first. 163428, 163429, and 167978 Jim
  4. Location of dependency libraries. (Need Owner)
    1. We had some in the STS deployment lib directory, and others in the Tomcat shared lib. We need a methodology for deciding where to locate these.
  5. BasicDateTimeValue couldn't be used because of some fishiness with the time zones. 167979 Jim
  6. Verify that Mike's latest STS code is in, and we can build and deploy ourselves. Jim
  7. Check in fixes to card generator to Higgins. Separate from from ui Andy & Jim
    1. Separation is done
  8. Empty/missing claim (on forum) Mike
  9. LDAP CP should support any URI as the context ref (i.e. http) (Need Owner)
    1. This should be handled as part of the rework on the IdAS Registry
  10. CardID to context mapping. 163366 Jim
    1. We ended up making the CardID equal the contextRef. It looked like this: file:///<some path on the IdAS machine to a config file>?<some identifier inside the config file representing a context>.
    2. It would be nice if we could come up with something a little more abstract so we're not putting something as brittle and revealing as a local filename.
    3. This may be rolled into the previous task.
  11. STS builds are still not quite up to snuff -- see recent list traffic. Mike

See Also

Back to the top