@Harald Eilertsen Thank you. It is good to be back.

@FenTiger I updated MagicSignOn.org with use cases and added a brief comparison between OAuth and OpenWebAuth.

Use Cases: #^https://magicsignon.org/page/openwebauth/uses

New Home Page: #^https://magicsignon.org/page/openwebauth/home

@FenTiger It sounds like a sensible approach to me, but @Mario Vavti and @Mike Macgirvin 🖥️ would be the ones implementing it, so it depends on what they think.

@Mario Vavti That's what I thought. We should probably mention that in the spec.

@Scott M. Stolz
Speaking of which, if OWA does not send profile information, such as display name and avatar, maybe it should. Because we can't assume that other platforms will use the same protocols for communication.
Maybe we can provide a way of including the display name and avatar of the authenticated user as part of the OWA authentication process. Make it optional, and state that as a fallback, you would use other methods to get this information (and provide a list of the fallback methods). That way the protocol remains backwards compatible, while providing additional information for those who want to utilize it.

@FenTiger
A "compare and contrast" with OAuth sounds great, too, but might give people the impression that they have to pick one or the other - which I don't think is necessarily true, though I haven't fully explored the implications of merging them.
I think it is more a situation where each has a different use case.

OWA allows [email protected] to log into example.com as [email protected], and example.com determines what [email protected] can do on example.com. Example.com cannot impersonate [email protected], nor can example.com control example.social on behalf of the user.

Whereas with OAuth, you can set it up so that example.com becomes an agent for [email protected] and depending on how you set it up, example.com can manipulate example.social on behalf of the user.

Or at least that is the layman's explanation of it. In that sense, OWA is simpler to set up, and also purposefully limits the scope of power example.com has in relation to example.social.

Speaking of which, if OWA does not send profile information, such as display name and avatar, maybe it should. Because we can't assume that other platforms will use the same protocols for communication. Will an ActivityPub only platform be able to get the display name and avatar and profile of a Zot only user, for example?

How would such a situation be handled?

@FenTiger I was also thinking of making some other changes too. When I talk to people about it, they seem to think it works like OAuth and don't understand the use cases OWA addresses. So adding a section on use cases might help people understand.

I can start writing a use cases section for inclusion.

And we might want to mention certain activities, like how to get someone's profile and avatar, since that is a question that came up. We could even point to other FEPs or the ActivityPub specs to explain how it is done, since I don't think OWA includes the full profile information.

Basically, explain some of their next options after they authenticate the user, emphasizing that OWA was meant to be flexible and work with multiple protocols, such as ActivityPub, Zot6, and Nomad.

@FenTiger They did calm down when I said Hubzilla invented OpenWebAuth in 2017, and then quoted what you said above. I think it was a case where they thought I was just some random person who did not know what he was talking about. It was heated but respectful.

@FenTiger It was pretty heated. They said I was gaslighting. I told them we literally invented OpenWebAuth, so I think we would know.