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] W-5: SSO Profile Enhancements (Part 1)


> 1. The SSTC continue to work with the structure given in the ID-FF 1.2
> materials. In other words, separate generic flows and schema extensions
> required to support Web SSO and federation from specific technology
> realizations.  

Yes, it's been my hope that we could generalize things by describing new
"bindings" for the SAML request/response protocol that would be bound to a
browser and URLs as the transport instead of SOAP. This models the use of
redirection to carry messages in both ID-FF and SAML, but permits (nearly)
any protocol message to be carried that way when practical.

I also think we should try and unify the processing rules and content
between the artifact and POST profiles as much as we can, which I think is
very achievable if the artifact request is simply viewed as an alternate
binding for returning the Response message to the destination site when the
browser "binding" is used. This requires some respinning of what an artifact
really is, but I don't think that's insurmountable.

I think the end result will be similar in form if perhaps not in
presentation, but will be easier to understand and to extend to new use
cases. As an example I noted before, if the AuthnRequest and Response
messages are simply viewed as SAML protocol, then we already have a SOAP
binding, and a profile for SOAP-speaking clients and providers falls out
from that fairly readily.

-- Scott



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