Hey there,
this is about the new #ActivityPub C2S specs. introducing new properties.
In https://swicg.github.io/activitypub-api/basicprofile#discovery – the according example https://swicg.github.io/activitypub-api/examples/oauth/index.html expects the properties to be either in the /.well-known/oauth-authorization-server or in the Actor.
How can I support them in Actors created by fedify, e.g. in an ActorDispatcher ?
Maybe they should be defined in the default context …
#fedify #oauth
Replying to @sl007@digitalcourage.social
@sl007 These vocabularies should be implemented in Fedify. See also the docs on extending the vocabulary. Could you file an issue for this?
Replying to @sl007@digitalcourage.social
about above;
We just finished the first Social CG Dev meeting after the summer break [thus not the real first Tuesday this month] …
There will be some even new properties in the Data Portability Draft.
I summed up the new C2S spec drafts here:
https://digitalcourage.social/@sl007/117189119258003701
And then there is a Special Community Call for next Tuesday :
https://www.w3.org/events/meetings/4b3419c9-0d4c-460f-8a32-b575acd87b6c/
Sebastian Lasse@sl007@digitalcourage.socialEsteemed #Fediverse –
the #ActivityPub #ClientToServer API is magic.
For menschys we are currently implementing the new specs.
There are multiple drafts already, e.g.
Auth
https://swicg.github.io/activitypub-api/basicprofile
with according
Metadata https://client.dev/
and example in https://github.com/swicg/activitypub-api
Seek
https://swicg.github.io/activitypub-api/seekitem
Autocomplete
https://swicg.github.io/activitypub-api/autocomplete
Server Sent Events
https://swicg.github.io/activitypub-api/sse
#fedidev #oauth #seek #autocomplete #c2s
swicg.github.io/activitypub-api/basicprofileReplying to @hongminhee@hollo.social
Well, after the issues with the given ActivityPub "OAuth example", I looked up
@fedify /vocab …
In all the actor types like https://github.com/fedify-dev/fedify/blob/main/packages/vocab/src/person.yaml
the following properties would be missing [if the official OAuth demo should work] :
grant_types_supported: ['authorization_code'],
response_types_supported:
['code', 'code token'],
code_challenge_methods_supported: ['S256'],
token_endpoint_auth_methods_supported: [
'client_secret_basic'
// optional
/*, 'private_key_jwt'*/
],
token_endpoint_auth_signing_alg_values_supported: ['RS256', 'ES256'],
client_id_metadata_document_supported: true,
optional
scopes_supported and ui_locales_supported:
---
anyway:
I believe it is just misleading because of the order of querying the server and the actor description.
I would expect it to meet the spec and pull above properties from the server wide .well-known oauth and just the endpoints from the Actor …
