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.
20071128 IGF teleconf notes
notes from 20071128 teleconf meeting.
On call:
Duane Buss
Jim Sermersheim
Phil Hunt
Tom Doman
- Talked about the way contexts are configured and discovered.
- It would be good if there was a more dynamic way than hand-writing XRDS documents
- Do a dynamic config/registry example (Jim will do)
- It would be good if there was a more dynamic way than hand-writing XRDS documents
- Need dynamic discovery of what can go into a configuration
- An IGF identity stack could consist of a stub that uses Apache license
- Can use Higgins or other stack to provide services to that stub
- Reviewed http://www.openliberty.org/wiki/index.php/IGF_Architecture#Servlet_Application
- From an application's POV, all data looks the same whether pushed (i.e. incoming token), or pulled (i.e. backend data source)
- Application Services stack could be used like a security provider and shared across different applications
- Talked about providers that can join other providers
- Phil is thinking everything from Caching & Optimization down from http://www.openliberty.org/wiki/uploads//0/0c/Arch-Servlet.gif could be done in Higgins.
- Tom: What does the Caching & Optimization layer do?
- Can analyze incoming operations (like CARML statements) and do things like prefetch (which may consist of multiple underlying operations) data and store it in mem.
- Routing layer can handle things that the existing IdAS registry does, but can also deal with mapping -- though maybe that should be done by a mapping provider?
- Jim: when are the CARML statements passed?
- There can be a CARML declaration passed at a preconfig time, can be sent as a separate file up front which can be reviewed by an auditor,
- Up front stuff can declare what the client app expects to do/see in terms of operations, schema, etc.
- Could also have CARML declarations associated with a transaction (like NewUserRegistration)
- There can be a CARML declaration passed at a preconfig time, can be sent as a separate file up front which can be reviewed by an auditor,
- AAPML data can be returned to express things like:
- Partial data was returned, and here's why
- Data exists, but consent is needed before it's released
- Talked about how IdAS can be extended to handle the passing of CARML and AAPML policy data
- Revive thread on API extensibility (Jim will do)
- Fix jspolicy cp so it will compile (Jim, Tom, or Duane will do)
