Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Beyond Higgins 1.0"
(→Identity Selector Selector) |
(→Web service endpoint) |
||
| Line 7: | Line 7: | ||
=== Web service endpoint=== | === Web service endpoint=== | ||
| − | As discussed in the previous Austin F2F in October 2007, the Higgins project has decided that an IdAS web service is in scope for the future of Higgins. Parity will be developing and contributing an XDI | + | As discussed in the previous Austin F2F in October 2007, the Higgins project has decided that an IdAS web service is in scope for the future of Higgins. Parity will be developing and contributing an XDI endpoint. |
=== Caching and Indexing === | === Caching and Indexing === | ||
Revision as of 15:36, 6 November 2007
This is a new page to for Higgins concepts that will be addressed beyond the initial release 1.0.
Note: we're just getting started filling in this page. The upcoming Jan 8-10 Provo F2F Agenda will be the first place where we start the design work and discussions around these topics.
Contents
Candidate layers above current IdAS API
This section describes several sets of functionality that could be layered over the current IdAS API.
Web service endpoint
As discussed in the previous Austin F2F in October 2007, the Higgins project has decided that an IdAS web service is in scope for the future of Higgins. Parity will be developing and contributing an XDI endpoint.
Caching and Indexing
To greatly enhance the performance of IdAS in situations where the underlying Context Providers do not support caching and indexing on their own, and especially those that maintain connections to remote data sources, an generic caching/indexing layer could be useful.
Deep Search and Access
Although the Higgins data model supports Subject Relations as first-class objects, IdAS in Higgins 1.0 treats them shallowly. For example, a search (e.g. using an IdAS Filter) treats Subject Relations no differently from other attributes. Many use-cases (esp. cross-contextual use cases) would expect that these links would be recursively traversed to N levels, with cycle detection, etc. and the attributes merged roughly analogous to inheritance.
Schema(ontology) mapping
A layer that maps from each source ontology to a specified target ontology. This layer could consume the existing IdAS API and support the this same API --performing the mapping as the value add between the two.
Authorization
A layer that acts as an authorization policy (e.g. XACML) enforcement point.
Identity Selector Selector
Requirements
- Allow user on any platform to configure what selector they would like to be their default
- Consistent UX on all platforms for setting/changing the default
- Consistent API from browsers and local apps
- Decouple browser <object> tag parsing from selector