[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 I > > 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 show > 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 an > authentication statement in it, though there might be multiple statements > in > it. This doesn't preclude a separate attribute assertion, of course, or > 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 Authn > > statements, as long as the statements all have different methods. > > Method (AuthnContext) is really not a problem, particularly <snide>given > how > little anybody does with it anyway</snide>. > > I'm more concerned about attributes that have processing rules attached, > 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 from > 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]