My votes...

["Mishra, Prateek" <pmishra@netegrity.com>]

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

[Prateek Mishra] 

1.

I view the use-case recommendations as being at a fairly high level and not
at a sufficient level of detail for us to implement 2. Indeed, it may turn
out that there may be some requirements at the level of message round-trips
and messaging details, that this group drives into the use-case discussion.

 {AP-2} Questions the PEP can ask the PDP 

1.      "Yes/No/Can't decide". 
[Prateek Mishra]

YES. 

I would propose the following modifier: in addition, the PDP would also
return a certain amount of meta-data for BOTH the negative and positive
cases. An example of meta-data relevant to the positive case is validity
period: this seems to me to be important in any performant PEP
implementation.  SAML 1.0 would standardize some simple forms of meta-data
but leave sufficient flexibility for arbitrary meta-data to be returned.

 
2.      All information in the assertions supplied by the PEP. 
[Prateek Mishra] 

NO.  
3.      Specific attributes requested by the PEP.
[Prateek Mishra] 

YES.

In addition, I would assume that there may be attributes other than those
explicitly provided as assertions by the PEP that may be returned in this
step. These attributes are somehow stored or found at the PDP. My main point
is that the returned attributes should not be constrained to those
explicitly passed from the PEP to PDP.


4.      Any information that the PDP can discover. 
[Prateek Mishra] 

NO.

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

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. 
[Prateek Mishra] 

3. 

An arbitrary set of assertions from many different APs may be required by
the PDP to make a decision. One way to control the complexity here is to
require that all of the assertions "depend upon" a single name assertion
(authenticated subject).

 
{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?
[Prateek Mishra] 

1.

We should not mandate any type of combination, but our message structures
and protocols should allow for combination and should be checked to ensure
this property. 

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


[Prateek Mishra] 

1. 

Assertion validation could take place directly at the PEP or within program
logic or through

some XKMS-based service. I assume that the 

intention here is avoid closely coupling assertion validation with the PDP. 


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