Re: [security-services] Proposed,categorized To-Do list for SAML 2.0 (SAMLng/SAML.next) [updated 20-Feb-2003]

Added back in the sections [C] and [D] to this list, which I'd somehow carved
off in past forwards. 

the 2nd item in [C] is in response to the XACML request for enhanced, richer
AuthorizationDecisionQuery and AuthorizationDecisionResponse. 

JeffH
--------------------------------------------------------------------------

[B] Major bugs and RFEs that open up new areas of work (targeted to
    2.0)

- Any of these could be sped up if someone writes a proposal
- the below items are in no particular order (ie unprioritized)

   - Simple sessions
   - Liberty-style identifier federation via NameIdentifier exchange
   - Enhanced RequestAbstractType to support Liberty use cases
   - Richer SSO profiles a la Liberty
   - Protocol for exchanging operational agreements
     (aka metadata exchange)
   - Introduction protocol (eg common domain and cookie, or some 
     roughly equivalent approach)
   - Assertion encryption via XML Encryption
   - B2B, A2A, back-office profiles
   - Profile for mid-tier usage a la Hitachi
   - Profiles for multilevel access controls
   - Profiles for multi-participant transactional workflows
   - SAML credentials collector and credentials assertions
   - SASL support in authentication methods
   - HTTP protocol binding (a la REST)
   - ebMS protocol binding
   - Baseline attribute namespaces
   - Hierarchical delegation of privileges among federated attribute
     authorities
   - Standardized trust between SAML-enabled servers
   - Persistent caching (mirroring?) of assertions at multiple sites
   - Expressing security processing workflow definitions (?)
   - Privacy and anonymity features a la Shibboleth and Liberty
   - Anonymous name identifier (same as above?)
   - SAML feature discovery through WSDL, UDDI, etc.
   - Kerberos support
   - Pass-through authentication
   - Rich/dynamic sessions (more than Liberty)
   - X.500 attribute support
   - Delegation use cases
   - Use of intermediaries
   - Dependency audit ("validity depends on")
   - Negative assertions
   - More complex queries, e.g. all attributes in namespace X
   - Standardizing policy around which attributes get supplied

   - various bug fixes

    - fragment identifiers:

      In the next major revision, SAML 2.0, change the SAML Core document 
      as follows: To the final sentence of Section 1.2.1 beginning on line 
      203, add ", and MUST be absolute [RFC 2396]."  The reason this cannot 
      be added to a minor revision is that it restricts the possible values 
      of SAML URIs, and is thus backwards incompatible.


[C] Items that other groups should publish and SAML should simply
    register

   - (or D?) Authorization service profiles (separate PDP from PEP;
     e.g. standardize in profiles what's provided as Evidence)

   - Obligations or actions that PDP needs to express to PEP
     along with decision (a la XACML?)

     aka: enhanced, richer AuthorizationDecisionQuery and 
          AuthorizationDecisionResponse


[D] Items that are separate from SAML

   - Authentication context
   - Support for Liberty authentication and confirmation method URIs
     (we're not sure there even are any)

---
end