If I recall correctly, it doesn't define the format parameter, just gives one fixed value for the SAML flow. Either way, I am suggesting we keep the SAML flow out of the spec, keeping just the general assertion flow, with better format definition.
EHL On 4/15/10 11:55 AM, "Chuck Mortimore" <cmortim...@salesforce.com> wrote: +1. Did anyone have a chance to review the proposal I made here? I have a couple of people from the SAML community reviewing it offline, but would welcome feedback from this group. The sample text is attached to this post: http://www.ietf.org/mail-archive/web/oauth/current/msg01735.html One specific thing to note - the assertion flow is really appropriate for both autonomous and on-behalf-of user flows, so it will take some special editing to make that work with the current structure of the intro. -cmort On 4/15/10 11:02 AM, "Eran Hammer-Lahav" <e...@hueniverse.com> wrote: The assertion flow included in the specification doesn't offer enough to provide interop. Previous discussions ruled out the idea of offering a single SAML 2.0 based flow. Proposal: Leave the flow as a generic assertion flow, using SAML 2.0 as an example, and defining the syntax/values of the format parameter. As long as the format parameter is well-defined, the rest can be left for assertion-language-specific specs and implementations. Needed: Language defining the format parameter in a way which ensures interop across clients using the same format value (i.e. Registry, URI-based, etc). EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
