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


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]