Loqi[preview] [samuelgoto] > I'll put instructions on how to use this
Ok, here is one way anyone with a domain can be an Indie FedCM IdP that https://webmention.io would accept as an IdP.
You have three options:
1) You can implement https://indieweb.org/FedCM_for_Indi...
[Joel_Auterson]Got EXIF extraction working for photos :) I realised I was including location data in all my photos so now Hugo extracts it selectively and then my build strips it from the images https://www.joelotter.com/notes/2024/04/19-japan-19/
Loqi[preview] [Joel Auterson] Spent Wednesday evening in Kabukicho - def worth a visit, especially if you’ve played the Like A Dragon games as it’s the inspiration for Kamurocho. Had drinks in the Golden Gai, met some lovely people, had far too much shochu. https://www.joelotter.com/img/2024/04/japan-19-1.jpeg
Loqi[preview] [Evan Prodromou] @jesseplusplus I had a much more pessimistic feeling about federation by the early 2010s, when that ecosystem had collapsed into a few dominant players. It wasn't until we started the Social Web Working Group at the W3C in 2014 that I started feelin...
[Joe_Crawford]one prerequisite for a webmention is the link to the target be included in the originating url so that seems like the result should be failure, flagging or the like
aaronpkcause it's not like someone set up a Wordpress site with the webmention plugin and is sending webmentions from actual pages on the site where it's only spam because of the content of the page
[snarfed]maybe someone's site has a "send me a webmention" form pointing to http://wm.io, and this is the usual indiscriminate "find forms with text boxes, plug in our URL" spam
pcarrierThe client could generate everything based on local storage, that the server merely confirms at the end by verifying the unsigned assertion and signing it
pcarrierDoes it though? I could imagine keeping a list of user, private key in local storage, and the server resigning the assertion that's been signed by the client to prove it has the private key after verifying the user ID -> public key association, for example
pcarrierMaybe I misunderstand what problem is being solved, but some of the design feels overly constraining to me. I don't like first party cookies either, in my ideal world every FP/IdP request could be signed by my passkey rather introducing a stateful session with cookies
[jgarber]Assume this is about an authorization endpoint service akin to http://indielogin.com. I’m 99% sure I’ve used the right terminology, but apologies if the wording is slightly off:
[jgarber]In an IndieAuth flow, what are some authorization endpoint strategies (besides RelMeAuth) for attesting that a person "owns" the domain they're authenticating with?
pcarrierwouldn't be comfortable with any member of the web team changing a key corporate security policy whenever they feel like it, whereas changes to the main DNS zone is likely to go through sysops
aaronpkbut there isn't really a difference in the UX depending on which they click, because neither case asks for any user input before triggering the passkey prompt
aaronpkhave you thought about what happens if someone registers a new account accidentally and then wants to move that passkey onto their existing account?
pcarrierno. everything belongs to teams, so you'd invite the other account onto the same team, then one of the accounts would leave the team and could be kept around empty
aaronpkone thought was to detect a first-time account and ask if they meant to log in to a different account, then go through some sort of recovery flow like if they have an email address
[jgarber]I’m probably missing some context here, but this presumes the person realizes after the fact that they created a second account (both using passkeys)?
[jgarber]User realizes they messed up, they initiate an account merge flow that prompts for two passkeys in sequence (the current account’s then the “other” accounts which I suppose they’d have on device or have access to), and then the application is responsible for handling the data merge.
aaronpkit's definitely an edge case and not as much of a problem with separate buttons, but i was trying to make just one button for both actions where it would be more likely to happen
aaronpkright but if you assume they got into the situation because they weren't able to use the two different passkeys on the same device, they're stuck
aaronpkit's actually: created account on computer A, created second account on phone B, now you want to move the passkey on the phone to the account created from computer A
pcarrierbut I mean, sure, let's do that. You log onto your computer, you click enroll, you use your phone. Now phone has A and B. You log into A from phone, click merge, log onto B, done
pcarrieryou log onto account A from computer A. you click enroll, pick mobile, scan the QR code shown by computer A on phone B. now phone B has passkeys A, B, and C where passkey C belongs to account A
pcarrieryou log onto account A on phone B using passkey C, then hit merge, then select passkey B. now account A has passkeys A, B, C and you can delete passkey C.
aaronpktwo problems with that: you are forcing the user to switch devices to go through this flow (they were on their phone when they made the second account accidentally), and you are forcing them to delete the extra passkey, which is not good UX right now
pcarrierhowever, you want to use an account you've lost access to. you reach out to me. I find a way to validate your identity (E-mail address on the account, domain you own where you can change DNS, etc.) and send you a one-time link to log into a fresh session for your account without a passkey.
aaronpki don't _need_ to have any identifying information for an account to be functional, and in fact i would like to only collect any identifying information after the account is created so that i can do it incrementally and when it makes sense
aaronpkwhat i'm trying to do is make it so you can click "register" and make an account where there is no information yet, then go add a domain to your account (which will require that i do domain verification). but then you should be able to add a second domain too. and there's no reason to ask the user to create a separate username for this either
[jgarber]Okay, so it is super easy on that Yubico demo site to rack up passkeys. I was expecting an iOS/macOS prompt asking if I wanted to use an existing one but that highlights my ignorance of the underlying implementation code.
aaronpkask the user for their email, check if you have an account with that email, if so ask for navigator.credentials.get, if not do navigator.credentials.create
[jgarber]The “ask for email get or create” flow _could_ be used nefariously to determine the existence of an account for a given email similar to how 401’s can leak the same (vs. a generic 404).