comments on use-case strawman 2

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

(1)  Much better, thanks for the hard work.

(2)  We decided, as I recall, to use "authn" as the shorthand for
"authentication", not "authc"; because, among other reasons, for us
speakers of USA English "authc" and "authz" are pronounced very similarly.

(3)  Goal [R-Reference] either needs more elaboration or (likely) needs to
be dropped.  What is a "reference"?  It doesn't have a standard
well-understood security meaning nor is it defined in the glossary.  This
Goal seems to me to be making an assumption about a low-level mechanism
for optimizing some of the transfers.  The Scenarios do use the term
"reference" to name one of the elements that gets passed around.  In the
Scenarios I would call this element a "Sign-On Token", since it's
something the user gets back after signing on.  Since it's in the category
of "authentication  assertion" Goal [R-AuthC] (should be AuthN) already
covers the requirement that a format for this be defined.

(4)  I think we have two classes of requirements, technical requirements
like "must do push and pull" and "must be in XML", and business-level
requirements.  The only current requirements I would put in that category
are [R-MultiDomain] and [R-SingleDomain].  In another message I suggested
a requirement about policy-based disclosure.  Another requirement in this
space is, I think, what Scenario 3 is trying to get at.  Since there is no
technical distinction that I can see between Scenario 1 and Scenario 3,
the point presumably is that the "Security Service" component can be in a
different administrative domain from the user.  This IMHO should (though I
still find it to be not very compelling) be a Requirement:

  [R-ThirdParties]  The security service can be operated by a third party.

and be removed as a separate technical scenario (since it isn't).

(5)  Another business-level requirement is:

  [R-SecurityPolicy]  Security measures in [OSSML] should support common
  institutional security policies regarding assurance of identity,
  confidentiality, and integrity.

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

(6)  Regarding Use Case 1, I suggest renaming it to "Sign-On Service".
Classically this is an "Authentication Service" (parallel to Use Case 2's
"Authorization Service") but as we have seen the term "authentication" is
confusing due to overloading.  If we define "Sign-On" as "a user action to
provide evidence of identity to a system or service" then "Sign-On
Service" IMHO describes the component in question unambiguously.

(7)  I'm not sure whether Use Cases 1 and 2 were intended to meet my
suggestion of having a high-level architecture as an intro to the
requirements.  They go part of the way to do this, but not enough.  We
should incorporate Dave's domain model and Hal's proposed language:

  I suggest that the actors we are interested in are:

  User
  Authn Authority (don't feel strongly about name)
  Authz Authority (don't feel strongly about name)
  Policy Decision Point (PDP)
  Policy Enforcement Point (PEP)

where I would change "authn authority" to "sign-on service" as above.
(Yes, I see that PEP and PDP are used in Use Case 2.)  I think this would
incorporate the concepts presented in these two Use Cases so they wouldn't
be needed as separate items.

 - RL "Bob"