RE: [security-services] A browser/POST question...

["Philpott, Robert" <rphilpott@rsasecurity.com>]

See my 2 proposals at the end of this message...

As I mentioned in the note raising this to the list, I personally think it
is useful to add a clarifying statement (for consistency with the B/A
Profile). Telling the implementer that the data is not prescribed by the
profile and thus MUST NOT (I'm also okay with SHOULD NOT) be included might
keep someone from including it anyway and creating an interop issue down the
road.  Everything I hear about this tells me this really IS what we meant
for the semantics. As Prateek said, it's not mentioned in the POST Profile
(so it shouldn't appear in implementation).

I had separately provided a private draft of edits to Eve that contained
some clarifying text on this.  I stated the following pending the outcome of
the discussion on the list:
-------------------
The <saml:Subject> element for each statement in the SSO assertion(s) being
returned MUST contain a <saml:SubjectConfirmation> element as follows:
*	The <saml:ConfirmationMethod> element MUST be set to
urn:oasis:names:tc:SAML:1.0:cm:bearer.
*	The <SubjectConfirmationData> element MUST NOT be specified.
-------------------

Scott had suggested "Each statement subject included in the response MUST
include a <saml:ConfirmationMethod> element of
urn:oasis:names:tc:SAML:1.0:cm:bearer.". 

I tried to be a bit more specific - statements are returned in the SSO
assertion(s) (that are in the response).  Also, since the response MAY
include other non-SSO assertions (the profile does say this), I was
restricting the confirmation method to JUST the SSO assertion statement
subjects.  Or should it really be on all subjects of all statements of all
assertions in the response? I believe it is the former.

I REALLY did start out hoping that this could be an editorial clarification
since I really think it's what we've always meant.  I have NOT actually
heard anyone express the opinion that we do have a normative issue with
ConfirmationData in the POST profile.  I think this discussion has really
just been about whether we should add a normative statement about
ConfirmationData that simply clarifies what we meant and what's being
implemented.  

We can discuss the matter on the next call and a) turn this into a normative
issue and restart last call after we resolve it, b) add a clarifying
normative statement as part of our post-last call final edits, or c) make NO
change to the last call spec.

Note that if we delay the start of Last Call until next week, I think it
means the schedule may get pushed into September...

PROPOSAL #1: I propose that we NOT make any statement about ConfirmationData
change:
-------------------
The <saml:ConfirmationMethod> element of each assertion MUST be set to
urn:oasis:names:tc:SAML:1.0:cm:bearer.
-------------------
to:
-------------------
The <saml:Subject> element for each statement being returned in the SSO
assertion(s) MUST contain a <saml:SubjectConfirmation> element where the
<saml:ConfirmationMethod> element MUST be set to
urn:oasis:names:tc:SAML:1.0:cm:bearer.
-------------------
This (I think) is REALLY an editorial clarification to the current text and
we can proceed with Last Call.  

PROPOSAL #2: Make NO change to the current text at all until the post-Last
Call edits.  As Scott and I have both noted, the text is currently
"muddled".  But if folks don't like proposal #1, I suggest we publish what
we have and deal with it as mentioned earlier.

Cheers!

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Thursday, May 01, 2003 11:41 AM
> To: 'Mishra, Prateek'; ''Eve L. Maler' '; security-services@lists.oasis-
> open.org
> Subject: RE: [security-services] A browser/POST question...
> 
> > I dont have a big issue with this but I do not really see
> > this as errata. Basically, it does not matter what the
> > <saml:ConfirmationMethod> is set to in the FORM/POST profile;
> > it is never discussed in the profile. So why explicitly
> > include a statement that says DONT use it?
> 
> Method or Data? Method is always bearer, of course.
> 
> In a sense, I guess that's what I was saying originally. If people were
> confused by the absence of a statement about Data, I was
> just trying to point out that sending it didn't make any sense.
> 
> > Scott, you have the most expeience with the POST profile. Do
> > you end up spending time discussing
> > <saml:ConfirmationMethod>? Is clarity the real issue here?
> 
> Yes, I think it's just a matter of clarity. It's never come up, but that's
> because I'm the one who implemented the profile, so the
> people using my code don't mess with what's happening underneath.
> 
> -- Scott