[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] A browser/POST question...
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]