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] minutes for SSTC telecon/focus 2002-02-26

Couple comments (sorry I was unable to make the call)...

> Prateek:  AuthorityBinding and RespondWith are separate, right?
> Irving:  thought they were the same, but now see they're different
>   is AuthorityKind saying "what I'll accept" or "what I'll respond
>     with" ?  need to clarify
> Hal:  clearly means "what I'll produce"

That was the intent, but it wasn't really necessary to say more (IMHO)
because SAML already specified that if I send an AttributeQuery to
something that advertised itself as Kind="attribute", I still have to be
able to deal with the other statement types (maybe deal with=drop on

This is really the issue (which I guess Irving noted). If you want to
get more specific about what AuthorityKind means, then tighten up the
query/response rules. Otherwise, it's really just a hint. Take it out if
you like...

> Hal:  I'm a strong proponent of keeping clear distinction,
>   having clear semantics for the different queries/statements

Me too. I guess the motivation for bundling statements is efficiency,
but I don't understand the semantics of asking for attributes and
getting a decision as well. What was the Action? Or the resource, since
it's optional with attr queries? If a different kind of query is
invented where it makes sense to get multiple statement types, that's

> Irving:  problem is that enumerations in XML aren't extensible
>   so wherever we have enumerations we have extensibility problem

This is a good way to describe the reasons for using a QName. It can
reference any element you define in a namespace, so you control the
extension of the enumeration by controlling the schema for the

> Irving:  so proposal is to add additional "NameSyntax" attribute, in
>   addition to current SecurityDomain, to NameIdentifier element

I like the name "NameSyntax"...does anybody like the idea of changing
"AttributeNamespace" to "AttributeNameSyntax"? Is that consistent?

-- Scott

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

Powered by eList eXpress LLC