This weekend an online virtual IndieWebCamp took place. One of the topics discussed and worked upon has my strong interest: making it possible to authorise selective access to posts.

Imagine me writing here about my intended travel. This I would want to share with my network, but not necessarily announce publicly until after the fact. Similarly, let’s say I want some of those reading here to get an update about our little one, then I’d want to be able to indicate who can have access to that posting.

In a platform like FB, and previously on Google plus with its circles, you can select audiences for specific postings. Especially the circles in Google allowed fine grained control. On my blog it is much less obvious how to do that. Yet, there are IndieWeb components that would allow this. For instance IndieAuth already allows you to log-in to this website and other platforms using your own URL (much like Facebook’s login can be used on multiple sites, although you really don’t want to do that as it lets FB track you across other sites you use). However, for reading individual postings that have restricted access, it would require an action made by a human (accepting the authorisation request), which makes it impractical. Enter AutoAuth, based on IndieAuth, that allows your site to log-in to mine without human intervention.

Martijn van de Ven and Sven Knebel worked on this, as sketched out in the graph below.

Selective access to content inside a posting
Now, once this is working, I’d like to take it one step further still. The above still assumes I have postings for all and postings for some, and that implies writing entire postings with a specific audience in mind. More often I find I am deliberately vague on some details in my public postings, even though I know some of my network reading here can be trusted with the specifics. Like names, places, photos etc. In those instances writing another posting with that detailed info for restricted access does not make much sense. I’d want to be able to restrict access to specific sentences, paragraphs or details in an otherwise public posting.

This is akin to the way government document management systems are slowly being adapted, where specific parts in a document are protected by data protection laws, while the document itself is public by law. Currently balancing those two obligations means human intervention before sharing, but slowly systems are being adapted to knowing where in documents restricted access material is located. Ideally I want a way of marking up text in a posting like this so that it is only send out by the webserver when an authorisation like sketched above is available.

So that a posting like this is entirely possible:

“Today we went to the zoo with the < general access > little one < / general access > < friends only > our little one’s name < / friends only >

< general access > general IMAGE of zoo visit< / general access >
< friends only >
IMAGE with little one’s face< / friends only >

6 reactions on “Getting Authorised Access Posts on the #Indieweb

  1. I’m missing something here: I don’t understand the difference between “Ton lets me have an account on Zylstra.org that I can login to with IndieAuth and once I do that I can read ‘authenticated user only’ posts” and what you are describing. I read the AutoAuth page and it doesn’t clarify.

    Can you help?

    • Hi Peter,
      There’s 3 different scenario’s here, the way I understand it:
      You having a WP account on my blog: meaning I need to approve and maintain your account in my WP install. Would work for separate posts and separate feeds.
      You requesting access with IndieAuth: meaning you manually need to login each session using your own site’s credentials, and no account maintenance on my end. Would work for separate posts and feeds, and potentially for the same posts and feed on the same url as the public stuff.
      You requesting access with AutoAuth: meaning your machine can do the logging in and then fetch content and feed at the same url as public stuff, no manual approval needed, and no maintenance on my end. (it’s indieauth without human intervention)

  2. Thank you for the write-up Eddie! Yes, if you get it working, I most definitely want to test AutoAuth on my WP site. Looking to experiment with selective access to parts of my postings, and doing so for different audiences. As described here.

    Replied to IndieWebCamp Online 2019 by EddieHinkle

    … if I get it working and start creating private posts for people on the IndieWeb, it might encourage them to start adding AutoAuth to their projects as well!

  3. @Ton, I assume this means, then, that on your server side you maintain a list of Circles-like lists of IndieAuth IDs and what content-access-level each has?

    After that, reading your post again, and your comment, and staring at the flow diagram for awhile, it looks like AutoAuth is simply a way of handing out long-lasting tokens that allow access to restricted content.

    So, for example, if my RSS reader passes an AutoAuth token to your RSS endpoint, and you’ve set me up in the “Friends” circle, then I get RSS passed to me that includes content marked as “Friends-only” in your CMS.

    Without AutoAuth, I would have to authenticate to your website through my RSS reader every time the feed gets refreshed. Which would be annoying.

    Right?

  4. My friend Juliane created a /now page behind a password, which she shared with me and others. My friend Peter has a public one. I like the concept of the /now page containing “everything you would tell someone you haven’t met in a year to quickly catch up”. I do week notes which are somewhat similar in content yet different in intention, but trying to write a /now page I realised some of the most informative parts are intended for a smaller audience than the general public. Or I’d need to water the information value down to make it fit for general publication. Juliane’s solution helps. Ideally I’d have the same /now page for multiple audiences, with content shown, partly shown or not at all, depending on who’s reading.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.