OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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 2.4.3.2
(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"



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]