I’ve made some more updates to this FEP since my last post on this thread:
Add a sequence diagram (PR in review)
Mention that the zid= login mechanism can work with other authentication protocols too
Mention the risk of mixup attacks introduced by doing the above
Point out that a session cookie is typically used to check if the user is logged in
Briefly discuss the question of how a remotely logged in user can post to the Fediverse; mention that Hubzilla does this by signing posts using the target instance’s key
Some other minor updates based on attempting to implement it
If after 1 year the authors have not requested the proposal to be finalized, a facilitator should inquire about the status of the proposal.
Preempting this: I have not yet requested finalization for this FEP because there’s an important use case which it doesn’t cover yet: authentication/authorization of media file fetches.
Suppose that
Alice posts an image file to her instance, without making it public. Bob is allowed to view this image, but other users in general are not.
Bob visits his instance at bob.example and sees Alice’s limited-visibility post, which contains an image tag pointing to her instance: <img src="https://alice.example/my-private-picture.jpg">
OpenWebAuth can be used to demonstrate to Alice’s instance that Bob’s web browser should be allowed to retrieve the image. I don’t think this FEP should be considered to be “FINAL” without a detailed description of how this mechanism works.
I recommend changing the name of this FEP from “The OpenWebAuth Protocol” to something like “OpenWebAuth: Federated Single Sign On.”
That way people know what it is just by looking at the title. Also, to avoid confusion.
A recent question in our support forum revealed that some people thought this was a competitor to ActivityPub and was asking how to transfer posts using OpenWebAuth.
It sounds like we need to make it clear that OpenWebAuth is specifically for federated single sign on, and is not a substitute for ActivityPub or Zot6.
This sounds fair enough to me - we could certainly do without that kind of confusion - but does this mean that the “61cf” hash code needs to change too? That would break any links to it, which sounds like a bad idea.
(Perhaps this question belongs in its own thread, but I can’t start threads in this category…)
Yes, the identifier changes when the title is changed. I don’t recommend renaming because this FEP was discussed in many places and has many incoming links. However, if the rename is necessary, we can leave a markdown file with a link to the new FEP on the path of the old FEP.
At the very least, the description needs to be updated in the FEP so people don’t miss the fact that this is specifically for federated single sign on only.
If we can’t change the title because it changes the identifier of the actual FEP, we could also add a subtitle “Federated Single Sign On” in the body.
And on lists such as the README, that can say anything we want it to say since that does not affect the hash.
Add further explanation that OpenWebAuth is only for federated single sign on, and other protocols such as ActivityPub and Zot are used for federating content. Since OpenWebAuth is specifically for remote authentication, there are a variety of use cases, not just social media. For example, it could be used for commenting on blogs or logging into websites.
That way we don’t have to change the title which changes the FEP identifier, but we still can refer to it elsewhere using a different name.
If this is acceptable, I or someone else could create a merge request.
Well, the “Summary” section already opens by mentioning “single sign-on” - perhaps it just needs a more emphatic section title? I.e. “Single Sign-On for the Fediverse” or something.
I’m not too concerned with the details, really, as long as the URL doesn’t have to change, so feel free to propose something.
Sounds good. As I mentioned before, I only brought this up because we had someone come into the support forum thinking it was more than federated single sign on. So, while it is clear to us and it does mention federated single sign on, people unfamiliar with it might make assumptions otherwise.
And I agree with not changing the URL and the FEP-61cf part.