this post was submitted on 09 Feb 2024
1 points (100.0% liked)

Fediverse

17734 readers
3 users here now

A community dedicated to fediverse news and discussion.

Fediverse is a portmanteau of "federation" and "universe".

Getting started on Fediverse;

founded 5 years ago
MODERATORS
[email protected]
[email protected]
1
FEP-61cf: The OpenWebAuth Protocol (socialhub.activitypub.rocks)
submitted 9 months ago by [email protected] to c/[email protected]
5 comments fedilink hide all child comments
 

This is the proposed FEP-61cf: The OpenWebAuth Protocol. OpenWebAuth is the “single sign-on” mechanism used by Hubzilla, (streams) and other related projects. It allows a browser-based user to log in to services across the Fediverse using a single identity. Once logged in, they can be recognised by other OpenWebAuth-compatible services, ...

top 5 comments
sorted by: hot top controversial new old
[–] [email protected] 0 points 9 months ago (2 children)

This looks really odd in relation to other fediverse software; Why /magic and required to be on the root of the domain? Why hard-require routing the domain part of the user ID when .well-known/webfinger exists? Why is there a X-Open-Web-Auth header which the spec only describes as "its purpose is unclear from the code"?
So many questions.

I definitely like the idea of distributed sign-in, Solid did a decent work of that many years ago after all. This particular proposal just looks rather odd.

[–] [email protected] 0 points 9 months ago

The author wrote this FEP by reverse engineering the Hubzilla implementation. The point of proposing it is to find and answer questions like these.

[–] [email protected] 0 points 9 months ago (1 children)

I agree, and .well-known/webfinger is already largely adopted, we should build upon what we already have, not creating even more standards.

[–] [email protected] 0 points 9 months ago

OpenWebAuth has been in use on the fediverse since before WebFinger became so widely used.

Like I said in a previous comment, this FEP was written by reverse engineering the existing implementation. It's still a proposal so it still has to go through a discussion period where issues like this can be worked out and it can be updated

[–] [email protected] 0 points 9 months ago

The proposal fails to sufficiently motivate why existing protocols like OpenId Connect can't be used given that trusting the user's home instance seems necessary with this protocol too. The name also is confusingly close to WebAuthn.