[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [security-services] ISSUE: core-27: RespondWith specifiedqueriesreturn AN assertion
FWIW, this thread is tangentially related to the threads leading up to.. It's FINAL: Additional Verbiage for Section 3.4.4 http://lists.oasis-open.org/archives/security-services/200203/msg00044.html ..in that the below concerns some of "the constraints expressed by the query." I'd scrawled: > > Section 3.2.1.1 of core-27 effectively > specifies that a Responder can return only one assertion in response to a given > request, because all the values of RespondWith specify return of "an > assertion", and the specified default behavior if RespondWith is absent from > the request is the behavior associated with a RespondWith value of > #SingleStatement. The above is only partially correct, it seems, because there can be multiple <RespondWith> elements in a request based on <RequestAbstractType> (Section 3.2.1, line 935). The relationship between <RespondWith> element(s) and queries in a <Request> appears to be undefined (or maybe I'm not finding it). Since <SubjectQuery>, <AuthenticationQuery>, <AttributeQuery>, and <AuthorizationDecisionQuery> each query about a single Subject, what does it mean to have more than one <RespondWith> element attached to a <Request> containing one of those queries? And since each <RespondWith> is semantically defined as meaning "an assertion", does it mean that if I make an <AuthenticationQuery> about some Subject, and include more than one <RespondWith> elements, that the responder should "AND" the values of the <RespondWith> elements when concocting its response? What if such an ANDing doesn't necessarily make sense, for example if I make an <AuthenticationQuery> about some Subject and include two <RespondWith> elements, one whose value is #SingleStatement and the other whose value is #AuthorizationDecisionStatement? Other pathological cases are easy to concoct, including ones that sorta might make sense (eg <AuthenticationQuery> w/ #MultipleStatement and #AuthenticationStatement and #AttributeStatement specified in multiple <RespondWith> elements). Also, <AssertionIDReference> and <AssertionArtifact> queries may explicitly query based on multiple values of AssertionIDReferences or AssertionArtifacts. If <RespondWith> is present, must the number of <RespondWith> instances equal the number of instances of <AssertionIDReference> or <AssertionArtifact> elements? What if they differ? > The "an assertion" language in Section 3.2.1.1 of core-27 needs to be cleaned > up to bring it in line with section 3.4.2. Actually, the "an assertion" language may be OK and it is more other aspects, as described above, that need to be clarified. JeffH
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC