@evan @julian @thisismissem There is a mapping in the resource server between PreferredUsername and an actor. This is a hack; I had to extend it because Mastodon uses the username as a unique identifier. Without Mastodon support, it would be a mapping between IssuerUserId and Actor. The data for the mapping comes from the JWT token.

But that's beside the point.

@evan @julian @thisismissem There is a mapping in the resource server between PreferredUsername and an actor. This is a hack; I had to extend it because Mastodon uses the username as a unique identifier. Without Mastodon support, it would be a mapping between IssuerUserId and Actor. The data for the mapping comes from the JWT token.

But that's beside the point.

@naturzukunft @julian @thisismissem I think your point was that any configuration that requires adding plugins or adapters for KeyCloak is a bad architecture, and you're committed to using KC entirely off-the-shelf.

@evan @naturzukunft @julian as Client ID Metadata Documents move through the standards process, I would assume keycloak will adopt them and Client ID Prefixes.

@evan @naturzukunft @julian as Client ID Metadata Documents move through the standards process, I would assume keycloak will adopt them and Client ID Prefixes.

@evan @naturzukunft @julian but keycloak being able to understand wtf a json-ld document of type Service or Application is? Incredibly unlikely, especially when the contents within isn't even remotely aligned with the IANA registry for Dynamic Client Registration Metadata values.

@naturzukunft @evan @julian we have a userinfo endpoint now in mastodon that gives you a unique subject (sub) claim: https://docs.joinmastodon.org/methods/oauth/#userinfo

This is all discoverable via standards that exist in OAuth (with a touch of OIDC language)

@thisismissem @naturzukunft @julian but they don't work right now, out of the box? I think that doesn't meet his requirements then.

@thisismissem @naturzukunft @julian hey, that brings up a great point. Does Mastodon support clients using OAuth for accessing the read-only parts of the API (reading an actor, reading an outbox, reading a note)? I've done it with no authentication and with HTTP Signatures but I don't know if you can use OAuth. That would be a huge step in the right direction.

@evan @naturzukunft @julian not for AP, because we're don't support anything related to C2S. We could add OAuth support there theoretically, but it's not a priority right now.

@thisismissem @naturzukunft @julian right, but the ActivityPub API is not just about posting activities to the `outbox`. It also includes reading all the actors, collections and objects in the Activity Streams 2.0 format.

Anyways, I might look into it and make an issue and PR. If it worked properly, you could do a decent read-only application with the ActivityPub API, without making any commitment to the client-to-server part of the spec. That'd be a nice step forward for the API.

@evan @naturzukunft @julian talk to the team first. Doing changes here is not simple.

cc @MastodonEngineering

@julian @naturzukunft FEP/d8c2 is poorly designed and the comments on socialhub show this. It's not how OAuth is meant to work.

We should be using Authorization Server Metadata + Rich Authorization Requests for any OAuth implementation for an ActivityPub API.

Scopes would ultimately be pretty minimal, e.g., profile, offline_access (both OIDC), and maybe like manage:keys for updating signing keys; the rest should probably be RARs.

For discovery, if the Actor object advertises an authentication method of OAuth or OIDC, the look for the authorization server URL, discover all OAuth specifics from there.

For clients, you could do dynamic client registration, but it has drawbacks, so I'd recommend Client ID Metadata Documents.

@julian @benpate @evan I think FEP-3b86 only really allows for actions that the home server already knows how to carry out; the advantage of FEP-d8c2 is that it allows clients to add functionality of their own; see eg Evan's checkin app, which can post geo-tagged activities even via a server which doesn't natively support them.

@thisismissem @julian @naturzukunft is this in a FEP or RFC someplace?

@thisismissem @julian @naturzukunft the point of discovery is to find the important endpoints and parameters for the flows. Many implementers who are concentrating on a single API skip discovery because the resource provider has already defined the specific flow. Alternatively, many API providers allow client registration out of band. It is absolutely 100% OK to do OAuth without using features like discovery and dynamic client registration.

@FenTiger @julian @evan

This is a good point, though I'm not clear how different servers would handle outbox requests for activities that they don't support. I'm pretty sure mine would just die.

My big concern with OAuth tokens is that they require me to give away write access to my Fediverse identity when I "like" or "reply" to something, which could easily be an attack vector.

We talked about scoping OAuth tokens, but it feels like a lot of moving parts. More details later

I'm genuinely behind on this. I've skimmed Evan's FEP, but a lot of OAuth complexity is still opaque to me.

It seems like the missing piece with using the C2S API would be *figuring out* what endpoints I can call to initiate an activity.

Does FEP-d8c2 implement discovery in some way that I'm not seeing? Or, is this something *still to be defined* and I'm just jumping the gun, here?

@evan @thisismissem @julian @naturzukunft

@benpate @julian I suppose this is where fine grained authorization (such as RAR) comes in - assuming that people will understand it - which they might not!

Looking forward to talking about the details properly...