Conversation

Notices

1. Disinformation Purveyor :verified_think: (thatguyoverthere@shitposter.club)'s status on Tuesday, 14-Feb-2023 01:33:28 JST Disinformation Purveyor :verified_think:
   is there any reason a fediverse instance couldn't ask you to sign something with a private key as an authentication mechanism instead of username/password?
   • Disinformation Purveyor :verified_think: (thatguyoverthere@shitposter.club)'s status on Tuesday, 14-Feb-2023 01:44:39 JST Disinformation Purveyor :verified_think:

     in reply to
     or in the case of an AP server that speaks nostr protocol, the user could subscribe to the provided relay and send an encrypted message that could only be read by the secret key holder with a phrase that needs to be included in a reply or pasted into a field on the login page.
   • Floyvid Ninesneed (floyvid_ninesneed@geofront.rocks)'s status on Tuesday, 14-Feb-2023 02:04:39 JST Floyvid Ninesneed

     in reply to
     someone would need to write the code
     Disinformation Purveyor :verified_think: likes this.
   • MattZ (colinsmatt11@gleasonator.com)'s status on Tuesday, 14-Feb-2023 02:04:43 JST MattZ

     in reply to
     @thatguyoverthere Yes, because they don't support it.
   • Disinformation Purveyor :verified_think: (thatguyoverthere@shitposter.club)'s status on Tuesday, 14-Feb-2023 02:04:43 JST Disinformation Purveyor :verified_think:

     in reply to

     • MattZ
     @colinsmatt11 I'm not sure I follow. I mean it's authentication. I'm not asking why can't people already using password auth also accept signatures. I am asking if there is some technical reason that it couldn't be done this way. How current ap servers authenticate users isn't really important unless it's some kind of technical requirement. I don't think the AP spec determines how you manage user auth. I would think being able to prove you own the private key to a public key the server could store would be sufficient.
   • Disinformation Purveyor :verified_think: (thatguyoverthere@shitposter.club)'s status on Tuesday, 14-Feb-2023 02:05:43 JST Disinformation Purveyor :verified_think:

     in reply to

     • Floyvid Ninesneed
     @Floyvid_Ninesneed yeah I'm just wondering if there is a technical reason NOT to consider it.
   • MattZ (colinsmatt11@gleasonator.com)'s status on Tuesday, 14-Feb-2023 02:29:27 JST MattZ

     in reply to
     @thatguyoverthere Private keys aren't portable and many people don't have a security key, that's biggest issue for its adoption.
     
     AP spec defines almost nothing lol.
     AP servers can use any authentication middleware, but it's simply not worth the effort because it would only be used by a selected number of people.
   • Disinformation Purveyor :verified_think: (thatguyoverthere@shitposter.club)'s status on Tuesday, 14-Feb-2023 02:29:27 JST Disinformation Purveyor :verified_think:

     in reply to

     • MattZ
     @colinsmatt11 What I am doing is already a bit niche so yeah I doubt it's something that would gain lots of adoption (and realistically most programming isn't "worth the effort" but I enjoy a challenge and building things is fun). I am trying to work out how to bridge activity pub and nostr in a single service, and this would allow me to do that fairly cleanly. Someone had proposed using public keys as usernames in the AP side, but this seems flawed not just because it means unsightly long @ s, but also anyone could technically paste a public key into the username field and claim they own it (until challenged to sign something). If instead you treated it like an extern_uid you could create an authentication pathway for people who enter a valid public key using the `npub1....` format into the username login field. You could either give them something to sign and give back, or it would even be easy enough to just have the server send the user an encrypted message over nostr that they need to reply to. The server would be acting as a nostr relay already so the user could subscribe to the local relay and effectively authenticate the AP session using nostr as the provider.
   • MattZ (colinsmatt11@gleasonator.com)'s status on Tuesday, 14-Feb-2023 03:31:09 JST MattZ

     in reply to
     @thatguyoverthere Well good luck with it because I don't believe it's a good idea for various reasons.
     
     As for "worth it" ideas, honestly it's a limited amount because it depends on your target users.
     
     My target users is usually just me, so I don't really care much.
     
     For fun I solve math problems instead of programming because it's pure logic so I don't have deal illogical stuff which usually occurs in programming.
     Disinformation Purveyor :verified_think: likes this.
   • Disinformation Purveyor :verified_think: (thatguyoverthere@shitposter.club)'s status on Tuesday, 14-Feb-2023 03:31:09 JST Disinformation Purveyor :verified_think:

     in reply to

     • MattZ
     @colinsmatt11 I am not a mathematician so math only ever seems worth solving when there is some kind of problem solving the math will help me overcome. Learning how to measure rafters isn't something you do until you need to cut rafters kind of thing.
     
     The signature verification method could also make nomadic identity possible since only the person holding that private key could use it, and if it were included in webfinger as an alias or something you could validate that a person owns the account quite easily.
   • Disinformation Purveyor :verified_think: (thatguyoverthere@shitposter.club)'s status on Tuesday, 14-Feb-2023 03:49:09 JST Disinformation Purveyor :verified_think:

     in reply to

     • MattZ
     • silverpill
     @colinsmatt11 @silverpill no but I have been toying around with running mitra at some point. Pretty cool that a specification exists for proofs like that already. It looks like mitra is already including them in activity streams. I would essentially be doing something similar but on the client to server side and using a side channel protocol for handling the proof. In my case part of the purpose is to make it so that one server could act as a nostr relay and ap federated server with an account being represented in both protocols using common attributes that are not able to be impersonated. The nomadic identity component is kind of a side effect.
   • MattZ (colinsmatt11@gleasonator.com)'s status on Tuesday, 14-Feb-2023 03:49:10 JST MattZ

     in reply to

     • silverpill
     @thatguyoverthere Have you considered checking out FEP-8b32 by @silverpill
     
     https://codeberg.org/fediverse/fep/src/branch/main/feps/fep-8b32.md
     Disinformation Purveyor :verified_think: likes this.
   • Disinformation Purveyor :verified_think: (thatguyoverthere@shitposter.club)'s status on Tuesday, 14-Feb-2023 09:41:07 JST Disinformation Purveyor :verified_think:

     in reply to

     • MattZ
     • silverpill

     @colinsmatt11 @silverpill there appears to be a specification along these same lines using the same keys nostr uses already. Of course it’s “not fit for production deployment”

     https://w3c-ccg.github.io/lds-ecdsa-secp256k1-2019/

     This specification describes the Ecdsa Secp256k1 Signature created in 2019 for the Linked Data Signatures specification.

     { "@context": "https://w3id.org/security/v2", "http://schema.org/action": "AuthenticateMe", "proof": { "challenge": "abc", "created": "2019-01-16T20:13:10Z", "domain": "example.com", "proofPurpose": "authentication", "verificationMethod": "https://example.com/i/alice/keys/2", "type": "EcdsaSecp256k1Signature2019", "jws": "eyJhbGciOiJFUzI1NksiLCJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdfQ..QgbRWT8w1LJet_KFofNfz_TVs27z4pwdPwUHhXYUaFlKicBQp6U1H5Kx-mST6uFvIyOqrYTJifDijZbtAfi0MA" } }
   • silverpill (silverpill@mitra.social)'s status on Wednesday, 15-Feb-2023 01:28:41 JST silverpill

     in reply to

     • MattZ

     @thatguyoverthere @colinsmatt11 I've been thinking about using proofs for C2S as well: https://socialhub.activitypub.rocks/t/fep-8b32-object-integrity-proofs/2725/3
     There's already an experimental API in Mitra that allows you to sign activity with your Ethereum wallet, but it is not AP C2S. I'm planning to implement proper C2S at some point

     Disinformation Purveyor :verified_think: likes this.
   • Disinformation Purveyor :verified_think: (thatguyoverthere@shitposter.club)'s status on Wednesday, 15-Feb-2023 03:14:13 JST Disinformation Purveyor :verified_think:

     in reply to

     • MattZ
     • silverpill
     @silverpill @colinsmatt11 I started reading over your code and the mentioned proposal last night. I think it's a lot more approachable than the go code that I've been trying to parse.
   • silverpill (silverpill@mitra.social)'s status on Wednesday, 15-Feb-2023 05:32:44 JST silverpill

     in reply to

     • MattZ

     @thatguyoverthere @colinsmatt11 Good to hear! The code is very much work in progress. I'm currently using my own signature suites (documented here). Also, I haven't even implemented FEP-c390 (identity proofs). Once I do that, everything will be much simpler because there's a lot of overlap between FEP-c390 and FEP-8b32.