[security-services] Proposed, categorized To-Do list for SAML 1.x and2.0 (SAMLng/SAML.next)

[Jeff Hodges <Jeff.Hodges@sun.com>]

Eve Maler and I composed the below to-do items from..

SAMLng (nee SAML v2.0) brainstroming items/features
http://lists.oasis-open.org/archives/security-services/200208/msg00005.html

..and personal notes. We took a stab at sorting them into these categories..

[A] Feasible Near-term high-priority items, and bug fixes
- Bugs that are backwards-compatible (targeted to 1.1)
- Functionality that's backwards-compatible/orthogonal and
  high-priority
- The list as a whole can be completed in 3-6 months
- Any decision that needs to be made in the short term


[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)


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


[D] Items that are separate from SAML


We propose that the TC consider addressing the items listed in [A], below, in
the near term, say over the next 3..6 months, at the end of which we'd have a
revised SAML Specification Set 1.x which we'd submit for OASIS-wide approval.
While that approval process chugged along, we could then get to work on the
items listed in [B] (or a subset thereof), with the goal of developing SAML
2.0. 

So we hope that this list will provide a useful basis for discussion at the
upcoming SSTC concall next Tuesday. 

thanks,

JeffH & Eve


----------------------------------------------------------------------------


[A] Feasible Near-term high-priority items, and bug fixes

- Bugs that are backwards-compatible (targeted to 1.1)
- Functionality that's backwards-compatible/orthogonal and
  high-priority
- The list as a whole can be completed in 3-6 months
- Any decision that needs to be made in the short term
- the below items are in no particular order (ie unprioritized)

   - Formalizing operational agreements between sites (see Liberty
     provider metadata schema (section 4 of [1]) and the saml-dev 
     work [2], for examples; this is guidance/facilitation work rather
     than protocol work)
   - WS-Security profile ([3], possibly to go to WSS TC)
   - Figure out versioning of modularly published profile and binding
     specs
   - Sharpen conformance language around the notions of profiles
     vs. extensions
   - Express that an assertion should not be cached
   - Fix fragment identifier gaffe [4]
   - Standardize issuer name formats (request came from XACML)
   - Fix xmldsig issues (might turn out to be a [B] item) [5]

[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)

* = Sun may want to write a proposal in this area

   - 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*
   - Introduction protocol (common domain and cookie)
   - 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

[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)
   - (or D?) Obligations or actions that PDP needs to express to PEP
     along with decision (a la XACML?)

[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)
	
---------------------------------------------------------------------------
References

[1] Liberty Protocols and Schemas Specification
http://www.projectliberty.org/specs/liberty-architecture-protocols-schemas-v1.0.pdf

[2] Proposed InterOp Scenario for SAML at Catalyst 2002
draft-catalyst-interop--04.doc
http://lists.oasis-open.org/archives/saml-dev/200206/doc00001.doc

[3] The WS-Security Profile of SAML
draft-sstc-ws-sec--profile-01.doc
http://lists.oasis-open.org/archives/security-services/200207/doc00000.doc

[4] ISSUE: Fragment identifiers for URI references onthe Format attribute
http://lists.oasis-open.org/archives/security-services/200206/msg00020.html

[5] XML Sig issues w/ SAML
http://lists.oasis-open.org/archives/security-services/200207/msg00001.html

---------------------------------------------------------------------------