@sl007 These vocabularies should be implemented in Fedify. See also the docs on extending the vocabulary. Could you file an issue for this?
fedify.dev
The Activity Vocabulary is a collection of type-safe objects that represent the Activity Vocabulary and the vendor-specific extensions. This section explains the key features of the objects.
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 …
github.com
ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.
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?
github.com
ActivityPub API Task Force repository. Contribute to swicg/activitypub-api development by creating an account on GitHub.
