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: 2.x suggestions

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,


Possibly some additional work in this area for REST usage, and HTML5
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

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


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.

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