2.x suggestions

["Cantor, Scott" <cantor.2@osu.edu>]

I had an action to propose some concrete changes to the conformance
document in the event that a new version of the standard is undertaken.

As a related point, I thought it would be useful to propose some specific
extensions that I think ought to be merged into the core documents,
probably without actually changing any namespaces, just as a way of
combining and streamlining the material.

On that subject,

Core:
http://wiki.oasis-open.org/security/SAML2DelegationCondition
http://wiki.oasis-open.org/security/SAML2AttributeExt

Bindings:
http://wiki.oasis-open.org/security/SimpleSignBinding
Possibly some additional work in this area for REST usage, and HTML5
enhancements?
I think we need to codify IdP-initiated SSO by proposing a basic,
unsigned, query-string parameter based subset of AuthnRequest
functionality as a trigger for the IdP. There really is no such thing as
IdP-initiated SSO, so there has to be a request. Not specifying one is
non-interoperable.

Profiles:
http://wiki.oasis-open.org/security/RequestInitProtProf
http://wiki.oasis-open.org/security/IdpDiscoSvcProtonProfile
http://wiki.oasis-open.org/security/SstcSaml2AttributeX500Profile (this
was really errata to the original)

Metadata:
http://wiki.oasis-open.org/security/SAML2MetadataAttr
http://wiki.oasis-open.org/security/SAML2MetadataIOP
http://wiki.oasis-open.org/security/SAML2MetadataAlgSupport
http://wiki.oasis-open.org/security/SAML2MetadataUI
http://wiki.oasis-open.org/security/SAML2MetadataDRI

In terms of conformance, I would take a hard look at everything that's
currently MTI and probably reduce the number of bindings that are MTI for
Web SSO.

I could see continuing to have conformance modes that divide into "light"
and "full", but I would change the emphasis between them to have less to
do with "state management" and more on which pieces of the spec I see get
used heavily and are useful for truly scalable deployment. A "full"
implementation shouldn't have to do things like logout or NameID mgmt, but
should have to support metadata for configuration and at least one full
metadata profile that is interoperably specified.

I think if we're going to make logout part of any mandatory conformance
class, we need more specified on how it's supposed to work and a practical
set of UI guidelines for it. Since I don't think that's doable, I don't
happen to think it should be mandatory, but I'm open to somebody supplying
the missing material.

Finally, I would tighten and clarify conformance for implementing ECP. We
have growing interest in that material, and while I don't think it should
be MTI, it should be more interoperable by requiring some specific
client/IdP interactions.

That's a start anyway.

-- Scott

PS. Might also be worth looking at deprecating some things that see little
or no usage or were intended to be replaced by other work.