[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Syntax for request/response
From: Tim Moses [mailto:firstname.lastname@example.org]
Sent: Monday, May 07, 2001 6:18 PM
To: 'OASIS Security Services group'
Subject: Syntax for request/response
Background: it has been suggested that there are (at least) four styles for the contents of the request/response messages:
1. The requestor sends an assertion with the required field types, but missing values,
2. The requestor sends fields and values, in the form of a list, not an assertion,
3. XPATH expressions, and
4. XML query statements.
David Orchard has offered to evaluate the characteristics of each approach and recommend one. But, in order to do that, he needs example uses.
While it is an open question whether request/response messages will explicitly declare their type, nevertheless, there are three types in SAML:
1. The requestor expects the responder to produce an assertion, with the requestor as subject, meeting the specified requirements,
2. The requestor expects the responder to locate and retrieve an assertion with some other identified entity as subject, meeting the specified requirements, and
3. The requestor expects the responder to evaluate an access statement, possibly having first located and retrieved a suitable assertion, and return the result of the evaluation.
While it is an open question whether assertions will explicitly declare their type, nevertheless, they are of two main types:
1. Authentication and
Authentication assertions primarily contain a "name" attribute and attribute assertions contain other attributes.
So, taking into account the requirements set in the use cases, here are some sample request/response pairs.
1. The requestor requests an authentication assertion that will be accepted by an identified secondary domain. The requestor, in its request, identifies the target domain. The responder returns an indication of its success or failure and the resulting assertion or a reference to an assertion (in the event of success) that it stores for later retrieval.
2. The requestor requests an attribute assertion that will be accepted by another (unspecified) secondary domain. The request specifies the requested attributes. For instance, a group name, a role, a signing authority or a security clearance. The responder returns an indication of its success or failure. If it indicates success, it may return the requested assertion or a more general version of the requested assertion. If it indicates failure, it may return nothing or a more constrained version of the requested assertion.
3. The requestor sends a reference to an authentication or attribute assertion to the responder, indicating that it wants the corresponding assertion to be returned. If successful, the responder returns the assertion.
4. The requestor sends a description of an assertion that it would like the responder to locate, retrieve and return. If successful, the responder returns a success indication and an assertion that either exactly meets the requirements or is more general. If unsuccessful, the responder returns a failure indication and (optionally) one or more assertions that are more specific than the one specified.
5. The requestor sends a question concerning the authorization status of a subject in relation to a specified resource. The subject may be identified by name, by an authentication assertion or by a reference to an authentication assertion. If necessary, the responder locates and retrieves the specified (or a suitable) assertion) and evaluates it in relation to the resource. It can reply in one of three ways: "Yes", "No" or "No, but if you had asked this (more specific) question, the answer would have been 'yes'".
David - Is this sufficient for your purposes? Best regards. Tim.
Powered by eList eXpress LLC