[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Use Case & Requirements Doc Strawman 1 Issues List
>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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC