Delete if you are on the use case and requirements list. This is a slightly reworked version of what I posted yesterday to that list.

Hi Phill, I sent out some candidate requirements to the use case and requirements group yesterday. Two or three of them are candidates for adding to your list of interim requirements. There is quite a lot of overlap between the use-case and core-assertion group, but as far as I can tell you are not subscribed to the use-case list.

Below is a lightly edited version of my email to the use-case list, with one requirement (concerning firewall traversal) removed, as it is not something for the core-assertion group to consider.

[R-OfflineAuthorities] Online and offline authorities should be supported. In most, if not all the scenarios I have seen widely discussed, there seems to be an assumption that the attribute authority is online and therefore accessible to a variety of entities (directly or indirectly). For particularly sensitive cases, I think it would be better to have the authority offline (and therefore harder to attack).

[R-OptionalSignatures] Signatures should be optional If we mandate every message is signed, then this will be bad for performance when two sites need to exchange a lot of information. Alternatives such as the two parties establishing a secure session and periodically sending a signed hash of previously sent attributes should be allowed.

[R-AuthzDecisionRefused] Metadata should be provided for denied requests. If a request for authorization is denied, optionally metadata indicating why the request is denied should be returned. (An example might be "credit card expired".) (As an aside, I believe this is already implicitly allowed by the S2ML AzData element, because this can contain arbitrary element. I am suggesting it might be made an explicit element.)