RE: [xacml] FW: SAML AI 0076 - XACML Policy Transport

["Hal Lockhart" <hlockhar@bea.com>]

On the SAML call yesterday (10/14) the few people who expressed an opinion
felt that this was more appropriate to do in XACML. They felt that if we
wanted to introduce an abstract "policy" element which could contain any
kind of policy, not just XACML and then define the XACML constructs below
that, it might make sense to have SAML define abstract policy layer.
Otherwise the feeling was this was more appropriate to do in XACML.

Unless somebody feels the abstract policy layer is important, I suggest we
simply do it as described below. If at a future time there is a push for an
abstract layer, we can adjust accordingly. DOing it in the XACML TC will
also make it easier to deal with any interactions with other proposed 2.0
changes, such as to Target.

My feeling is that this will have to be a separate profile. Any opinions on
this?

Hal

> -----Original Message-----
> From: Hal Lockhart [mailto:hlockhar@bea.com]
> Sent: Tuesday, October 14, 2003 11:27 AM
> To: xacml@lists.oasis-open.org
> Subject: [xacml] FW: SAML AI 0076 - XACML Policy Transport
>
>
> I just posted this to the SSTC list. Comments from the XACML TC are more
> than welcome. Since the XACML TC F2F is before the SAML F2F, I will try to
> get a reading on today's call as to whether they will pursue this
> work item.
>
> Hal
>
> -----Original Message-----
> From: Hal Lockhart [mailto:hlockhar@bea.com]
> Sent: Tuesday, October 14, 2003 11:18 AM
> To: security-services@lists.oasis-open.org
> Subject: AI 0076 - XACML Policy Transport
>
>
> I thought at least some of this had been previously proposed within the
> XACML TC, but I can find no evidence for this. Therefore, this should be
> considered as coming from me as an individual. I will cross post it to the
> XACML list for comment.
>
> The basic idea of this proposal is twofold:
>
> 1) wrap an XACML <Policy> or <PolicySet> in a SAML statement so as to
> provide a common framework for header elements (version, issuer, validity
> interval, signature, etc.)
>
> 2) provide a SAML mechanism to retrieve policies by identifier or by
> <Target> evaluation.
>
> ------------------------------------------------------------------
> ----------
> ----------------
> The issue that needs to be decided first is whether this work
> should be done
> within the SSTC or the XACML TC. I do not see any strong argument either
> way. Since the work consists of extensions to the SAML schemas,
> it seems to
> me that the SSTC should have the right of "first refusal."
> ------------------------------------------------------------------
> ----------
> ----------------
>
> Details:
>
> A. XACML Policy Statement
>
> Define a new SAML Statement Type:
>
> <XACMLPolicyStatement> which inherits from StatementAbstractType (not from
> <SubjectStatementAbstractType>)
>
> It can contain either an XACML <PolicySet> or <Policy>
>
> B. XACML Policy Query
>
> Define two new SAML Query Types:
>
> <XACMLPolicyIdQuery>
>
> <XACMLPolicyTargetQuery>
>
> All inherit from <QueryAbstractType>
>
> The <XACMLPolicyIdQuery> contains one or more <PolicyId> or <PolicySetId>
> values. The response would return the matching Policies or PolicySets, if
> available.
>
> The <XACMLPolicyTargetQuery> contains an XACML request context which needs
> to only include the Subject, Resource and Action elements to be considered
> for policy Target matching. The response would return zero or
> more Policies
> or PolicySets which are potentially applicable to the decision. The
> responder could chose to match on some target elements and ignore others,
> but it would be required to return every potentially applicable policy or
> policyset it has. In other words, it can return a superset, but
> not a subset
> of the policies applicable to the decision.
>
> The existing SAML <Response> would be used to return an assertion
> containing
> XACML Policies and/or PolicySets as specified by the query.
>
> Note that the existing SAML <AssertionIdReference> could also be used to
> request an Assertion containing XACML POlicies, but this seems less likely
> to be useful than the Policy Id query.
>
> Hal
>
>
>
> 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/xacml/members/leave_w
orkgroup.php.