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] | [List Home]


Subject: Re: [security-services] AI 0031 Clarify text around AuthorityKind


I realize I'm yanking on something that wasn't part of the presumed 
original problem...  I'm sorry for any confusion (and for any annoyance 
at my "thinking out loud" on this).

Scott Cantor wrote:
> I certainly agree that using types is sufficient, but could you clarify this ambiguity? How can somebody redefine what type
> samlp:AttributeQuery is bound to?

You're right that QueryType serves as a bedrock base type; you can't 
start from an unrelated branch of the type hierarchy, so I can't see a 
way to have the kind of symbol space clash I was talking about before. 
That's good.

However, in making a little diagram to try and figure this out, I think 
that (a) I should withdraw my earlier offhanded wish for type-only 
AuthorityKind, and (b) your proposed wording *may* not be entirely 
sufficient to describe the semantics we need.  The reasons: There may 
not be a one-to-one correspondence between types and elements, and there 
can be a "skew" between the native/foreign boundaries for types vs. 
elements.

Let's say you have a type hierarchy like this:

samlp:QueryAbstractType
|
|__samlp:QueryType
    |
    |__my:MyQueryType

Because we require the <samlp:Query> element to be the "root" of any 
AuthorityKind value, samlp:QueryType is thus the corresponding root 
type; any element with, say, samlp:QueryAbstractType is out of the 
question.  Cool.

But let's say that, in someone's extension of SAML, these types are 
bound to elements in the following pattern:

samlp:QueryAbstractType
|
|__samlp:QueryType = <samlp:Query>, <my:MyBasicQuery>
    |
    |__my:MyQueryType = <my:MyFullQuery1>, <my:MyFullQuery2>,
                        <samlp:Query xsi:type="my:MyQueryType">

What if I wanted to say that an authority is in charge of answering only 
<my:MyBasicQuery> queries?  I need to be allowed to provide an element 
name in this case, because there's no type unique to only this element.

What if I wanted to say that an authority is in charge of answering only 
<my:MyFullQuery1> queries?  Again, I need to be allowed to provide an 
element name, this time to distinguish it from <my:MyFullQuery2>, which 
is bound to the same type.

I think this means that your proposed text should be changed to allow 
the naming of both elements and types, even when there's an extension. 
Unless we don't want authorities to be this selective in their power... ??

Further, if I say that AuthorityKind="samlp:QueryType", does this mean 
to say that the authority responds to queries of both the form 
<samlp:Query> and the form <my:MyBasicQuery>?

If I say that AuthorityKind="my:MyQueryType", does this mean to say that 
the authority responds to all of <my:MyFullQuery1>, <my:MyFullQuery2>, 
and <samlp:Query xsi:type="my:MyQueryType">?

This points to a potential insufficiency in all the wording we've ever 
had on the subject.  If we want these interpretations, we should 
probably spell it out.

> All I see is two ways of accomplishing the same thing, but I don't quite see where there's a potential for ambiguity.
> 
> The reason I proposed text that introduced this problem is that the actual errata brought up was that the text *presumed* use of
> xsi:type, but I guess that can be fixed by still requiring the type of the derived element to be used.

Agreed.  I'm just being a troublemaker. :-)

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com



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