Even though it is possible, it is usually a good idea to keep claims "coarse grained". By default, in a web app, the claimset will be sent back and forth on each request (as it is serialized in cookies), so you will have a potentially rather large payload going across the network.
You can override this by configuring WIF to use "session" as opposed to cookies, but...you get all the disadvantages of server side session (e.g. configuration for WebFarms, affinity, etc)
The other thing to consdier with this approach is the maintenace of that knowledge in the STS. You will need to keep a rather large set of rules to issue these claims that are likely to change often.
You definitely don't want all these in a central infrastructure STS as it will become the bottleneck of potentially large set of apps. So you will end up putting all these logic into a RP-STS (and STS that is associated with your app). Not impossible, but probably inconvenient.
Typically, the biggest advantage of a "permission" claim is that the Authorization manager is tricial to write:
if( PrincipalContainsDocumentClaim( documentYouAreTryingToOpen )
ShowDocument(documentYouAreTryingToOpen );
else
AccessDenied(documentYouAreTryingToOpen );
I think a better approach is to have an authorization manager that is able to answer the questions:
bool HasAccess( IPrincipal p, string document )
Inside that component you'd use the claimset to decide whether user has access or not. That logic might include mapping of roles, usersnames, and maybe other "higher order" claims (e.g. the org you belong, the country you are in, etc) into permissions.
Another problem of "permission claims" is that if you make a change (e.g you grant access to logged in user) how do you refresh the claimset? You'd have to logoff-logon which is normally not a great user experience.