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.
I sent out some candidate requirements to the use case and requirements
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
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.
Online and offline authorities should be supported.
In most, if not all the scenarios I have seen widely discussed, there seems
be an assumption that the attribute authority is online and therefore
to a variety of entities (directly or indirectly). For particularly
I think it would be better to have the authority offline (and therefore
harder to attack).
Signatures should be optional
If we mandate every message is signed, then this will be bad for performance
two sites need to exchange a lot of information. Alternatives such as the
parties establishing a secure session and periodically sending a signed hash
previously sent attributes should be allowed.
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
AzData element, because this can contain arbitrary element. I am suggesting
it might be made an explicit element.)