Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse

NodeBB

  1. Home
  2. Technical Discussion
  3. @hongminhee @fedify

@hongminhee @fedify

Scheduled Pinned Locked Moved Technical Discussion
activitypubfedifyoauth
1 Cross-posts 5 Posts 2 Posters 5 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • sl007@digitalcourage.socialS
    sl007@digitalcourage.socialS
    sl007@digitalcourage.social
    wrote last edited by
    #1

    @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.socialH 1 Reply Last reply
    0
    • sl007@digitalcourage.socialS 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.socialH
      hongminhee@hollo.socialH
      hongminhee@hollo.social
      wrote last edited by
      #2

      @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?

      1 Reply Last reply
      0
      • ? [[global:guest]] crossposted this topic to General Discussion
      • sl007@digitalcourage.socialS
        sl007@digitalcourage.socialS
        sl007@digitalcourage.social
        wrote last edited by
        #3

        @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?

        1 Reply Last reply
        0
        • sl007@digitalcourage.socialS
          sl007@digitalcourage.socialS
          sl007@digitalcourage.social
          wrote last edited by
          #4

          @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

          1 Reply Last reply
          0
          • sl007@digitalcourage.socialS 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.socialS
            sl007@digitalcourage.socialS
            sl007@digitalcourage.social
            wrote last edited by
            #5

            @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/

            1 Reply Last reply
            0

            Hello! It looks like you're interested in this conversation, but you don't have an account yet.

            Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

            With your input, this post could be even better 💗

            Register Login
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            Powered by NodeBB Contributors
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • World
            • Users
            • Groups