Second, I think that for the OpenID Provider UI there needs to be a way for a RP to influence the UI. Basically, there would be one UI that is generic and totally related to the OP. This would be the default UI shown in the pop-up browser window. However, if the RP has a relationship with the OP, there should be a way for the RP to invoke the pop-up browser window such that some of the UI is customized to the RP. One feature I really like of Facebook Connect is that it gives clear UI context to what the user is doing.
I know for some OP's, its important to only allow customization from RP's that are in a relationship with the OP. This could easily be accomplished by using 2-legged OAuth and associating the UI customizations to the OAuth Consumer Token. The RP would then construct the 2-legged signed URL and load it into the pop-up browser window. The OP would verify the signature and make the necessary customization.
Here's one mock that should look familiar... (my apologies if this is what was discussed and drawn on the whiteboard. I couldn't "read" the whiteboard over the live stream. Final caveat; I'm no UI designer :)
In the default case, the RP's realm string would be displayed along with some generic text and a generic image representing the RP site. The OP image on the right would of course be unique to the OP.
In the case where an RP could provide customizations. The RP realm could be replaced by title text, the description could be specific to the relationship the user is establishing with the RP, and the RP image could be specific to the RP. To make these customizations work from a security perspective, the RP would need to obtain an OAuth Consumer token (and secret) via an out-of-band process (normal OAuth). The RP would then provide the OP with the necessary customizations during this provisioning process. These customization could include, RP realm, UI title text, UI description, and RP image. At UI display time, the OP retrieves the necessary customizations based on the OAuth Consumer token and displays the UI to the user.
With this kind of a model, the UI stays consistent and familiar to users, but also provides RP's with some ability to customize the content to their needs.
2 comments:
hmm why not extend the Association model to include customizable UI elements too ? If the OP is doing something special for a trusted RP (or an RP that is in some relationship with OP :-)) then they can as well include that in the Association process itself.
The two-legged OAuth model would be more useful if we want to support an request artifact model in OpenID to reduce the #of params passed in URL (to reduce the data transferred in as url query params). I believe Nat (or someone else) has already proposed similar approach for that.
You're correct, the association model could be used. My only concern is that associations need to succeed for the authentication event to complete. Also, they tend to occur on a more frequent basis than UI elements would change.
My rationale for using OAuth comes from thinking that the RP customizable UI is a "protected resource" at the OP. From this perspective, an RP can access the unprotected resource (the generic UI) or the protected resource (the customizable UI). OAuth is just used in it's normal flow to protect the protected resource.
I'm not too particular as to how it works. If using the association call makes more sense that's fine.
Post a Comment