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?
 

Resolution:

1. This issue is now obsolete and can be closed as several security services (shared sessioning, PDP-->PEP relationship)
have been identified within S2ML.

2. This issue should be kept open.

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?

The "attribute authority" terminology has already been introduced in the Hal/David diagrams and discussed by
the use-case group. So this issue can be viewed as requiring more detail concerning the flows derived
from the diagram to be introduced into the use-case document.

The following use-case scenario is offered as an instance:

(a) User authenticates and obtains an AuthN assertion.
(b) User or server submits the AuthN assertion to an attribute authority and in response
obtains an AuthZ assertion containing authorization attributes.
 

Resolution:

1. A use-case or use-case scenario similar to that described above should be added to SAML.
2. This issue is adequately addressed by existing use cases and does not require further elaboration within SAML.
 
 

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?

The S2ML use-case scenario had the following steps:

(a) User Jane (without public/private key pair) authenticates utilizing a trusted server X and receives
an AuthN assertion. The trusted server holds a private/public key pair. The AuthN assertion received
by Jane includes a field for the server X's public key.

(b) User submits a business payload and said AuthN assertion to trusted server X. The trusted
server "binds" the assertion to the payload using some form of digital signing and sends the
composite package onto the next stage in the business flow.
 

Resolution:

1. A use-case or use-case scenario comprising steps (a) and (b) above should be added to the use-case document.
2. A requirement for supporting "binding" between AuthN assertions and business payloads thru digital signature
be added to the use-case document.
3. This issue has been adequately addressed elsewhere; there is no need for any additions to the use-case document.
 
 

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:

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