Data Sharing Design Issues

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Overview

The Higgins Attribute Data Service 2.0 must be flexible and support multiple protocols and flows. Consideration must be given for the following:

• Pattern of Sharing:
  • Frequency: Immediately access to updates (online access to PDS) or periodic updates (daily, weekly, on demand data feeds).
  • Granularity: Access to data about a specific user or access to data for all participating users each time.
  • Change Notification: Immediate notification that a specific user's data has changed.
• Discovery:
  • Protocol: The protocol used to access the data (e.g. XDI, HTTP, FTP, etc.)
  • Endpoints: The endpoint(s) for access to the data for a specific user or a group of users.
  • Authentication: The type of authentication required to access the data at the endpoint(s).
• Data Mapping: Can the relying party consume and produce data represented in the Persona Data Model as Higgins XDI or does there need to be a translation to/from another representation?
• Trust: How is trust established between a Higgins PDS and a Relying Party (e.g. sharing X.509 certificates, passwords, etc.)
• Policy: What are the ground rules for what can be done with data exported from and imported into the Higgins PDS?
• Access Control: How does a user specify which data can be read/wrtten by which parties? (e.g. voter registration number with local council but not with merchants).

Data Representation

Client apps of the Attribute Data Service 2.0 will want to consume data from it using different formats and protocols. Many such formats/protocols exist. They fall into two main categories: open vs. closed schema. Closed schema representations (e.g. Portable Contacts, Activity Streams, etc.) can be optimized for clarity and conciseness but lack extensibility. Open schema representations (e.g. XDI and RDF Linked Data), while supporting any schema are often less readable by humans.

Since the Persona Data Model 2.0 will be evolving over time using an open schema representation allows us to rapidly evolve the model without having to make as many changes to PDS-based code. When using closed schema representations the low level code (parsers, generators, etc.) don't have to change at all when new attributes, classes and structures are introduced.

With open schema representations a distinction can be made between the low level structure and the specific schema being used. For example two RDF files may use different vocabularies for representing the same data. By default when exposing PDS data using an open schema representation we directly use (without mapping) the attribute names and structure defined in the PDM. However, a given relying party may with to use their own schema and a conversion between that schema and the PDM may be necessary. If so, the PDS includes functions for conversion (aka mapping) between schemas that can likely be used to convert to and from any relying party-specific schema if necessary.

Data Exchange Patterns

The following sections describe at a high level, different models for exchanging user attributes with a relying party or data provider using the Higgins PDS:

1. Simple Form Filling / Screen Scraping. A standard web based form is filled in by the user. The relying party designed the form to be filled manually. With Higgins 2.0, a browser extension can be used to fill the form with attributes from the user's PDS and to store values scraped from the form into the PDS. The browser extension injects javascript into the page that calls Higgins APIs implemented in the PDS Client. Calls to getAttributeEx are used to retreive attribute values from the PDS and calls to setAttributeEx are used to store attribute values into the PDS. The first time getAttributeEx and/or setAttributeEx are called for a specific web form, the Azigo 3 selector is activated asking for the user to consent to this and future data exchanges. These attributes are stored into and retrieved from a context specific to the domain of the form. This data is also available from the user's persona and can be used to privde data to other relying parties. A nice characteristic of this model is that the relying party does not need to do anything beyond providing a standard web form for this to work. The biggest problems are the need for the user to visit the replying party web page each time data is to be updated and the need for mapping rules between the relying party form vocabulary and the Higgins Persona Data Model.

2. Metadata Driven Form Filling. A web based form is filled in by the user's selector. The relying party embeds metadata indicating to the relying party how to exchange the data. This can be done is a number of ways:

• A. Relying Party Directed Form Filling / Screen Scraping. Identical to Simple Form Filling / Screen Scraping except the relying party embeds the javascript with calls to getAttributeEx and/or setAttributeEx into the web form.

• B. Standard IMI Form. The relying party embed metadata (e.g. an OBJECT tag) onto the page that activates the Higgins 2.0 Selector. The resulting interaction concludes with a security token posted to the form.

3. Relying Party Driven Exchange. The relying party accesses the user's PDS to get and set attributes when desired. The Higgins 2.0 PDS uses a Universal Data Identifier (UDI) to reference a context which can be accesses via XDI. Bootstraping this process requires the user to add the relying party to the ACL for the context and provide the relying party with the UDI. Providing the UDI to the relying party may be done in conjunction with one of the form based approaches described above (e.g. a hidden field or a special purprose attribute in a token). The relying party must obtain an OAuth token in order to access the UDI. The additional processes involved in change notification are described HERE.

4. Peer to Peer Exchange. The user shares a UDI for a context with another user. The users' PDSs exchange the attributes on behalf of the users. This scenario is very similar to that between a user and a relying party, with the exception that identifying the user may be a challenge. The details of this scenario are TBD.