Notices by FenTiger (fentiger@zotum.net)
-
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Wednesday, 04-Jun-2025 02:28:01 JST 
FenTiger
@silverpill Do you have to double-knock every time? Can't you cache the result when a POST succeeds, so you know which signature method to use next time you deliver to that instance? -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Sunday, 11-May-2025 08:08:29 JST
FenTiger
"Servers SHOULD implement NodeInfo..." seems a bit strong, especially considering that some people are quite strongly opposed to it. Is this really a SHOULD? Or would it be better to write a paragraph or two about the pros and cons, and let implementers decide for themselves?
Would it be worth recommending that implementers provide a config option to allow NodeInfo to be switched on and off by the instance admin?
Should there be a recommendation that "Consumers SHOULD NOT assume that any given Fediverse site will implement NodeInfo"?
I've seen code out there that uses a NodeInfo hit to decide which auth protocol to use for cross-instance login. I personally don't like this approach and would prefer not to encourage people to use designs like this. -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Thursday, 24-Apr-2025 04:40:49 JST
FenTiger
+1 for not sending private keys over the wire. I'm no expert, but I feel a lot more comfortable with this design. -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Sunday, 23-Mar-2025 21:39:57 JST
FenTiger
Today I had a quick go at working out how Hubzilla handles permissions for media files.
I've been meaning to do this for a while, to work out how it relates to OpenWebAuth authentication (as described in FEP-61cf), but unless I'm missing something (very possible), it's an entirely separate mechanism.
Summary: it's based on bearer tokens / capability URLs. Each post gets given a random token, and that token grants access to any media files which are attached to it. If you're allowed to view the post, the URLs that it contains grant you the capability to download the attachments, too.
When a post is created:- Generate a random token for it.
- Record that the token grants permission to access any attached media files.
- Store the token to the DB as part of the post.
When a post is encoded to ActivityPub:- Find the associated token and append it to any URLs referring to attached media files
- Also do the same for any attachment objects
Presumably this happens when it's rendered to HTML, too, but I couldn't find that bit.
When a media file is requested:- Extract the token from the request.
- Check that the requester has permission to view the file, including checking whether the token grants permission.
Pretty simple really, though it took a bit of grepping and guesswork to find all these pieces, and I'm not sure I've found all of it.
#ActivityPubDev -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Thursday, 20-Mar-2025 03:35:58 JST
FenTiger
@silverpill Well, in my (sketch of a) design, things like sharedInbox and proxyUrl point at the specific server that's hosting the clone, rather than being common to all the clones (and the oauthAuthorizationEndpoint and such are best found via different mechanisms entirely).
I'll readily admit that there are other possible ways to build it, though. -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Thursday, 20-Mar-2025 02:50:09 JST
FenTiger
I would vote against putting it in endpoints, personally, because endpoints is "typically server/domain wide" and is allowed to be a link rather than a nested object, while gateways should be considered to vary from actor to actor, because two actors might be cloned to different sets of servers. -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Friday, 31-Jan-2025 21:17:00 JST
FenTiger
This was my experience too.
It also doesn't play very well in practice with JCS canonicalisation, as used by FEP-8b32 signatures: #^https://zotum.net/channel/fentiger?mid=d9557d63-a9e5-4bba-a39d-e2ee785def42
Trying to treat messages as "JSON-LD first" has taken me a very long way down a blind alley, and cost me a lot of time.
:( -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Tuesday, 26-Nov-2024 01:45:37 JST
FenTiger
@silverpill
How does it check that the user is logged in? Does it present a login form?
It checks whether the user has a session cookie. Hubzilla doesn't show a login form here; it could, but that wouldn't work so well for eg image fetches.
And then, after login, which instance generates activities?
FEP-61cf only covers authenticating the user. It doesn't tackle the question of what happens when the now-authenticated user writes a post. How should that post federate outwards, in such a way that other instances can trust it? I don't know how Hubzilla approaches this; maybe @Mario Vavti can comment. -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Thursday, 03-Oct-2024 05:30:49 JST
FenTiger
@silverpill That'll do - thanks.
I'm sure I saw some discussion relating specifically to collections - but maybe it wasn't in an FEP. -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Wednesday, 02-Oct-2024 22:35:44 JST
FenTiger
Is there an #FEP which covers adding the attributedTo property to collections?
#ActivityPub -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Sunday, 25-Aug-2024 21:20:58 JST
FenTiger
Announcing FedIAM 0.1.0 - Sign in with a Fediverse account!
Suppose you want to allow people to log in to your web site. How will they identify themselves? With a username and password? We've all got far too many of those already, and they're not even particularly secure. Perhaps with a Google or Facebook account? That's a lot easier, but do we really want to allow these companies even further into our lives?
FedIAM is a research project which aims to offer an alternative: using Fediverse and IndieWeb protocols, visitors can log in using any one of thousands of small, independent networks run by ordinary people - or even using a provider that they host themselves, independently of any outside influence.
Now available as open source!
#^https://codeberg.org/FenTiger/FedIAM -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Tuesday, 13-Aug-2024 15:54:54 JST
FenTiger
@silverpill Good question. Quick, shallow answer: this is just a login system, not an #ActivityPub instance. It could certainly be used in front of an ActivityPub instance, though, and in that context, it's definitely worth thinking about. I don't have any concrete answers, but off the top of my head:
The simplest option would be to create a new local actor, and use this purely for login. Sometimes this is the only option - IndieAuth and the native OIDC mode can both work without the existence of an AP actor at the IdP end.
Another option would be to pair it with AP C2S. The OAuth2/OIDC based modes can provide an access token as well as an identity; this could be used to authorise the RP to connect back to the IdP and post using C2S. This would take a bit of standardisation work, but not a lot; my impression is this would be fairly easy to build.
What if the user has a FEP-ef61 nomadic actor? Sending the private key from the IdP to the RP is probably not a very good idea, but perhaps the IdP could expose an access-controlled endpoint to generate a signature on the user's behalf. With this method the RP would construct an object with attributedTo set to the user's nomadic actor ID, request a signature from the IdP, and then distribute the object however it chooses. (In this case, perhaps the IdP should get to choose the new object's ID too, at which point this starts to look a lot like a variant of C2S.) -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Monday, 12-Aug-2024 02:15:19 JST
FenTiger
@silverpill Yes. It lets you log in using an existing account rather than having to register a new one - but in a "Fediverse compatible" way, without any of the technical and social problems which come with using a Big Tech provider.
It can also (in some, admittedly limited, circumstances) recognise your login session automatically, without having to actually enter your ID every time you click from one site to another. -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Sunday, 11-Aug-2024 19:04:01 JST
FenTiger
Anyone interested in single sign-on / #SSO? Want a new toy to play with? I've been experimenting with it recently, and now I've got something to share: an experimental demo of how a "Sign in with the Fediverse" mechanism might work.
If you have a Mastodon or Hubzilla account, or an IndieAuth-style self-hosted identity, I'd like to invite you to try and sign in to my test site at login.mythik.co.uk.
Headline features:- User authentication/authorization based on the Ory tools.
- Supports signing in using an existing Fediverse (or other) account - or one you host yourself
- Open source - well, not yet, but it could be, if people are interested in it
- Written by a non-expert! Woefully insecure! All manner of attacks, just waiting to be found! Invite your security expert friends to the party, and laugh together at the n00b! Fun for all the family!
Supported identity providers include:- Mastodon (must be a recent version that includes this pull request). mastodon.social is known to work.
- Hubzilla (any version). zotum.net is known to work.
- #IndieAuth / #FedCM
- Another instance of itself, using OpenID Connect
(There's a chance Streams might work, too.)
Protocols supported:- #OIDC Discovery
- Client ID Metadata Document
- FedCM for IndieAuth
- #OpenWebAuth
- A method using the Mastodon API
- Classic (non-FedCM) IndieAuth (if you're lucky; I found this very hard to test, and had various problems with it)
- My original experiments used Dynamic Client Registration but I've moved away from this.
If you can get it to work - share a screenshot and let me know what you think!
(I'll try to keep this running for a while, but I can't guarantee it - partly because I haven't finished trying to attack it yet. If I have to take it down for some reason, I'll edit this post to say so.) -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Friday, 12-Apr-2024 10:50:53 JST
FenTiger
@silverpill What's the purpose of the did: and key: prefixes at this point? Can they be removed?
It might be a good idea to have something there that can differentiate newer versions of the scheme - but if did: in particular can go, people might be less likely to associate this with all the dodgy bl*ckch*ain stuff. -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Saturday, 16-Mar-2024 20:27:55 JST
FenTiger
@Helge Your suggestion of did://key:1234567/path would have the upside of being compatible with Go's url.String() function, which also turns out to be unable to process did: URLs with paths.
My #BangHeadHere sign is taking a bit of a battering today... -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Saturday, 09-Mar-2024 20:06:16 JST
FenTiger
Oh, joy: it turns out that Go's net/url package doesn't understand that DID URLs can have paths.
Parsing "https://example.social/path/to/object" gives me a useful result:
&url.URL{
Scheme:"https",
Opaque:"",
Host:"example.social",
Path:"/path/to/object",
[...]
}But parsing "did:ap: key:z6abcdef/path/to/object" gives me this:
&url.URL{
Scheme:"did",
Opaque:"ap🔑z6abcdef/path/to/object",
Host:"",
Path:"",
[...]
}So I need some kind of wrapper to detect DID URLs and parse the paths out of them. That's easy enough, I suppose, but then I need to actually use that wrapper, in all the relevant places...
#ActivityPub #FediDev #BangHeadHere -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Monday, 26-Feb-2024 20:56:18 JST
FenTiger
Is the apresolver endpoint expected to work?
I tried https://mitra.social/.well-known/apresolver/did:ap: key:z6MkuXdkTDa1iAZraZCRT9N5BpXKZxvBYpR4T7EG4tTxYuda/actor, and got a 200, but it's a HTML page, not the actor object. I don't see a Link header, either.
(Space inserted so Hubzilla doesn't convert "key" into a 🔑 emoji!) -
Embed this notice
FenTiger (fentiger@zotum.net)'s status on Tuesday, 30-Jan-2024 00:41:01 JST
FenTiger
For a while now I've been meaning to take a look at #OpenWebAuth, but I've been a bit daunted by the reverse engineering effort that it would take.
This changed when I came across this page:
#^https://hz.eenoog.org/wiki/pascal/Fediverse(28)20(29)OpenWebAuth(28)20(29)support/Home
This links to three PRs adding OpenWebAuth to Mastodon and PixelFed. Reading these PRs saved me a lot of time by clearly highlighting the areas of the code which I needed to study. With these and a bit of grepping I've been able to implement most of #OpenWebAuth locally, so that my toy instance can now log me into Hubzilla, and I can very nearly allow Hubzilla users to log in to me, too.
Here's a quick writeup of how it works, in the "happy case". I'm wondering if it's worth polishing this further and making it into a #FEP.
1. The OpenWebAuth flow can begin in one of two ways:
(a) The user visits the target instance and sees a login screen. They type their Fediverse ID into a form field and click "Login".
(b) The user follows a link to the target instance. This link has a query parameter, zid=, which specifies the user's Fediverse ID.
Either way, the target instance has learned the user's ID, but has not verified it yet.
2. The target instance constructs a URL of the form
https://home-instance.example/magic?owa=1&bdest=<destination URL>
The parts of this URL are:
Scheme: Must be HTTPS
Hostname: The same as the hostname portion of the user's ID
Path: Must be /magic
Query parameters:
owa: must be set to 1
bdest: The URL that the user is trying to visit. This is encoded as UTF-8 and then converted to a hexadecimal string.
The user's browser is redirected to this URL.
3. The /magic endpoint at the user's home instance decodes the bdest destination URL. It performs a webfinger lookup on the root URL of the destination site and looks for a link with rel set to http://purl.org/openwebauth/v1. This identifies the target instance's token endpoint.
The home instance constructs and issues a signed HTTPS request to this endpoint. This request must have an Authorization header starting with the word Signature followed by the encoded HTTP signature. The keyId property of the signature points to the public key in the user's actor record, just as for ActivityPub signed requests.
4. The target instance's "token" endpoint extracts the "keyId", fetches the actor record, extracts the public key and verifies the signature.
On success, it generates an URL-safe random string to use as a token. This token is stored locally, associated with the actor who signed the message. The token is also encrypted using the actor's public key and the RSA PKCS #1 v1.5 encryption scheme. The encrypted result is encoded as URL-safe Base64 with no '=' padding bytes.
Next it constructs the following JSON object in response:
{
"success": true,
"encrypted_token": <the base64-encoded token>
}
On failure it can also return a result with success set to false.
5. The signed request issued by the /magic endpoint completes. The home instance decodes the JSON response and verifies that success is true. Next it decodes the Base64-encoded encrypted token and decrypts it using the actor's private key.
If successful, it takes the original bdest destination URL, adds the query parameter: owt=<decrypted token>, and redirects the user's browser to it.
6. The user arrives at their destination URL. The target instance sees the owt= query parameter and checks its local storage for the token which it saved in step 4.
If found, this token contains the user's verified identity, and the target instance logs them in, overriding any existing login they may have. The token is also deleted from local storage so that it cannot be redeemed more than once.
All GNU social JP content and data are available under the