RE: SW Frameworks and SAML mechanisms

["Simon Y. Blackwell" <sblackwell@psoom.com>]

"I.e. XACML maybe  the right thing for one community, then they
should use it, but XACML may also be totally off for another community
that for reasons I would not bother about, prefers to develop
their own auth*-vocabulary and schemas."

As chair of the XACML committee, I am quite concerned about the above
comment. I am very focused on assuring that our use of terminology is highly
consistent with industry standards and have spend considerable time
belaboring this issue with respect to the creation of our glossary document.
What has you make this assertion?

> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> Sent: Tuesday, July 24, 2001 11:29 PM
> To: Hallam-Baker, Phillip; Security-Services (E-mail)
> Subject: SW Frameworks and SAML mechanisms
> 
> 
> Hi,
> Having been following this work on-and-off since it became
> an OASIS activity, I have some questions and comments
> bothe regarding the general strategy and how to support a
> SAML API.
> 
> A difference between SAML and let's say ebXML and BizTalk, is
> that SAML goes beyond the technical framework by addressing
> things that are not strictly security-oriented but rather content and
> context-oriented.
> 
> To the [technical] security part I would count: digital signatures, 
> assertion-ID's, protocol bindings, protocol flows, validity data etc.
> However, "Claims" is IMHO "information" that the parties have
> agreed on (in spite of being associated with rights, which can be
> derived to security).
> 
> In S2ML there was an lighter (IMO better), type of mechansim 
> in the form of AzData that was a *framework independent*
> extension schema.  To build (and use) a SW framework
> based on such methods is very straightforward as the
> root schema+ security framework is constant and only
> payloads differ.  You simply register a code-class
> (implementeting a particular payload schema) and this
> one rides on the general framework.  By doing that a
> receiver can automatically decode any assertion and
> based on received payload schema do whatever
> is needed:
> 
> Init:
>         registerS2MLAzData (myfavoritauthorizationscheme.class);
>         registerS2MLAzData (someotherscheme.class);
> 
> Usage:
>         o = receiveS2MLFrameworkObject ();
>         if (o.AzData instanceof myfavoritauthorizationscheme) ...
>         if (o.AzData instanceof someotherscheme)...
> 
> Customized content (99% of all SAML-apps?), is IMO only valid
> within "communities", "domains" or "applications" (like
> Shibboleth and network  management to name two extremes),
> regardless of method used to achieve this functionality.
> 
> Due to the fact that the needs of different "communities" evolve with
> arbitrary speed and are totally uncorrelated (as the e-business
> world itself), as well as documentation issues, makes me less
> convinced that SAML should have bothered with "content" at all.
> I.e. XACML maybe  the right thing for one community, then they
> should use it, but XACML may also be totally off for another community
> that for reasons I would not bother about, prefers to develop
> their own auth*-vocabulary and schemas.
> 
> A SAML-example of what I mean: The term "Advice" is
> relevant in certain scenarious but certainly not in others.
> In true server-to-server communication there are seldom
> any advices to get, just pretty strict rules to follow.
> 
> Naturally, interoperability is ZERO between *different*
> "communities" but that's "compliant" with the entire e-business.
> As XML-schemas allow compatibility to be automatically
> verified both on name and content (and by a thing X-OBI are
> working with, also dynamically discoverable), at run-time,
> makes their use somewhat manageable at least.
> 
> To change the SAML route at this stage is admittedly not very
> realistic, but maybe some of the authors of the advanced extension
> mechansims could elaborate a bit on how universal binary
> SAML components and APIs can be created based
> on Schema inheritance or substitution groups? 
> As this is fairly new stuff in general, I guess it could be
> educating as well :-).
> 
> Regards
> Anders Rundgren
> X-OBI
> 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-services-request@lists.oasis-open.org
>