RE: [security-services] ISSUE: NameIdentifier specification needs tobe clarified

["Ahmed, Zahid" <zahid.ahmed@commerceone.com>]

>As I see it, the current definition of NameIdentifier is 
>generic enough that we could easily end up with conflicting 
>"profiles", as happened in the early days of X509 certificates. 
>How do we represent an X500 DNAME? what about email addresses? 
>In the absence of specific guidelines, I'm afraid we'll end
>up with the usual mess of standards-compliant software that 
>doesn't interoperate.



I agree that we need to clarify the semantics of NameIdentifiers 
(core-27 section 2.4.2.2, lines 631). 

Furthermore, without a structured definition and processing rules 
for Security Domains, support for basic interoperability of Name 
Identifiers, a core element of SAML 1.0, may not be achievable.

Hence, I think we do need to improve the schema definition 
of NameIdentifier such that following high level requirements, 
implicitly assumed in SAML 1.0, are satisfied:

1. NameIdentifier's Security Domain Interoperability Support
   It is required that SAML processing systems be able to
   resolve and interpret security domains in a sematically 
   consistent manner. 

2. Domain-qualified Naming Systems Support
   Need ability to model a principal's Name w.r.t. its 
   Security Domain such that we do not have name identifier
   value collisions. The Security Domain may or may not be 
   the same as the Issuer. Use of security domain should
   be optional.
   
3. Enable Federated Identity Processing
   To support federated identity systems for a range of 
   applications, SAML must support extensible content models 
   for Security Domains.


Analysis of Above Requirements
Requirements #1 and #2 above imply that SAML 1.0 support an optional 
way to employ concrete definitions of Security Domains. URI based
definitions is one option to achieve interoperabiluty via
formalized and agreed-upon definitions of Security Domains although
I would prefer NOT making it the only way to model Security
Domains. However, we must allow extensions of Security Domain
models, as requirement #3 states, such that they fit better w.r.t. 
differing name identifiers context, for example, LDAP, Kerberos, 
etc. that we have previously discussed as part of the current 
issue.


Hence, I recommend following changes in core-27:

1) Model Abstract Security Domains
SAML 1.0 define an abstract definition of Security Domain 
that captures general properties of a Security Domain. The 
Abstract Security Domain can be extended by concrete
definitions of Security Domains by SAML enabled applications 
in terms of the semantics of their applications needs. 

2) Concrete Definition of Security Domain
Additionally, SAML 1.0 also include one concrete definition 
of Security Domain that may be used by SAML applications.


In line with this here is a possible sub-schema that we can 
employ to modify latest SAML 1.0 Core-27 schema. This
schema supports URI-based Security domain optionally.
It also is supposed to allow instantiation of NameIdentifers
w/o Security Domains. Lastly, SAML implementors can
have the option of extending the Security Domain via
the domain abstraction included here.


NOTE: the XML schema here may need to be changed, but it 
is here mostly here as a starting point to model
above approach.

  <!-- 
      // Abstract_SecurityDomain type - primitive definition 
      // of Security Domains
  -->
       <xsd:complexType name="Abstract_SecurityDomain" abstract="true">
              <xsd:sequence>
                 <xsd:element name="SecurityDomainID" type="xsd:string"
  		      maxOccurs="1"/>
              </xsd:sequence>
       </xsd:complexType>


  <!-- 
        // SecurityDomain Element that optionally may include URIs 
  -->
        <xsd:element name="ConcreteSecurityDomain">
           <xsd:complexType>
              <xsd:simpleContent>
                  <xsd:extension base="Abstract_SecurityDomain">
                     <xsd:attribute name="SecurityDomainURI"
type="xsd:anyURI"/>
                  </xsd:extension>
              </xsd:simpleContent>                              
           </xsd:complexType>
        </xsd:element>

 <!-- 
       // NameIdentifierType definition that optionally may contain 
       // a Security Domain element
 -->
      <xsd:complexType name="NameIdentifierType">
          <xsd:sequence>
             <xsd:element name="SecurityDomain"
 		  type="Abstract_SecurityDomain"
              minOccurs="0" maxOccurs="1"/>
          </xsd:sequence>
          <xsd:attribute name="Name" type="xsd:string"/>
      </xsd:complexType>

thanks,
Zahid

Zahid Ahmed
Commerce Security Architect
Commerce One, Inc.
408-517-3903


-----Original Message-----
From: Irving Reid <Irving.Reid@baltimore.com>
Sent: Monday, February 25, 2002 09:12:09 -0500
To: security-services@lists.oasis-open.org
Subject: [security-services] ISSUE: NameIdentifier specification needs to
beclarified
    

I'd like to formally raise an issue that we need to clarify the semantics of
NameIdentifiers (core-27 section 2.4.2.2, lines 631ff. There has been some
discussion on the list, starting with message "RE: [security-services]
NameIdentifier proposed change (Sun L3 comment)"
(http://lists.oasis-open.org/archives/security-services/200202/msg00123.html
)

As I see it, the current definition of NameIdentifier is generic enough that
we could easily end up with conflicting "profiles", as happened in the early
days of X509 certificates. How do we represent an X500 DNAME? what about
email addresses? In the absence of specific guidelines, I'm afraid we'll end
up with the usual mess of standards-compliant software that doesn't
interoperate.

Here's a proposal, to get the debate going.

The SecurityDomain attribute on NameIdentifier is changed to an anyURI. SAML
defines specific URI values, within the SAML URI namespace, to identify
certain well known identifier formats such as X500 DNAME and Internet email
address. In these cases, the content of the Name portion is the entire
identifier. For example (using Eve's proposed non-empty element format):

<NameIdentifier
SecurityDomain="http://www.oasis-open.org/committees/security/docs/draft-sst
c-core-27#email">irving@baltimore.com</NameIdentifier>

<NameIdentifier
SecurityDomain="http://www.oasis-open.org/committees/security/docs/draft-sst
c-core-27#X500-dname">cn=Irving
Reid,ou=Engineering,o=baltimore.com</NameIdentifier>

SAML applications SHOULD use defined SecurityDomain values and name formats
whenever possible.


If anyone else thinks this is a good idea, we can work up the normative
language.

 - irving -