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: [security-services] Slightly revised proposals to core/bindings


I'm not going to clutter up the list with another meg of files, but please find an update to the core and binding extensions for new
SSO profiles in Word form here:

http://usfs2.us.ohio-state.edu/SAML/

The change that I made is something I'm coming to feel fairly strongly about in light of the complexities I'm seeing in Liberty
regarding changes to their SAML extensions. What I did was reformulate the original proposal, an extension to samlp:Request, as an
extension to samlp:Query within an unchanged samlp:Request.

I have come to believe that just as Assertions extend by defining new statement types, profiles that use requests should extend by
defining new Query types. We can quibble about whether a request for SSO is a proper query, or what the name of it should be, but
the control over versioning the semantics of the query are much cleaner this way.

As a simple example of why, our model for indicating expectations on the part of requesters and responders is the RespondWith and
AuthorityKind elements, and both of them deal with query and statement types as QNames. While they may not be applicable in the case
of this interaction, which is not the usual query to an authority interaction, the consistency of the approach is the point.

-- Scott



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


Powered by eList eXpress LLC