OpenID in the works?

Quick question: is OpenID (or some form of PS2 authentication) scheduled?

Imagine you're running an Outfit website. It would simplify your life enormously to be able to send people to the Sony site to authenticate and then return a simple character ID (that the user can choose from among their characters). Then you can just know if the person logged in is in your outfit, their name, details, etc.

And that's just the first usage off the top of my head, seems important to 3rd parties to be able to verify identities from in game.

 

Hi Joey, and thanks for the response!

I may be dense, but this isn't an OpenID end point, I don't think, it's a auth-gateway API response, yeah? That is, if I'm a 3rd party and I send a user to this url they will just stay at this URL. Right?

OpenID works as indicated in this flow diagram: http://openid.net/pres/protocolflow-1.1.png or as explained by this blog post: http://www.windley.com/archives/2006/04/how_does_openid.shtml

(Huge apologies if you already know that.)

So ideally a 3rd party would say "What is your PS2 character URL?" (or, likely, what is your character name and 3rd party can construct the URL.)

Then the 3rd party sends you to that URL at SOE, so something like: https:/ / census.daybreakgames.com/get/ps2/CHARACTER_NAME/authorization

Then SOE would prompt for login (as above) and once logged in, SOE would send you back to the 3rd party (via the success URL provided by the 3rd party) and the 3rd party then knows you are the CHARACTER_NAME that you said you are because SOE said you "own" the URL above.

Is this process accomplished by that URL you provided? Because the thing you provided looks more like a tool for a user to find out what character IDs they own. (also useful)

Obviously, since you have the URL you provided, if you wanted to be an OpenID provider, it would be pretty simple, but it has to obey the OpenID protocol, provide the right tokens, and confirm ownership of a SPECIFIC URL.

 

How is a fansite supposed to use a cookie granted by that site/service?

 

Not to nitpick, but you don't use cookies to authenticate users on 3rd party sites, you use tokens.

 

given openId is a seperate use login/password, it won't happen.  Google and Yahoo are openId, thus you could opt to use those logins if you wanted to tie them to an account, but with all the security hoohaa Sony had... this will not happen.  Here's the main site for openId if you care, but I wouldn't hold my breathe for SOE support: [url="http://openid.net/">http://openid.net/[/url]

Does the authorization in census.daybreakgames.com also work the same on census.daybreakgames.com (where eq2's data is atm)?

 

That doesn't really make any sense.

There's no security risk associated with SOE being an OpenID provider. They wouldn't have to provide any extra password/login, it would just use the login mechanism they already have.

It's not about tying an SOE account to something else, it's about SOE telling someone else, via a very established and non-risky protocol, "yes, such and such owns this character." 

Maybe I'm missing something, but I don't see the problem.

 

Oh I know. <img src="/station/images/smilies/3b63d1616c5dfcf29f8a7a031aaa7cad.gif" border="0" /> Just asking what we're supposed to do with the setup Joey mentioned. The way it's implemented now, it elevates privileges within the browser through a cookie. That's great for sites like EQ2Players and PS2Players which are thick client websites. But I think most fansites are storing some or all data on a server and it's nontrivial for a third party server to piggyback the permissions granted by a browser cookie.

I would love to see a token system so that additional info can be shared between Census and fansites.

 

What you're missing is the fear caused by their security issues they had a year or so back.  I'm seriously doubting they will even consider an being an OpenID provider.

 

OpenID is not really important to me. I have no problem using the SOE login. I just want to be able to "prove" that someone is who they claim to be. Then someone can take ownership of their characters and add data that others can see.

Imagine a guild leader recommending equipment upgrades to their guildmates. The items would appear in that player's inbox and they could add them to their wishlist. Players would be able to add an Avatar, send messages to guildmates, etc. All kinds of social features would be possible.

 

The two are not connected. Literally, they have nothing to do with each other. It's like saying "Well, due to the way they have had security issues, they won't be providing account management."

Also, on twitter, I had interactions with Smedly who seemed interested in the idea once we showed him how Valve does it and what fans use it for.

Well, since that's exactly what OpenID is for, and it's the simplest most established way of doing this, I strongly suspect you actually are interested in OpenID. <img src="/station/images/smilies/3b63d1616c5dfcf29f8a7a031aaa7cad.gif" border="0" /> OpenID would continue to use the SOE login<span style="white-space: pre;"> mechanism.<span style="white-space: pre;">

 

What I would like to have done is have them add a character password in the options section of the character window. They could at the users option add a password that wasn't their account password to each character. Then the user would provide that character password to our site. We then could send quarry with charID and the provided PW crypted or otherwise and get back a true or false if it matched. I don't even want their login information flowing through my site, around my site or them even thinking about it while at my site lol.

 

Believe me, I'll be one of the first ones using OpenId if they provide it as my site's auth system can link to various login systems including openId.  However, security fears are still a factor, wether unfounded or not. 

I wish you luck in convincing Smedly and company.

 

Can this be used to be able to see your own characters even if you have disabled eq2players update.  Because currently you can view your own characters on eq2players when logged in, even if eq2players updates is disabled.

 

You need to try to undersand how OpenID works.

This suggestion is just utterly ridiculous in the face of OpenID. OpenID is simpler, doesn't require an extra password added, is more secure than what you've suggested, and doesn't involve any login information passing through your site.

 

In 15 months of the Data forums existence, there hasn't been a cross word between API users. Let's please keep it civil.

Would SOE adopting OpenID allow users to selectively choose which API-powered sites can access their data, and allow the user to revoke access to that data at any time? 

 

It'd be nigh similar to how you describe what could happen now.  Effectively, the user would log into the SOE OpenId first (either from the API site or still be logged from SOE's site, kinda like google keeps you logged in across multiple sites... cuz google is openId) and then use the API site with their credentials confirmed.

and yes, that's prolly not the exact technically correct details, but that is more or less what happens.

 

As ... kind of outlined above, that's not how it works.

You're thinking of OAuth, generally. (Currently OAuth2 is the standard, I believe).

OAuth is designed to allow 3rd parties to have access to private information that's revokable, whereas OpenID is just to confirm identity. You CAN pass back different infortmational bits of identity information (first name, last name, email, etc.) via OpenID.

However, in this context, you really only need to confirm the ownership of a character name. Character names are unique across all PS2 servers, so once you have that confirmed, you can pull the information you need from the public API for the details on your visitor.

 

Feldon, I enabled Google and Yahoo signon's for my site just a little while ago.  These are both OpenID.  Feel free to see them in action, which really only makes a nice one-click login for my site.  For SOE, as mentioned, getting the data you can get through that authorization link you mentioned prior in this thread is about what you'd be able to pull.

Essentially, when linking the account, my site redirects to a google/yahoo site and it makes them login (if not already) and then asks the user if they want to allow my site to use this feature.  Even shows what it's allowing the site access to.

 

If all you want to do is confirm ownership of a character, I'm not sure it's even worth the development effort for SOE to add OpenID.

If SOE wants to allow fan sites to access "opted out" characters, then that's accessing private/hidden data and it needs to be secure. And SOE needs the ability to shut out fan sites that abuse that data at either the account level or the entire fan site. If OpenID is capable of all this, then I'd like to hear more. If not, then let's move on.

Additional: Here's the thing... In the case of SOE Data Feeds, it's not the user or the browser that is asking for more permissions to be granted. It is the FAN SITE that is asking for access to data not otherwise available. Why isn't the fan site getting permission directly from SOE through a token system? Maybe I'm just showing my ignorance for OpenID, but it just seems the browser and sessions is the wrong place to do this.

Again if OpenID is ideal for this, then I'll shut my big trap.

 

If all you want to do is confirm ownership of a character, I'm not sure it's even worth the development effort for SOE to add OpenID.

If OpenID were particularly complicated, if they didn't already have a login proxy in front of the API, or if there were not already libraries in pretty much every conceivable language that already do the OpenID work, I might agree. However, it's not particularly complicated and the facilities for doing it are pretty much already there. See below for what this gains us.

<span style="color: #444444; font-family: verdana, arial, helvetica, sans-serif; font-size: 11px; background-color: #f3f5ff;">If SOE wants to allow fan sites to access "opted out" characters, then that's accessing private/hidden data and it needs to be secure. And SOE needs the ability to shut out fan sites that abuse that data at either the account level or the entire fan site.

Opted out characters are still owned by their owners. What data you can get to regarding those characters is out of the scope of this request. If you've opted out and you don't want your stats shown, then when a 3rd party asks for stats about your character ID, they will/should not get it. You see this in how Valve uses the API for Dota2... dotabuff can't get your info if you've decided to disallow 3rd parties from seeing your stats, but it can still identify you when you log in via their OpenID implementation.

SOE COULD decide "well, let's allow people to opt out of public statistics, but then allow them to authorize 3rd parties to look at their stats on a case-by-case basis." I mean, there's definitely scenarios where this might be useful (and this is where OAuth would come in) but again, it's outside the scope of this request. This request is just "confirm that visitor to my site owns character X."[1]

This allows PlanetSide2 forums to show stats about posters, it allows outfit sites to not have to do management of who is in or out of the outfit, it prevents users from having to have/memorize "yet another set" of login/password details, it also allows the site not to have to worry about hosting credential information, etc. Simple implementation, good reward in exchange.

<span style="color: #444444; font-family: verdana, arial, helvetica, sans-serif; font-size: 11px; background-color: #f3f5ff;">It is the FAN SITE that is asking for access to data not otherwise available. Why isn't the fan site getting permission directly from SOE through a token system? 

It does, essentially. There's token exchange between the fan site and SOE, that's the main part that's missing, currently. In the OpenID scenario, SOE simply doesn't do the token exchange with the fan site unless the user that's logged in on the SOE end matches the character the fan site is asking to confirm ownership for. These cryptographically generated tokens do the only thing OpenID is interested in: verifying identity in a safe manner, but since it's all token/REST based, the SOE cookies stay with SOE, the fan sites' cookies stay on that site, etc.

And yeah, this is basic OpenID stuff, but I understand the whole exchange is a little complicated. Fortunately, as I mentioned, there's plenty of OpenID libraries out there that implement the protocol and so if you want to use it (as either provider or consumer), it's pretty straight forward.

1. Granted, SOE might want to allow 3rd parties to request email address in their initial exchange, but as mentioned above, SOE would say "X is requesting to identify you and in addition grant them your email address." This is pretty standard fare, but the critical part is the character identification; the email address would just be for correspondance convenience and to allow plugins for common 3rd party CMS/forum sites, but the fan site could just as easily ask for it after confirming Character ownership.