[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Update: Contributed doc. browser bindings incl. Shibboleth
Thank your for your contribution. I urge you to joing the bindings sub-group for further discussion on this topic. In addition to weekly conference calls, there is also a bindings mailing list on which details of various proposals are discussed. In the meantime here are a few questions: (1) How does the user travel from the source site to the destination site? In Scenario 1-1 of the Use-Case document, the user utilizes her browser to select a link pointing to the destination site at the source site. Selection of this link has the effect of re-directing the user to the destination site. All of these steps are completely within the framework of stock commercial browsers and HTTP 1.1/1.0. What are the corresponding steps in your proposal? To what extent are they standard? In particular, i am unable to follow the steps (p.3): "The source-site generates an entire SAML assertions and puts it in a HTML form and returns to the user's browser which performs the actual re-direct with the help of some javascript" What is really happening here? A page is loaded into the user's browser and it automatically posts into some remote site. This has nothing to do with re-direction but has to do with the effect of some specific Javascript code running in the "background". Will all browsers implement this code correctly? (2) Commercial usage of the internet is based upon fairly heavy use of re-direction. A major challenge with the use of POST is that interacts poorly with re-direction (RFC 2068, Section 10.3, attached). Certainly, we can ignore this type of practical usage but many sites are built around the idea that once users arrive at the site and authenticate (implicitly thru SSO) they may be re-directed to an appropriate URL. In your solution, the user can only be served a HTML page with a choice of URLs and must re-select a target URL at the destination site. More later, prateek ---------------------------------------------------------------- RFC 2068 states in Section 10.3: 10.3.2 301 Moved Permanently The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD be done using one of the returned URIs. Clients with link editing capabilities SHOULD automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cachable unless indicated otherwise. If the new URI is a location, its URL SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request. >>-----Original Message----- >>From: Anders Rundgren [mailto:anders.rundgren@telia.com] >>Sent: Saturday, July 28, 2001 9:47 AM >>To: Mishra, Prateek; security-services@lists.oasis-open.org >>Cc: Tim Moses; RL 'Bob' Morgan; Marlena Erdos >>Subject: Update: Contributed doc. browser bindings incl. Shibboleth >> >> >>Hi Prateek, >>You asked for the write-up. Did never got any feedback though. >>Here is an upgrade that also includes Shibboleth: >> >> http://www.x-obi.com/OBI400/andersr-browser-artifact.ppt >> >>The Push model is by no means dead. It is the Pull model that has >>problems. Although one can argue if this is a Push model really... >> >>Regards >>Anders >> >> >> >> >> >> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC