[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] AI 0031 Clarify text around AuthorityKind
> This seems strange to me. Element names and type names are in different > symbol spaces, meaning that it's possible to write a schema that defines > a type foo:Thing and an element <foo:Thing>. And though it would be > anomalous, it's certainly technically possible to write a schema that > binds element <foo:Thing> to foo:OtherThing, even in the presence of a > type definition for foo:Thing. This would be ambiguous in SAML's > AuthorityKind. Is it really ambiguous? Lines 720-722 of draft 05 state: For extension schemas, where the actual type of the <samlp:Query> would be identified by an xsi:type attribute, the value of AuthorityKind MUST be the same as the value of the xsi:type attribute for the corresponding query. Doesn't this text explicitly state preference for "type" over "element"? In any case, I am happy to add a potential erratum if you still feel this is an issue and we can discuss it tomorrow. Thanks, Jahan ---------------- Jahan Moreh Chief Security Architect 310.286.3070 > -----Original Message----- > From: Eve L. Maler [mailto:eve.maler@sun.com] > Sent: Monday, April 21, 2003 10:10 AM > To: SAML > Subject: Re: [security-services] AI 0031 Clarify text around > AuthorityKind > > > Scott Cantor wrote: > > The relevent text in core draft-04 starts on line 725. > > > > In general, I think it's in pretty good shape, as it's more > explicit than RespondWith was about the QNames being either element > > names or type names. > > Believe it or not, I hadn't realized that the AuthorityKind wording > allows for both types and elements! > > This seems strange to me. Element names and type names are in different > symbol spaces, meaning that it's possible to write a schema that defines > a type foo:Thing and an element <foo:Thing>. And though it would be > anomalous, it's certainly technically possible to write a schema that > binds element <foo:Thing> to foo:OtherThing, even in the presence of a > type definition for foo:Thing. This would be ambiguous in SAML's > AuthorityKind. > > I think we may want to treat this as an erratum that needs fixing as > soon as possible (possibly through some backwards-incompatible change) > and pick either elements or types. > > (Note that, even if we decide to get rid of <RespondWith> in V2.0, we'll > still have it in V1.1, and we may want to align whatever we do with > AuthorityKind to <RespondWith> or vice versa in V1.1.) > > > The apparent issue is with the assumption that extension query > types would be passed using xsi:type only. > > > > I suggest a change to lines 731-734 of the final sentence to read: > > > > ---begin--- > > Query extensions may be passed as a literal extension element > subtitutable for <samlp:Query> (e.g. <ns:NewQuery>) or as a > > <samlp:Query> accompanied by an xsi:type attribute (e.g. > <samlp:Query xsi:type="ns:NewQueryType">). In such cases, the > > "AuthorityKind" attribute MAY be set to either the derived > element name or the xsi:type value. > > ---end--- > > > > Even for built-in types, the intent was that either > <samlp:AttributeQuery> or <samlp:AttributeQueryType> would be > acceptable, and > > this isn't a big deal for implementers. It may be preferable to > use only the type in all cases, I guess, but I don't think it's a > > big deal. > > I'd be happier just using one, obviously, and I guess using the type is > fine, particularly if we can get some implementor feedback > confirming this. > > > Since AuthorityBinding is simply a rudimentary form of in-band > metadata, it's something to revisit for SAML 2.0 in conjunction with > > metadata discussions. > > Agree... > > Eve > -- > 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]