RE: Syntax for request/response

Title: Syntax for request/response

I 
think it safe to say that at a minimum the XACML group would suggest 1 and 3 or 
4 for request/response styles. One of the values of XML is that it stores 
information in a manner to which very granular entitlement rules can be applied, 
i.e. arbitrary sub-nodes in an XML document. There is no reasonably concise and 
expressive manner to point to a node within an XML document with just 1 or 2. If 
SAML does not support 3 or 4, then a huge portion of the value of XACML will be 
unavailable to SAML compliant implementations.

 

On a 
different note I think "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'".   Is quite important for 
it allows the building of applications that can, without human 
intervention, help facilitate access when access should indeed be granted 
to the requestor without, and this is important, embedding prior knowledge of 
the entitlement policies in the requesting 
application.

  
-----Original Message-----
From: Tim Moses 
  [mailto:]
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 
2.      Attribute. 

  
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. 

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