Comments on draft-sstc-saml-spec-00

["Edwards, Nigel" <Nigel_Edwards@hp.com>]

Hi Folks,
I have a few comments on the current SAML spec document. 
Unfortunately I will not be at the FTF, but I hope some may
find the following useful.

First I would like to say that it is shaping up very well - a lot of
progress since the last FTF. Here are my specific comments.

Line 115 (static model) and Line 172 (producer consumer model):
Currently the producer-consumer and static models seem to be in
misalignment on attribute authority. I found the static model
relationships involving attribute authority a bit confusing. I think
one of the problems is that we have it issuing authorization
attributes (at least as I interpret the diagram). However in the
producer-consumer model we have it issuing attribute assertions. To my
mind there are two possibilities call it attribute authority and have
it issue attribute assertions; call it authorization authority and
have it issue authorization assertions.

Line 139 (Authorization Assertion)
I had some difficulty aligning this definition with the core-assertion
model I see evolving. It seems to have in mind some all encompassing
(optionally signed) data structure containing all the attributes that a
PDP would need to make a decision. I think the model implicit in the
core assertion work is one of atomic assertions. The advice element
(Line 572) allows for the inclusion of other assertions (or references
to other assertions). However, the intent is that these assertions are
supporting evidence, used in arriving at the encompassing assertion.
     In the general case, I cannot see what purpose it would serve to
have PDPs consume a single signed data structure containing assertions
signed by other authorities. It seems to me that the general case is
for the PDP to check the individual assertions (which could easily be
grouped together in a single message). Also I could not figure out
from the static model what issues an Authorization Assertion. Note
also that the current core assertion model (line 252) only defines
"Authentication Assertion", "Attribute Assertion", "[Authorization]
Decision Assertion".

Line 146 (Policy Decision Point)
I note Marlena has done a fair bit of work recently. I think it is
important to capture the idea of the PDP using assertions - the
current definition does not mention assertions. I propose the
following alternative definition which is a lightly edited reworking
of the current text. "The place where a decision is arrived at as a
result of evaluating submitted assertions, the requested operation,
and the requested resource in light of applicable security policy."

Line 546 (Element <Object>)
Using string to denote an object seems to me to be unnecessarily
weak. I doesn't have a well defined semantics. Contrast with Element
<subject> where I think the semantics associated with keyInfo, Role
and Account are better understood.
    I would prefer for us to tackle what I believe is likely to be the
common case and have URIs. Also I think we should give consideration
to being able to specify sets of resources in a single element. Again
I believe a common case will be issue assertions referencing sets of
resources (e.g. in a folder).

Line 556 (Element <Action>
There seemed to be a cut and paste problem here (repeat of definition
of Element <object>). I am more comfortable with having the semantics
of this loosely defined (i.e. string). Since the semantics of the
string will be defined by the object to which it is applied.

If you are still reading, I hope you found some of the above useful ;-)
I hope you have a successful FTF.
Nigel.