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



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