RE: comments on use-case strawman 2

[Darren Platt <dplatt@securant.com>]

Bob,

> (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.

We'll make this change as part of straw man 3.


> (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.

We will create a new issue on the issue list in the SSO group to begin to
work this issue.  We will not vote on it this week.


> (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,

I think we may have done a better job capturing that difference in the issue
list this time - check out ISSUE[UC-1-02:ThirdParty].  Does this capture
hyour requirement, or would you like us to add a new issue to the group with
this requirement?


> (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.

We will add this to the issue list.  Please provide any supporting text you
would like included.  I'm not sure what it means specifically.


> (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.

We will add this as an issue to the list.


> (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.

At this stage in the process are use cases are intentionally specific about
the actors.  It was felt that the work of abstracting out the commonalities
is best left for the design phase.

As an example, with UC-1, the use case is one of web single sign-on.  The
actors are a web user, a source web site and a destination web site.  If we
change this terminology to principal, AA, and PEP for example, we would lose
the information about the actual concrete usage.

Perhaps we should open a new issue to change the concrete names in the
document to this common terminology, and debate this on the mailing list.
Let me know if you would like to proceed this way.

Regards,

Darren