RE: Interim requirements

["Edwards, Nigel" <Nigel_Edwards@hp.com>]

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.)