Title: RE: [security-services] SAML Authn Ctx Combination Spec
Paul, I see what you mean.
Basically, you want the text to say that only one "top-level" RequestedAuthnContexts element is allowed. But 0 or more second-level RequestedAuthnContexts elements are ok.
The other questions I had were:
- the meaning of RACComparison in relation to a RequestedAuthnContexts element that has RequestedAuthnContexts sub-elements and those that don't.
For those RequestedAuthnContexts that do not have RequestedAuthnContexts sub-elements, it seems that "all" should not be used.
For those RequestedAuthnContexts that do have RequestedAuthnContexts sub-elements, it seems that only "all" (and possible a new operator "either") should be used. Where "all" represents AND and "either" represents OR.
- I think that although the schema supports infinite nesting, the text should reflect that a RequestedAuthnContexts element is either a top-level element or a nested element (only one level deep). I.e., do *not* allow the following:
<RequestedAuthnContexts>
<RequestedAuthnContexts>
<RequestedAuthnContexts>
...
Tom.
P.S. it seems like introducting both RequestedAuthnContexts (with an and/or operator) and RequestedAuthnContext (with an AC comparison; perhaps even reusing the one from SAML Core) would make this simpler.
> -----Original Message-----
> From: Paul Madsen [mailto:]
> Sent: Friday, July 07, 2006 9:16 AM
> To: Thomas Wisniewski
> Cc: OASIS SSTC
> Subject: Re: [security-services] SAML Authn Ctx Combination Spec
>
>
> Sorry for the confusion Tom.
>
> The schema snippets I inserted in my previous message was not my
> proposal, but rather my interpretation of what you were proposing,
> (which I then tried to argue against :-) )
>
> My actual proposal to address the issue you raised was/is as follows
>
> 1) keep schema as is in v2 (5/18/06)
> 2) relax text that limited the number of <RequestedAuthnContexts>
> elements in a message to ensure that nesting is allowed
>
> thanks
>
> Paul
>
> Thomas Wisniewski wrote:
> >
> > Paul, I agree with your sentiments.
> >
> > Perhaps I'm looking at a diff version (5/18/06), but what you are
> > proposing obviously changes the schema and the example (you
> indicated
> > that neither would change). The current spec proposes a
> single element
> > RequestedAuthnContexts that was nested whereas the changes
> you propose
> > below would indicate a list of RequestedAuthnContext
> elements inside a
> > single RequestedAuthnContexts element. So the schema would
> changes as
> > you indicated below and the example would change to
> >
> > <RequestedAuthnContexts RACComparison="all">
> > <RequestedAuthnContext RACComparison="exact">
> > <saml:AuthnContextClassRef...></..>
> > </RequestedAuthnContext>
> > <RequestedAuthnContext RACComparison="exact">
> > <saml:AuthnContextClassRef...></..>
> > </RequestedAuthnContext>
> > </RequestedAuthnContexts>
> >
> > Tom.
> >
> > > -----Original Message-----
> > > From: Paul Madsen [mailto:]
> > > Sent: Friday, July 07, 2006 8:27 AM
> > > To: Thomas Wisniewski
> > > Cc: OASIS SSTC
> > > Subject: Re: [security-services] SAML Authn Ctx Combination Spec
> > >
> > >
> > > Thomas Wisniewski wrote:
> > > >
> > > > It would seem ok, but a bit awkward.
> > > >
> > > why?
> > > >
> > > > Would your example be changed to
> > > >
> > > > <RequestedAuthnContexts RACComparison="all">
> > > > <saml:AuthnContexxtClassRef...></..>
> > > > <RequestedAuthnContexts RACComparison="exact">
> > > > <saml:AuthnContexxtClassRef...></..>
> > > > </RequestedAuthnContexts>
> > > > </RequestedAuthnContexts>
> > > >
> > > > Is that whay you're trying to say?
> > > >
> > > the example wouldn't change. I was proposing leaving the
> schema as
> > > is, merely loosening the text that disallowed multiple
> > > <RequestedAuthnContexts> elements in a message
> > > >
> > > > Why not just have a top level (maxOccurs="1")
> > > > RequestedAuthnContext element that then defines an unlimited
> > > > number of
> > > RequestedAuthnContext
> > > > elements that have a comparison operator attribute and
> contain the
> > > > saml AuthnContextClassRef element.
> > > >
> > > So, something like
> > >
> > > <complexType name="RequestedAuthnContextsType">
> > > <sequence>
> > > <element ref="RequestedAuthnContext"
> maxOccurs="unbounded"/>
> > > </sequence>
> > > </complexType>
> > >
> > > <complexType name="RequestedAuthnContextType">
> > > <sequence>
> > > <element ref="saml:AuthnContextClassRef"
> > > maxOccurs="unbounded"/>
> > > </sequence>
> > > <attribute name="RACComparison" type="anyURI" use="optional"/>
> > > </complexType>
> > >
> > > we wanted the comparison operator on the top-level
> element as well.
> > > Given that, we tried to minimize the number of new elements by
> > > introducing the nesting.
> > >
> > > Additionally, the above forces an SP to insert the
> > > <RequestedAuthnContext> element even when all they want to do is
> > > give a list of <AuthnContextClassRef>s they want combined.
> > > >
> > > > Do I need to satisfy all the RequestedAuthnContext elements in
> > > > order to satisfy the RequestedAuthnContexts element? I.e., in
> > > your example
> > > > you say this is an AND -- so I assume the answer is
> yes. I.e., you
> > > > cannot express that you are requesting either AC-1 or AC-2
> > > (exactly)
> > > > in your schema.
> > > >
> > > the 'all' on the outermost <RequestedAuthnContexts> in
> the example
> > > requires you to satisfy both. We don't have an 'either'
> but neither
> > > does core SAML.
> > > >
> > > -
> > > Paul Madsen e:paulmadsen @ ntt-at.com
> > > NTT p:613-482-0432
> > > m:613-302-1428
> > > aim:PaulMdsn5
> > > web:connectid.blogspot.com
> > >
> >
> >
> ----------------------------------------------------------------------
> > --
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date:
> > 7/4/2006
> >
>
> --
> Paul Madsen e:paulmadsen @ ntt-at.com
> NTT p:613-482-0432
> m:613-302-1428
> aim:PaulMdsn5
> web:connectid.blogspot.com
>
