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:]
>>Sent: Saturday, July 28, 2001 9:47 AM
>>To: Mishra, Prateek; 
>>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
>>
>>
>> 
>> 
>> 
>> 
>>
>>