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: 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