Hypothes.is is a peer-based global commenting and annotation system for documents and media. Open source distributed non-profit infrastructure.
Currently we have a commenting system, but it’s problematic: comments not enabled for all pages, additions at the discretion of site owner, located at bottom of the page (instead of in-context), also sometimes there are a lot of comments (thousands). Another problem: no permanence to the system; e.g., TechCrunch replaced Disqus with Facebook comments. Also channel may be limited to a region or country.
Why these efforts fail:
No reputation model… (long list, quick review)
Design criteria: works inline, community moderated reputation model, works everywhere, context-aware, pseudonymous, works across media types.
This is a good time, based on work being done in this community: Open Annotation Collaboration (using this standard with a reputation model).
Stance model: ability to support or challenge what’s being said by others, make an observation, offer link, ask question… Why annotation and stance? gauging credibility: ratings of meaningless qualities, gross characterizations, loss of fidelity. We can do better.
Hypothes.is has a Reputation Fellows Program, upcoming workshops to help think through some of the problems in reputation.
Diversity of interfaces: plug-ins, URL, wesite, API, links/reveals from pages.
Action flow: Highlight, Annotate, Submit. Heatmap along right edge, view annotations, moderate.
Lots of work to optimize all dimensions. Long list of advisors. Timeline puts them in alpha testing in first half of next year, beta testing later in the year.
There are different efforts + projects. As a consequence, there are also different local perspectives.
PDEC’s desire is not to build any concrete things (trust frameworks, technology, etc), but:
to coordinate existing efforts, and help finding each other
to follow, track and educate about existing efforts and different views
to facilitate dialogue between the actors
to support new startups/initiatives to realize the vision
to bring together sociologists, technologists, lawyers, etc. working on personal data
to include people who are new to the circle but doing related work
Some concrete topics during the session:
multi-jurisdiction issues
multi-disciplinary groups with interdisciplinary focus
defining the new business layer (not just legal layer)
common elements of a trust framework
technologists (want to push things forward?) + lawyers (want to push things back?) need to work together!
how do we represent individuals?
legal practice becomes law
role of regulation (managing risk)
look at existing regulator models for telecom + postal interop
what is institutionally required for certain services + systems
what can individuals do? where are groups + capital required and where are they not required?
relationsip of IdPs to each other and to nation-states who set policies
Kaliya presented the “Personal Data Ecosystem Landscape” diagram explaining the conceptual relationships between different parties in the Personal Data Ecosystem.
Doc: Sam and Craig work with Kynetx, the group behind evented APIs: a simple way to move events (something happening, like a state change: when the balance on your bank account changes, dryer cycle is done, etc.) from one system to another. A lot of “things” have an online component, like location change, phone ringing. Now we’re extending certain “events” (me interacting with something) from being captured in data silos to an interactive state (from an “interaction silo”–nothing else happens outside that locked system). Sid suggests visiting websequencediagram.com for a better visualization.
The data becomes a noun in an information flow. Evented APIs allow for verbs: reporting on a state change that can trigger some action. Drummond suggests it’s “Twitter for machines.” Kevin asked about activity streams, Sam: trying to open up the structure. Terry: this is an observer pattern. Sam: this should be trivially implementable in a micro-controller.
Are people polling your API? If so, they’re polling interaction data to get some interaction state.
Examples:
Public Radio Player + ListenLog + twilio + texting + twitter = escrowed indication to pay/donate. Accumulate context (donation tied to time/show on that station)
Phil’s example using TripIt, Foursquare and Expensify to coordinate expenses for his trip. (See the other Evented API session for a little more on how this works.)
I can use it to be more selectively active in passive activities – get notification of certain blogs that have new post with keyword, etc.
“Bring your core competence of your business into an API is an economic imperative.” -Craig Burton
One more (classic VRM) example: changing your address with the 10,000 sites you’ve ever done business with. What if you could change it once, say in your personal data store, then share it with people/organizations that you want to continue to do business with, ONCE, and the update is automatically distributed?
Also other predictive modeling, notification of events in different context (oil light comes on in a rental car – the company needs to know, not the renter), also 4th party brokering. Craig suggests emancify.org
General request for update on who’s doing what that’s compatible with Drupal.
Paul, Forge Rock, has done work with OpenSSO, OpenDS
Scotty, Stanford, uses two modules: weapon of mass destruction and a shibboleth module to deal with Drupal on campus and Drupal Gardens projects. Makes logins look like their webAuth, works with SAML 2.
Question about if drupal works with MongoDB: yes, Drupal 7 has a database module that does.
Question about presentation controls (UI) for graphic presentation of data: look to jquery for widgets and toolkits.
Isaac, Animate Login, described his drupal and android project to use QR codes on mobile phones to get away from password use.
Scotty briefly described his current mobile web project that resizes and reorients pages.
Of interest to a stealth brokering (authentication) project I’m working on, suggestions to look at these technologies:
Microblogging APIs (including PubSubHubub) for notification of consent
Data price for online services is too high. There’s provisioning data by hand or by value, problems of oversharing, lying.
Another problem: meaningless consent to unfavorable terms, messy and painful management, more oversharing.
Enables you to manage sharing (host: biographical, reputation including credit scores, location, etc.; other authorized users: share selectively, protect; other requesters) and protect access from a single hub (authorization manager).
UMA gives users a true digital footprint dashboard. Unified access control under one access manager. You can test for claims like “over 18″ or reuse policies with multiple hosts. Not good for serious security concerns though. You can keep rebuilding your “sharing circles.” Can’t advertise your content without giving it away, can’t get a global view of all sharing relationships.
UMA lets web apps easily offer “context, control, choice and respect.” You can provide sophisticated protection and sharing of any user content or data that isn’t meant to be public, can outsource the entire job to third party AMs, can ensure that protection of sensitive resources is stronger than the “Private URL” trick, build trust more readily with users who are “privacy fundamentalists, and can integrate these features using lightweight OAuth, JSON, HTTP, REST paradigms and a freely implementable protocol.
Glossary item: Access Control Lists (ACLs)
Demo of UMA in action with the SMART system. SMART: Student-Managed Access to Online Resources, a project at School of Computing Science, Newcastle University. They’yre planning to open-source its “UMA/j” implementation and contribute to Apache Amber. smartam.net and gallerifyme
UMA’s history with OAuth: they’ve kept up with emerging tech. UMA pliers are really just enhanced OAuth players. Think of Authorization Manager as “authz server,” think HOST as “resource server, and Authorizing User and “resource owner.” Much overlap between authz server and resource server. They standardized scope enough to make this interoperable.
UMA has 3 phases: 1. protect a resource, 2) get authorization, and 3) access a resource. The process depends on the authorizing user being present, even if as shared agent or power of attorney.
Phase 1: Alice introduces host and AM using OAugh (possibly dynamic registration). The host registers sets of resources to be protected and available scopes at AM host resource set registration endpoints. Alice ensures that AM knows her policies for sharing an item. (She can set policies out of band.) Scope URIs resolve to scope descriptions (can live anywhere). Host registers resource sets and maps to available scopes using RESTful API.
Glossary item: Scope = like the object and potential verbs. What’s possible to do with APIs and what happens in the access, permissions.
Between phases 1 and 2: an intermission. Requesting party learns about a resource (discovery, email, etc.), and knows how to use the API and scopes at the host (somehow).
Phase 2: Get Authorization. Requester attems to get resource but… token from AM requester token endpoint, permission for scope from AM authorization endpoint, likely claims to win permission. Host uses AM token status endpoint to check each attempt by requester, then Host uses AM permission registration endpoint to register the sought-after scope. This flow is a back-and-forth process for requesting access to something.
Language between requesting party and requester is really important. There’s a fair amount of redirection to facilitate the flow of tokens and claims.
Edge case: Alice to Alice sharing! (Sharing with herself.) She only needs to list herself in the policy.
Promises: can’t be made by software, must be made in person (self-asserted). UMA doesn’t discriminate against claims.
Next steps: they’ve submitted 2nd Internet Draft. More info at later session.
![[del.icio.us]](http://digitalidcoach.com/wp-content/plugins/bookmarkify/delicious.png)
![[Facebook]](http://digitalidcoach.com/wp-content/plugins/bookmarkify/facebook.png)
![[LinkedIn]](http://digitalidcoach.com/wp-content/plugins/bookmarkify/linkedin.png)
![[Ma.gnolia]](http://digitalidcoach.com/wp-content/plugins/bookmarkify/magnolia.png)
![[Technorati]](http://digitalidcoach.com/wp-content/plugins/bookmarkify/technorati.png)
![[Twitter]](http://digitalidcoach.com/wp-content/plugins/bookmarkify/twitter.png)
![[Email]](http://digitalidcoach.com/wp-content/plugins/bookmarkify/email.png)