[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC