[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Some candidate requirements
I'd like to offer up the following candidate requirements for the final specification. For the purposes of this exercise, I will call the final specification X-Auth. By "attribute authority", I mean whatever is issuing the name assertion, entitlement or responding to the AzRequest in S2ML 1. 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). 2. At least one of the protocol bindings should support secure firewall traversal. Secure firewall traversal is one in which the inbound message is authenticated and authorized (using X-Auth). The reason for this, is that in many cases, the attribute authority that needs to respond to a request may be behind a firewall. 3. 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. 4. 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.) -- Nigel Edwards <nigel_edwards@hp.com>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC