Protocol contents

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

Title: Protocol contents

Colleagues -

(Note: you'll need to use Courier font to view this properly.)

Here is the conceptual model ...

Legacy
Credential          Assertion        Result
-------->           -------->        ----->
           Authority            PDP           PEP
       ->            --
      |                |
       ----------------
           Assertion

Credential translation takes place at two locations: the Authority, which translates either an assertion or a legacy credential into an assertion, and at the PDP, which translates an assertion into a result (Yes or No).

The physical data flow depends upon the communication model and may be (for instance) from the Principal to the Authority, from the Authority to the Principal, from the Principal to the PEP, from the PEP to the PDP, from the PDP to the Authority, from the Authority to the PDP, and back from the PDP to the PEP.  What flows in each of these messages is more than just the assertion.  For instance, in the message from the PEP to the PDP, the PEP may provide the assertion, the posited name or requested action and (optionally) a verified authenticator (e.g. a password or an asymmetric or symmetric-key challenge/response pair).

The result (provided by the PDP to the PEP) may be viewed as an assertion.  It must contain the result ("Yes" or "No") and, in order to properly enforce accountability, we need to ensure that a PEP cannot later claim that the PDP provided a particular result in response to a different request.  So, additional information must be included.  The Assertions sub-committee needs to decide whether or not the definition of the result is in their scope.

Following the dictates of application-enablement, we want the PEP to do nothing more complicated than is absolutely necessary.  It may obtain an authenticator from the Principal (e.g. a password, a data/signature pair or an asymmetric or symmetric-key challenge/response pair).  It may obtain an assertion or a reference thereto from the Principal.  And, it must be able to verify the Result from the PDP.  Everything else should be done by the PDP.

It is entirely possible for the assertion issued by one entity to be provided to the next entity in the chain of the conceptual model, unaltered.  However, it is not possible in all circumstances for the response message in one exchange to be the request message in the next exchange.  The message from the Principal to the PEP, in the above example, has to be augmented by the PEP to form the message it sends to the PDP.

However, I am supportive of the idea that there can be a single schema for all the messages and the job of the Protocols sub-committee will be to define the contents of that schema and profile that contents for each of the messages in the communications model.

Just to be clear, the protocols are not an end-product of the specification.  They merely form guidance to the Bindings sub-committee for what they have to include in the protocol bindings.  Developers will work from the specified bindings, not the specified protocols.

Best regards.  Tim.

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