Final text of ballot

[Tim Moses <tim.moses@entrust.com>]

Title: Final text of ballot

Colleagues - I have received two comments on the ballot. 
The first was from Prateek, and (if I understand correctly) it requested that the model explicitly identify that components of the model may be combined (e.g. the Authority and PDP may be combined).

The second was from Marlena and it can be resolved by separately identifying an "assertion validation" component.  Perhaps, the interface protocol can by X-KISS.  And it can be called by either the PEP or the PDP.

It was probably not really necessary, but just to be sure, I have added two questions to address these comments.
We are scheduled to close the voting by the end of today (Wednesday) on the West Coast.  So, please send your votes to the list by the deadline.  I will have results available for tomorrow's telecon.

Phil - Have you made arrangements for the telecon?
Best regards.  Tim.

{AP-1} Generalized or specialized solution
This is a common question about the design process.  Should we develop a solution that is specialized to satisfying just those requirements identified by the Use Case sub-committee, or should we "induce" a more general set of requirements and provide a solution for that?  In the latter case, we would "profile" the chosen design to address the identified use cases.

The arguments are familiar.  On the one hand, the specialized solution could be more streamlined for the particular situations identified by the Use Cases sub-committee.  On the other hand, the generalized approach may turn out to be sufficiently flexible to address a broader set of problems, and thereby find more widespread use.

Question: which of these statements do you agree with (only one, please)?
Answer:
1. We should develop a generalized solution as an interim step to satisfying the specific requirements identified by the Use Cases sub-committee.

2. We should directly address the requirements identified by the Use Case sub-committee.
{AP-2} Questions the PEP can ask the PDP
(Note: In our discussions we have spoken in more general terms about the questions "one entity" can ask "another entity", not limiting the discussion to the conversation between the PEP and the PDP.  However, I think it will be easier to address one pair of entities at a time.  The discussion will be more concrete.  If necessary, we can decide later on a similar question about other entity pairs.)

We have to decide what types of information should be supplied by the PDP to the PEP.  Four options appear to be available.

1.      The PDP renders a simple "Yes/No/Can't decide" response to the question posed by the PEP.  In the case where the PEP needs to validate the Principal's attributes, the PEP supplies "requested action", (optionally) an authenticator and the authentication and attribute assertions (or references thereto).  The PDP can only say, "yes, the Principal should be granted the requested action", "no, the Principal must not be granted the requested action", or "I can't tell".  Naturally, if the PDP needs additional information, not supplied by the PEP, and it is able to locate and retrieve it from another source, then it can make use of that information in coming to its decision.  This approach supports the notion of PEPs that rely entirely on infrastructure services to make security decisions for them: the assertions and their contents are entirely opaque to the PEP, and the PEP embodies no notion of security policy whatsoever.  Advocates of this approach expect faster uptake of SAML by application developers, because the PEP can be implemented in a vendor-neutral fashion by developers that  have no specialized security knowledge.

2.      The PDP returns all authentic contents from the supplied assertions.  So, the PEP can ask: "what is the Principal's name and attribute values?"  It passes (optionally) an authenticator and the authentication and attribute assertions (or references thereto) to the PDP.  Then the PDP returns the authenticated name and all the attributes to the PEP.  The PEP has to decide what to do with the attribute values.  This model implies a more sophisticated PEP; one that can interpret and act upon attribute values.  So, as some have pointed out, this type of PEP embodies some notion of security policy.  One view is that it is really acting as a PDP that encompasses a PEP.  So, an alternative approach is for the PDP-PEP conversation to be in the style of "1", above, and to allow PDPs to be cascaded.  That would cause us to define a PDP-PDP protocol.

3.      The PDP returns selected authenticated attribute values solicited by the PEP.  So, the PEP can ask: "what is the Principal's name and the following attribute values ... ?"   The processing is as above, except that the PDP only returns values for the specified attribute types.  The idea is that if a PEP doesn't know how to handle a particular attribute type, then it won't ask for it.

4.      The PDP returns as much information as it can find on the Principal, including unsolicited attributes.  It has been suggested that some PEPs may not be able to anticipate what attribute values are available.  So, they would welcome whatever the PDP can discover, and select from that set whatever they can make use of.  Personalization data was cited as an example.  Others felt that personalization data was outside our scope and SAML should not concern itself with such matters.  Some said that there is a continuum of security and personalization information, and it is not possible to draw a clear line between one type and the other.

Question: What type of information should the PEP expect to receive from the PDP?  The answers are not mutually exclusive, so answer "yes" to as many ways as you want.

Answer:
1.      "Yes/No/Can't decide".
2.      All information in the assertions supplied by the PEP.
3.      Specific attributes requested by the PEP.
4.      Any information that the PDP can discover.
{AP-3}  Question: should we define a PDP-PDP protocol?
Answer:
1.      Yes.
2.      No.
{AP-4}  The number of assertions in a message
The question arises as to how many assertions, and of what types, can appear in a single message.  Again, let's focus on the message between the PEP and the PDP.  The implications of our decision for the other messages should become clear.

The options are:
1.      Each message contains a single assertion.  As an attribute assertion "depends on" an authentication assertion, it may take two messages to validate an attribute.

2.      Each message may contain a single authentication-attribute assertion pair.  The authentication assertion should be the one on which the attribute assertion depends.

3.      Each message may contain any number of assertions of any type.  But, no conclusion should be drawn by the PDP from the fact that two or more assertions appear in the same message.  Presumably, all the assertions should be associated with the same Principal.  So, we'll have to address the question: what should happen if they appear to relate to more than one Principal?

Question: How many assertions may appear in a single message?
Answer:
1.      Only one.
2.      Only one related pair.
3.      An unlimited number.
{AP-5} Combining components
Question: Should the core assertions/protocols group explicitly identify in its model that components may be combined (e.g. the Authority may be combined with the PDP)?

Answer:
1.      The model should explicitly identify that components of the model may be combined.
2.      The model should not explicitly identify that components of the model may be combined.
{AP-6} Assertion validation component
Question: Should the core assertions/protocols group identify "assertion validation" as a separate component in its model?

Answer:
1.      The model should identify "assertion validation" as a separate component.
2.      The model should not identify "assertion validation" as a separate component.

---------------------------------------------------------------------------------------
Tim Moses
Tel: 613.270.3183