Re: Final text of ballot

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

My votes below.

 - RL "Bob"

---

> {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.

I vote for "2".  I think general-applicability is an underlying design
principle that we will apply as engineers.  But I am opposed to developing
another list of "general" requirements distinct from those generated by
the use-case subcommittee.  If people have requirements that this spec
should meet, they should work them through the use-case group.

> {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.

I vote for "1".  That paragraph is a reasonable definition of a PEP, and
the services it requires from a PDP.  If this concept has not been clearly
defined by the use-case group in the domain model, then it should be.  It
is crucial that we define and promote a clear architecture with
well-defined roles, since this is what multi-vendor interoperability
depends on.

> {AP-3}  Question: should we define a PDP-PDP protocol?
> Answer:
> 1.	Yes.
> 2.	No.

I vote for "2".  I don't believe this is ready for standardization.  If
someone has an example of such a service that is in production and is
well-defined enough for standardization, they should propose it.

> {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.

None of the above.  This issue needs more definition before a sensible
vote can be taken.  Examples should be developed with various approaches,
demonstrating how they meet requirements.

> {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.

I vote for "1".  Only because this will be done in practice, and we need
to settle and discuss whether this implies mixing functionality in
protocol messages (I strongly believe we should not).

> {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.

I vote for "2".  Requirements for validating assertions by each component
should be made clear as part of defining how messages/assertions are
processed by those components.  Something like PKI-style delegated
validation is out of scope.