RE: [security-services] Groups - SAML shared credential (draft-saml-shared-credential-discussion-01.doc) uploaded

["Scott Cantor" <cantor.2@osu.edu>]

> The IDP would recognize that it would be unable to satisfy the requested 
> AC class of #2 without authenticating the user in a different way.
> 
> So, yes I think this could work.
> 
> But, I have trouble understanding how it would fit with existing AC
> classes.

It may not. But at a minimum, I think we'd have to deal with this somehow
even if the solution chosen was similar to the original proposal because
"SwitchUser" doesn't tell me enough to know what it is you actually want the
IdP to do.

So I think SwitchUser is unnecessary and insufficient, essentially, but I
don't have a specific AuthnContext proposal on how it could be addressed.

Conceptually, it would seem that a new (or perhaps extension of an existing)
bucket in the AC schema would be used to capture whatever it is that we
think is actually important to express here.

The problem is that that probably applies to many of the existing context
classes (it's sort of orthogonal to them), which results in some
combinatorial problems.

> But, if the above URI instead looked like 
> 'urn:SAML:ac:classes:shared:mobile' (or 
> 'urn:SAML:ac:classes:mobile:shared"), giving the SP this info, the 
> implication appears that we need to extend all existing classes.

Right. I agree, it's not ideal. What I'm not clear on is how else you could
do it.

> If the AuthnStatement allowed multiple AuthnContext elements (like the 
> AuthnRequest does for RequestedAuthnContext) this wouldn't be an issue I 
> think.

Well, it can be handled on the assertion side more cleanly than on the
request side. In an assertion, you can actually express both a class and a
specific declaration. But on the request side, it's one or the other.

Bottom line, I agree, but I don't see any other piece of the spec that could
work. Attributes don't give you any kind of meaningful hook into the SSO
request flow at the moment, and the only way to influence how the IdP
interacts with the user other than very coarsely is AuthnContext.

-- Scott