RE: SW Frameworks and SAML mechanisms

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

Anders, it appears that your response speaks entirely to SAML. Whereas, your
initial posting and mine spoke to XACML creating its own auth vocabulary. I
am confused.

I would also very much like to see a response from someone on Security
Services. Since we are bound to use certain aspects of what SAML specifies,
then it would be useful to know why SAML is not flawed in the manner that
Anders points out.



> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> Sent: Thursday, July 26, 2001 12:38 AM
> To: Simon Y. Blackwell; Hallam-Baker, Phillip; Security-Services
> (E-mail); xacml@lists.oasis-open.org; Simon Godik
> Subject: Re: SW Frameworks and SAML mechanisms
> 
> 
> Simon,
> I don't doubt a second that both the SAML stuff like Advice 
> etc. and XACML 
> are well-designed. But I "fear" that SAML assertion 
> attributes in many 
> implementations could equally well be 100% customized as they 
> only have a 
> meaning in a certain community.  Sectors like health-care may even
> *want* to define their own profiles. An observation: ebXML defines 
> a segmented standard where you can choose only the transport 
> and leave core components (vocabulary). ebXML did not even 
> *try* to sketch a PurchaseOrder, in spite of being a major 
> source input to 
> the design. I.e. contents is scary stuff and SAML would have 
> benefited 
> from making content separate, and entirely focused on *technical 
> security*, that has a much better chance surviving, and also is a task
> for "true" specialists. Content is more a task for: "Politicians".
> E.g.. I cannot see any reason for asserting a SAML "Evidence"
> "This is an Md", when a specialized health-care attribute
> schema could equally well say this in a (for them only), more
> natural way.  In many scenarious asserted data are simply a
> bunch of attributes that the RP are supposed to recognize,
> trust and use in a scenario-dependent way.
> 
> XACML should be a content canditidate for certain SAML-profiles,
> but this is a "marketing" issue as well.
> 
> The recent posting claiming that SAML "Advice" could become the
> general container for all sorts of "rubbish", is an indication
> that my fears are indeed not unjustified. 
> 
> There are still two unanswered questions from my previous posting:
> 1. Will every *likely* SAML app require a unique extension schema?
> 2. How does this match the neeed for a SAML API?
> 
> - Anders
> 
> >"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?
> 
>