RE: [security-services] Groups - saml-session-token-v1.0-wd06.pdfuploaded

[Hal Lockhart <hal.lockhart@oracle.com>]

The main idea behind this profile is to standardize existing practice, which generally uses one of the two forms of cookie described. 

A cookie is set by the server and returned on the next request from the browser. This is just the behavior we want. A header is sent one way from sender to receiver, but not automatically returned by the browser.

As it happens we are considering creating a different profile which would use HTTP headers to transport SAML Assertions. This would be intended to meet other usecases.

Hal

> -----Original Message-----
> From: Colin Wallis [mailto:Colin.Wallis@dia.govt.nz]
> Sent: Monday, February 21, 2011 5:34 PM
> To: security-services@lists.oasis-open.org
> Subject: RE: [security-services] Groups -
> saml-session-token-v1.0-wd06.pdf uploaded
> 
> 
> We were taking a deeper look at it just yesterday (better 
> late than never I guess) in preparation for bringing it into 
> a future release of our NZ iGovt Logon Service messaging spec.
> 
> This questions was raised (and I haven't had the opportunity 
> to clarify exactly what it means with the person but thought 
> I would forward to the TC anyway..)
> 
> "Do you know why they've limited themselves to passing by 
> cookie?  I'd think you'd want to be able to pass a reference 
> in a header var (but haven't tried to think it through)." 
> ,..was from Bill Young, our Architect on this application.
> 
> My immediate thought was 'scope', but would welcome your views folks.
> 
> Cheers
> Colin
> 
> -----Original Message-----
> From: Cantor, Scott E. [mailto:cantor.2@osu.edu] 
> Sent: Monday, 21 February 2011 7:55 a.m.
> To: security-services@lists.oasis-open.org
> Subject: RE: [security-services] Groups - 
> saml-session-token-v1.0-wd06.pdf uploaded
> 
> I think all of my major concerns have been addressed.
> 
> Thanks,
> -- Scott
> 
> 
> ====
> CAUTION:  This email message and any attachments contain 
> information that may be confidential and may be LEGALLY 
> PRIVILEGED. If you are not the intended recipient, any use, 
> disclosure or copying of this message or attachments is 
> strictly prohibited. If you have received this email message 
> in error please notify us immediately and erase all copies of 
> the message and attachments. Thank you.
> ====
> 
>