RE: [ws-sx] Issue 94: Define Domain

["Ashok Malhotra" <ashok.malhotra@oracle.com>]

It seems to me that the word "domain" is introduced specifically to prohibit
nested assertions that make no sense.  The bullet I quoted (Section 3.1.3 bullet 4)
says in its entirety:
"Assertions from one domain MUST NOT be nested inside 
assertions from another domain.  For example, assertions from a transaction domain
should not be nested inside an assertion from a security domain."

Note that each security assertion defines the assertions that can be nested
within it or contained in a nested Policy.  The problem is that both these
situations allow extensibility for as-yet-undefined assertions and this seems to
where the "same domain" recommendation applies.

If all the assertions defined in WS-SecurityPolicy are put in the same domain
then, it seems to me, the "same domain" recommendation has no teeth as any 
security assertion can be nested within any other security assertion.

Consider the following correct examples:

<sp:SignedParts>
  <sp:body/>
</sp:signedParts>

<sp:IssuedToken ...>
  <sp:Issuer> ... </sp:Issuer>
  <sp:RequestSecurityTokenTemplate TrustVersion = ...>
    ...
  </sp:RequestSecurityTokenTemplate>
</sp:IssuedToken>

Now if we swap nested assertions we get nonsense assertions

<sp:SignedParts>
  <sp:Issuer> ... </sp:Issuer>
  <sp:RequestSecurityTokenTemplate TrustVersion = ...>
    ...
  </sp:RequestSecurityTokenTemplate>
</sp:signedParts>

<sp:IssuedToken ...>
  <sp:body/>
</sp:IssuedToken>

Thus, it seems that domains should be defined as subsets of the security policy assertions.
Perhaps, authentication, protection, etc.  Or corresponding to the major divisions
of WS-SecurityPolicy.

All the best, Ashok
 

> -----Original Message-----
> From: Hal Lockhart [mailto:hlockhar@bea.com] 
> Sent: Wednesday, July 26, 2006 12:16 PM
> To: Marc Goodner; Ashok Malhotra; ws-sx@lists.oasis-open.org
> Cc: Prakash Yamuna
> Subject: RE: [ws-sx] Issue 94: Define Domain
> 
> Tony suggested that the definition of domain used by SP is 
> from RFC 2828. I don't think so. These are given:
> 
> ----
> $ domain
>       (I) Security usage: An environment or context that is 
> defined by a
>       security policy, security model, or security architecture to
>       include a set of system resources and the set of system entities
>       that have the right to access the resources. (See: domain of
>       interpretation, security perimeter.)
> 
>       (I) Internet usage: That part of the Internet domain name space
>       tree [R1034] that is at or below the name the specifies the
>       domain. A domain is a subdomain of another domain if it is
>       contained within that domain. For example, D.C.B.A is a 
> subdomain
>       of C.B.A. (See: Domain Name System.)
> 
>       (O) MISSI usage: The domain of a MISSI CA is the set of MISSI
>       users whose certificates are signed by the CA.
> 
>       (O) OSI usage: An administrative partition of a complex
>       distributed OSI system.
> ----
> 
> None of these seem to fit. I think the meaning of domain as 
> used by SP is more like this:
> 
> ---
> From Merriam-Webster online dictionary:
> 
> http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=domain
> 
> 4: a sphere of knowledge, influence or activity <the domain of art>
> ----
> 
> But this begs Ashok's question as to whether WS-SP 
> constitutes one domain or several.
> 
> Hal
> 
> 
> > -----Original Message-----
> > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > Sent: Tuesday, July 25, 2006 4:03 PM
> > To: Ashok Malhotra; ws-sx@lists.oasis-open.org
> > Cc: Prakash Yamuna
> > Subject: [ws-sx] Issue 94: Define Domain
> > 
> > Issue 94.
> > 
> > -----Original Message-----
> > From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
> > Sent: Tuesday, July 25, 2006 12:21 PM
> > To: ws-sx@lists.oasis-open.org
> > Cc: Prakash Yamuna
> > Subject: [ws-sx] NEW ISSUE: Define Domain
> > 
> > Title: We need a definition for "domain" in WS-SecurityPolicy
> > 
> > Description:
> > WS-SecurityPolicy uses the word "domain" in several places.  For 
> > example, in Section 3.1.3 bullet 4:
> > "Assertions from one domain MUST NOT be nested inside 
> assertions from 
> > another domain." ...
> > 
> > Target: WS-SecurityPolicy
> > 
> > Proposal: I think we all know what's meant here but we need 
> a formal 
> > definition for the word "domain".  One possibility is to group all 
> > assertions within a domain in a single namespace that contains only 
> > assertions for that domain.
> > 
> > All the best, Ashok
> > 
> 
> 
>