[Concordia] CardSpace support for Authn Mechanism Policy

[Paul Madsen]

correction, the <Issuer> does not go in the 
<RequestSecurityTokenTemplate>, but rather in the container <IssuedToken>

Key is that the <IssuedToken> is RP policy over what it desires in the 
eventual token that is issued to it

paul

Paul Madsen wrote:
> Hi Scott, I should have been more specific, the <Issuer> I was referring 
> to would be any that the Infocard RP would specify in its 
> RequestSecurityTokenTemplate, e.g. what Managed Card Provider it wanted 
> the identity selector to send the RST to.
>
> I was assuming that, for the demo, the Infocard RP would not try to 
> force a given Managed Card Provider
>
> paul
>
> Scott Cantor wrote:
>   
>>> Otherwise, when constructing the <IssuedToken> element the hybrid
>>> provider SHOULD NOT specify an <Issuer> element, but rather create a
>>> corresponding required claim type, taking the value of the
>>> RequestedAuthnContext and inserting it into the URI attribute of the
>>> <ClaimType> element within the <RequestSecurityTokenTemplate>
>>>     
>>>       
>> Is it necessary to dictate no Issuer? I would think that would be
>> contextual. If I had a single IdP handling both the Cardspace and pure SAML
>> IdP functions, I ought to be able to use the same issuer identity, which
>> simplifies metadata and trust mgmt.
>>
>> -- Scott
>>
>>
>>
>>
>>   
>>     
>
>   

-- 
Paul Madsen             e:paulmadsen @ ntt-at.com
NTT                     p:613-482-0432
                        m:613-282-8647
                        aim:PaulMdsn5
                        web:connectid.blogspot.com