Sele

From IndieWeb

Sele is a IndieAuth provider (client and server) by Jacky Alciné. It's meant to be friendly to selfhosting. Progress is publicly tracked on the alpha and the final releases, as well as the backlog.

The latest (read: unsupported) version exists at https://sele-test.jacky.wtf. The instance meant for community use lives at https://sele.jalcine.dev.

Purpose

Sele is meant to

  • provide an opinionated service that can be leaned on as a service. Ideally, its feature development is driven through community interest and the ability of maintainability said features. By providing this, the goal is to make the integration of IndieAuth into personal sites and services simpler.
  • drive new approaches for IndieAuth to encourage plurality and open access for people getting started with the IndieWeb.
  • provide components for expanding one's IndieAuth support like through device authorization and push notifications in a referential and extendable fashion.

Authentication

In the spirit of plurality, Sele comes with support for some in-built means of authentication and has support for adding more over time on a per-installation basis.

In-progress Methods

A live progress list of these methods can be found at git.jacky.wtf.

Authorized device confirmation

This would allow an application to approve requests on behalf of the Web interface of Sele. In order for this to work, authorized applications (called devices) will be able to subscribe to Sele and respond to attempts for authorization that a user acts upon.

Push notifications

In relation to device confirmation, this provides the generic interface for interfacing with pub-sub systems for handling request confirmation. This will come with support for services like:

Email Links

This works a bit similarly to Authorized device confirmation but uses SMTP over TLS (encrypted e-mail sending) to send a message to an address in order to get a confirmation or rejection to a request. The e-mail will have expirable signed links for requests that can approve, deny or view for more auditing.

RelMeAuth

Defined on the Wiki as RelMeAuth, this is meant to be a shell of a framework to let people authorize using external providers. The intent is to have this plugin support at most looking for a rel=me authn URL that points to a metadata endpoint. Other compatible methods can be found by adding OAuth2 client support.

OAuth2 Client

The shell of running an OAuth2 client (in this case, as a proxy to one implementing their own) to use for the identification of a user based is meant to help extend things like RelMeAuth (see https://indieweb.org/RelMeAuth#FAQ specifically, as this is why silo backlinks are only supported when OAuth2 is provided). A bundle of services will be added like:

Authorization

In order to confirm if an IndieAuth authorization request can be shown for approval, Sele requires authentication (as previously handled). Once that's been confirmed, Sele — either via the Web or through an authorized application — will inform the user of what kind of access is being requested, by whom and how to classify this attempt for future reference. This is done by showing scopes, the information gleamed from the client's h-app and past experiences the authenticating site has had with this client.

Additionally, one can adjust the associated post-types, scopes, destination or channels that the client will be able to use after this request is approved. This functionality is available after you enable Sele to read Micropub configuration from your site.

TicketAuth

Sele aims to provide a working implementation of TicketAuth. In order to do this, it aims to answer a few questions intentionally left open by the specification:

  • How does one send a ticket? Sele will do this in a few different ways:
    • It'll subscribe to your identity's URL (site) and listen for any new follow posts.
    • It'll poll your contacts from Micropub and send tickets
    • It'll send tickets to the URLs listed in the audience field of posts from one's feed.
  • How does one request a ticket? Sele provides a few moments:
    • Sele provides endpoints to generate a ticket for a fixed identity.
    • Sele can automatically approve ticket redemption from identities in one's contacts

Protecting Feeds

For this example with Alice (she/her) and Janet (they/them), we assume that Alice is using a reader that understands TicketAuth and Sele as her IndieAuth provider, namely Lighthouse. We can also assume that Alice's reader is built to conform to ethical engagement. Janet is also using Sele in this example.

  • Alice visits Janet's feed at https://janet.example/all.
  • Alice's informed by Janet's website that this page requires authentication.
  • Alice's reader notices TicketAuth support by this site
    • This could have been detected before by checking the author's own representative h-card and looking for TicketAuth support there
    • This would be done by looking for a IAM endpoint on the page itself
  • Alice's reader then attempts to request a token and informs Alice of the lack of access and that it's waiting for a response.
  • Janet's IndieAuth provider can inform Alice of this in a number of ways.
    • Sele sends a periodic e-mail of a list of those requesting access.
    • Sele's mobile app equivalent can poll for new ticket requests and show them.
    • Sele supports sending notifications using https://ntfy.sh/, Pushover, XMPP or private IRC messages.
    • Sele shows a list of requests sorted by the resource (realm) or the requester on the dashboard.
  • When Janet's provider approves this request,
    • Alice's reader will continue the flow to obtain an access token for this resource.
    • Alice's reader will fetch the resource using this token.
    • Because Alice's reader is also built with ethical engagement, it restricts the adjustment of the replies to this feed's post by keeping the same audience of the post, carries the same content warnings and visibility, if shown on the top level. It will defer to what each individual post uses (and give the user an option between them).
    • Alice's reader will use that token to fetch the posts in the feed over time as well as it's implied that it's required to read those posts.
  • When Janet's provider rejects the request,
    • Any sort of messaging that can shown to the user is presented when this feed is attempted to be presented in the reader
    • Sele will only retry this with user consent and will respect any headers around retrying.

Protecting Posts

The flow for protecting posts is similar to protecting feeds.

Planned Features

DID Provider

  • Provide DID URNs that one can apply to a URL as a alsoKnownAs value.

Enabling a Protected IndieWeb

For a Micropub server that sets the visibility of posts to be either unlisted or for those whose audience is set to be non-public, Sele should provide a means of leveraging either its form of TicketAuth across each of the services one uses. This could look like:

  • allowing issuing of tickets for TicketAuth if you set a contact into a particular group in your Micropub server automatically by listening for changes in the group (perhaps over WebSub)
  • generating dynamic Vouch URLs for Webmention servers that work with a Micropub server to determine an aggregate of posts that match particular criteria:
    • the last n engagements (over a window of time?) between the parties that satisfy a sense of access
    • a URL to their follow post to you that they sent
    • a page that has some sort form of Web of Trust backing (like KeyOxide, a signed PGP message to a known key)
    • contextually relevant URLs (like if liking a book review, a link to themselves pointing to the same book)
Retrieved from "https://indieweb.org/wiki/index.php?title=Sele&oldid=92272"