RE: Use Case & Requirements Doc Strawman 1 Issues List

["Mishra, Prateek" <pmishra@netegrity.com>]

>ISSUE[UC-1-01:Shibboleth] Which requirements of the Shibboleth
>security system for Internet 2
>(http://middleware.internet2.edu/shibboleth/index.shtml) are to be
>included?Should an additional use case
>scenario explicitly using Shibboleth be added to the use case and
>requirements document?

 This is a very tricky point and one that revolves around "privacy
considerations" as opposed to a use-case. It is basically a policy
issue between an AP and a subject. How about the following statement:

An AP should only release credentials for a subject to an RP 
if the subject has been informed about this possibility
and has assented. The exact mechanism and format for interaction between
an AP and a subject concerning such privacy issues is outside the scope
of the specification.


>ISSUE[UC-1-02:ThirdParty] Use case scenario 3 (single sign-on, third
>party) describes a scenario in which a Web user logs in to a
>particular 3rd-party security provider which returns an authentication
>reference that can be used to access multiple destination Web
>sites. Is this different than Use case scenario 1 (single sign-on,
>pull model)? If not, should it be removed from the use case and
>requirements document?

I would like to argue that in fact cases (1) - (3) are sub-cases
of a single use-case. There may be well be value in calling out 
all three distintly, tho' that is not entirely clear to me.

I would also strongly suggest that instead of directly using terms
like "auth reference" we use a term like "credentials artifact". The
point being there may be many ways to serve up information with creds
in them to the users browser -- we do not need to insist that a reference
is being passed.
  
[Web Browser Use-Case]

1. Subject with Web Browser Client visits AP site.
2. Subject performs authentication act at AP site.
3. AP site provides user with credentials artifact bound to browser state.
4. User visits RP site with credentials artifact; RP site authorizes subjec
access to resources based on credentials artifact.

All of the sub-cases such as: the credentials artifact is actually
a reference and the RP site must "pull" the actual assertion etc.
seem to me to be detailed sub-cases that could even be covered
in the Bindings section. As Anders has pointed out,
in fact, a POST could be used to traverse from the AP to the users
browser and from thence to the RP;
in such a case there is no need for a reference to be passed between
the sites.
There is also no need to bind the use-case to a re-direction, or,
to be concerned whether the user visited the RP first etc.

I have to admit that I am not able to follow the logic of steps
3-6 of Scenario 2. What does Step 3 mean?
Is it the user who is being authorized to
access the destination site? Or is it the source site? It would
really help to identify the parties involved in the authentication
and authorization acts. In any case, I need to understand how
it fundamentally differs from the [Web Browser Use-Case] above.

>ISSUE[UC-1-03:ThirdPartyDoable] Questions have arisen whether use case
>scenario 3 is doable with current Web browser technology. An
>alternative is using a Microsoft Passport-like architecture or
>scenario. What is the difference? Should this be done?

Please see my comments above. I agree that it is valuable to 
call out the case where a security service is being used directly
by a user. Unfortunately, a user with a browser can only interact
with a security service in limited ways and it is hard
to distinguish this from the [Web Browser Use-Case]. 
In contrast, a service
can use a security service in many more flexible ways (Case 3
of S2ML) provided, of course, we agree on a standard interface
to the security service. 

>ISSUE[UC-1-04:ARundgrenPush] Anders Rundgren has proposed on
>security-use an alternative to use case scenario 2 (single sign-on,
>push model). The particular variation is that the source Web site
>requests an authorization profile for a resource (e.g., the
>credentials necessary to access the resource) before requesting
>access. Should this scenario replace the existing use case scenario 2?
>Should it be made an additional scenario?

I would argue that what Anders is referring to is a security
service called "security discovery": given a resource protected
by a security engine we wish to query the security engine
about the security properties of the resource.
This is an important topic but completely distinct from the 
[Web Browser Use-Case]. I would strongly recommend that we
keep the two topics separated.

>ISSUE[UC-3-01:UserSession] AuthXML includes an entity called a "session"
>that is not specified by any of the use cases in Straw Man 1. What is
>a session, and what use case scenarios should be developed to specify
>the need for sessions and their use?

>ISSUE[UC-3-02:ConversationSession] Is the concept of a session between
>security authorities separate from the concept of a user session? If
>so, should use case scenarios or requirements supporting security
>system sessions be supported?

Please see my note summarizing the different session notions
sent to this list. Fundamentally, I have argued that the
main issue of interest is somehow communicating some standard attributes
(or even meta-attributes) of a loosely defined concept called
a session from one security engine to another. We probably need
some terminology along the lines used above to explain these
ideas.

- prateek mishra