[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Proposed, categorized To-Do list for SAML 1.x and2.0 (SAMLng/SAML.next)
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 ---------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC