OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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
>>, section 4.1.5), lines 565-567 imply that more than one 
>>assertion could be transferred. This raises all sorts of 
>>questions about
>>the receiver should behave, particularly if the authn assertions refer
>>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
>>behaviour they think is appropriate for their solution.
>>(b) Specify that all authn assertions must contain the same 
>>Subject (or
>>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
>>My life would be easiest if we choose (b), though I could see how it
>>be too severe a constraint on some applications.
>> - irving - 
>>The information contained in this message is confidential and is
>>for the addressee(s) only.  If you have received this message in error
>>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
>>special, indirect or consequential damages arising from alteration of
>>contents of this message by a third party or as a result of any virus
>>passed on.
>>In addition, certain Marketing collateral may be added from 
>>time to time
>>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