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.
Attribute Data Service 1.1
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
The Attribute Data Service 1.1 (ADS) is the umbrella name for the following web services each of which offers a different kind of access to the same data:
- IdAS Proxy Service and its supporting Attribute Service
- A new REST API under development
- A new HGraph API - under development
Contents
IdAS Proxy Service
The IdAS Proxy Service 1.1 is layered over the Attribute Service 2.0 to provide a bi-directional, synchronizing XDI endpoint over data managed by Context Provider plug-ins to the IdAS package. These context providers area also data adapters to a variety of back end data stores.
The Attribute Data Service 1.1 uses a variant of the IdAS Proxy Service, with the following changes:
- The UDI Resolver is configured to support sync:// UDIs
- The IdAS Registry is configured to include the org.eclipse.higgins.idas.cp.rdf2 context provider.
You send XDI messages to the proxy service endpoint using one of the following client libraries:
- Org.eclipse.higgins.idas.client (Java IdAS Client)
- Org.eclipse.higgins.idasclient.cpp.core (C++ IdAS Client)
Example XDI message
- ADS XDI Example - generated by the Org.eclipse.higgins.idasclient.cpp.core PDS Client. It shows an example of some user information encoded in the Higgins flavor of XDI. The user has both a "billing" and a "receiving " (shipping) address, name, organization, etc.
Complex attribute values
The XDI above contains a repeated idiom for representing complex attributes (object-valued predicates) that is far more verbose than required. Every section represented like this:
<xdi:xdi> <xdi:s xri="$value$hash$sha$256!f68f4bb3513a89c6ea41b6eeffe6af0ea2a7d2f3f172b72bf26ecb29d9713020"> <xdi:p xri="$value"> <xdi:data><![CDATA[urn:efa25e71-5b6f-4844-b139-4ed26dd1c3e5]]></xdi:data> </xdi:p> </xdi:s> </xdi:xdi>
Should be written like this:
<xdi:ref xri="=(urn:efa25e71-5b6f-4844-b139-4ed26dd1c3e5)"/>Single literal values
Similarly, since in every case above there is only a single value for a literal, every section that looks like this:
<xdi:p xri="+(http://www.w3.org/2006/vcard/ns#postal-code)"> <xdi:xdi> <xdi:s xri="$value$hash$sha$256!0a38e8a3c328b1616ac3c34720d0ceb578bd3f5e8bfff9841bb0804dd4d2b5eb"> <xdi:p xri="$value"> <xdi:data><![CDATA[55555-1234]]></xdi:data> </xdi:p> </xdi:s> </xdi:xdi> </xdi:p>
Should look like this:
<xdi:p xri="+(http://www.w3.org/2006/vcard/ns#postal-code)"> <xdi:data><![CDATA[55555-1234]]></xdi:data> </xdi:p>
UDIs not URNs
EntityIDs are supposed to be resource UDIs not urns. So after we correct that error in our XDI then the entityIDs will look (internally) like:
=mydex.org*alice/($context)*(+home+and+family)//Entity_12345
Where
- =mydex.org is the name of the PDS operator
- alice is the community name assigned to alice by Mydex
- $context indicates that we're looking for a "context" service endpoint in the XRDS
- +home+and+family is the id of the context
- Entity_12345 is the entityID within +home+and+family
Which as an XRI 2.0 in URI form would be:
http://xri.net/=mydex.org*alice/($context)*(+home+and+family)//Entity_12345
Or for external (e.g. as sent to an RP) non-correlation purposes...
http://xri.net/=mydex*!F83.62B1.44F.2813/($context)*(+home+and+family)//=!2C75.AC49.21D3.1207
Where
- !F83.62B1.44F.2813 is an i-number (randomly generated per-RP pseudonym) that is associated with alice
- !2C75.AC49.21D3.1207 is an i-number (randomly generated per-RP pseudonym) that is associated with =alice
Implementation note:
- The active client (and other server-side code) must attempt to resolve every absolute UDI. Since this is very expensive, if must cache the results of the resolution by associating the resolved URI (or nil) with the UDI. Not sure yet how to define "stale" in the cache. The need for this cache is obvious. MikeM mentioned to PaulT a few weeks ago that even this might not be enough of a boost to performance. MikeM suggested that we might have to define physically co-resident "context sets" (sets of contexts) and include a set identifier in the UDI. This has NOT been mentioned above since doing so would fundamentally break the principle that a user can "move" (physically relocate) an individual context to their choice of PDS operator at any time.
Other Improvements
- Should we be using the JSON serialization of XDI instead of the XML serialization?
- It would be nice if XDI had a convention for URI shortening based on a default namespace. That if relative entityIDs were used (e.g. "#245") we wouldn't have to have these long entityIDs like this one used below: "urn:efa25e71-5b6f-4844-b139-4ed26dd1c3e5".
- In addition to a default (per document) namespace, if arbitrary namespace definitions were allowed then instead of "http://www.w3.org/2006/vcard/ns#n" we could say "vcard:n" (where vcard="http://www.w3.org/2006/vcard/ns#")
- The following XDI exposes data that is not quite (though very close) compatible with the latest Persona Data Model 2.0 documentation. For example we no longer use "p:billing"
- The above example could be significantly shortened if it only described a single address (the second address doesn't have any illustrative value).
For reference here is an RDF/N3 representation of a single person (Person_1) and their address, name and telephone number. Some "cheating" is going on here: entityIDs have been hand crafted to be pretty (e.g. :Address_1 vs. :efa25e71-5b6f-4844-b139-4ed26dd1c3e5):
:Person_1
rdf:type p:Person ;
p:role p:Buyer ;
vcard:adr :Address_1 ;
vcard:n :Name_1 ;
vcard:tel Voice_1 .
:Address_1
rdf:type vcard:Address ;
vcard:extended-address
"Suite 1000"^^xsd:string ;
vcard:locality "Peoria"^^xsd:string ;
vcard:postal-code "61604"^^xsd:string ;
vcard:region "IL"^^xsd:string ;
vcard:street-address
"123 S Main Street"^^xsd:string .
:Name_1
rdf:type vcard:Name ;
rdfs:label "Name_1"^^xsd:string ;
vcard:family-name "Jones"^^xsd:string ;
vcard:given-name "Alice"^^xsd:string .
:Voice_1
rdf:type vcard:Voice ;
rdf:value "tel:+358-555-1234567"REST API
Data Access
- See ADS 2.0 REST API
The ADS 2.0 REST API is an alternative to the IdAS Proxy Service 2.0 that allows a Relying Party to access the current data for all users that have opted into sharing their personal data with that Relying Party (as a single data stream/file) via a Context UDI or the latest data for each user through separate entityIds (aka Resource UDIs).
The endpoints publishing this data will be protected via an authorization/access control mechanism; two proposed alternatives are OAuth 2.0 and a simple API key shared secret (though other alternatives could be supported). Endpoints will also be needed for Relying Parties to publish their version of a user's personal data for integration with that user's persona on the ADS Operator's system. In order to reduce the administrative overhead, and avoid complexity in the user interface, the ADS Operator's system and the Relying Party will each have a credential for accessing each other's endpoint (each user will not need a separate credential).
Data Updates
In a peer to peer data sharing arrangement between two users in social networking scenarios, there is a requirement for real time notification of updates to shared data. In a C2B or B2C scenario, the requirement is more commonly for access to the current data when it is needed. We propose to use Activity Streams to track the time of changes to user's data. This will allow each Relying Party (and PDS Operator) to always find the time of the last change to the data for each user. An example of an entry for an update notification follows:
<entry> <id>tag:pdsoperator.org,2010:/activity/4859568/AddressUpdate/2519358/2009171</id> <title type="text">Michael Mcintosh address update.</title> <published>2010-06-21T00:28:35Z</published> <author> <name>Michael McIntosh</name> <uri>http://pdsoperator.org/mmcintosh</uri> <id>tag:pdsoperator.org,2010:/Person/4859568</id> <activity:object-type> http://www.eclipse.org/higgins/ontologies/2009/4/persona.owl </activity:object-type> <link rel="alternate" type="text/html" href="http://pdsoperator.org/mmcintosh" /> </author> <link rel="alternate" type="text/html" href="http://pdsoperator.org/mmcintosh/activities/1234" /> <content type="xhtml">...</content> <activity:target> <activity:object-type> http://www.eclipse.org/higgins/ontologies/2009/4/persona.owl</activity:object-type> <id>tag:pdsoperator.org,2010:/Personas/2519358</id> <title>RP Personal Data</title> <link rel="alternate" type="text/html" href="/mmcintosh/rp/persona" /> </activity:target> <activity:object> <activity:object-type> http://www.eclipse.org/higgins/ontologies/2009/4/persona.owl</activity:object-type> <id>tag:pdsoperator.org,2010:/AddressUpdate/2519358/60764840</id> <title>My New Address</title> <link rel="alternate" type="text/html" href="/mmcintosh/address/1643" /> </activity:object> </entry>
Change Notification
At first there is an expectation that data updates will require notification, though perhaps not as real time as is needed in a typical social networking application. We expect to use PSHB for notification when a user's personal data has been changed. Any relying party that requires notification can subscribe and will receive notifications when data has been updated.
Data Provenance
There are several approaches to data provenance we are considering, each with its own benefits and drawbacks
- One approach would be for the provider of a user's personal data to by convention only include verified attributes. This is simple yet does not allow a provider to include a user's self asserted data nor does it allow a consumer to differentiate between attributes verified by different authorities.
- Another approach would be for the data provider/authority to sign the user's data. This would provide the ability for the consumer to verify the data origin but would require the user to share all of the verified data when sharing only a subset would otherwise be necessary.
- A third approach would the PDS operator to augment a user's data with a set of statements that indicate the origin of the data. This would allow the consumer to know which data was verified by which authority, but will require the consumer trust the PDS operator to provide the correct provenance. We propose to use this approach. Details on data model extensions to be determined.
Reference
Social Web Acid Test - Level 0, is a description of a use case for the Federated Social Web. A Strawman Protocol Flow has been specified (in early draft form) which provides a solution composed of Atom Activity Streams, PSHB, WebFinger, and Salmon. The solution described above is based in large part on this specification.