[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] FW: [security-bindings] Multiple authn assertions in one Browser Artifact Profile exchange?
>> >>In the browser artifact profile as described in the >>bindings-06 document >>(http://lists.oasis-open.org/archives/security-services/200111 /msg00020. >>html >>, section 4.1.5), lines 565-567 imply that more than one >>authentication >>assertion could be transferred. This raises all sorts of >>questions about >>how >>the receiver should behave, particularly if the authn assertions refer >>to >>different subjects. This is a general problem whenever a bunch of assertions is bound to a "subject" and passed thru a profile from one entity to another. In this sense, it has little to do with the web browser profile itself and more to do with dealing with a plurality of assertions and statements associated with a system entity. We have a clear interpretation of multiple statements and multiple assertions in our specification. The RP must consider all of the assertions and statements as conjunctively describing the system entity. Generally speaking the RP's attitude should be to find the information it requires amongst the plurality of information and make its judgement. If there are multiple AuthN statements, well, it can pick out the pieces it needs and render its decision. The web browser profile will call out the conditions under which transfer of assertions via artifact is well defined. This includes (1) an assertion with at least one AuthN statement (2) certain counter-measures around the assertion carrying the authN statement. Other than these issues, the profile takes no position on the general question of multiple assertions and statements obtained via artifacts. I guess I would summarize my position on this as: I dont see the problem in permitting this type of generality. We have to deal with it anyway, in the general case. - prateek >> >>Do we want to say anything more about this? Alternatives include: >> >>(a) Make no changes to the spec. Implementers are free to choose >>whatever >>behaviour they think is appropriate for their solution. >> >>(b) Specify that all authn assertions must contain the same >>Subject (or >>at >>least, the same NameIdentifier within the Subject) >> >>(c) Specify exactly how the receiver should behave. Two possibilities >>are to >>say that access should be allowed if any one of the Subjects would be >>allowed, or that access should only be allowed if all of the Subjects >>are >>allowed. >> >>My life would be easiest if we choose (b), though I could see how it >>might >>be too severe a constraint on some applications. >> >> - irving - >> >> >>-------------------------------------------------------------- >>---------- >>----------------------------------------- >>The information contained in this message is confidential and is >>intended >>for the addressee(s) only. If you have received this message in error >>or >>there are any problems please notify the originator immediately. The >>unauthorized use, disclosure, copying or alteration of this >>message is >>strictly forbidden. Baltimore Technologies plc will not be liable for >>direct, >>special, indirect or consequential damages arising from alteration of >>the >>contents of this message by a third party or as a result of any virus >>being >>passed on. >> >>In addition, certain Marketing collateral may be added from >>time to time >>to >>promote Baltimore Technologies products, services, Global >>e-Security or >>appearance at trade shows and conferences. >> >>This footnote confirms that this email message has been swept by >>Baltimore MIMEsweeper for Content Security threats, including >>computer viruses. >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC