Regarding unlimited time keys, I think people are overreacting. When the renewal of a key is a single click on the API interface (probably on the API Home, where there would be a list of keys with a "Refresh" button on each line, however small) you are not talking about updating a load of app configs on anyones machines. You can make a setting for your own personal use, and other ones for handing out for corp purposes or to friends for advice on fits. Most people won't have more than a handful of API entries, and will be more in the habit of demising leys when leaving a corp than they will have been before. A default view setting which hides demised keys would be ideal, but with the ability to view and reinstate old keys.
Originally by: Matalino
Originally by: CCP Prism X
Granularity of customization
I'm quite open to the possibility of an Advanced Access View which would break the groups further down into calls. It does however depend on how much time I can actually get from Eve Gate developers but it's certainly not an impossibility at this point. However, all I'm ready to promise is the group granularity (for non-super users) and the templates (could even include the old full/limited defintion) which need to be completely idiot proof to serve their purpose. By all means do propose your take on how to best break this down and what templates would be most useful!
Twist some arms if you need to. Having an Advanced Access View is important. Having two layers of granularity allows the top layer to be much simipler than a single layer could be while still retaining a reasonable level of granularity. It doesn't need to be a seperate view: just have the groups as folders than expand to list the API's within them.
Since you requested proposals on how to break it down, this is what I suggest for the current API's:
Spot On. Matalino, except account/Characters.xml.aspx . A view which showed the group level but allowed outline drill into each API call would be cool, but I am really not sure how much that limits the scalability of the API system itself. if you are using in64s, that might limit you to 64 pages of API call and I for one want to see a much better Tower API expansion, detailing fits and module status, perhaps including ammunition.
The templates idea is a really good one, and it would allow corps to take a position on whether or not they are bothered about alt characters on the same account. The argument of separate accounts for the purpose of spying is a strong one against availability of account information from the API, and nobody will ask you for screenshots of all of your accounts on Eve, so the best compromise here is to keep the account's information available, but make it optional and in it's own group.That way, if a corp wants to see it but the pilot (player) doesn't, then presumably the corp won't recruit the player. Account information would obviously not be available on a Character-only key, and would need to be account-bound.