[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Proposed clean up on subject text
What about the case of, say, an Attribute query over SOAP? An Attribute Authority will respond with an assertion saying that "the entity with identifier X has the following associated attributes". I don't imagine that subject confirmation would be included, because the referenced entity isn't part of the exchange. So, the default interpretation of that assertion should definitely not be "bearer". I'd like to see text in core, section 2.4.1 "Element <Subject>", state that the absence of any SubjectConfirmation elements MUST be interpreted as having no correlation to any presenter of the assertion. Leaving it up in the air seems very dangerous to me. Somebody show me where I've missed it here. -- Steve Anderson OpenNetwork > -----Original Message----- > From: Conor P. Cahill [mailto:email@example.com] > Sent: Friday, November 12, 2004 12:42 PM > To: Philpott, Robert > Cc: Scott Cantor; SAML > Subject: RE: [security-services] Proposed clean up on subject text > > > > Philpott, Robert wrote on 11/12/2004, 12:35 PM: > > > [RSP] I agree with Scott. Parties could potentially agree on > > out-of-band mechanisms of confirmation that aren't conveyed in the > > assertion subject. The OOB mechanism could be something other than > > bearer. Lacking an OOB agreement, I agree that bearer would probably > be > > the default. > > So, from the assertion's point of view, it's a bearer token unless there > is some OOB agreement as to how it can be presented (such as a case > where the token must be presented on a client-auth SSL connection). > > In other words, the assertion makes no requirements on what one has > to do to confirm the subject. Other things may come into play, but > that's OOB and OOScope. > > Conor > > > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to http://www.oasis- > open.org/apps/org/workgroup/security-services/members/leave_workgroup.ph p.