OpenID Support

That makes absolutely no sense - it's *because* you're using OAuth that OpenID support should be easy.

Whatever, thanks for the answer, I'll keep looking.

Stephen, it does make sense. OpenID is used to authenticate on site A using credentials stored on site B. OAuth lets you authorize access to site A using credentials stored on site B. The two standards have many overlapping use cases.

In any case, implementing OpenID is non-trivial as it require significant changes to our auth system, login flow, and usernames. As Ariel said, we are involved in both the OAuth and OpenID communities and we're actively participating in discussions re: a proposed merger of the standards. Until some consensus/stability is reached on the scope/overlap of the two standards we won't be implementing OpenID. If things change in the future we may re-assess the situation.

!mmalone:

Authentication and Authorization are two discrete activities as you know. There's nothing barres you to use existing usernames (and let them be changed by user anyitme) while using OpenID for authorization.

OpenID and OAuth doesn't expose a conflict of interest in anyway...
While using OpenID for authorizing access to users for site access, it's perfectly possible to use OAuth for authorizing "on-behalf access" to API.

OAuth establishes a trust channel between the API provider and consumer. There's no point to involve "Identity Provider" after establishment of API trust binding. And there's no requirement in OAuth for API provider being also the Identity Provider... In contrast, OpenID access "requires" contacting OP whenever user claims an ID. So responsibilities are well defined in here.

API Provider creates the trust binding to a consumer with OAuth for one time than let's access by authenticating requests every time without user interaction. Whenever user decides to break the coupling, an interface of API provider helps the user to provision his/her request.

Real user access to site via OpenID is completely different though...
"Relying Party" (API provider web app in the former scenario) MUST request the proof of the ownership for claimed Identity everytime. So OP should be involved in every authorization action.

Technically OpenID and OAuth can have overlapping specifications but their use cases are completely different. No end-user should care about OAuth and access granting process shouldn't be more complex than just a confirmation screen. On the other hand, in OpenID access case, user should be aware of his/her "Identifier" URI to claim an identity.

It's nice to hear Pownce team are involved in the communities of both OpenID and OAuth. I'm sure this will foster a near-perfect implementation of both standarts in Pownce, over the time.

...But I think, -with current standards- deployment of these two technologies are not mutually exclusive in anyway.

At this time, there are at least 31 people petitioning for OpenID support at Pownce. I think that most of us are more interested in using OpenID to login to our Pownce accounts, rather than using our Pownce URLs as OpenIDs.

http://demand.openid.net/site/pownce.com

I found an article which discusses OpenID, OAuth, the differences between the two, and how they can compliment each other. I thought it might be of interest to those following this thread. Here's an excerpt:

Obviously, both OpenID and OAuth are needed for a better user experience. OpenID solves the problem of having far too many usernames and passwords to remember. OAuth solves the problem of how to share information between sites without giving your password from one site to another. Together the technologies may make things simpler for the user.

http://mashable.com/2008/07/28/openid...