Re: [xacml] 7.7 Obligations

[bill parducci <bill.parducci@overxeer.com>]

> But if I must, SAML is based on querying some static or dynamic database
> for assertions about specific things. You make a SAML <something> request,
> you get a SAML <something> response, over some unspecified protocol.
> There is no remote authorization decisions going on. There is no
> management interfaces, so what is left behind the interfaces is left up to
> interpretation, i.e. configuration and operation.
> 
> I see nothing in the SAML specs that says anything about even how actions
> based on a SAML request/response pair should behave. So, I see no
> correspondence with the value or lack there of with the SAML
> specification.

give this a peep:
http://www.oasis-open.org/committees/security/docs/cs-sstc-schema-protocol-01.xsd

this is why the SAML context mapping is specifically addressed in *our* spec.

> What is different about an "operational" view? Just because you tag it
> "operational" means that it is not a concern?

no. what i am saying is that where the PEP *may* be located is not relevant to the discussion because one of the situations where it *will* be is on the other end of a SAML authorization decision query. therefore how a PEP behaves that is only 'attached' to the PDP via such a request is crucial to the reproducibility of the results. 

[...]

> I didn't say it had to be in the RequestContext, but you could configure
> the PDP it will hand you only "understandable" obligations. If you base
> your PDP decision on authenticating the requesting application (i.e. the
> PEP), you can have a list of configured obligations that the particular
> PEP understands, and return a standard decision of Permit with
> obligations or Deny, accordingly.

keyword *configure*. now, what are the specs for that?

> How about:
> Either by configuration, per PEP or in general, and/or by XACML context, a
> PDP SHALL ONLY respond with Permit or Deny with obligations that a PEP
> understands.
> 
> It's pretty simple. A PEP knows what obligations it can understand, and a
> PDP knows what obligations it emits. Just as a PEP know what attributes is
> must supply, and the PDP know what attributes it must be supplied.

no, incredibly difficult because...(ok, this time with shorter sentences :oP)

...you still must address how you maintain accurate mappings for the capabilities of each PEP to the PDP. the only dynamic way to do this is to have each PEP present its capabilities upon request (or at least when it comes on line/updates its skill set). that means another protocol entirely. 

*then* once you have that figured out you must address how you extend the current XACML spec so that policy writers can create polices that take this into account (e.g. "only send a permit if PEP can do 128 bit encryption, *not* 56 bit bit encryption.") which, if you think about it takes you right back to the existing spec: don't permit unless you can understand the decision in its entirety.

b