<div dir="ltr">On Tue, Sep 24, 2013 at 4:01 PM, Atwood, Mark <span dir="ltr"><<a href="mailto:mark.atwood@hp.com" target="_blank">mark.atwood@hp.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>| It's actually opposite of how you describe. Writing a good OpenID consumer<br>
is hard due to user interface design issues,<br>
| especially since most people (even most technical people) have no idea how<br>
to properly use OpenID. Education efforts<br>
| have been ongoing for 8 years, so that won't really help either.<br>
<br>
</div>Except that in our case, all our apps are *already* OpenID consumers.  There<br>
is no additional education or development needed here.<br>
<br>
Standing up another provider is more work.  Making our existing apps be<br>
provider agnostic is less.<br>
<span><font color="#888888"><br></font></span></blockquote><div><br></div><div>It's generally less work to use a centralized provider and it's definitely more friendly to end users.</div><div><br></div>
<div>If every application is provider agnostic each one of them will have their own OpenID consumer interface. This means it's necessary to make all of them look the same, which requires modifying a lot of applications. Adding different auth mechanisms (like persona) means adding it to every single application, too.</div>


<div><br></div><div>By having a centralized provider, you keep the login workflow of clicking "log in" on any of the applications, which will redirect users to a consistent login interface. Assuming we wanted to allow OpenID as a consumer, or persona, we'd only have to add it to a single location, rather than to every single application we use.</div>


<div><br></div><div>- Ryan</div></div></div></div>