Let me summarize the previously agreed upon solution: The idea was to have two parent interfaces AuthenticationInfo and AuthorizationInfo, which would be used in the Authentication and Authorization subsystems only (i.e. no compile-time dependency between the two), which would be quite nice in maintaining separation of concerns. The Account interface would then just become a sub interface of both, to make it super easy for end-users to just implement one interface and be be done with it.
Now the challenge: I did a search for where the Account interface is being used - there are over 130 usages. The problem is that every place in the Authentication subsystem that references Account would have to be refactored into using AuthenticationInfo. Account would essentially be a util class, or maybe just visible to the realm package and not anywhere else. While the IDE can refactor this quite easily and I don't foresee any problems there, this touches _A LOT_ of code. My preference is to just get 0.9 final out with the way things are now and do this kind of change once we move the codebase into the ASF incubator SVN repo. My thinking is that if such a change would be viewed as invasive by end-users, then it is better to introduce such change when we switch over to the package structure of org.apache.jsecurity.*. That is, it is much better to just get any invasive changes out at the same time in one lump to minimize the perceived overhead instead of trickling potential causes of irritation over time. Any thoughts?
