OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Final text of ballot


Title: Final text of ballot

{AP-1} Generalized or specialized solution
: 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. 

I agree with 1 above. 

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.  

I am happy to accept Tim's assertion that "(if you answer anything else, you aren't talking to a PEP) "

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.

Yes: I assert that there exists at least one type of object that needs to make this type of request regardless of whether we call it a PEP, a PDP or whatever. I will call it a Policy Querying Point

Any party making a request should specify the types of response it is capable of handling.

This MAY be considered an extension mechanism. So a strict PEP with no pretentions might make the following requests:

<SAMLQuery>
   <Query>
      <Authority>

         <Subject>Alice
         <Object>http://bizco.shop.new.net/wherever.html
   <Respond>Decision

A PQP with the ability to cache the assertion data might add

<SAMLQuery>
   <Respond>Decision
   <Respond>ValidityInterval

A PQP with the ability to infer more general policy data might send

<SAMLQuery>
   <Respond>Decision
   <Respond>ValidityInterval
   <Respond>Claims

A PQP with generalized XACML processing might send

<SAMLQuery>
   <Respond>Decision
   <Respond>ValidityInterval
   <Respond>Claims

   <Respond>http://www.oasis.org/schema/xacml/2012-11-05.html

Now we can call this a PDP to PDP protocol if we wish but really all that is happening here is the reuse of elements we have already defined. The impact on the schema is not very significant (it adds perhaps 10 lines). We can consider this to be an extension mechanism if we like, however even if we don't specify a PDP-PDP protocol now we still need to consider how we might add one in the future.

Adding this mechanism unifies the PEP-PDP protocol with the PDP to Authority protocol without introducing ambiguity and gives us the PDP-PDP protocol as a bonus. So a PDP might query an authority as follows:

<SAMLQuery>
   <Query>
      <Authority>

         <Subject>Alice
         <Object>urn:role:finance
   <Respond>Claims

 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. 

I don't like this, I don't think the PDP should ever send info that is not specifically requested.

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.  

1 and 3. 

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

2. No, but:
3. We cannot prohibit the use of the PDP-Authority protocol as a PDP-PDP protocol. We should not make provision for the PDP-PDP interaction (which is likely to be policy centric) but we cannot avoid specifying something that is a PDP-PDP protocol.

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

Answer: 1

However, an assertion may contain a reference to another assertion. For example  the subject element might allow the principal to be specified as 'the party authenticated by such and such an assertion' . And that assertion might be carried as advice. i.e:

<SAMLResponse>
   <Assertion> 
       <AssertionID>urn:somestuff:230978a23589y25
       <Claims>
            <Authority>
                <Subject>
                      <Reference>urn:otherstuff:z908398f0497
      <Advice>
          <Assertion>

              <AssertionID>urn:otherstuff:z908398f0497

I don't think we necessarily need to do this in version 1.0 but it is the clean way of achieving the desired result in a single message.

I certainly don't think that the response to any query should be an unstructured sequence of assertions that it is the job ob the recipient to work out the meaning of. That smacks of using an expensive logic engine to recover the information that the originator of the data must have had available.

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

Answer 2.

All we can specify as a standards body is the requirements for interoperability and the bits on the wire. We cannot force people to accept our view of the problem.  

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

 Answer 1.

The extent to which the validity of assertions is to be treated may vary. It may be worth mentioning that an implementation may wish to force validation by specifying a 'Validate> condition in the manner of XTASS. The exact mechanism for validation is likely to be outside the scope of SAML however.

Phillip Hallam-Baker (E-mail).vcf



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC