Oasis Security Services Use Cases And Requirements: Issues List

26 Feb 2001

Purpose

This document catalogs issues with the requirements and use cases for the Security Assertions Markup Language (SAML) developed the Oasis Security Services Technical Committee.

Introduction

The issues list presented here documents issues brought up in response to Use Case and Requirements drafts 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.

Issues

Group 0: Document Format & Strategy

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:

1. Merge similar use case scenarios into a few high-level use cases, illustrated with UML use case diagrams. Preserve the detailed use case scenarios, illustrated with UML interaction diagrams. This allows casual readers to grasp quickly the scope of SAML, while keeping details of expected use of SAML in the document for other subcommittees to use.
2. Merge similar use case scenarios, leave out detailed scenarios.

Status: Open

ISSUE:[UC-0-02:Terminology] Several subcommittee members have found the current document, and particularly the use case scenario diagrams, confusing in that they use either domain-specific terminology (e.g., "Web User", "Buyer") or vague, undefined terms (e.g., "Security Service.").

One proposal is to replace all such terms with a standard actor naming scheme, suggested by Hal Lockhart and adapted by Bob Morgan, as follows:

1. User
2. Authn Authority
3. Authz Authority
4. Policy Decision Point (PDP)
5. Policy Enforcement Point (PEP)

A counter-argument is that abstraction at this level is the point of design and not of requirements analysis. In particular, the real-world naming of actors in use cases makes for a more concrete goal for other subcommittees to measure against.

Another proposal is, for each use case scenario, to add a section that maps the players in the scenario to one or more of the actors called out above.

Possible Resolutions:

1. Replace domain-specific or vague terms with standard vocabulary above.
2. Map domain-specific or vague terms to standard vocabulary above for each use-case and scenario.
3. Don't make global changes based on this issue.

Status: Open

ISSUE:[UC-0-02:Arrows] Another problem brought up is that the use case scenarios have messages (arrow) between actors, but not much detail about the actual payload of the arrows. Although this document is intended for a high level of analysis, it has been suggested that more definite data flow in the interaction diagrams would make them clearer.

UC-1-08:AuthZAttrs, UC-1-09:AuthZDecisions, and UC-1-11:AuthNEvents all address this question to some degree, but this issue is added to state for a general editorial principle for the document.

Possible Resolutions:

1. Edit interaction diagrams to give more fine-grained detail and exact payloads of each message between players.
2. Don't make global changes based on this issue.

Status: Open

Group 1: Single Sign-on Push and Pull Variations

ISSUE:[UC-1-01:Shibboleth] The Shibboleth security system for Internet 2 (http://middleware.internet2.edu/shibboleth/index.shtml) is closely related to the SAML effort. An attempt has been made to address the requirements and design of Shibboleth in the SAML requirements document to allow implementation of SAML to be part of, or at least interoperable with, Shibboleth implementations.

In particular, the following issues have been introduced to address Shibboleth requirements:

• UC-1-04:ARundgrenPush
• UC-1-06:Anonymity
• UC-1-07:Pseudonymity
• UC-1-10:UntrustedPartners
• UC-4-04:SecurityDiscovery
• UC-9-03:PrivacyStatement
• UC-9-04:RuntimePrivacy

If these issues, along with the straw man 2 document, have addressed the requirements of Shibboleth, then the subcommittee can address each issue on its own, rather than Shibboleth as a monolithic problem.

Possible Resolutions:

1. The above list of issues, combined with the straw man 2 document, address the requirements of Shibboleth, and no further investigation of Shibboleth is necessary.
2. Additional investigation of Shibboleth requirements are needed.

Status: Voted, Resolution 1 Carries

Voting Results

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?

As written, the use case is not truly different from use case scenario 1. However, if the use case scenario is expanded to include multiple destination sites, the importance of this use case becomes more apparent.

The following edition to the single sign-on, third party use case scenario would be added:

In this single sign-on scenario, a third-party security service provides authentication assertions for the user. Multiple destination sites can use the same authentication assertions to authenticate the Web user. Note that the first interaction, between the security service and the first destination site, uses the pull model as described above. The second interaction uses the push model. Either of the interactions could use a different single sign-on model.

Fig. X. Single Sign-on, Third-Party Security Service

Steps:

1. Web user authenticates with security service.
2. Security service returns SAML authentication reference to Web user.
3. Web user requests resource from first destination Web site, providing authentication reference.
4. First destination Web site requests authentication document from security service, passing the Web user's authentication reference.
5. Security service provides authentication document to first destination Web site.
6. First destination Web site provides resource to Web user.
7. Web user requests link to second destination Web site from first destination Web site.
8. First destination Web site requests access authorization from second destination Web site, providing third-party security service authentication document for user.
9. Second destination Web site provides access authorization. 10. First destination Web site provides authorization reference to Web user.
10. Web user requests resource from second destination Web site, providing authorization reference.
11. Second destination Web site provides resource.

Possible Resolutions:

1. Edit the current third-party use case scenario to feature passing a third-party authentication assertion from one destination site to another.
2. Remove the third-party use case scenario entirely.

Status: Voted, Resolution 1 Carries

Voting Results

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.

It seems that at least one possible solution for the third-party security system exists -- that each destination site pass the authentication assertion from the third party security service to the next destination site, just as in peer source and destination scenarios such as use case scenarios 1 and 2.

Therefore, it seems that the scenario is at least theoretically implementable. It will be up to the other subcommittees and implementors of the standard to decide on how to define that implementation.

Possible Resolutions:

1. The use case scenario should be removed because it is unimplementable.
2. The use case scenario is implementable, and whether it should stay in the document or not should be decided based on other factors.

Status: Voted, Resolution 2 Carries

Voting Results

Bob Blakley noted, "I think the proposed implementation only works if you follow direct links, and not if you pick destinations from a history list, use bookmarks, etc..."

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.

Fig X. Single Sign-on, Alternative Push Model.

Possible Resolutions:

1. Use this variation to replace scenario 2 in the use case document.
2. Add this variation as an additional scenario in the use case document.
3. Do not add this use case scenario to the use case document.

Status: Voted, No Conclusion

Voting Results

Bob Blakley noted, "I can't really see how to do this without significant changes to the current link resolution architecture of web sites -- specifically without making sure both source and destination are expecting to have to handle this flow."

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.

A single sign-on use case scenario would be added as follows:

In this single sign-on scenario, the user does not first authenticate with their home security domain. Instead, they go directly to the destination Web site, first. The destination site must then redirect the user to a site they can authenticate at. The situation then continues as if in a single sign-on, push model scenario.

Single Sign-on, Alternative Push Model

Steps:

1. Web user requests resource from destination Web site.
2. Destination Web site determines that the Web user is unauthenticated. It chooses the appropriate home domain for that user (deployment dependent), and redirects the Web user to that source Web site.
3. Web user authenticates with source Web site.
4. Source Web site provides user with authentication reference (AKA "name assertion reference"), and redirects user to destination Web site.
5. Web user requests destination Web site resource, providing authentication reference.
6. Destination Web site requests authentication document ("name assertion") from source Web site, passing authentication reference.
7. Source Web site returns authentication document.
8. Destination Web site provides resource to Web user.

Possible Resolutions:

1. Add this use case scenario to the use case document.
2. Do not add this use case scenario to the use case document.

Status: Voted, No Conclusion

Voting Results

Bob Blakley said, " I agree that servers will have to do this, but it can easily be done by writing HTML with no requirement for us to provide anything in our specification."

ISSUE:[UC-1-06:Anonymity] What part does anonymity play in SAML conversations? Can assertions be for anonymous parties? Here, "anonymous" means that an assertion about a principal does not include an attribute uniquely identifying the principal (ex: user name, distinguished name, etc.).

A requirement for anonymity would state:

[CR-1-06-Anonymity] SAML will allow assertions to be made about anonymous principals, where "anonymous" means that an assertion about a principal does not include an attribute uniquely identifying the principal (ex: user name, distinguished name, etc.).

Possible Resolutions:

1. Add this requirement to the use case and requirement document.
2. Do not add this requirement.

Status: Voted, Resolution 1 Carries

Voting Results

ISSUE:[UC-1-07:Pseudonymity] What part do pseudonyms play in SAML conversations? Can assertions be made about principals using pseudonyms? Here, a pseudonym is an attribute in an assertion that identifies the principal, but is not the identifier used in the principal's home domain.

A requirement for pseudonymity would state:

[CR-1-07-Pseudonymity] SAML will allow assertions to be made about principals using pseudonyms for identifiers.

Possible Resolutions:

1. Add this requirement to the use case and requirement document.
2. Do not add this requirement.

Status: Voted, Resolution 1 Carries

Voting Results

In support of Resolution 1, while voting, Bob Blakley said, "I'm really ambivalent about this. At an implementation level AND at a specification level, I can't see how a pseudonym should differ from a 'real' name. If it shouldn't, then we have no work to do. However, we should at least discuss the issue."

ISSUE:[UC-1-08:AuthZAttrs] It's been pointed out that the concept of an "authentication document" used in the use case and requirements document does not clearly specify the inclusion of authz attributes. Here, authz attributes are attributes of a principal that are used to make authz decisions, e.g. an identifier, or group or role membership.

Since authz attributes are important and are required by [R-AuthZ], it has been suggested that the single sign-on use case scenarios specify when authz assertions are passed between actors.

Possible Resolutions:

1. Edit the use case scenarios to specify passing authz attributes with authentication documents.
2. Do not specify the passing of authz attributes in the use case scenarios.

Status: Voted, Resolution 1 Carries

Voting Results

ISSUE:[UC-1-09:AuthZDecisions] The current use case and requirements document mentions "Access Authorization" and "Access Authorization References." In particular, this data is a record of a authorization decision made about a particular principal performing a particular action on a particular resource.

It would be more clear to label this data as "AuthZ Decision Documents" to differentiate from other AuthZ data, such as AuthZ attributes or AuthZ policy. To this point, the mentions of "access authorization" would be changed, and a new requirement would be added as follows:

[CR-1-09-AuthZDecision] SAML should define a data format for recording authorization decisions.

Possible Resolutions:

1. Edit the use case scenarios to use the term "authz decision" and add the [CR-1-09-AuthZDecision] requirement.
2. Do not make these changes.

Status: Voted, Resolution 1 Carries

Voting Results

ISSUE:[UC-1-10:UnknownParty] The current straw man 2 document does not have a use case scenario for exchanging data between security services that are previously unknown to each other. For example, a relying party may choose to trust assertions made by an asserting party based on the signatures on the AP's digital certificate, or through other means.

The following use case scenario would illustrate using assertions from an unknown party.

In this scenario, an application service provider has a policy to allow access to resources for all full-time students at accredited 4-year universities and colleges. It would be difficult for the application service provider to maintain agreements with hundreds of such organizations in order to verify assertions made by those parties. Instead, it chooses to check the key of the asserting party to ensure that the asserting party is a 4-year university.

Fig X. Unknown Partner

Steps:

1. Student authenticates to university security system.
2. University provides authentication document to student application, including authentication event data and authorization attributes.
3. Student application requests resource from application service provider. Request includes authentication document.
4. Application service provider makes a trust decision about the authn and authz data, based on the key used to sign the assertion. It determines that the signing party is an accredited 4-year university, based on a signature on the key made by an accrediting organization.
5. Application service provider makes an authorization decision based on the authz attributes of the student.
6. Application service provider returns resource to the student.

Possible Resolutions:

1. Add this use case scenario to the use case document.
2. Do not add this use case scenario to the use case document.

Status: Voted, Resolution 2 Carries

Voting Results

In voting for resolution 2, Bob Blakley said, " I think this overspecifies behavior... both the 'interesting' flows in the diagram here are from the Application Service Provider to *itself*. Why should we tell the A.S.P. how to make trust decisions about assertions?"

ISSUE:[UC-1-11:AuthNEvents] It is not specified in straw man 2 what authentication information is passed between parties. In particular, specific information about authn events, such as time of authn and authn protocol are alluded to but not specifically called out.

The use case scenarios would be edited to show when information about authn events would be transferred, and the requirement for authn data would be edited to say:

[CR-1-11-AuthN] SAML should define a data format for authentication assertions, including descriptions of authentication events.

Possible Resolutions:

1. Edit the use case scenarios to specifically define when authn event descriptions are transferred, and edit the R-AuthN requirement.
2. Do not change the use case scenarios or R-AuthN requirement.

Status: Voted, Resolution 1 Carries

Voting Results

ISSUE:[UC-1-12:SignOnService] Bob Morgan suggests changing the title of use case 1, "Single Sign-on," to "Sign-on Service."

Possible Resolutions:

1. Make this change to the document.
2. Don't make this change.

Status: Open

ISSUE:[UC-1-13:ProxyModel] Irving Reid suggests an additional use case scenario for single sign-on, based on proxies.

A scenario would be added to the document as follows:

Scenario X: Single Sign-on, Proxy Model

In this model, the user authenticates to a proxy and then sends a request, including credentials, to the proxy. The proxy generates OSSML assertions, attaches them to the request, and forwards the request to the destination web site. The destination web site replies to the proxy, and the proxy forwards the reply back to the client.

In this model, the user authenticates to a proxy and then sends a request, including credentials, to the proxy. The proxy generates OSSML assertions, attaches them to the request, and forwards the request to the destination web site. The destination web site replies to the proxy, and the proxy forwards the reply back to the client.

Alternatively, the initial message from the client to the proxy could include both the authentication credentials and the request rather than having a separate round-trip for authentication.

Fig X. Single Sign-on, Proxy Model

Steps:

1. Web user authenticates to proxy.
2. Web user requests destination resource through proxy.
3. Proxy provides authentication document to destination Web site.
4. Proxy requests destination resource from destination Web site.
5. Destination Web site provides destination resource to proxy.
6. Proxy provides destination resource to Web user.

There are two sub-variants to this use case: In some cases the proxy will return OSSML tokens of some sort to the client, and the client will use those tokens (most likely in the form of HTTP cookies) to make subsequent requests within the single-sign-on session. In the other variant, the proxy has an existing session mechanism with the client. In that case, the proxy can store the OSSML tokens and transparently attach them to subsequent requests within that session.

Possible Resolutions:

1. Add this use case scenario to the document.
2. Don't make this change.

Status: Open

Group 2: B2B Scenario Variations

ISSUE:[UC-2-01:AddPolicyAssertions] Some use cases proposed on the security-use list (but not in the straw man 1 document) use a concept of a "policy document." In concept a policy document is a statement of policy about a particular resource, such as that user "evanp" is granted "execute" privileges on file "/usr/bin/emacs." Another example may be that all users in domain "Acme.com" with role "backup administrator" may perform the "shutdown" method on resource "mail server," during non-business hours.

Use cases where policy documents are exchanged, and especially activities like security discovery as in UC-4-04:SecurityDiscovery, would require this type of assertion. If these use cases and/or services were adapted, the term "policy document" should be used. In addition, the following requirement would be added:

[CR-2-01-Policy] SAML should define a data format for security policy about resources.

In addition, the explicit non-goal for authorization policy would be removed.

Possible Resolutions:

1. Remove the non-goal, add this requirement, and refer to data in this format as "policy documents."
2. Maintain the non-goal, leave out the requirement.

Status: Open

ISSUE:[UC-2-02:OutsourcedManagement] A use case scenario provided by Hewlett Packard illustrates using SAML 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:

1. This SAML assertion has been generated by B's attribute authority (or Policy Decision Point) and confers the role "System Manager for A" to Joe.
2. The CIM management console generates the XML content and attaches an SAML assertion. The CIM management console signs the request and sends it as an HTTP request.
3. The request now has to traverse A's firewall or the boundary into A's network. The gateway at this boundary uses its SAML evaluation engine (or Policy Enforcement Point) to verify that this incoming message is allowed. It does this, by verifying the signature and discovering the request is from Joe. Next it uses two assertions to authorize the incoming message: the assertion issued by B's attribute authority that is attached to the message (conferring the role "System Manager for A" on Joe); an assertion issued by A's attribute authority granting "Gateway Access" to any entity that has a valid "System Manager for A" assertion issued by B's attribute authority. Note that the second assertion can be pushed to the gateway (part of its configuration), or retrieved dynamically from a repository (or indeed the issuer) (the last case is shown here).
4. The request is forwarded by the gateway to the managed device.
5. The SAML evaluation engine on the managed device needs to determine if a "StopService" request from Joe is allowed. It does this by using two assertions: the "System Manager for A" assertion issued by B's attribute authority; an assertion issued by A's attribute authority granting "Full Management Rights" to any entity with a valid "System Manager for A" assertion issued by B's attribute authority.
6. The managed device executes the "StopService" method.

Status: Open

ISSUE:[UC-2-03:ASP] A use case scenario provided by Hewlett Packard illustrates using SAML 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 SAML evaluation engine in the server needs to retrieve the SAML 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 SAML engines in the gateway and client will have to retrieve assertions issued by both authorities.

Fig X. Application Service Provider.

Steps:

1. The client authenticates with B's attribute authority.
2. B's attribute authority provides an authentication assertion that the client is a "valid user."
3. The client requests an application through A's gateway, providing a reference to the authentication assertion.
4. The gateway needs to know that incoming packets from a client in B are allowed. It needs an assertion from B's attribute authority that the client is a valid user, and an assertion from A's attribute authority that entities issued "valid user" assertions from B are allowed access. The gateway requests the assertion from B's attribute authority.
5. B's attribute authority provides the assertion.
6. The gateway requests an authorization assertion from A's attribute authority.
7. A's attribute authority provides the authorization assertion.
8. The gateway forwards the request to the Server.
9. The server requests the assertion from B's attribute authority.
10. B's attribute authority provides the assertion.
11. The server requests an authorization assertion from A's attribute authority.
12. A's attribute authority provides the authorization assertion.
13. The server authenticates with A's attribute authority.
14. A's attribute authority provides a reference to an authentication assertion that the server is an "Approved Application".
15. The server returns the application to the client.
16. It is also important that the client check that the application is valid. This avoids problems such as an attacker spoofing the service provider and providing a word processor service that silently emails copies of all documents generated by the client to the attacker. This might be done by the client SAML evaluation engine checking two assertions: one from A granting "Approved Application" status to the server; one from B granting the attribute "execute" to any entity with "Approved Application" status issued by A. The Client requests the authentication assertion from A's attribute authority.
17. A's attribute authority provides the assertion.
18. The client requests an authorization assertion from B's attribute authority.
19. B's attribute authority provides the authorization assertion.

Status: Open

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?

Status: Open

ISSUE:[UC-2-05:B2B Transaction via an e-marketplace or trading hub] Zahid Ahmed proposes the following additional use case scenario for inclusion in the use case and requirements document.

A B2B Transaction involving buyers and suppliers that conduct trade via an e-marketplace that provides trading party authentication and authorization services, and other business services, in support of secure transaction and routing of business document exchanges between trading parties.

Steps:

1. A trading party (e.g., buyer) creates a business document for subsequent transaction with another trading party (e.g., supplier) accessible via its e-marketplace.
2. The sending, i.e., transaction-initiating trading party (TP) application creates a SAML Credential to be authenticated by the authentication and security service operated by an e-marketplace.
3. The trading party application transaction client packages the XML-based SAML Credential alongwith the other XML-based business document over a specific transport, messaging, and application protocol.
   Some examples of such (layered) protocols are following (but not limited to):
   • Secure transports: SSL and/or HTTPS
   • Messaging protocol: S/MIME and JMS.
   • Message Enveloping Formats: SOAP, etc.
   • B2B Application Protocol: ebXML, BizTalk, etc.
4. E-marketplace Authentication Service validates the TP Credential and creates a SAML Named Assertion and any Entitlements for the transaction-initiating TP.
5. The E-marketplace Messaging Service then packages the Named Assertion and Entitlements along with the original message payload into a tamper-proof envelope (i.e., S/MIME multi-part signed)
6. The resulting message envelope is transmitted to the target trading party (service provider).
7. The receiving trading party application extracts and processes the TP identity (i.e., Named Assertion) and authorization (i.e., Entitlement) information available in the received envelope.
8. Receiving TP application then processes the business document of the sending TP.
9. Receiving TP sends back a response to sending TP via its e-marketplace by repeating Steps 1 through 6.

Possible Resolutions:

1. The above scenario should be part of OASIS Use Cases/Requirements.
2. The above scenario should not be added to the document.

Status: Open

ISSUE:[UC-2-06:B2B Transaction using different messaging and application protocols] Zahid Ahmed has proposed that the following use case scenario be added to the use case and requirements document.

A B2B Document Exchange Transaction that involves two trading parties such that sending trading party (e.g., Buyer) uses one messaging and transport protocol (e.g., OBI) and receiving party (e.g., Supplier) uses a another messaging/transport protocol (e.g., ebXML). A B2B transaction service must provide relevant security interoperability services as part of its general messaging and application interoperability mechanism.

Steps:

1. The sending trading party employs a specific messaging and application protocol.
2. The sending TP application then transacts with the receiving TP via its e-marketplace following Steps# 1 through 3 in Issue# UC-2-05 described above.
3. The e-marketplace authentication and security service provider authenticated and validates the sending TP and produce relevant SAML security assertions as described in Step# 4in Issue# UC-2-05 described above.
4. The e-marketplace interoperability service transforms the incoming message to target trading party messaging and application protocol such that SAML Named Assertions and any SAML Entitlement document instances are included into the newly transformed message for subsequent transmission to the receiving TP.
5. The receiving TP extracts, processes the security assertions about the sending TP as described in Step# 7 in Issue# UC-2-05 above.
6. Receiving TP sends back a response to sending TP via its e-marketplace by repeating Steps 1 through 5.

Possible Resolutions:

1. The above use case scenario should be added to the of OASIS Use Cases/Requirements document.
2. This use case scenario should not be added to the document.

Status: Open

ISSUE:[UC-2-07:B2B Transaction over multiple e-marketplace or trading hubs/portals] Zahid Ahmed proposes the following use case scenario for inclusion in the document. This use case/issue is a variant of ISSUE# [UC-2-05].

In this scenario the transacting trading parties are members of different e-marketplaces or trading communities. To support B2B transactions between trading parties of different e-markletplaces, the e-marketplaces will provide secure interconnectivity between the set of trading hubs involved in the transaction between the transaction parties. In this manner e-marketplaces will act as trusted intermediaries between transacting trading parties.

Steps:

1. Repeat Steps# 1-5 in Issue# [UC-2-07].
2. Receiving e-marketplace, e.g., e-marketplace A, message service transmits the message to target e-marketplace, e-marketplace B.
3. E-marketplace B Authentication Service validates the Signed Envelope that contains the E-marketplace signature used to package the SAML security assertions about the sending TP.
4. E-marketplace B Authentication Service may additionally validate And/or insert new SAML Named Assertion and Entitlements, depending on its inter-portal connectivity security policies.
5. E-marketplace B transmits the authenticated message received from E-marketplace A to either another e-marketplace, e-marketplace C (repeat of Steps 1 through 4), or to the target TP.

Possible Resolutions:

1. Above scenario involving multiple trading hubs should be added to the document.
2. The above scenario should not be added to the document.

Status: Open

ISSUE:[UC-2-08:ebXML] Maryann Hondo proposed this use case scenario for inclusion in the use case document. (Note that an interaction diagram illustrating this use case still must be developed, to replace the current diagram. Also, the steps involved should be brought in line with other use case scenarios in the use case and requirements document.)

Use Case Scenario X: ebXML

Fig X. ebXML

Steps:

1. Party A wishes to engage with Party B in a business transaction. To do this, Party A accesses information [stored in an ebXML Collaboration Party Profile (CPP)] about Party B's requirements for doing business. Party A and Party B negotiate at Collaboration Party Agreement (CPA). Some of the information in a CPP or CPA might include:
   • Party B requires authorization credentials from AuthServiceXYZ
   • Party B requires that Party A be authorized by XYZ in the BuyerQ role.
2. Party A then must be able to determine:
   • How to get these authorization credentials.
   • where/how to insert these credentials in an ebXML message
3. Party B's Message Service Handler (MSH) has received a digitally-signed ebXML message from Party A and wishes to obtain authorization information about Party A
   • Authorization data must be retrievable based on the DN in the certificate used to sign the ebXML message.
4. Party A has enrolled with AuthServiceXYZ. Party A engages in ebXML business transactions and wants to restrict what entities are able to retrieve its authorization data.

Potential Resolutions:

1. Add this use case scenario to the use case and requirements document.
2. Do not add this scenario.

Status: Open

Group 3: Sessions

ISSUE:[UC-3-1:UserSession] Should the use cases of log-off and timeout be supported? These result in the notion of session management. Advantage: Allows complete web user experience across multiple web sites. If not done as part of this specification, then some other body or work will have to standardize this functionality. Disadvantage: More complex than just passing authentication references between source and destination. Will slow down Technical committees work on specification of authentication/authorization only queries.

Candidate Requirement:

[CR-3-1-UserSession] SAML shall support web user session(s).

The following use case scenario would be added to the use case and requirements document.

A Single Sign-on and hand-off

Note that this is a duplicate of Oasis security Services Scenario #1

Fig X. Single Sign-on, User Session.

Steps:

1. A user logs onto the source Web site. This results in the creation of a session on the source web site.
2. User requests a link to a destination web site. This link contains an authentication reference/token/ticket.
3. User requests resource represented by link on destination web site, including reference
4. Destination web site requests validation of authentication reference from source web site.
5. Source web site returns success or failure, optionally additional session information.
6. Destination web site returns web site to user

Timeout

1. Assume that the user has gone beyond the timeout limit on the source web site.
2. The source web site will query each participating web site to determine if the user has been active on their web site.
3. If the user has not been active on any of the destination web sites within the timeout period, the destination web sites are instructed to delete the session.

Logout

1. User logs out of the source web site.
2. Each of the destination web sites are instructed to delete the session.

Possible Resolutions:

1. Add this requirement and/or use cases to SAML.
2. Do not add this requirement and/or use cases.

Status: Voted, Resolution 1 Carries

Voting Results

In voting for resolution 1, Jeff Hodges added, "rationale: if there's these "assertions" floating about between various entities that serve to assert the identity of some particular entity, there's notions of "validity time period" (however implemented), and there's notions of "state" relative to the asserted identity, then I feel what we have here meets the definition of a "session", and we ought to use that term (and really figure out what all the implications are)." He also attached the following URLs:

      http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=session&action=Search

      http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=state

    

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? [DavidO: I don't understand this issue, but I have left in for backwards compatibility]. [DarrenP: I think this issue arose out of a misunderstanding/miscommunication on the mailing list and has been resolved. This is more of a formality to vote this one to a closed status.]

Possible Resolutions:

1. Do not pursue this requirement as it is not in scope.
2. Do further analysis on this requirement to determine what it is specifically.

Status: Voted, No Conclusion

Voting Results

ISSUE:[UC-3-03:Logout] Should SAML support transfer of information about logout (e.g., a principal intentionally ending a session)? [DavidO: Isn't this covered in UC-3-1? I've kept here for backwards compatibility]

Candidate Requirement:

[CR-3-3-Logout] SAML shall support web user logout.

Possible Resolutions:

1. Add this requirement and/or use cases to SAML.
2. Do not add this requirement and/or use cases

Status: Voted, No Conclusion

Voting Results

In voting for resolution 2, Jeff Hodges added, "rationale: I believe this is subsumed within the topic of [UC-3-1:UserSession] and we should deal with it explicitly in that context."

ISSUE:[UC-3-6:Destination Logout] Should logging out of a destination web site be supported? Advantage: allows web sites control over their local domain, current model implemented on the web. Disadvantage: potentially more interactions between source and destination web sites

Candidate Requirement:

[CR-3-6-Destination Logout] SAML shall support logout at destination web sites

Possible Resolutions:

1. Add this requirement and/or use cases to SAML
2. Do not add this requirement and/or use cases

Status: Voted, No Conclusion

Voting Results

ISSUE:[UC-3-7:Logout Extent] What is the impact of logging out at a destination web site?

Possible Resolution:

1. Logout from destination web site is local to destination [DavidO recommendation]
2. Logout from destination web site is global, that is destination + source web sites.

Status: Voted, Resolution 1 Carries

Voting Results

Jeff Hodges, abstaining, said, "rationale: needs clarification. E.g. BobB's point in Group3VoteBlakley.html should be considered."

ISSUE:[UC-3-04:StepUpAuthn] "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 authn and require certificate authn. Should SAML support step-up authentication? Should a use case be developed illustrating step-up authn?[DavidO: I don?t think this is applicable to the session requirements, but I?ve kept here for backwards compatibility].

Possible Resolutions:

1. Move this issue to the AuthN issue group and leave open for discussion and voting.
2. Step up Authentication is not a requirement. Close the issue.

Status: Voted, No Conclusion

Voting Results

ISSUE:[UC-3-05:SessionTimeout] Should timeout be supported?

Candidate requirement:

[CR-3-5-Timeout] SAML shall support timeout of a user log-on.

Possible Resolutions:

1. Add this requirement and/or use cases to SAML.
2. Do not add this requirement and/or use cases.

Status: Voted, No Conclusion

Voting Results

In voting for resolution 2, Jeff Hodges added, "rationale: I believe this is subsumed within the topic of [UC-3-1:UserSession] and we should deal with it explicitly in that context."

Bob Blakley said, "However I believe that the phrasing of the requirement is wrong. I think what we should support is expiration of assertions. Timeout is an action a receiving system implements based on observing that an assertion has timed out."

ISSUE:[UC-3-8:Destination Timeout] Should timing out of a session at a destination web site be supported?

Candidate requirement:

[CR-3-8-DestinationTimeout] SAML shall support destination web site timeout.

Possible Resolutions:

1. Add this requirement and/or use cases to SAML
2. Do not add this requirement and/or use cases

Status: Voted, No Conclusion

Voting Results

In voting for resolution 2, Jeff Hodges added, "rationale: I believe this is subsumed within the topic of [UC-3-1:UserSession] and we should deal with it explicitly in that context."

Bob Blakley said, "I don't feel that I understand well enough what we'd consider doing here to express an opinion yet."

Group 4: Security Services

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?

Status: Open

ISSUE:[UC-4-02:AttributeAuthority] Should a concept of an attribute authority be introduced into the SAML 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?

Status: Open

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 SAML use case document? As a requirement? As part of an existing use case scenario, or as its own scenario?

Status: Open

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 SAML standard?

Possible Resolutions:

1. Yes, a service could be provided to send authorization data about a service between security zones. This would require some sort of AuthZ assertions (UC-2-01:AddAuthzAssertions).
2. No, this extends the scope of SAML too far. AuthZ in SAML should be concerned with AuthZ attributes of a principal, not of resources.

Status: Open

Group 5: AuthN Protocols

ISSUE:[UC-5-03:AuthNThrough] All the scenarios in Straw Man 1 presume that the user provides authentication credentials (password, certificate, biometric, etc) to the authentication system out-of-band.

Possible Resolutions (not mutually exclusive):

1. Should SAML be used directly for authentication? In other words should the SAML model or express one or more authentication methods or a framework for authentication?
2. Should this be explicitly stated as a non-goal?
3. Should the following statement would be added to the non-goals section?

   [NO-Authn] Authentication methods or frameworks are outside the scope of SAML.

Status: Voted, Resolution 1 Fails, Resolution 2 Passes, Resolution 3 No Conclusion

Voting Results

NOTE: resolutions for this issue were voted on separately.

ISSUE:[UC-5-02:SASL] Is there a need to develop materials within SAML that explore its relationship to SASL [SASL]?

Possible Resolutions:

1. Yes
2. No

Status: Voted, No Conclusion

Voting Results

[ISSUE:[UC-5-01:AuthNProtocol] Straw Man 1 explicitly makes challenge-response authentication a non-goal. Is specifying which types of authn are allowed and what protocols they can use necessary for this document? If so, what types and which protocols?

As written, this issue covers a lot of ground. [UC-5-03:AuthNthrough] covers the core issue of the removal of all considerations of modeling authentication methods within SAML, which need not be discussed further in 5-01.

There is an aspect of these requirements that has been discussed and noted as important on the list. There is a need for describing different forms of credentials (name-password, public key, X509 certificates etc) within OSSML. In this sense there is a connection to the different "permitted forms of authn" [2] and OSSML.

REFERENCES: I believe these requirements are consistent with or can be derived from Nigel's suggestion [1] but is perhaps closer to the current style of specification in Strawman 2. It also reflects the discussion in [2] and [3].

      [1] http://lists.oasis-open.org/archives/security-use/200102/msg00029.html

      [2] http://lists.oasis-open.org/archives/security-use/200102/msg00038.html 

      [3] http://lists.oasis-open.org/archives/security-use/200102/msg00064.html

    

Possible Resolutions (not mutually exclusive):

1. The Non-Goal

   "Challenge-response authentication protocols are outside the scope of the SAML"

   should be removed from the Strawman 3 document.
2. The following requirements should be added to the Strawman 3 document:

   [CR-5-01-1-StandardCreds] SAML should provide a data format for credentials including those based on name-password, X509v3 certificates, public keys, X509 Distinguished name, and empty credentials.

   [CR-5-01-2-ExtensibleCreds] SAML The credentials data format must support extensibility in a structured fashion.

Status: Voted, No Conclusion

Voting Results

In voting for resolution 2, Bob Blakley said, "My thinking here is that we need to provide a way to assert what mechanism was used to authenticate the user (e.g. certificate-based authentication) and what the user's authenticated credential resulting from that authentication (e.g. X.509 cert) was. I'm still nervous about allowing the VALUE of the password to be used as credential information as in S2ML, but I do understand why this was done and that it's useful."

Group 6: Protocol Bindings

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/)?

Status: Open

Group 7: Enveloping vs. Enveloped

ISSUE:[UC-7-01:Enveloping] SAML data will be transferred with other types of XML data not specific to authn 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 SAML 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:

1. SAML data and other data are sent as separate messages.
2. Enveloping the other data in an SAML message.
3. SAML data is enveloped in the other data message type.
4. Some combination of the above.

Status: Open

Group 8: Intermediaries

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 SAML conversation? Can intermediaries add, subtract, or alter data in an SAML message? Should a use case scenario involving a 3rd-party intermediary be included in the use case and requirements document?

Status: Open

Group 9: Privacy

ISSUE:[UC-9-02:PrivacyStatement] Important private data of end users should be shared as needed between peers in an SAML 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?

One statement suggested by Bob Morgan is as follows:

[CR-9-02-3-DisclosureMorgan] SAML should support policy-based disclosure of subject security attributes, based on the identities of parties involved in an authentication or authorization exchange.

[CR-9-02-2-DisclosureBlakley] SAM should support *restriction of* disclosure of subject security attributes, *based on a policy stated by the subject*. *This policy might be* based on the identities of parties involved in an authentication or authorization exchange.

Status: Open

ISSUE:[UC-9-01:RuntimePrivacy] Should protecting the privacy of the user be part of the SAML 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?

Status: Open

Group 10: Framework

ISSUE:[UC-10-01:Framework] Should SAML provide a framework that allows delivery of security content negotiated out-of-band. A typical use case is authorization extensions to the core SAML constructs. The contra-position is to rigidly define the constructs without allowing extension.

Possible Resolutions:

1. Specify only the explicitly allowable content of messages, no framework
2. Allow full extensibility of message content (verbs and nouns) as well as flexible intermediary processing
3. Allow full extensibility of message content (verbs and nouns) with rigidly defined intermediary processing.

Status: Open

Group 11: AuthZ Use Case

ISSUE:[UC-11-01:AuthzUseCase] The use case scenarios outlined in straw man 2 include explicitly only authn 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:

Scenario N: Authorization Service

This use case illustrates an authorization service that provides authorization checks for resource access. This authorization service is expected to operate within a single security domain, where the owner of the resource also controls the policies at the Policy Decision Point corresponding to those resources.

Fig X. Authorization Service.

Steps:

1. User authenticates to security system.
2. Security system provides authentication assertion to user.
3. User requests resource from application (where the resource can be execution of an action, a file, a database record, etc.), providing authentication assertion.
4. Application requests a check of permissions from the security server for user to access resource.
5. Security system decides on user's authorization and provides permission information.
6. Application provides resource to user.

Possible Resolutions:

1. SAML should include a use case describing an authorization service, as described above in Scenario N.
2. No such use case is necessary.

Status: Open

ISSUE:[UC-11-02:AuthzFirstContact] A second scenario for the Authorization use case combines first contact single-sign-on (UC-1-05:FirstContact), authentication (UC-5-01:AuthNProtocol) and authorization.

Scenario N+1: Authorization Service, First Contact with Authentication

In this scenario, the client makes contact only with the application; there is not a separate authentication phase between the user and the security system.

Steps:

1. Client sends a single message containing both an authentication request and a resource request, to the application. A typical example would be an HTTP request with a client certificate or HTTP Basic Auth username and password.
2. The application sends a combined authentication and authorization request to the security system.
3. The security system replies with an authentication reference ([R-Reference]) and permission information.
4. The application returns the authentication reference and the requested resource to the client.
5. On subsequent requests, the client makes simple resource requests (including the authentication reference). These requests are identical to those in steps 3-6 of Scenario N.

Possible Resolutions:

1. SAML should include a scenario for an authorization service that also supports user authentication.
2. SAML should include a scenario where authentication and authorization requests can be combined in a single message exchange.
3. Both such scenarios should be added.
4. No such scenarios should be added.

Status: Open

Group 12: Encryption

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:

1. Allow for explicit use of encryption, such as XML Encryption (http://www.w3.org/Encryption/2001/). SAML messages would then be transferred securely on any protocol.
2. Require transport protocols to support some form of encryption. Examples: S/MIME for MIME, HTTP/S for HTTP.

Status: Open

Group 13: Business Requirements

ISSUE:[UC-13-01:Scalability] Bob Morgan brought up several "business requirements" on security-use. One was scalability. This issue is a placeholder for further elaboration on the subject.

A candidate requirement might be:

[CR-13-01-Scalability] SAML should be appropriate for high volume of messages, and for messages between parties made up of several physical machines.

Status: Open

ISSUE:[UC-13-02:EfficientMessages] Philip Hallam-Baker's core assertions requirement document included several requirements that were efficiency-oriented. When that requirement document was merged into Straw Man 2, the efficiency requirements were excluded.

One such requirement was:

[CR-13-02-EfficientMessages] Should support efficient message exchange Integrity checks such as digital signature can add excessive overhead to messages.

Potential Resolutions:

1. Add this requirement to the use case and requirements document.
2. Leave this requirement out of use case and requirements document.

Status: Open

ISSUE:[UC-13-03:OptionalAuthentication] Philip Hallam-Baker's core assertions requirement document included several requirements that were efficiency-oriented. When that requirement document was merged into Straw Man 2, the efficiency requirements were excluded.

One such requirement was:

[CR-13-03-OptionalAuthentication] Authentication should be optional To Satisfy [R-EfficientMessages] Messages may omit authentication altogether.

Potential Resolutions:

1. Add this requirement to the use case and requirements document.
2. Leave this requirement out of use case and requirements document.

Status: Open

ISSUE:[UC-13-04:OptionalSignatures] Philip Hallam-Baker's core assertions requirement document included several requirements that were efficiency-oriented. When that requirement document was merged into Straw Man 2, the efficiency requirements were excluded.

One such requirement was:

[CR-13-04-OptionalSignatures] Signatures should be optional To Satisfy [R-EfficientMessages] Messages may use a shared secret and Message Authentication code for Authentication in place of digital signature.

Status: Open

ISSUE:[UC-13-05:SecurityPolicy] Bob Morgan proposed a business-level requirement as follows:

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

Potential Resolutions:

1. Add this requirement to the use case and requirements document.
2. Leave this requirement out of use case and requirements document.

Status: Open

ISSUE:[UC-13-06:ReferenceReqt] Bob Morgan has questioned requirement [R-Reference] in that it is not specific enough. in particular, he said:

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

One possible, more specific elaboration might be:

[CR-13-06-1-Reference] SAML should define a data format for providing references to authentication and authorization assertions. Here, a "reference" means a token that may not be a full assertion, but can be presented to an asserting party to request a particular assertion.

[CR-13-06-2-Reference-Message] SAML should define a message format for requesting authentication and authorization assertions using references.

[CR-13-06-2-Reference-Size] SAML references should be small. In particular, they should be small enough to be transfered by Web browsers, either as cookies or as CGI parameters.

Potential Resolutions:

1. Replace [R-Reference] with these requirements.
2. Leave [R-Reference] as it is.
3. Remove mention of references entirely.

Status: Open

Document History

• 5 Feb 2001 First version for Strawman 2.
• 26 Feb 2001 Made the following changes:
  • Changed references to [OSSML] to SAML.
  • Added rewrites of Group 1 per Darren Platt.
  • Added rewrites of Group 3 per David Orchard.
  • Added rewrites of Group 5 per Prateek Mishra.
  • Added rewrites of Group 11 per Irving Reid.
  • Converted the abbreviation "AuthC" (for "authentication") to "AuthN."
  • Added Group 13.
  • Added UC-1-12:SignOnService.
  • Converted candidate requirement naming scheme from [R-Name] (as used in the main document) to [CR-issuenumber-Name], per David Orchard.
  • Added UC-0-02:Terminology.
  • Added UC-0-03:Arrows.
  • Updated UC-9-02:PrivacyStatement with suggested requirements from Bob Morgan and Bob Blakley.
  • Added UC-1-13:ProxyModel per Irving Reid.
  • Added status indications for each issue.
  • Recorded votes and conclusions for issue groups 1, 3, and 5.
  • Added Zahid Ahmed's use cases for B2B transactions.
  • Added Maryann Hondo's use case scenario for ebXML.
  • Added comments to votes by Jeff Hodges, Bob Blakley.