RE: Promote "Optional Signature" to Requirement

[George_Robert_Blakley_III@tivoli.com]

Philip,

>The idea of the ESA requirements analysis scheme is to uncover the
>requirements that tend to be embedded in architecture. It is not a
question
>of requirements having higher status than architecture. Each architectural
>statement must be supported by a requirement statement. Each requirement
>statement must either have one or more architectural elements that satisfy
>it or an explanation as to why it was not met. The idea is that the
>architecture contains all the statements that make it into code:-)
>
>The basic idea of the analysis is to be able to identify the reasons
>behind the design after the fact. A big problem with IETF specs is that a
>lot of the design rationale is lost and you have to find someone from the
>original team if you want to fiddle with it. This in turn leads to
>superstitious treatment of features whose justification is long gone or
>inapplicable.

I agree entirely with your concern that we shouldn't lose design rationale
in our final work product, and
I think the ESA approach seems good.

>We can try a different method of structuring the dialogue on the
>list. However I am anxious to avoid the typical IETF approach in which
>requirements, design elements etc are all thrown onto the list and have
half
>of them forgotten in the drafts...

I don't object to the ESA scheme and don't propose to change our approach
at this point -- your
explanation of the approach is very helpful (in fact I'm glad I screwed up
in public, because I suspect
that others will also benefit from your explanation.  I apologize if I made
you repeat yourself; I didn't
get onto all of the subgroup lists immediately).

>I would add the following two requirements:-
>
>[R-IntraDomain] Efficiently support communication of auth data intra
domain.
>    {describe bob's scenario here}

I don't object to this proposal in general, but I'm not sure it captures
everything I wanted to say.  I agree
with the intra-domain requirement, but I intended the same sort of thing to
apply, for example, to VPN
extranet configurations.  The basic sense of what I'm trying to get at is
simply that
the level and nature of threats is a feature of the protocol environment,
not a
feature of the tokens, and that therefore the countermeasure ought to be
chosen
to be appropriate to the protocol environment rather than being hardcoded
into
tokens which will be used in a variety of different protocols

>[R-IdentifyMessages] Distinguish between messages from different versions
of
>the protocol.

Again this is close to what I intended but not exact.  I want to be able
to distinguish between differnt versions of *tokens* even when they're used
in the same version of a protocol binding, unless we want to decide in
advance
that use of a different version of token always implies that a new version
of
each protocol is (implicitly or explicitly) created.

>Then add in Bob's solutions to the problems in the architecture piece
pretty
>much as is.
>
>An alternative solution to [R-IdentifyMessages] is to use the XML name
>space.


--bob

Bob Blakley
Chief Scientist, Security
Tivoli Systems, Inc.