Oasis Security Services Use Cases And Requirements: Issues List
8 Feb 2001
This document catalogs issues with the requirements and use cases for the XML standard derived by the Oasis Security Services Technical Committee.
The issues list presented here is a catch-all of issues brought up in response to Use Case and Requirements Draft 1 as well as other issues mentioned on the security-use and security mailing lists, in conference calls, and in other venues.
Each issue is formatted according to the proposal of David Orchard to the general committee:
ISSUE:[Document/Section Abbreviation-Issue Number: Short name]
Issue long description.
Possible resolutions, with optional editor resolution
Decision
The issues are informally grouped according to general areas of concern. For this document, the "Issue Number" is given as "#-##", where the first number is the number of the issue group.
The issues are in varying levels of resolution. Some are stated as questions or placeholders for further investigation. Others are stated as problems with resolutions, and still others have full-blown use case scenarios attached.
ISSUE:[UC-0-01:MergeUseCases] There are several use case scenarios in the Straw Man 1 that overlap in purpose. For example, there are several single sign-on scenarios. Should these be merged into a single use case, or should the multiplicity of scenarios be preserved?
Possible Resolutions:
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? In particular, how to address the requirements for anonymity and privacy that Shibboleth makes? Should an additional use case scenario explicitly using Shibboleth be added to the use case and requirements document?
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?
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?
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?
The use case would be inserted as follows:
Fig X. Single Sign-on, Push Model #2.
Steps:
ISSUE:[UC-1-05:FirstContact] A variation on the single sign on use case that has been proposed is one where the Web user goes directly to the destination Web site without authenticating with a definitive authority first. Should this be added as a use case?
ISSUE:[UC-1-06:Anonymity] What part does anonymity play in [OSSML] conversations? Can assertions be for anonymous parties? What levels of anonymity can be maintained, and how should this be called out in the requirements document? Is an anonymous use case scenario needed, or should it be simply noted as a requirement?
ISSUE:[UC-2-01:AddAuthzAssertions] Some use cases proposed on the security-use list (but not in the straw man 1 document) use a concept of an "authz assertion." In concept an authz assertion is a statement of policy about a resource, such as that user "evanp" is granted "execute" privileges on file "/usr/bin/emacs." Should this type of assertion be supported in [OSSML]?
Possible Resolutions:
ISSUE:[UC-2-02:OutsourcedManagement] A use case scenario provided by Hewlett Packard illustrates using [OSSML] enveloped in a CIM/XML request. Should this scenario be included in the use case document?
The use case would be inserted as follows (some editing for clarity):
This scenario shows an enterprise A that has outsourced the management of its network devices to a management service provider B. Management messages are exchanged using CIM/XML over HTTP. (CIM or Common Information Model, is a management standard being developed by the Distributed Management Task Force - http://www.dmtf.org/, an XML DTD for CIM has been defined.)
Suppose the operator, Joe, wants to invoke the StopService method. This will be executed by the XML/CIM agent on the managed device, if authorized.
Fig
X. Outsourced Management.
Steps:
ISSUE:[UC-2-03:ASP] A use case scenario provided by Hewlett Packard illustrates using [OSSML] for a secure interaction between an application service provider (ASP) and a client. Should this scenario be included in the use case document?
The use case would be inserted as follows (some editing for clarity):
In this scenario an ASP, A, is providing an application (possible examples could be a word processor or an ERP application) to users in another enterprise, B. A VPN (for example IPSEC) is used to provide a secure end-to-end tunnel between the client and server.
A major difference between this scenario and the outsource management service scenario is that all assertions are "pulled" in this scenario. This means the assertions are not attached to application messages; instead they must be retrieved either directly from the attribute authority, or a repository. For example, once the client has been authenticated, the [OSSML] evaluation engine in the server needs to retrieve the [OSSML] assertions issued by A and B. This will involve making a request to a repository inside B, traversing both A and B's firewall as shown in the diagram. Similarly the [OSSML] engines in the gateway and client will have to retrieve assertions issued by both authorities.
Fig
X. Application Service Provider.
Steps:
ISSUE:[UC-2-04:HealthCare] A request for a use case focussing on health care and particularly HIPPA has been made in the Security Services TC. Should such a use case scenario be added to the use case document? What are the particulars of HIPPA and how are they different from other use cases?
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?
ISSUE:[UC-3-03:Logout] Should [OSSML] support transfer of information about logout (e.g., a principal intentionally ending a session)? Should a logout use case be added to an existing use case scenario, or should a new scenario about logout be added to the document?
ISSUE:[UC-3-04:StepUpAuthc] "Step-up" authentication is when a receiving party refuses to accept an authentication from an authenticating party and asks for a higher level of authentication. For example, the RP can refuse password authc and require certificate authc. Should [OSSML] support step-up authentication? Should a use case be developed illustrating step-up authc?
ISSUE:[UC-3-05:SessionTimeout] Session timeout is an event that occurs when a security system invalidates a principal's session after a period of inactivity, without action by the principal. Should communication about timeout of sessions be supported by [OSSML]? Should a use case illustrating session timeout be developed?
ISSUE:[UC-4-01:SecurityService] Should part of the use case document be a definition of a security service? What is a security service and how is it defined?
ISSUE:[UC-4-02:AttributeAuthority] Should a concept of an attribute authority be introduced into the [OSSML] use case document? What part does it play? Should it be added in to an existing use case scenario, or be developed into its own scenario?
ISSUE:[UC-4-03:PrivateKeyHost] A concept taken from S2ML. A user may allow a server to host a private key. A credentials field identifies the server that holds the key. Should this concept be introduced into the [OSSML] use case document? As a requirement? As part of an existing use case scenario, or as its own scenario?
ISSUE:[UC-4-04:SecurityDiscover] UC-1-04:ARundgrenPush describes a single sign-on scenario that would require transfer of authorization data about a resource between security zones. Should a service for security discovery be part of the [OSSML] standard?
Possible Resolutions:
ISSUE:[UC-5-01:AuthCProtocol] Straw Man 1 explicitly makes challenge-response authentication a non-goal. Is specifying which types of authc are allowed and what protocols they can use necessary for this document? If so, which types and which protocols?
ISSUE:[UC-5-02:SASL] What relationship does [OSSML] have to SASL (RFC 2222)? SASL (Simple Authentication and Security Layer, http://asg.web.cmu.edu/sasl/) is a way to add authentication to a connection-based protocol. Is there a design model for [OSSML] in SASL? Could [OSSML] augment SASL, or vice-versa?
ISSUE:[UC-5-03:AuthCThrough] All scenarios in Straw Man 1 presume that the user provides authentication credentials (password, certificate, biometric, etc.) to the authenticating system out-of-band. Could and should [OSSML] be used directly for authentication? Or should this be explicitly stated as a non-goal?
ISSUE:[UC-6-01:XMLProtocol] Should mention of a SOAP binding in the use case and requirements document be changed to a say "an XML protocol" (lower case, implying generic XML-based protocols)? Or "XML Protocol", the specific W3 RPC-like protocol using XML (http://www.w3.org/2000/xp/)?
ISSUE:[UC-7-01:Enveloping] [OSSML] data will be transferred with other types of XML data not specific to authc and authz, such as financial transaction data. What should the relationship of the documents be?
Note that of the solutions below, 2. is more useful when the conversation is mostly an [OSSML] conversation, such as for single sign-on. 3. is more useful for conversations that are mostly "other," such as XML-based server-to-server commerce.
Possible Resolutions:
ISSUE:[UC-8-01:Intermediaries] The use case scenarios in the S2ML 0.8a specification include one where an intermediary passes an S2ML message from a source party to a destination party. What is the part of intermediaries in an [OSSML] conversation? Can intermediaries add, subtract, or alter data in an [OSSML] message? Should a use case scenario involving a 3rd-party intermediary be included in the use case and requirements document?
ISSUE:[UC-9-02:PrivacyStatement] Important private data of end users should be shared as needed between peers in an [OSSML] conversation and protected entirely from hostile 3rd parties. In addition, the user should have control over what data is exchanged. How should the requirement be expressed in the use case and requirements document? Should a use case scenario illustrating privacy protection be provided?
ISSUE:[UC-9-01:RuntimePrivacy] Should protecting the privacy of the user be part of the [OSSML] conversation? In other words, should user consent to exchange of data be given at run time, or at the time the user establishes a relationship with a security system?
ISSUE:[UC-10-01:Framework] Should [OSSML] provide a framework that allows delivery of security content negotiated out-of-band. A typical use case is authorization extensions to the core [OSSML] constructs. The contra-position is to rigidly define the constructs without allowing extension.
Possible Resolutions:
ISSUE:[UC-11-01:AuthzUseCase] The use case scenarios outlined in straw man 2 include explicitly only authc use cases. Should a use case featuring an authz conversation, such as a policy enforcement point (PEP) querying a policy decision point (PDP) for authorization for a user to execute an action?
The use case would be included as follows:
This use case illustrates an authorization service that provides authorization checks for resource access.
Fig
X. Authorization Service.
Steps:
ISSUE:[UC-12-01:Encryption] UC-9-02:PrivacyStatement addresses the importance of sharing data only as needed between security zones (from asserting party to relying party). However, it is also important that data not be available to third parties, such as snoopers or untrusted intermediaries.
One possible solution for implementors is to use secure channels between relying party and asserting party. Another is to use encryption, either with a shared secret or with public keys.
Possible Resolutions: