Fwd: Re: [security-services] Moving subjects up to assertions(disregard first reply)

[Anne.Anderson@Sun.COM]

--- Begin Message ---

• From: "Eve L. Maler" <Eve.Maler@Sun.COM>
• To: 'SAML' <security-services@lists.oasis-open.org>
• Date: Mon, 08 Mar 2004 17:32:10 -0500

I met with Anne today and confirmed my understanding of XACML's needs 
wrt building on top of SAML.  Comments and a proposal are below:

Anne Anderson wrote:
> XACML has two strong use cases.
> 
> 1. XACML's Query and XACMLAuthorizationDecisionStatement are NOT
>    tied to a Subject.  An XACML request may contain no Subject
>    whatsoever!  The only requirement is that it contain a
>    resource.  Any Subject information is weighted equally with
>    any Resource or Action information.

I confirmed that it would be acceptable to Anne if XACML had to derive 
its special kinds of queries from our new RequestAbstractType structure. 
  It seems entirely appropriate and within the spirit of SAML to query 
on whatever criteria one wishes.

(Incidentially, I also confirmed that she's okay with our decision to 
block element substitution.  It appeals to her, as it does to me, to use 
<saml:XXXX xsi:type="xacml:YYYY"> to indicate the SAML "primacy" of any 
XACML-extended markup.)

XACML includes both queries that don't specify subjects as a criterion, 
and also queries that do specify XACML-flavored subject information. 
XACML subjects are pretty much collections of attributes, which is a 
structure very different from our identifier-based one.

> 2. XACML's XACMLPolicyStatement does not contain a Subject at all
>    (it MAY refer to one or more Subject Attributes, but those may
>    refer to many different subjects that might come in from
>    different requests).
> 
>    This Statement has an issuer (the policy creator), but no
>    Subject.  Yet I think it is squarely in the scope of SAML as a
>    Security Assertion.

In talking with Anne, I came to agree that this is a perfectly 
reasonable thing to want to do with a "security assertion markup 
language".  I feel that since XACML is one of the earliest users of SAML 
and since the XACML TC's intent is to profile/extend SAML V2.0 formally 
rather than just being "inspired" by it this time around, we should 
continue to accommodate XACML wrt subjectless assertions.

Therefore, I propose that we do the following:

- Keep <Assertion> as the main assertion element we expect
   everyone to use.

- Bind it to a type called AssertionType that requires
   <Subject>.

- Add an ancestor type that has no subject information in it,
   just the usual common stuff like MajorVersion, so that
   AssertionType gets the common stuff from this ancestor.

- Call the ancestor type *AssertionAbstractType (fill in
   asterisk with "Generic" or "SAML" or "Subjectless"?).

- To make the whole extension point thing work, declare an
   element *Assertion (fill in asterisk with same answer as
   above) and insert it in the obvious places.

I again considered the idea of adding SubjectAbstractType (with nothing 
in it) instead of using this approach, but it appears that 
XACMLAuthorizationDecisionStatement really doesn't *require* a subject 
in it, and I would really like to avoid making <Subject> optional on 
regular SAML assertions.  Also, on reflection it seemed that it would be 
Tag Abuse to require XACMLPolicyStatement to have an empty <Subject> 
element.  In this case it's better for XACML to define its own 
<xacml:Subject> element with its own semantics and optionality (rather 
than a <saml:Subject xsi:type="xacml:XACMLSubjectType"> element).

	Eve
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.

--- End Message ---