As you've pointed out, the current text is in somewhat of a grey area. It's either over specified ( remove any reference to SAML ) or underspecified ( be very explicit about exactly what is expected )
I'd advocate that the core spec is left under-specified. If we're prescriptive on the exact version and format of SAML, than the result will be other use-cases will simply force non-standard extensions. It seems we do need to document exactly what what specific values of assertion_format requires, but the core spec should be open to multiple formats. This would allow for flexibility with SAML, which has multiple versions, formats, and confirmation methods, but also allow for this message exchange patterns with completely different assertion types. It will somewhat future proof the core spec. Note that I'd be happy to work on the documentation of a specific format and contribute that to the group. -cmort On 4/1/10 12:24 PM, "Eran Hammer-Lahav" <e...@hueniverse.com> wrote: A generic assertion flow is too under-specified to be included. If a SAML2 assertion flow isn't enough or useful, we should define what is and fully specify it. The current text is still incomplete as it doesn't address how the assertion should be encoded in the request. EHL On 4/1/10 11:21 AM, "Marius Scurtescu" <mscurte...@google.com> wrote: Instead of "SAML Assertion Flow" maybe we should stick with the more generic "Assertion Flow". The assertion_format parameter allows you to define the assertion type. Maybe we can predefine some well know formats, for example: "saml1", "saml1.1" and "saml2"? Marius On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > I'm making good progress working off David's draft and bringing text from > WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far > it is largely in line with David's proposal and the majority of changes are > purely editorial. > > The only significant change I have made (which is of course open to debate) > is renaming all the authorization flows parameters. I dropped the oauth_ > prefix (no real need since these are purely OAuth endpoints, not protected > resources), and made most of the parameter names shorter. I am not done so > they are not consistent yet. > > You can follow my progress (changes every few hours) at: > > http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth > .txt > > Please feel free to comment on anything you like or dislike. I will publish > the whole thing as an I-D once it is feature complete for the WG to discuss > before we promote this to a WG draft. > > I hope to be done with the initial draft by middle of next week (I'll be > flying most of Fri-Sat so no progress over the weekend). > > 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
