Hi there,
i try to connect rdfPub from AndStatus .
Yesterday I finally made it to the oauth2 registration. And then I got stuck at the call to the whoami endpoint.
@yvolk descibed that here: Basic implementation of "client to server" ActivityPub protocol · Issue #499 · andstatus/andstatus · GitHub
Is there a FEP or similar for connecting AP Apps to C2S Servers ?
@aaronpk have you dealt with this topic?
ActivityPub is a “follow your nose” spec. That means that you have to START with an actor URL, otherwise you have no idea which oauth endpoints are going to be correct for your given actor.
Once you HAVE an actor URL, all of your endpoints radiate outwards from there. That’s why there’s no “whoami” endpoint pointing at your current actor URL—because you need to start with the Actor URL to complete the oauth flow in the first place, such an endpoint would be redundant
Let me know if that helps, or if maybe I’ve misunderstood your question somewhere
Hi, yes, I think you got that wrong.
As I understand it, it is a more convenient approach than webfinger.
An application like AndStatus accepts a user, e.g. tester@rdf-pub.org.
It then knows the C2S server and can ask for the RFC 8414 - OAuth 2.0 Authorization Server Metadata
It then has data to create a dynamic client on the OAuth server.
And then it can forward the user to the OAuth server, so that he gets a consent screen there and get a login form with UserName and password.
AndStatus then receives an authentication (e.g. a JWT).
And with this authentication/jwt AndStatus can call up https://rdf-pub.org/api/whoami without knowing the actor’s IRI/Url.
The C2S server can then use a JWT claim to determine e.g. username/userId and find the corresponding actor. The C2S server then responds with the actor’s profile.
And then AndStatsu is ready for “foloow your nose”
This sounds completely backwards from the ActivityPub approach. There’s no way within activity pub to “determine the c2s server” without having an actor profile because the actor profile defines which oauth endpoint(s) are appropriate for that actor. there’s no such thing as a “c2s server” in the spec, only the endpoints listed on a given actor profile
Well, as far as I know this is unfortunately not described anywhere 
@yvolk which C2S applications did you integrate in AndStatus until now?
And yes, that is the reason for this Thread
As the thread at Github that you referenced shows, the whoami endpoint was used in Pleroma for ActivityPub connection. Not sure for today’s state.
But the idea isn’t new and it isn’t specific to ActivityPub either 
E.g. in AndStatus it was used for ActivityStreams connection to Identica sites for many years.
@nightpool
How does an AP client application get the URL of an actor profile? Does the user have to log in with the URL e.g. https://myactivitypubserver.org/users/profiles/0815 ?
Here is an abstract example of what we are talking about here
Actors (In the sense of use cases, not related to AP Actors!)
Process
Correct, that is the only way envisioned in the ActivityPub spec. (Or using a browser extension or something similar to fill in their actor URL, or using some other integrated server + client combination that handles auth separately). There is no concept of a “username + server” combination in ActivityPub like there is in e.g. Mastodon.
One way you might imagine this existing in a many-client world is if federated servers provided a “client browser” of different example client applications that their users could use, and then the links to each client would contain a query param that would fill in the user’s actor URL, so that the client could fetch the oauth properties immediately and start the oauth process. That’s just one idea about how a good UX could be achieved using a follow-your-nose system though, there are probably countless others.
i did not really understand this.
Another note about “whoami” (“me”) that I wrote here: Basic implementation of "client to server" ActivityPub protocol · Issue #499 · andstatus/andstatus · GitHub
Citing from there:
Adding “whoami” endpoint to an Actor’s profile seems silly to me also Please add a link to it as “me” property of the OAuth access token response just like shown in IndieAuth and as @puckipedia suggested.
Please note that the whoami endpoint serves very important purpose, which the user’s profile doesn’t (because it’s publicly accessible): successful access to it really proves that a client application is correctly authenticated by a server. Accessing this endpoint after initial account creation in a client application allows a User to check if authenticated connection to a server works now.
In the long run whoami and other oauth endpoints should be moved from user’s links to the server’s: why duplicate the same URLs for every user? This means that the whoami endpoint and other common OAuth endpoints far better be added to the “Register client” response…
In ActivityPub the endpoints json object
is described as (typically server/domain-wide) endpoints this means, that
oauthAuthorizationEndpoint & oauthTokenEndpoint are not actor specific.
It’s all very confusing!
@nightpool this would mean that a client only needs any endpoint of any actor and could use it to determine oauthAuthorizationEndpoint & oauthTokenEndpoint for any actor.
The endpoints document may be shared between actors, but you have no way to know which actors use a specific endpoints document without requesting that actor first. Merely sharing a domain is not enough evidence
Hi all, playing with @eprodrom 's ap
It’s not calling the whoami endpoint and also not oauth-authorization-server
→ Exception: No endpoints found
I assume he is setting a standard in his book
I’ve been laid up with the flu for the last few days and have had a lot of time to think. I think it’s really nice when the user specifies the oauth issuer and not the ActivityPup server!
Maybe I’ll get around to experimenting with it between the years.
The question is how to deal with different clients who have different expectations.
Could you explain this?
Also, if you’d like something implemented in ap, there is an issue list here:
at the moment my codebase is not able to test this, i can remember getting stuck on something.
Yes, I had given up here:
But I’m still in the process of getting all the tests working again after a DomainModel refactoring, that will take some time.