The SAML profile

[Erik Rissanen <erik@axiomatics.com>]

All,

I have started editing the SAML profile. Anne has done a very good job 
with the profile, but I have noticed the following things which I think 
need to be changed. See the SAML profile wd 5.

Section 4.4, page 23-24 describe a functionality which I think cannot be 
implemented well and there is a better alternative.

The functionality is that if the XML attribute ReturnContext="true", 
then the PDP shall return an XACML <Request> in the SAML profile 
response, which contains those attributes which the PDP used during 
request evaluation. This is what David Chadwick posted about to the 
comments list a few weeks ago:

http://lists.oasis-open.org/archives/xacml-comment/200811/msg00024.html

His use case is that he wanted to know which role triggered the 
policies. As I explained on the list I think that use case is handled 
better by means of dynamic obligations, which I suppose we will discuss 
on Thursday.

The problems with this functionality are:

- If the meaning of "was used" is that the attribute was referenced by 
the PDP, then you will end up with lots of superfluous attributes in the 
response since there might be many non-applicable policies, which are 
found to be non-applicable only after attributes have been referenced. 
This make the feature non-useful.

- If the meaning is something else, then I cannot think of how to define it.

- Obligations are more efficient since it is possible to target only the 
interesting attributes and we avoid the overhead of collecting any 
attribute which was used by the PDP.

- In XACML 2.0 it is possible to refer to any attribute with an XPath, 
which makes this very difficult to implement.

- It is difficult (impossible?) to implement this at the granularity of 
individual attribute values in multi valued attributes (such as "role") 
since a set functions could be used on the multi value attribute, in 
which case it is difficult to track which of the individual values was 
the "significant" one.

*** Proposal: I propose that the ReturnContext-feature in the SAML 
profile draft is removed.


We have previously talked about how policies supplied in a SAML XACML 
Authz  request are in relation to the other policies in the PDP. We said 
some weeks ago that the supplied policies will be inserted in the top 
level policy set *before* the existing policies in the PDP. I now 
noticed that the SAML profile draft already contains text on this issue. 
It's different from our previous decision in two respects: first, the 
supplied policies are inserted *after* the existing policies and there 
is an XML attribute "CombinePolicies". If this is false, then the 
existing policies in the PDP shall not be used at all. See section 4.4, 
page 24.

I think it makes more sense to put policies before since then for some 
combining algorithms they will be more significant which might be 
desirable if you are providing policies in the first place.

*** Proposal: change insertion of policies to *before*.

*** Action needed: do we want to support the "CombinePolicies" option?

I think that this seems a nice enough feature, so it's ok for me. It 
would be useful if one wants to make use of the context handler in a 
PDP, but want to control the policies himself.

*** Proposal: fix wording on wording on page 24, around line 768. It 
says "If the CombinePolicies XML attribute is true,. then the PDP MAY 
choose to use such XACML Policy instances.". I think it should say "..., 
then the PDP MUST combine the supplied policies with the existing 
policies in the PDP". The same wording appears also at the top of the 
next palge, which should also be changed.


In section 4.7 there are some TBDs about matching the holder of 
attributes. This can be easily fixed now that the core schema is done.

*** Proposal: fix the attribute holder matching. It should say that "The 
<Match> element shall be evaluated according to the XACM schema against 
the <Attributes> elements in the <Request>. If it evaluates to "Match" 
to an <Attributes> element, then the attributes shall apply to that 
<Attribute> element".



*** Proposal: change wording at end of section 4.11. It says now "An 
implementation MUST be prepared to handle any circular dependencies that 
may arise". This could be interpreted such that the PDP must be able to 
resolve circularly inherited attributes among the supplied attributes in 
a SAML XACML Authz request. This is not the intent. It was meant to mean 
that the PDP must not crash or otherwise behave badly if there is a 
circular dependency. I propose that we say "An implementation is not 
required to resolve any inherited dependencies between supplied 
attributes, but MUST NOT treat any circular dependencies which may arise 
as an error or otherwise fail on them."



In section 5.2, page 33, it says that the <ReferencedPolicies> MUST 
contain copies of all policies referenced from the supplied policies. I 
think this is a too strict requirement and it may in many cases be 
useful to have SAML XACML policy assertions with "external" policy 
references, and it should be allowed.

*** Proposal: Change the above mentioned MUST to a MAY in the section 5.2.



In section 5.6, at the end of page 35, it says that "The <saml:Issuer> 
element identifies the entity that generated the XACMLPolicy Response 
message". I think it should not always have to like this. I can imagine 
situation where a policy repository contains signed policies in SAML 
assertions and those are returned by a policy query. In this case I 
might want to receive the original issuer of the policy, rather than the 
policy query service as the issuer.

*** Proposal: Change the text to "The <saml:Issuer> element identifies 
the originator of the contained XACML Policy, which MAY be the generator 
of the XACMLPolicy Response message".



Section 6 talks about saml Advice. I am not very familiar with the use 
of Advice, but this section lists no reason for why one would want to do 
what it described. So, either explain what good it is for, or drop 
section 6 altogether.

*** Proposal: remove section 6 unless someone can explain what it is 
good for.


Section 8 contains specifications for metadata. This section is to a 
large degree unfinished work.

*** Proposal: remove section 8. Open an issue on the issues wiki which 
says that WD 5 of the SAML profile contains metadata specificatoins, and 
that those should be considered for the future metadata profile for 
which there is a working draft already.


Section 9 contains (line 1248) a really long URN, which I think is a typo.

**** Proposal remove the prefixing duplicate URN string.


Best regards,
Erik