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

[Paul Madsen <paulmadsen@rogers.com>]

Scott, thanks, its good to get confirmation that I wasn't missing 
something trivial about AC

I'll take the action to dig to deeper into authn context schema and 
classes to better understand what might be possible .

I'd expect there are other similarly orthogonal aspects of 
authentication for which we'll come up against this in the future.

paul

Scott Cantor wrote:
>> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>
>   

-- 
Paul Madsen                        e:paulmadsen @ ntt-at.com
NTT                                p:613-482-0432
                                   m:613-302-1428
                                   aim:PaulMdsn5