John,
There is a requirement to bind a user's clearance (i.e.
security-classification and security-categories) authorizations to her
identity and public key.
Good - that's one use. (Mind you - it does seem to assume the
recipient's AC is long-lived, which not all authorization
policies would allow).
I guess another potential use of labels within ACs would be for a
gateway to control message routing based on the originator AC and
other info.
A different scenario that may be relevant is a "permission to
publish" attribute, perhaps with a mail list name as its value.
The intent would be that the mail list would only accept incoming
messages where the originator has the required attribute(s). Now this
one may lead to some trickiness - firstly, it may be appropriate
for the mail list to remove the originator's AC (it could be
usable for lots of things which we don't want the entire list
to know about) and, secondly, multiple expansions could occur
meaning that different ACs may be needed at different stages.
The recent draft on "role" names might also be calling for
functionality which can be implemented using ACs.
I guess people will identify other potential uses of
ACs (even limiting ourselves to mail). The step after that
would presumably be to accept or reject the different
scenarios and then consider how best to pack the
ACs with the messages.
Regards,
Stephen.