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] | [List Home]

Subject: RE: [security-services] Issue of multiple authn statements during SSO

> > > as well as how to interpret a case in which you would get multiple
> > > assertions, each with bearer confirmation, and an authentication
> > > statement.
> >
> > [Rob] Not sure why you'd want to do it with multiple assertions.  As
> > said - I want to do it with a single assertion/multiple statements.
> Well, I was asking how we could better constrain or define what might
> up so that the profile is less ambiguous. It sounds like your use case
> could
> be met by saying that there should only be one bearer assertion with
> authentication statement in it, though there might be multiple
> in
> it. This doesn't preclude a separate attribute assertion, of course,
> additional non-bearer assertions for other purposes.
[Rob] Are you saying we'd allow one or more statements in a bearer
assertion, but not multiple bearer assertions with authn methods?  I
guess that works. Although for Web SSO, we also don't want to preclude
attribute statements from appearing in the same assertion with one or
more authn statements.  We want to do it this way to avoid the overhead
of using multiple assertions.

> > [Rob] It may be reasonable to say an assertion can have multiple
> > statements, as long as the statements all have different methods.
> Method (AuthnContext) is really not a problem, particularly
> how
> little anybody does with it anyway</snide>.
> I'm more concerned about attributes that have processing rules
> such as the Reauthn timestamp. At a mininum, we'd need to make a rule
> about
> using the shortest of the possible values, I guess, or preclude it
> appearing twice.

[Rob] I would NOT want to constraint the assertion to only use one
Reauthn timestamp or using the shortest.

I think the reauthn timestamps should always apply to the method in the
specific statement in which it is specified.  I would normally want a
reauthn timestamp on a low grade method to be longer than a high-grade
method.  The semantic is simply that if the SP relies on a specific
method for graded authn checks, then the reauthn time associated with
that method applies.  If you don't care about graded authn at the SP,
then maybe the shortest should be used.  But that would not work for the
graded case.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]