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] | [List Home]


Subject: Re: [security-services] Comments on Work Item 28b: Attribute Reconciliation between XACML and SAML


Eve,

My take on what Irving was saying (but not to put words in his mouth)  
was not that we should add <any namespace="##other"...> to everything  
we design, but more that we should consider strategies for how we:

a) allow extensions to SAML itself
b) figure out what SAML "is" in terms of writing schema that  
specifically provides solutions, and leaving the rest to others, that  
may extend SAML, "plug-in" *to* SAML, or "plug-in" SAML to their  
solution.
c) deal with issues of versioning - when the namespace revs, and/or  
semantics change, we cause extra work for implementors. Sooner or  
later, it would be nice to get to the point where we don't have  
implementors supporting several different versions of SAML and ID-FF,  
and wondering when the next major change is coming to the software  
they've spent months writing... Designing with an upgrade path in mind  
may help avoid confusion.
d) think about the changes we're making in terms of usability by either  
the implementor or deployer - how easy will it be to write this stuff  
as software? How easy will it be to setup a piece of software written  
to the spec?

In some cases (probably only a few) we might add an <any  
namespace="##other"...> ;)

- JohnK

On Wednesday, Oct 22, 2003, at 12:47 US/Eastern, Eve L. Maler wrote:

> Irving,
>
> We can probably improve on our existing design in this respect, but  
> I'm wary of "'any' schemas", just as I was wary of what we called  
> "#PCDATA DTDs" in the old days: if you don't lock down your semantics  
> in specific markup, you haven't achieved anything of value by using an  
> XML-based protocol.  You do make a good point about farming out  
> various pieces of work to other namespaces that are not necessarily  
> under our control, and we can usefully look for places where the  
> markup should be more loosely coupled.  I suspect we'll need to have a  
> philosophical discussion on these points this week.
>
> 	Eve
>
> Reid, Irving wrote:
>
>> I'm going to start with a bit of a philosophical rant here; I'll try  
>> to keep it short...
>> The more XML specs I see (and, to be honest, I haven't seen _that_  
>> many), the more I prefer a minimal approach to schema design. As I  
>> see it, the fewer software components that need to care what's inside  
>> any given element, the easier it is to compose solutions. When  
>> someone does need to look inside an element, they should be able to  
>> do it with standard XML mechanisms like XSLT, XQuery, etc. This leads  
>> to an approach where the schema defines a thin framework, with  
>> type="any" in almost every element.
>> I see SAML and WS-Security (especially WSS) going down a road of  
>> requiring every piece of code that handles a document to understand  
>> the entire document, and often look inside almost every element in  
>> case there's something relevant inside. This leads to thousands of  
>> lines of wasted code, manipulating elements that the application  
>> wishes it didn't have to care about.
>> The other part of the minimalist philosophy is to not invent new  
>> mechanisms where XML already provides one (or more). For example,  
>> every time we want to add a new namespace or type designator, we need  
>> to ask "can this be done with xsi:type or XML namespaces?" I'll grant  
>> that sometimes the answer to that question will be "no", but I  
>> suspect there are plenty of XML schemas that could be made a lot  
>> simpler.
>> OK, enough of that. Corner me by a whiteboard some time and ask about  
>> my 6-line XML Schema for SAML...
>> My comments are based on Rebekah Lepro's submission of Tuesday, Sept.  
>> 30. Line numbers refer to the PDF document linked below.
>>> From: rlepro@arc.nasa.gov [mailto:rlepro@arc.nasa.gov]
>>> Sent: Tuesday, September 30, 2003 12:32 PM
>>> To: security-services@lists.oasis-open.org
>>> Subject: [security-services] Groups - 28b-draft-solution-0.1.pdf  
>>> uploaded
>>>
>>> Document Description:
>>> Initial draft of a proposed solution for attribute reconciliation  
>>> between SAML and XACML.  Also considers a solution to several  
>>> existing use cases presented on the mailing list.
>>>
>>> Download Document:   
>>> http://www.oasis-open.org/apps/org/workgroup/security/download.php/ 
>>> 3666/28b-draft-solution-0.1.pdf
>> I've been struggling with how to approach this issue, and trying to  
>> pin down why I feel uncomfortable with this proposal. The meat of the  
>> matter starts at line 15, Proposed Solution; all changes are to the  
>> "AttributeDescriptorType" schema.
>> 1) Change the semantics of the "AttributeNamespace" XML attribute.  
>> The old interpretation was as a "grouping" of attributes to reflect a  
>> pre-negotiated interpretation of both the attribute name and value.  
>> The new proposal is to use this attribute to identify the textual  
>> interpretation of the attribute name, ie. OID, URN, etc.
>> Rather than re-use AttributeNamespace, if we want this added  
>> complexity we should add a new "AttributeNameFormat" attribute.
>> 2) Add an optional "Issuer", with a corresponding "Format". First,  
>> the "Format" should be "IssuerFormat" to make it clear we're talking  
>> about the format of the "Issuer" attribute, not of the attribute  
>> value.
>> I'm not entirely sure what the "Issuer" attribute is supposed to  
>> mean. Is it a rough replacement for the existing  
>> "AttributeNamespace", that is, a way of identifying the context of  
>> the attribute? Or do you intend to allow a new assertion semantic?
>> Existing assertions look like:
>> Andy asserts that Chris is Blue (Andy is issuer, Chris is subject,  
>> Blue is attribute)
>> Are you proposing to support:
>> Andy asserts that Jean says that Chris is Blue (adding Jean as the  
>> attribute issuer)
>> I think that the semantic subtleties of this are far beyond what the  
>> average administrator will be able to understand and correctly  
>> configure.
>> 3) Add a "DataType" attribute to indicate the type of the  
>> corresponding AttributeValue. For this one, I'd like to see a clear  
>> argument for why we couldn't use xsi:type or namespaces to solve the  
>> problem.
>> I'm concerned about the effect of adding extra attributes, even if  
>> they are optional. Unless we have very specific guidance in our  
>> profiles, a relying party can't ignore them - after all, how can we  
>> know for sure whether
>> <Attribute name="foo" nameFormat="uri">...</Attribute>
>> and
>> <Attribute name="foo">...</Attribute>
>> are supposed to be interpreted as the same.
>> I'm having a hard time figuring out how to express my big concern,  
>> but here goes. I feel like every time we touch this spec (and  
>> WS-Security, and many others like them...) we're making it harder and  
>> harder for people to successfully implement the specifications. Worse  
>> yet, I think the complexity we're adding means that even if a piece  
>> of software correctly implements the specification, it will be  
>> prohibitively difficult for users to figure out how the software  
>> works. In normal circumstances this is a major problem. With  
>> security-related specifications, it's much worse. We simply cannot  
>> expect even well-trained computer scientists to be able to tell  
>> whether they're getting it right. There are too many examples of  
>> well-meaning but broken-by-design security mechanisms already.
>> Unfortunately, the next question is "what do I suggest we do about  
>> it?". I wish I could answer that. We don't want to start over from  
>> scratch, so I guess what I'm looking for is an evolutionary attitude  
>> that goes back to what I said at the beginning of this message.  
>> Wherever possible, we need to look at ways to solve new use cases by  
>> simplifying the schema rather than making it more complex.
>>  - irving -
>
> -- 
> Eve Maler                                        +1 781 442 3190
> Sun Microsystems                            cell +1 781 354 9441
> Web Products, Technologies, and Standards    eve.maler @ sun.com
>
>
> To unsubscribe from this mailing list (and be removed from the roster  
> of the OASIS TC), go to  
> http://www.oasis-open.org/apps/org/workgroup/security-services/ 
> members/leave_workgroup.php.
>



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