Sele

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.

Authorization

Due to Sele's projected nature of allowing people to register other methods of authentication (be it via WebAuthn, using a passphrase, or what have you), the flow is a bit different from the conventional session-based flow. It, generically, is as follows:

• An agent on behalf of a user/identity/site (a Web browser or another app) requests to obtain a challenge.
• The agent passes information of that challenge over to the user to attest their ability to complete it.
• Once completed and verified (which usually means the challenge response was acceptable), Sele generates a short-lived token (in this case, one generated using the Paseto algorithm) and returns it to the agent.
• At this point, it's up to the agent to redeem this token. Sele itself will attempt to redeem such a token by calling the API endpoint for doing so. I'm not currently sure how to handle other clients that'd like to use that token (pending security concerns).

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

• Authentication using multiple providers
  • WebAuthn
  • email (planned)
  • rel-me auth
  • SMS code (planned)
  • PGP challenge signature (planned)
  • XMPP challenge over OEMEO (planned)
  • IRCS challenge (planned)
• Multi-tenant support
• Serviceable via endpoints or in-built Web interface as a PWA
• Approve requests using supported apps
  • in-built PWA
  • Android
  • Linux
  • iOS and macOS are not on the roadmap.
• Client registration support
• Per-site app usage reporting
  • Reviewing apps used
  • Shareable as a h-feed to help promote apps
  • TicketAuth
• Extensions and Compat with OAuth 2.x
  • multiple callback responses modes including "form post", "fragment" and "query"
  • implementing portable identities

DID Provider

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