Skip to main content
Jump to: navigation, search

Difference between revisions of "04.30.2007 F2F Agenda"

(8:30am IdAS API and Data Model continued [Jim])
(Higgins Data Model (HOWL POV) [Paul] [10 min])
Line 257: Line 257:
 
* Proposed change of "higgins:Attribute" to "higgins:ValueAndMetadata"
 
* Proposed change of "higgins:Attribute" to "higgins:ValueAndMetadata"
 
* Two parallel ways of handling Complex attribute values
 
* Two parallel ways of handling Complex attribute values
** "Composite" OWL class (e.g. [[Person-with-address Example Context Ontology]]
+
** "Composite" OWL class (e.g. [[Person-with-address Example Context Ontology]])
 
** Composing from Simple attributes
 
** Composing from Simple attributes
  

Revision as of 16:38, 1 May 2007

Agenda for Higgins face-to-face meeting in Austin, Texas, April 30 - May 3, 2007.

Logistics

Location: IBM Austin, 11501 Burnet Road, Austin, Texas, 78758. Report to building 904 to get your badge. The meeting will be held in building 901 room 3G17.

The event will start Monday April 30 at 1:00 and end Thursday May 3 at mid day.

Hotel List for IBM Austin See visitor information for google map, etc.

Expected Attendees

  1. Jeff Broberg (CA)
  2. Greg Byrd (NCSU)--for first part only
  3. Andy Hodgkinson (Novell)
  4. David Kuehr-Mclaren (IBM)
  5. Mike McIntosh (IBM)
  6. Tony Nadalin (IBM)
  7. Nataraj Nagaratnum (IBM)
  8. Mary Ruddy (SocialPhysics)
  9. David Recordon (VeriSign) Monday EOD to Tuesday EOD only
  10. Drummond Reed (Cordance)
  11. Jim Sermersheim (Novell)
  12. Paul Trevithick (SocialPhysics)
  13. Abhi Shelat (IBM)
  14. Jim Yang (Identyx)

Draft Agenda

(Hopefully we have the order right now.)

  • Architecture/Design sessions: April 30th 1pm - May 2nd noon
  • Development Discussions: May 2nd noon - May3rd noon

MONDAY (April 30th) 1pm

1pm: STS 60 min [MikeM] [Brian and Paula to participate by phone]

  • Recent Refactoring [MikeM]
    • Bindings
    • Extension Points
    • Deployments
  • higgins.eclipse.org status[MikeM]

New Package Hierarchy (org.eclipse.higgins.sts)

  • api (most depend on this one)
  • xmlsecurity-apache
  • common
  • server
    • token
      • username
      • ALF
      • SAML
      • identity
      • encrypt
    • mapper
      • appliesTo
      • default
    • trust
    • metadata
    • profile
  • client
  • binding
    • common
    • axis1x
    • servlet
      • metadata
      • profile

New *.api package

  • new packages org.eclipse.higgins.sts.api.* --this is where all the interfaces live.
    • org.eclipse.higgins.sts.api.client
    • org.eclipse.higgins.sts.api.server
  • new interface IInformationCard (extends ITokenCard and ICard)
    • this interface is temporarily here, it will move to and be harmonized with org.eclipse.higgins.icard
  • org.eclipse.higgins.sts.client
    • this is a reference impl of org.eclipse.higgins.sts.api.client
    • can create an STS request. this is where I was forced to create IInformationCard
    • this package is primarily for use by i-card selectors
    • Mike has org.eclipse.sts.binding.axis1x
      • TestManage.java does everything necessary to connect to an STS, (e.g. create request, handle response)

Misc

  • TestManaged.java and TestPersonal.java will use the reference impl packages to illustrate the process and use of APIs
  • Mike is trying to move IdAS dependency into
    • token.identity package
    • profile servlet package
  • Daniel: what are your ideas about documentation
  • Mike: This is important. I forgot to mention something. What I'm thinking that there will be deployment-dependent WAR files. We currently have all these flexible deployment scenarios, but for sample deployments it would be nice if we could create, for example, a "personal STS deployment."
  • Daniel: what folks run into: the fact that we need strong encryption JAR files, is an example of all of these little things that folks run into
  • Mike: we need to come up with documentation for different audiences
  • for developers
  • for people who are deploying it
  • Daniel: I have some raw material on "deploying an IdP"
  • Mike: Paula has also made a stab at it; Brian has contributed a lot to this. I'd like to find the time and/or tech writer resource to get this right.
  • Daniel: if we at least have the doc on all the pieces that are explorable.
  • Mike: yes, as soon as the code settles down I'll get more into this.
  • Mike: there may be a couple more extension points (e.g FIPS-compliant crypto impl), and there are a few more. We might want to add audit to our discussions this week. At least an extension point that could emit audit records
  • Raj: this approach of separating interfaces into *.api is good for other Components
  • Raj: essentially proposes org.eclipse.higgins.api.sts (instead of org.eclipse.higgins.sts.api)

2:45pm Higgins RP Support [60 min] [Jeff B] (Brian, Uppili to participate by phone)

  • What is the near term (Higgins 1.0) scope of this area?
  • Chuck has offered code, but he's wondering who will take care of it
  • RP Component Design proposal [MikeM]
    • Policy Generation/Publication
      • e.g. CardSpace Object Tag Generation
    • Protocol
      • e.g. OpenId, WS-Federation, SAML Redirection
    • Token Consumption
      • e.g. CardSpace Token Decrypt, Verify, and Validate
  • JeffB: The motivation for this came out of work at CA to work with CardSpace
  • Examples of capabilities:
    • token dissasembly
    • dynamic generation of the <object> tag
    • mechanism for the storage and retrieval of the certificates (the private keys required for the dissassembly)
  • Tony, so what you're saying:
    • Enable the RP with policy (building
    • Signature validation of the signature
  • Mike: I'd like to be able to build a component that would be support CardSpace, OpenId and "foo" --any protocol. We'd set properties on this Component to say what protocols you want it to support. It would generate the content embedded with the page that comes to the user. The user does something and redirects and gets back to some piece of code that handles the response. The model for the Component to sort of support all of that.
  • Jeff: I'm interested in putting in work for this
  • Jeff: what do we mean by validating claims
  • Mike: Examples of claim validation the RP might want through some parameters on the component:
    • if "now" is in the validity the token
    • if the claims required are present
  • Jeff: Apache just came out with a CardSpace module. There's an opportunity for us to contribute.
  • Paul: language support?
  • Jeff: I think we need to support a number of different languages
  • Jeff: This is a missing piece of the Higgins architecture
  • Jim: how many crossover points with Pamela project?
  • Paul: okay, so the consensus is that Jeff will work with Mike and Brian to work on scoping this project.

Demos and Interop Planning Uppili to participate (1 hour)

  • Collaborative session to review and update the rows in the OSIS "Identity Agent" chart
  • Discussion of interop
  • IIW: pre-work
  • Burton: interop demos

TUESDAY

7:30am: Continental Breakfast

8:30am: HBX [60 minutes] [Abhi, Paul]

  • Abhi: Demo of IBM Z-HBX with identity mixer and CardSpace support
  • Paul: HBX startup wizard
    • Authentication to hosted Higgins (IdA) service
      • using i-name/OpenID or using URL+email
      • choosing passphrase
      • seeding with i-name/OpenID or URL
  • r-card HTML <object type="application/r-card">
    • p.requiredClaims = list of claim URIs [like CardSpace]
    • p.providedClaims = list of claim URIs
    • p.tokenType = <tokenType> [like CardSpace]
    • p.encryptionMethod = <encryptionMethod>
    • p.useRCard = True
    • p.relyingParty = <DN of RP>
    • p.rCardImage = <cardImage> [CardSpace image spex]
    • p.rCardRPURL = <feedURL>
    • p.rCardProtocol = XDI or RSS+SSE or Atom or OpenID-AX
  • RP security policy expression language
    • where does it stand; can we augment it per r-card?
  • Multiple HBX versions to support H1, H2, H3, H4?
  • Relationship to Kevin Miller's Perpetual Motion code
  • Security: MITM attacks--do we need to add some native code/PKI/etc.?

10:20am: ISS UI, ISS, I-Card Registry [Andy] (40 minutes -to be continued)

  • Illustrate the architecture Novell has been putting together
    • All written in C and C++
    • Uses Kevin Miller's Perpetual Motion Firefox plug-in (XPCOM) to launch ISS Client UI
    • ISS Client UI (written in GTK))
    • ISS talks XML_RPC to ICardRegistry
    • ICardRegistry allows for pluggable ICardStoreProviders
    • Multiple card stores allow for portability of cards
      • Motivation: local cardstore at home and another on an FTP "card provider" server
      • Preserve the card data as it came to N-i-card registry
      • Some auditing stuff should stay with the card
      • One cardstore at a time
      • Can import cards from CardSpace (also can specify the claims manually)
      • Implemented own signing
      • Two deployment approach:
        • ISS Client UI always runs locally and is a client to
        • issd (analogous to H RPPS) listening on/off the box (uses XML RPC)
    • Andy suggested that auditing information should live with the cards (there had been a thread that this information should live with the i-card registry)
    • Andy <please fill in here> the flow related to how the secret store is used
  • Talk about what has been implemented
  • Discuss convergence at the conceptual/architectural level
    • Comparison to Parity Ukraine versions of i-card registry, i-card providers
  • Discuss protocol-level interoperability
  • ICard Interfaces
  • Dependencies
    • GTK --UI support lib
    • openSSL --used for the X509 certs, RSA key gen and SHA2
    • liveXML and XMLsec will go away
  • Have checked in a snapshot of the code into Higgins
  • We should align the C++ client library with Mike's java client library
  • Need to align the C++ i-card interfaces with the Higgins interfaces
  • Notion of PersistentCard (id and value)
  • i-card registry has management methods
  • card store mirrors these methods (implemented by a store provider)
    • implement a particular kind of card store (CASA, filesystem)

11am: OpenID [Paul, Duane, David Recordon] (Uppili, Duane, Tom to call-in.)

  • Various ways to integrate OpenID
  • OpenID thru managed card (the username is overloaded with the OpenID URI)
      • flow: managed card request to STS
        • STS ask IdAS "OpenID" CP
          • This CP uses mapping to map either SREG attributes or new AX
          • CP provides read-access to an OP
      • CP acts both as an OpenID RP and as an OpenID user's browser
    • STS Protocol adaptation
    • URICard / OpenID
    • Token Extension
    • HBX doing openID auth
  • Standardized OpenID Claim URIs [David]
    • Mike: it would be easy to extend the MSFT managed card a bit. (e.g. some fragment of the CardId URI was the OpenId)
    • Mike: the protocol between IdA and TS is WS-Trust.
    • David: I'd like to define a Claim URI (in CardSpace displaying it as an OpenID)
    • Tony: WS-Federation now allows claim URI values in the claims (e.g. enum values). The dialect constrains where the Claim types might be. Claim Types are per dialect.
    • Tony: OpenID could define a dialect here.
    • Drummond: so the same Claim URI could be used in different dialects

1:00pm: [75 min] Dial into Burton Group interoperability call during lunch break

2:00pm: IdAS Registry [Paul, Jim, Drummond]

  • Review IdAS Registries Proposal 2B
  • Implementation of the IdAS Registry itself
  • Implementation of the IdAS/CP configuration API
    • We want a standardized API for IdAS CP configuration

3:00pm: IdAS API and Data Model [Jim] (Tom to call in)

  • Update operations, a summary
    • Folks wanted to be able to walk to the node and make updates. The problem is that some CPs don't allow this. We needed to allow the CP to batch a set of updates to the backing store. Went through detour of proposals that included transactions, and got back out of that. Jim distilled IdAS Update Proposals. Result: as you go through the values on attributes of DSes and when they are done, at the IDigitalSubject level we have an applyUpdates method to "make it so".
    • Jim: I think the noise has gone down and people seem happy with it.
    • This has spawned a number of side conversations about the Higgins Data Model

3:30pm: Use Cases [90 min] [David Kuehr-Mclaren]

  • Review new detailed use cases - identify gaps if any, and discussed possible API enhancements

6:00pm: Dinner sponsored by IBM

WEDNESDAY

8:30am IdAS API and Data Model continued [Jim]

  • Review/Discuss - Data model - IdAS, metadata, value - discussions (1 hour)
  • IdAS APIs and SPIs - should we look at separating those? (30 mins)
  • Moving to a JAAS or JAAS-like model for AuthN materials passed to IContext.open (30 mins)
  • Transactions
  • Authorization
    • example use case: the i-card manager relies on the "source" metadata to know who can edit an attribute
  • Model-changing APIs (e.g. add/rm attribute types)
  • Shallow vs. Deep API methods --currently all methods are shallow (i.e it is the responsibility of the IdAS client to follow SubjectRelationship links)

IdAS Service Descriptions

  • IdAS refactoring for service descriptions (1.5 hour)
    • Refactor or add a layer on top which exposes IdAS in a service-friendly way?

Higgins Data Model (HOWL POV) [Paul] [10 min]

  • Proposed change of "higgins:Attribute" to "higgins:ValueAndMetadata"
  • Two parallel ways of handling Complex attribute values

IPR [30 min] [Mary]

  • Update and risk management discussion
  • What code should be in Higgins

RCP enablement

  • Integration
    • OSGi Components
    • ISS
    • STS

LUNCH

1pm: Elbow-to-Elbow Integration / Development Discussions Begins

  • Half day or full day of working session time so that people can work F2F on their various ongoing projects.

Junit testing

Nightly Builds

  • Branching?
  • "incubation-" label needs to be done by 5/7.

THURSDAY (morning only)

8:30am: Elbow-to-Elbow Integration / Development Discussions (Continued)

Packaging

  • Deployments for M0.8
  • Support for multiple versions of components, should the Token Service be offered as an OSGI version also?

See Also

Back to the top