Re: Comments on ISSUE:[UC-13-05:SecurityPolicy]

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

> ISSUE:[UC-13-05:SecurityPolicy] Bob Morgan proposed a business-level
> requirement as follows:
>
>      [CR-13-05-SecurityPolicy] Security measures in SAML should
>      support common institutional security policies regarding
>      assurance of identity, confidentiality, and integrity.
> ...
>
> I'm not quite sure what this requirement means. I can read it two ways:
>
> 1) SAML should have ways of encrypting, protecting integrity,
> authenticating, etc.
>
> In this case, I think we already have (or are discussing) the necessary
> requirements.

This came from my note of 13-feb-2001, which said also:

> This IMHO is the positive statement that is the counterpart of the
> non-goal of not supporting nonrepudiation requirements.

We say, in our non-goals, that we won't support nonrepudiation, and we say
we're not inventing new crypto or security technologies.  Regarding what
we *will* do I find one relevant existing requirement:

  [R-Signature] SAML assertions and messages should be authenticatable.

The requirement I proposed is intended to mean what you suggest above.
This may be motherhood-and-apple-pie, but I think it's useful to actually
say that the kinds of security services we're designing are consistent
with what people are doing in real life today, rather than inventing new
entirely new services.  Non-goal #1 (and now that I notice it, why aren't
the non-goals labelled as the Requirements are?) sort of says this; I
prefer positive goal statements if possible.

> 2) SAML should have a way of expressing an institutional policy and then
> automatically enforcing that policy through the mechanisms described in 1).
>
> This is a much bigger issue, and one that I'd definitely like to place out
> of scope.

No, that wasn't what I meant, and it seems to me would be reading a lot
into this statement.  I agree that this reading would be out of scope.

 - RL "Bob"