OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [security-services] RespondWith element processing is underspecified

At f2f#5 we agreed to include the "RespondWith" element. However, no
agreement was reached on the semantics of this element as well as its
interaction with error conditions.
Is this an advisory element (i.e., essentially useless)? If so, why are we
including it
in the draft?
As an alternative it could be a considered a hard requirement; in other
words, if a requestor
submits a <RespondWith> value of "AuthenticationStatement", then the
responder MUST
respond with an assertion containing an AuthenticationStatement OR return an
error response. Of course, this does not cover the case when multiple
assertions are returned
(e.g., lookup by assertion id, for example). Does it mean every returned
assertion MUST contain a "Authentication Statement"? 
Additional example of complexity abound. Another example is given in
We have not discussed these processing rules at all. In their absence, the
<RespondWith> element adds additional complexity and confusion to the draft.
We should either:
    (a) remove section and the <RespondWith> element
    (b) drastically simplify its contents (for example, we can probably give
simple processing rules for the schema URI case).
    (c)  provide detailed processing rules for all of the cases.
- prateek

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC