Milestone 1.0M7

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

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

done items have strikethrough

Architecture

• Continue to evolve the Architecture across these broad areas including:
  • Integration of idemix (cross-card policy matching) Abhi
  • First cut at I-Card Registry design Paul, Valery, SergeyL
  • IdAS registry and configuration issues Paul, Jim, Tom, Valery
    • New proposal done, Jim will lead the effort from here

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. OpenID support: request approval of Sxip OpenID libraries

ISS Web UI (inside HBX)

• Initial implementation Abhi

Defer to 0.8

1. HBX Startup, authentication issues

RP Protocol Support

• Initial implementation 170063 Sergei
• Getting the RP Protocol Support Service running on an Eclipse server. 170082 Sergei
• New operation: create new CardSpace-compatible I-Card (.crd) 168850 SergeyL [in progress]

RP Enablement

• Getting the test RPPS code running on an Eclipse server. 170301 Sergei

I-Card Selector Service

• Begin initial implementation 160408 Abhi

I-Card Registry

• Design and implement I-Card Registry 160410 Valery
• Continue work on I-Card Provider API 160375 Valery

I-Card Providers

• Cardspace-compatible Managed provider
  • initialize with .crd data 168852 Valery
• CardSpace-compatible Personal provider
• URI provider 169233 Valery, SergeyL

Token Service

• Interop with live.microsoft.net (in progress) 152872 Mike
• Eclipse-Hosted Higgins Token Service 169870 Mike

Token Providers

• Self-signed SAML 1.1 160413 Mike
• Username / password 160414 Mike

IdAS

• IdAS API: schema create/retreive methods 160412
• IdAS unit tests (.higgins.idas.test) [Waiting for factory instantiation mechanism] 153208
• Many other open items

IdAS Context providers

• Jena-based provider (uses HSQLDB) [80% done] [waiting on IPzilla] 152856 SergeyL
• LDAP-based provider [waiting on IPzilla]

I-Card manager

• Initial implementation Sergei

Infrastructure

• Automated Builds Mary, Evgeniy
  • Trigger nightly builds on demand 169213
  • Trigger stable builds on demand 169214
  • Add build number to "stable build jar name" 169215
  • Add build hour and minutes
  • Add manifest document to all build zip files 169217
  • Switch the nightly build number from 0.6 to 0.7
  • If the triggered build fails, there should be a link to a logfile.
  • Add a CVS label as part of the build process
  • Create a nightly build process for the STS
  • Create a stable build process for the STS
• Documenting "How To set up an Eclipse-Hosted Server" Mary

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
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

• Higgins Home
• Milestone 1.0M8