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.
Difference between revisions of "11.16.2006 F2F Outcomes"
(→Conclusions, decisions, etc.) |
(→More conclusions) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | ===More conclusions=== | ||
| + | * IdAS: On the issue of the java object/DigitalIdentity parameter to IContext.open(): We reiterated our earlier design: we will add an IContext.getOpenPolicy() method that will (in the long run) return a description of this Context's authentication policy expressed in our emerging (and badly named) "RP Security Policy" format. The policy will indicate the range of acceptable DIs that can be passed to IContext.open(). | ||
| + | * IdAS: the proposal to add transaction support methods like as begin(), commit() and rollback()) to IContext was discussed. Decisions reached: | ||
| + | ** We should not add any of these methods because implementing them in ALL Context Provider implementations is, for some kinds of contexts, somewhere between extremely difficult and impossible. | ||
| + | ** It was proposed and agreed that all IdAS method calls should be considered atomic (succeeded or threw an exception (no other outcomes)). This was as far as we should go. This was a necessary condition for potential future support for transactions. | ||
| + | * ISS Web/Client UI design principles | ||
| + | *# we will try to make the user experience as similar to MS CardSpace as possible | ||
| + | *# except where we have usability test data that proves we have an improvement | ||
| + | *#* E.g. a button in browser toolbar that redirects the browser to the current user's I-Card Manager | ||
| + | *# except where we are required to innovate (e.g. Idemix's requirement to (sometimes) select multiple cards, not just one) | ||
| + | *# except where we are absolutely convinced that we have an improvement (that we'll later verify for usability). This last, squishy category currently includes the following hypotheses: | ||
| + | *#* The need in the browser to display some kind of identifier of the current user (in some households multiple people share the same OS account, so we need to show which person is the "active" Higgins user) | ||
| + | *#* The need in the browser to display the current card(s) (if any) being used in the current interaction (e.g. need to remind the user what personal information about themselves is being shared/exposed) | ||
| + | |||
===Conclusions, decisions, etc.=== | ===Conclusions, decisions, etc.=== | ||
| − | * | + | * We coordinated work for the demo of Higgins and Bandit components working together for IIW 2006 (Dec 4) |
* Progress was made on Idas Registry design & requirements | * Progress was made on Idas Registry design & requirements | ||
** rename current IContextFactory.create() -> .attach() | ** rename current IContextFactory.create() -> .attach() | ||
| Line 8: | Line 22: | ||
** registry now has bind operator to bind ContextRef to Context | ** registry now has bind operator to bind ContextRef to Context | ||
** Greg (and others) will continue design work | ** Greg (and others) will continue design work | ||
| + | ** Agreed to leave the registry as not a singleton (for now) | ||
* Reviewed, corrected, updated [[I-Card]] (updated) | * Reviewed, corrected, updated [[I-Card]] (updated) | ||
| Line 23: | Line 38: | ||
** the "cross-card" nature of Idemix will necessitate changes | ** the "cross-card" nature of Idemix will necessitate changes | ||
*** the user picks N>1 card in the card picker UI | *** the user picks N>1 card in the card picker UI | ||
| − | *** introduces changes & complexity to | + | *** introduces changes & complexity to [[RP Protocol Support]] and [[I-Card Selector Service]] |
| − | + | *** ...in addition to new components: Idemix [[Token Provider]] and Idemix [[I-Card Provider]] | |
| − | + | ||
| − | *** ...in addition to new components: | + | |
| − | + | ||
| − | + | ||
** IBM Zurich to propose new I-Card interface | ** IBM Zurich to propose new I-Card interface | ||
*** variant of TokenIssuerCard Interface | *** variant of TokenIssuerCard Interface | ||
| Line 42: | Line 53: | ||
* Reviewed and updated [[Deployments]] (updated) | * Reviewed and updated [[Deployments]] (updated) | ||
** agreed to have this page describes only what has actually been tested and is officially supported by the project | ** agreed to have this page describes only what has actually been tested and is officially supported by the project | ||
| − | ** | + | ** Tom Doman agreed to temporarily be the "owner" of the CardSpace Managed Card Provider Deployment Scenario |
| + | |||
| + | * Misc | ||
| + | ** Agreement that the first 1/2 hour of each weekly dev call would be items of general interest, but the second 1/2 hour would be dedicated to one of these specific areas of Higgins: | ||
| + | **# [[Identity Attribute Service]] and [[Context Provider]]s | ||
| + | **# [[Token Service]] | ||
| + | **# [[I-Card]]s, [[I-Card Registry]], [[I-Card Provider]]s, [[ISS Web UI]] | ||
Latest revision as of 11:15, 22 November 2006
More conclusions
- IdAS: On the issue of the java object/DigitalIdentity parameter to IContext.open(): We reiterated our earlier design: we will add an IContext.getOpenPolicy() method that will (in the long run) return a description of this Context's authentication policy expressed in our emerging (and badly named) "RP Security Policy" format. The policy will indicate the range of acceptable DIs that can be passed to IContext.open().
- IdAS: the proposal to add transaction support methods like as begin(), commit() and rollback()) to IContext was discussed. Decisions reached:
- We should not add any of these methods because implementing them in ALL Context Provider implementations is, for some kinds of contexts, somewhere between extremely difficult and impossible.
- It was proposed and agreed that all IdAS method calls should be considered atomic (succeeded or threw an exception (no other outcomes)). This was as far as we should go. This was a necessary condition for potential future support for transactions.
- ISS Web/Client UI design principles
- we will try to make the user experience as similar to MS CardSpace as possible
- except where we have usability test data that proves we have an improvement
- E.g. a button in browser toolbar that redirects the browser to the current user's I-Card Manager
- except where we are required to innovate (e.g. Idemix's requirement to (sometimes) select multiple cards, not just one)
- except where we are absolutely convinced that we have an improvement (that we'll later verify for usability). This last, squishy category currently includes the following hypotheses:
- The need in the browser to display some kind of identifier of the current user (in some households multiple people share the same OS account, so we need to show which person is the "active" Higgins user)
- The need in the browser to display the current card(s) (if any) being used in the current interaction (e.g. need to remind the user what personal information about themselves is being shared/exposed)
Conclusions, decisions, etc.
- We coordinated work for the demo of Higgins and Bandit components working together for IIW 2006 (Dec 4)
- Progress was made on Idas Registry design & requirements
- rename current IContextFactory.create() -> .attach()
- add a new IContextFactory.create (that just creates)
- agreed to adding IContext.configure() and IContextFactory.configure()
- registry now has state and manages context configuration
- registry now has bind operator to bind ContextRef to Context
- Greg (and others) will continue design work
- Agreed to leave the registry as not a singleton (for now)
- Reviewed, corrected, updated I-Card (updated)
- Reviewed and updated Architecture (updated)
- settled on using "in broswer" ISS Web UI
- made related changes to architecture diagram
- Reviewed Components
- emphasis on component "owners" and responsibilities
- discussed importance of component owners early & often updating the "Requires" column for their row
- Discussed Idemix integration
- outcome: Abhi now understands better how to do the idemix integration
- the "cross-card" nature of Idemix will necessitate changes
- the user picks N>1 card in the card picker UI
- introduces changes & complexity to RP Protocol Support and I-Card Selector Service
- ...in addition to new components: Idemix Token Provider and Idemix I-Card Provider
- IBM Zurich to propose new I-Card interface
- variant of TokenIssuerCard Interface
- IBM Zurich to continue work on RP Security Policy
- but with an understanding of the larger I-Card requirements
- e.g. I-Cards with complex attribute types
- but with an understanding of the larger I-Card requirements
- Reversed our earlier decision about Java 5
- Context Providers, Token Providers, etc. (plug-ins) may use Java 5
- Higgins core and interfaces must only require Java 1.4.2
- Agreed to document this here Developer Resources
- Reviewed and updated Deployments (updated)
- agreed to have this page describes only what has actually been tested and is officially supported by the project
- Tom Doman agreed to temporarily be the "owner" of the CardSpace Managed Card Provider Deployment Scenario
- Misc
- Agreement that the first 1/2 hour of each weekly dev call would be items of general interest, but the second 1/2 hour would be dedicated to one of these specific areas of Higgins: