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


I disagree with the assertion that Anders has identified a flaw.

Anders appears to be confusing SAML, bizTalk and ebXML. The somewhat strange
assertion is made that they are all the same.


The same criticism could be made of email since the SMTP specification does
not specify the content type and in any case SMTP is the same as FTP and
NNTP.

Every successful specification addresses about 80% of a well defined problem
and is capable of extension to address both the other 20% and other problems
outside the initial scope.

If people want to we can make Advice subject to the same extension
mechanisms as other elements - use abstract types and require extension of
the base class.

Differentiating information that can be ignored in an extension from
information that cannot is one of the most important issues for extensible
application.


There are certainly communities that want to apply systems built on SAML
with extensions to address specific applications that are outside SAML
scope. The assertion that they are all by their nature 'closed' and do not
require 'interoperability' is false. 

Standards facilitate interoperability. Standards cannot enforce
interoperability nor are they actually essential for interoperability. The
banking industry has racks of standards and racks of hardware that
(unhappily) interoperates with other racks of hardware at other banks using
protocols that bear no relation at all to the carefully crafted standards.

Industry would like us to produce a standard that will facilitate their
interoperability efforts. However they will get their job done in the end
with or without our help.


		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Simon Y. Blackwell [mailto:sblackwell@psoom.com]
> Sent: Thursday, July 26, 2001 9:45 AM
> To: 'Anders Rundgren'; Security-Services (E-mail);
> xacml@lists.oasis-open.org
> Subject: RE: SW Frameworks and SAML mechanisms
> 
> 
> 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?
> > 
> > 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: xacml-request@lists.oasis-open.org
> 

Phillip Hallam-Baker (E-mail).vcf



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


Powered by eList eXpress LLC