On 3/22/2006 8:52 AM, "Robert Yates" <[EMAIL PROTECTED]> wrote:
> Peter Davis wrote: >> The present atom-pub ID is ambiguous for UA support for 3xx class response >> codes (which would be required for the HTTP redirect binding). The POST >> binding carries no such dependencies on HTTP 3xx responses however. >> >> SAML POST only requires access to the POST and GET verbs of HTTP, and for >> convenience, support for response codes 3xx (redirect response codes), but >> those are not MTI for SAML POST to properly function. >> >> The defense RESTs ;-) >> > Not so fast ;-) The SAML POST binding requires that the HTTP UA be a > browser or at the very least it MUST be capable of rendering HTML forms > and then making posts of media type > `application/x-www-form-urlencoded'. Fair enough. (tho any self respecting webDav client should, which is what various blogging tools really are) > There is no such requirement on > atom clients, nor any HTTP UA. Google, for example, has an ATOM client > that is a plugin for word http://buzz.blogger.com/bloggerforword.html. > This certainly can't presently make use of SAML's POST binding. While > it can be argued that these clients could make use of this binding I > think the burden of being capable of parsing HTML Forms, forming a post > of media type 'application/x-www-form-urlencoded' and dealing with all > the character encoding pitfalls of html is too great when all they are > trying to do is authenticate. You are correct. As others have pointed out, however, conveying these messages as text/xml rather than application/x-www-form-urlencoded is not out of the question. > > The SAML redirect binding has more potential, as all HTTP UAs should > honor the 3xx return codes. The problem with this binding, that is also > shared with the POST binding, is how the user indicates to the SP the > location of his IdP. This (I think) is a challenge for any protocol proposal. IDP discovery has always been a challenge (esp when the user uses several IDPs for various purposes). Even with dmd1, we are faced with a requirement to have the user submit a URI to the SP to determine the IDP. > Here's the > problem. > > Elliot's dad's photostream has the following url. > http://apple.com/photostreams/elliots-dad. He e-mails the url of this > feed to Elliot and I. Now what? Again, assuming for the moment that you and Eliot use different IDPs, you would have to provide apple with some 'hint' as to where to try to route an authentication/attribute request. We have to go under the assumption that many IDPs will exist, and we'll need one (or more) mechanisms to: A] provide the relying party with at least a hint as to the set of IDPs the user and RP are willing to use for a given transaction/ B] convert that hint into something richer (metadata), which arms the RP with both the capabilities and endpoints in order to conduct the authentication > > Am not sure you can REST just yet. Your witness ;-) > Hehe. RESTful puns could get pretty bad. I'll give it a REST. =peterd (http://xri.net/=peterd) _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
