Epitrope
The Citadel Manufacturing and Trade Corporation
|
Posted - 2011.02.07 23:54:00 -
[1]
This is fantastic news!
On the subject of key expiration, I think a good balance between usability and security would be to have the option to extend a key's lifetime. If the player never uses it, and the keyholder never talks to the player, there's no reason the keyholder should be able to keep the key indefinitely. The key expiration date should be part of the key capabilities API, of course.
I don't have a problem with having key management in EVE Gate. Parts of EVE Gate are designed for sharing, and apparently there have been problems with losing sharing settings and resetting to bad defaults. API key management wouldn't ever be designed that way. As proof that security is being kept in mind during design, see the key expiration idea.
I would like API-level permissions in addition to group-level permissions. Simplicity is good, but EVE has a lot of complexity, and security isn't necessarily the best thing to trade for simplicity. Plus, I would imagine that if the applications can request keys, there would be very little direct key generation or editing.
As Stillman pointed out, there is an access log web page, but I think what people are asking for (and what I'm asking for!) is an API version of it. If one already exists and I just don't know about it, please enlighten me!
Applications should be able to request a key, not just have one given to them. As Ix pointed out, the application should be able to say "these are the calls I need to work" and "these are the calls that would enable optional functionality". It would be nice if applications could organize API calls into features, sort of like custom groups, which could be selected or deselected as a whole. It wouldn't be very useful, for example, to grant permission to use the mail bodies API call but not the mail headers call.
I'd imagined an application being able to request a key with only a character name; although this presents the potential for spam, rate limiting and having a maximum pending key request queue size should make it reasonable.
OAuth might be one way to do that, but I'm weakly against it in this instance. It seems to me to be needless complexity, an external dependency for application writers, and to not gain much for all of that. I haven't heard many arguments in favor of OAuth beyond "avoid Not Invented Here syndrome!" It's probably my understand of OAuth is incomplete; what am I missing?
I'm very much in favor of character-only keys. There are use cases for knowing what characters are on an account, such as for skill monitors to only complain when none of those characters are training. Recruiting has always seemed very invasive to me, however, and if it will be possible to see what characters are on an account, that API call should be optional and not the default. Privacy is more important to me than recruiters' convenience.
These are exciting times for the API. Go Prism X and Stillman!
|