First draft of ballot questions

Colleagues - Here is my proposed text for some questions confronting 
us.  I propose the following timetable.  Let's debate the questions 
until 5:00pm Eastern on Tuesday, 3rd April.  I'll issue the formal text of 
the questions by 9:00 am Eastern on Wednesday, 4th April, and close the ballot 
by 9:00am Eastern on Thursday, 5th April. We'll have the results available for 
our telecom at 12:00 Eastern on Thursday.  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.

    

    
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.

    

    

    
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.

    

    

    
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.

    

    

    
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:

    

    
"Yes/No/Can't decide".

    

    

    
All information in the assertions supplied by the PEP.

    

    

    
Specific attributes requested by the PEP.

    

    

    
Any information that the PDP can discover.

    

{AP-3} Question: should we define a PDP-PDP protocol?

Answer:

    

    
Yes.

    

    

    
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:

    

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

    

    

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

    

    

    
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:

    

    
Only one.

    

    

    
Only one related pair.

    

    

    
An unlimited number.