FW: Actions from the Focus Group meeting

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

Title: FW: Actions from the Focus Group meeting

-----Original Message-----
From:   Tim Moses
Sent:   Thursday, May 03, 2001 2:44 PM
To:     'Phill Hallam-Baker'
Cc:     'OASIS Security Services Protocols group'
Subject:        Actions from the Focus Group meeting

Phill - No excuses!  You know the rules!  You miss a meeting; you get the actions!

When the Focus Group met on Tuesday, it identified a number of issues that require further discussion and fast resolution.

Issues 1

Should assertions be "strongly typed".  One camp feels that assertions should indicate their type within the SAML taxonomy of assertion types (authentication, attribute, decision).  Another camp feels that the contents of the assertion are sufficient to deduce their type and that explicitly including the type is redundant.

I think those who argue "against" strong typing would say that the general assertion structure may find application in unexpected places and it is unnecessarily restrictive to name them within the SAML taxonomy.

I think those who argue "for" strong typing would say that we have to find the simplest solution to the use cases.  We don't have to solve any problems beyond those.  Having assertions declare their type will facilitate their processing, because it removes any potential ambiguity about the meaning of their contents.

Phill, I think you are an opponent of strong typing.  So, why don't you lay out your arguments in response to this email?

Issue 2

There are a number of options for the style of the "template" for requesting an assertion.  (Remember, "requesting an assertion" can mean "requesting the creation of an assertion, with the requester (or some other specified party) as its subject" or "requesting the retrieval of an existing assertion with some other specified party (or the requester) as its subject").

Issue 1 (reprise): in the current text, the assertion request does not indicate its type (e.g. whether a creation or retrieval action is expected).  It simply describes the assertion that it wants, and the responder has to decide whether it can satisfy the request by locating an existing assertion, or by creating a new one.

The current specification describes two styles for the assertion template:

1.      A list of "type/value" pairs, and
2.      An empty assertion with the required structure.

Dave Orchard identified two additional approaches that may be suitable:

1.      XPATH and
2.      XML Query.

David is willing to examine the options and recommend a suitable approach.  However, he needs example to work from.

Phill, I have to offer examples of assertion requests and responses.  You should keep an eye out for these and confirm that they are consistent with your proposal for assertions.

Issue 3

In the present text, there is no "decision assertion".  Instead, the PEP asks the PDP to return an attribute assertion that affirms its question.  For example, if the PEP wants to know if Joe should be permitted to Get URL http://www.x.com//y, then it asks for an attribute assertion that states that (according to the PDP) Joe should be permitted to Get URL http://www.x.com//y.  If the PDP decides that Joe should be permitted access, then it returns the requested assertion along with a status code indicating that the request was successfully fulfilled.  The PEP can store the resulting assertion for dispute-resolution purposes, but it would only actually act upon the status code.  (By the way, we have had discussion about dumb and bright PEPs.  In my mental picture, a PEP (by definition) respects completely the response it gets from its chosen PDP (a polite way of saying it is really dumb).  If it does anything else, then it isn't a PEP, it may be a combined PEP/PDP.)

Another camp argues that the PDP's "Yes/No" response should be in the form of an assertion.  I think the argument in favour of this is that the decision should be in the form of a persistent token for purposes of dispute resolution.

But, the two proposals are essentially equivalent: an assertion containing the answer "Yes" and a reference to the question, or an assertion containing an affirmation of the question, what's the diff?

Issue 4

We discussed what sorts of qualified responses the PDP should be able to give (in addition to the unqualified "Yes" and "No".  We decided that:

"Yes, but only if you do these additional things" would not be supported.

However, the consensus was that:

"No, but if you were to ask me again in a different way, then I might say "Yes"", should be supported.

So, we have to figure out how to represent this in the request/response protocol between the PEP and PDP.  A job for me, I suppose.

By the way, I shall be on vacation from 9^th May to 22^nd May.  So, don't be surprised if you get no response from me in that interval.

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