Re: [security-services] Seeking your comments: Plan of work for SAML2.X revision (SAML2Revision)

[Chad La Joie <lajoie@itumi.biz>]

Below are my comments and thoughts.  Most of these come from my work
with my non-edu customers (Scott and Nate are better at representing
that constituency).

I think the XML signature and encryption profiles should be updated to
include stronger algorithms in the MTI list.

Reworking the profiles in terms of the various roles would be very
helpful.  As has been noted on the calls numerous times, people find
navigating these specs to be a real pain.  Writing the profiles in such
a way that they can operate as a starting point for people would be very
beneficial.

In terms of metadata, I think that at a minimum its use as a
configuration mechanism should be MTI.  I understand that many SAML
products today are not concerned about peer-relationship scalability.
However, my experience is that many customers deploying these products
do end up in a place where such scalability becomes an issue.

Metadata as the foundation of a trust layer seems more controversial to
me.  I certainly think the way it is used in HE & RE is far superior to
what I see in the commercial sector (i.e., cut and pasting certs into
UIs or simply ignoring the issue altogether).  But I do understand that
some deployment may actually have things like working PKIX
infrastructure (though I'd sooner expect to stumble upon a unicorn).
So, my feeling here is that we should create a document describing the
use of metadata in this way and strongly recommend, but not mandate,
that implementations support this.  Or go a step further and have a
"scalable product" conformance section that does make it MTI.

Lastly, stronger wording about some of the datatypes (and possibly
corresponding schema changes) would be useful.  Here's some of the
things I've run across that cause problems:
- xs:string values that are empty or contain only whitespace
- xs:integer being defined as the infinite set of all whole numbers
- URI values that aren't URIs (I'm looking at you, Google!)
- multiple encoding of URIs (e.g., URLs that URL encoded and then entity
encoded and then stuck in metadata and entity encoded again)
- URL canonicalization (e.g., are these two ACS endpoints equal
http://example.com/acs and http://example.com:80/acs?)
- busted base64 parsing (some want everything on a single line, some
require only so many characters per line, some count preceding
whitespace, some do not)

On 5/29/12 12:51 PM, Thomas Hardjono wrote:
> Folks,
> 
> As you may know, one of the big tasks for the SSTC this year is to
> begin updating the core specs (and other related specs/documents).
> 
> To that end Scott Cantor on behalf of the SSTC has kindly setup a
> wiki-page containing the tasks agreed so far by the SSTC, as well as
> those needing consensus:
> 
> http://wiki.oasis-open.org/security/SAML2Revision
> 
> The first section ("Agreement") shows the items the SSTC has agreed
> upon.
> 
> The second section ("Close to Consensus") are items that are nearing
> group agreement and would like to finalize.
> 
> A such, we would like to request your input/comments/suggestions for
> the items that are listed in the section titled "Close to Consensus",
> as well as items under the "Discussion" section.
> 
> Please email your comments to the SSTC mailing-list so as to reach the
> broad membership of the SSTC.
> 
> Thanks.
> 
> Thomas + Nate
> 
> __________________________________________
> 
> 
> 

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered