[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: issuer, validity, processing rules
I had an action item from the F2F to clarify the relationship between Issuer and underlying signature or other protection. I don't have spec text to offer (yet), but let me suggest some philosophy and a modest addition to the core spec. We discussed the test that appears at the beginning of most (or all?) the Processing Rules sections in the SAML protocols in sections 3.x: The recipient MUST validate any signature present on the request or response message. To be considered valid, the signature provided MUST be the signature of the <Issuer> contained in the message. I suggest that, along the lines of these Processing Rules, that there are primitive operations called "processing" (or perhaps "validating") a SAML assertion, and a SAML protocol message; and that these can be described once (each), so that then they can be referred to in SAML protocol definitions and profiles. For assertions this would say something like: A party processing/validating a SAML assertion: MUST verify any XML signature applied to the assertion; MUST verify the validity of all Conditions elements; SHOULD evaluate Advice elements; MUST verify that the identity of the assertion Issuer is supported by the security mechanisms via which the assertion was provided (signature, SSL, etc), consistent with the party's policy; does any statement-specific processing/validation (maybe something about Subject Confirmation here?). The Conditions part of this is already written down in section 220.127.116.11 (lines 612-629 of core-2.0-draft-09-diff.pdf), but the language there has to weasel that there might be other validity considerations ... so better I think to gather up all this processing and give it a name, so it can be referred to easily in higher-level processing rules: "Step 1: validate assertion. Step 2: ...". The above is about assertions, similar language would be written about processing protocol messages in general. Regarding Issuer, the contorted processing language above tries to explain the fundamental semantics of a SAML assertion: that when an assertion is issued by an authority, the Issuer field expresses the identity of that authority; and that the result of processing/validating an assertion is that that identity is accepted, based on the relying party's policy, as being the authority that provided this assertion; so policies that use SAML assertions as input can be written based on Issuers, Subjects, and the various statement elements, rather than the details of signatures or other underlying security mechanisms. I'm sure there are better ways to say this, but I think this is the basic concept. - RL "Bob"