Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Milestone 1.0M7

Revision as of 12:55, 14 December 2006 by Paul.socialphysics.org (Talk | contribs) (ISS Web UI)

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.

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]

ISS Web UI

  • Jan's (IBM Zurich) team plans to contribute code to this component and to the (Firefox) HBX component. Jan's team's code implements most of the card selection user interface in HBX (in XUL) and supports this on the back end in the ISS Web UI component.

I-Card Selector Service

  • Begin initial implementation 160408

I-Card Registry

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

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

  1. Remove hard-coded HTML profile edit/view pages [in progress] 152860

HBX

  1. Startup processing
    1. Discovery of and/or connecting to a Higgins service endpoint URL
      • Explore optional use of XRI and/or i-names (community or top level)
    2. 1st time: Provisioning of user account on Higgins service
    3. 1st time: Display and user acceptance of Higgins service's Terms of Service (TOS)
    4. Nth time: Authentication to user account on Higgins service
    5. Background processing of screen-scrape jobs
  2. Update the HBX doc (e.g. target protocols (e.g. OpenID), non-pluggable assumption)
  3. For RSS: RP site i-card issuance 152861
  4. OpenID support

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