Open issues in the SAML profile

[Erik Rissanen <erik@axiomatics.com>]

All,

Here are some issues in the SAML profile which I have pointed out 
earlier, but I never got any response to since we started discussing the 
ReturnContext issue, and forgot about these. (I have made some 
improvements to these proposals since my previous email.)

Note, these all apply to the working draft 5 which Anne finished before 
she left. Not the original 2.0 SAML profile.


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 noticed 
that the SAML profile draft already contains text on this issue which 
says *after* the existing policies.  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*.

*** 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 page, 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> elements shall be evaluated according to the XACM schema against 
the <Attributes> elements in the <Request>. If any <Match> element 
evaluates to "Match" then the supplied attributes shall apply to the 
<Attributes> element which was referenced by the attribute designator or 
selector contained in the <Match> 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 8 contains specifications for metadata. This section is to a 
large degree unfinished work. Instead of including this section here and 
now, we should write a proper metadata profile, which should be 
compatible with the SAML metadata framework.

*** Proposal: remove section 8 for now.


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