## The authenticated Atom musings continue

Now that I’ve had a chance to think about this more than what was afforded by a quick response fired off between songs at a karaoke bar, I feel like expanding more on the details that I’d only implied (and probably badly) from the previous post. So, here’s how I think things could look.

For the purpose of this writeup I’ll use xx as a temporary placeholder XML namespace.

### Auth discovery

The feed would contain a <link rel="auth"> that points to the IndieAuth endpoint that validates the reader’s identity. This should, of course, support AutoAuth. (I assume that AutoAuth and IndieAuth can both be served from a single endpoint, incidentally.) Presumably the HTML renditions on the site would also include this <link> for the purpose of autodiscovery, so eventually browsers can get an extension to support AutoAuth so you never need to log in to IndieWeb sites manually.

If a feed declares this link, it is expected that supporting feed readers will fetch the feed individually per-user rather than trying to share it across all users (or will otherwise handle the fact that each user might have a different view of the feed).

Within the authenticated view, each item that is under an authentication wall should have metadata that indicates what the privacy settings are for the post. For example, there could be an <xx:privacy> tag with a rel attribute that gives a known name, and an optional text element that provides a human-readable message. If this tag exists it indicates which elements are allowed to be shared; by default, nothing is.

Possible examples:

<!-- never share anything about this item -->
<xx:privacy />

<!-- It's okay to spread the item's URN (in e.g. a favorites list) but nothing
else -->
<xx:privacy rel="id" />

<!-- Allow people to share that they liked a post and where to find it, but not
the content of the post -->

<!-- Just allow everything. Also this has a message associated with it. -->
<xx:privacy rel="*">This is a private entry but I'm okay with you reblogging it.</xx:privacy>


### Supporting WebSub and legacy readers

If someone is viewing the feed without any authorization at all, the feed should include one or more of the most recent unauthorized entries with the minimal set of metadata to indicate their existence, and with a tag indicating there’s more behind an authorization wall (and possibly a human-readable message in the <content>). For example:

<entry>
<id>urn:example:1</id>
<xx:private />
rel="alternate"
type="text/html" />
<published>1979-01-01 23:45</published>
<content type="html">This is a private entry.</content>
</entry>


The <link rel="alternate"> HREF should be one that would forward to the canonical URL if the reader were authorized, but should not provide any private information (e.g. a title slug). For example, this entry could have a URL of http://beesbuzz.biz/4594 which would then forward to its permalink. (The authorized rendition of the feed could instead link directly to the item.)

Optionally, <xx:private> could include an href attribute that points to a feed that should be pulled from by the authorized client upon receipt of this item’s WebSub notification. For example:

<entry>
<id>urn:example:2</id>
<xx:private href="http://example.com/feed?item=2" />
<!-- ... -->
</entry>


where http://example.com/feed?item=2 is a rendition of the feed that restricts it to only include this entry. (If the reader is not authorized to see the entry, the feed would simply have no entries in it.)

In any case, the purpose of this stub entry is to tell subscribers that there is new content to be seen, without necessarily indicating what the content is. It does unfortunately allow an unauthorized third party to see how many private items are being posted, however.

Anyway, when a feed reader receives a WebSub notification of an entry with this <xx:private /> element, it can initiate an authorized pull of the full feed on the behalf of every subscriber.

The inclusion of “one or more” such entry stubs allows for the possibility of letting legacy feed readers see stubs for arbitrarily many auth-walled entries, when multiple entries occur between polling intervals. The limit should probably be based on what’s a reasonable polling interval, and should probably not go back more than a day or so. This should of course be flexible based on the particular comfort level on the part of the content publisher; some might opt to limit it to 1, others might opt to put all their private entry stubs into their feeds (including RFC 5005 archive feeds). There is no single right answer for everyone.

But there definitely needs to be at least one, ideally the most recent one, to support WebSub.

### Implications of this approach

Off the top of my head:

Positives:

• Support for WebSub
• Doesn’t require complicated encryption or key exchange
• Bandwidth requirements are similar to those of a standard feed
• Low to no user impact

Downsides:

• No support for static publishing
• WebSub support requires a pull after a push, which is kind of wasteful
• More complexity for multi-user feed readers
• Leaks the existence of private posts, and statistics about private post counts can be inferred by third parties (but at least it doesn’t leak anything about how many recipients there are or how large the posts are)

Anyway, I’d personally be pretty comfortable with this set of tradeoffs. What do other folks think?