[security-services] AuthorityKind and RespondWith

[Irving Reid <Irving.Reid@baltimore.com>]

In my message titled "ISSUE: AuthorityKind and RespondWith"
(http://lists.oasis-open.org/archives/security-services/200202/msg00185.html
), I suggested that we replace the enumerated string types for those two
attributes with qnames.

In the ensuing discussion, particularly during the next conference call
(http://lists.oasis-open.org/archives/security-services/200202/msg00197.html
), it became clear that there were complications. We didn't get a chance to
talk about it on the Tues. Mar. 12 concall, so here's my attempt to spread
the mess out on the floor so we can look at it.

IR-1. RespondWith has mixed semantics

In core-27, lines 969-1001, RespondWith is specified as a URI reference with
possible values:
#SingleStatement, #MultipleStatement, #AuthenticationStatement,
#AuthorizationDecisionStatement, #AttributeStatement, or the schema URI
specifying the extension schema for extended Statement types.

Lines 960-961 specify that a request may contain any number of RespondWith
elements.

My understanding of the semantics of putting multiple RespondWiths in a
request is that there is an implied "or"; that is, if I ask for

<Request>
  <RespondWith>#AuthenticationStatement</RespondWith>
  <RespondWith>#AttributeStatement</RespondWith>
</Request>

I'm willing to accept responses containing either AuthenticationStatements
or AttributeStatements. This fits with the rationale, which is that the
requestor wants to make sure the response doesn't contain elements it can't
understand.

On the other hand, if I say:

<Request>
  <RespondWith>#SingleStatement</RespondWith>
  <RespondWith>#AttributeStatement</RespondWith>
</Request>

it seems there's an implied "and" - that is, the requestor can only handle
assertions that contain a single AttributeStatement.

My current inclination is to drop the #SingleStatement and
#MultipleStatement values, change the type to qname, and specify the exact
Statement element, as described in my earlier ISSUE message. This is a
slight functionality change - requestors can no longer constrain responders
to send only single-Statement assertions.



IR-2. RespondWith and AuthorityKind are subtly different

As of core-27, AuthorityKind specifies the kind of samlp:Query an authority
is willing to answer, while RespondWith specifies the kind of saml:Statement
the requestor is prepared to accept. I think this partly arises because our
Query structure doesn't match our Assertion structure. When we changed from
three different Assertion types to one Assertion containing different
Statements, we didn't make the corresponding change to Query.

I think the right way to fix this is to have a single Query type and use
RespondWith to specify what the result should be, but it's almost certainly
too late to make that drastic a change.

The alternative is to live with the disconnect between RespondWith and
AuthorityKind. What this means is that every implementation has to know the
rules (AttributeQuery means return assertions containing AttributeStatement,
etc.) and every extension schema that extends Statement has to specify what
the Query must look like (it might be possible to get away without extending
Query).

Unless a bandwagon forms very quickly around restructuring Querys, I'd like
to see us specify AuthorityKind as a qname, identifying the Query element
(i.e., <AuthorityBinding AuthorityType="samlp:AttributeQuery" ...>

 - irving -
 


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.