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: 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?




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


Powered by eList eXpress LLC