tag:blogger.com,1999:blog-34275044.post2388692215410652843..comments2023-04-23T07:00:02.839-04:00Comments on Identity in Practice: OpenID UX Summit MusingsGeorge Fletcherhttp://www.blogger.com/profile/12081110172957645007noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-34275044.post-68602873815061353152009-02-13T14:56:00.000-05:002009-02-13T14:56:00.000-05:00You're correct, the association model could be use...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.<BR/><BR/>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.<BR/><BR/>I'm not too particular as to how it works. If using the association call makes more sense that's fine.George Fletcherhttps://www.blogger.com/profile/12081110172957645007noreply@blogger.comtag:blogger.com,1999:blog-34275044.post-52568953265890598552009-02-13T13:36:00.000-05:002009-02-13T13:36:00.000-05:00hmm why not extend the Association model to includ...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.<BR/><BR/>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.Praveenhttps://www.blogger.com/profile/10778095038892167017noreply@blogger.com