@sl007@digitalcourage.social These vocabularies should be implemented in Fedify.

[sl007@digitalcourage.social]

@hongminhee @fedify

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

[hongminhee@hollo.social]

@sl007@digitalcourage.social These vocabularies should be implemented in Fedify. See also the docs on extending the vocabulary. Could you file an issue for this?

[sl007@digitalcourage.social]

@hongminhee

Yes, I will do.

Unfortunately in the example itself there are some things which I find very misleading:
https://github.com/swicg/activitypub-api/blob/main/examples/oauth/index.html

Apart from the variable-name "as" for "auth-server" ;)

For discovery `getAsFromOrigin` takes precedence over `getAsFromActor` but actor-endpoints are more specific than serverwides.
If it would be the other way around, the users does not have to enter their handles twice.
Opinion?

[sl007@digitalcourage.social]

@hongminhee

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 …

#ActivityPub #OAuth

[sl007@digitalcourage.social]

@hongminhee @fedify

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/