Data Sharing Design Issues
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.
- 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).
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:
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:
- 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.