We're reading this paper to learn about one example of existing user authentication technology, with an eye towards whether it makes sense for use with decentralized applications.
Suppose an RP has never seen a particular user before, and that user registers with the RP using OpenID for the first time. What useful information can the RP thereby learn about the user, and with what level of assurance? Why is it worthwhile for the RP to bother using OpenID to authenticate the user at all?
Is it reasonable to use OpenID for sign-in for applications that run solely in browser JavaScript (for example Snake, or applications written for Blockstack or Solid)?
Is OpenID helpful for applications that use end-to-end cryptography, and thus need to know other users' public keys?
Is there a way to use OpenID to help with *other* users' identities, for example to check that one is really reading/write a specific other user's data in a decentralized application?
Would it make sense to put OpenID identity strings (e.g. the paper's "www.johndoe.com") into access control lists?
What is the specific check that the RP and/or OP use in Figure 1's step 8 to verify that the user is who they way they are? Why can't a user trick an RP by sending something misleading at step 7? The paper is not clear about this; it might be useful to find a more detailed protocol description on the web.
After a user has finished signing into an RP, how does the RP verify that succeeding requests (i.e. HTTP GETs and POSTs) come from that same user?
Given that an RP may never have heard of a particular OP, and has no special reason to trust it, why does it make sense for an RP to even bother consulting that OP about user identity?
Suppose a malicious user is operating an OP, creates an OpenID ID at that OP, and uses it to open new accounts on some web services. You would think that any notion of "identity" claimed by such a user would be worthless. Is that a problem?