EVE Technology Lab

CREST depends on the SSO. It can be considered an extension of it (it's really the other way round, but it's close enough).

Getting the SSO out is a lot less risky than CREST, so it's a good first step, and gives people useful functionality.

i don't know how technically possible that is, but the actual display of which permissions are granted and the confirmation thereof should only be handled on a CCP controlled website (including signs for a working encryption ...). So no Frames that can be embedded on other websites or anything like that

i would also like an option to limit the privileges that are asked for (checkboxes that are enabled by default but can be disabled for specific permissions that you don't want to give

I would lie to point out one thing that I consider obligatory for crest to be widely accepted.

When user is presented with list of functionalities he exposes to application he have to be able to choose which items from that list he allows for the app to use and which one he dont.

That way an app can't force you to use all of potential crest functions implemented in it but only those I feel comfortable exposing.

Let's talk eve-mon for example. In imaginary future I can change skills via crest and I exposed that functionality to eve-mon. Later on CCP ship new crest functionalities - for example remapping. Eve-mon being best skill planner in the world implements it an ships an update, making all users to reaccept crest range he exposes to them.

Now let's say for the sake of argument that I do not want to expose that, but I still want to use crest for that but I still want to use eve-mon for skill changing. What I would want to see is that when eve-mon update ships I can choose not to add remapping to the list/remove from the list and eve-mon being awesome would still work without that function.

Why is it so important? Imagine different scenario. I use 'shady' betting app and all they wanted was SSO and api generation so far and I was in OK with that. I invested billions in there and then they ship an update that suddenly requires wallet transactions so it is easier for me to send more money to site and, hey - I'm not OK with that! But what can I do? I have billions there and I want them back/still want to use that site! But no. If I reject I reject all other functionalities - including SSO that is used for loging in.

What I'm asking for is this then. Granularity when aceepting crest exposure. Maybe even EULA that don't allow developers to force new functionalities on user on the ormise that otherwise they will loose access to app.

Ther e will be great applications out there when crest is out and they will implement more and more crest functions. Let us choose which of those we want to use and which one we don't like to.

Making the user able to deselect any requests is a minefield for the people maintaining apps and supporting users.

There's a couple of things that would be very useful:

1. EVE Mon was used as an example, and is a good one. It needs certain core functionality on the API or is useless, it does a lot of other things that are optional. It is very clever and will turn just work regardless of which are granted. Good programming.
However, there's no chance of it working if you turn off the character sheet. Part of the scope passed by the requesting app should be a listing of which items are optional and which are required. Those listed as optional get checkboxes.

There could also be the ability to request two different scopes and let the user pick from the two predefined ones.

2. There should also be a flag as to whether the whole API is optional or not. If it is you can just say no and continue to log on, otherwise you can still say no, but won't be able to complete log in. This can be handled by the app based on what is returned, but it would be good if the requirement is made clear i.e. that the consequences of saying no are understood.


Say I have an app that requires a certain aspect be set. As an example, alliance security systems nearly all require an account key, rather than character. If they change it to character, because the option was there and there's no clear guidance that the user shouldn't mess with this, they can't continue. The user gets kicked back to my app, and I them have to deal with telling them that the api they just made is useless and send them back. We get this all the time with the current system, because so many people just don't understand the instructions well enough and make an invalid key. I see no reason to make it so easy for them to mess up the auto generated one.

This idea has great potential to massively reduce my support workload to alliance members (then we just need to get them to understand cache timers...).


Finally: I do think it is very important that it is clear that the user can choose not to create an API key when asked.

Checking in to say this sounds great. It might also help streamline things like custom vcode masks like @fuzzysteve uses.

Check EVEMon @ File > Add API Key... > EVEMon features link in page. I know it's a little bit buried but... it's there.

On the subject of making the current API page better:

Please make the current eve websites' implementation of the SSO respect the page you requested before being redirected to login.

At present, if I follow a create predefined link, it will redirect to SSO which then dumps me on the eve homepage instead of at teh create predefined endpoint.

the only way to get it back is to then go back to the page I was sent from and click the link again.


I still want the better system to create keys using SSO though!!!!!!!! :)

For those asking about naming: the way a SSO works is that a website has to be registered with CCP before it can use it. As such, there will be a name associated with it. The name of the API key would likely be named to reference this, as that would make it easy for a user to remove the key if they so desired.

Likewise, on the SSO page as you're giving permission, it would be wise for CCP to put links to documentation about what the API key is, what it does, and how to disable it. If the user chooses to ignore it and still has no clue, that's their own fault. I see no problems with it if the information if readily available.

Expiration, due to the way it will work from a developer side, will be tricky. They'll receive the key they can use upon sign-in, but if the key expires, how would they go about getting a new one? I assume it would be another request to the SSO to get one if the current one doesn't work, but that would (I assume) be a mess on CCP's side to determine when they need to re-grant the key or even remove the old one. That's mostly semantics for how CCP decides to implement it though.

Likely, the API key would last much longer than the auth token. Once the token is used to log the user in on the developer's side, it's unneeded, which is why it can (currently) remain so short. The API key would need to be a bit longer unless the application only needed to access it once to grab information. Maybe the expiration could also be sent as a 'request' from the developer, and the user has right to turn it down/change it on the SSO permissions request page like the permissions themselves.