Re: [security-services] Proposed Agenda for SSTC Conference Call,Dec 23

[Ron Monzillo <Ronald.Monzillo@Sun.COM>]

Scott Cantor wrote:

>>Note that the WSS SAML token profile describes how assertions
>>may be chained such that SAML assertions (and other types of
>>security tokens) referenced (by STR) from the  confirmation
>>method of an assertion may be used to identify additional subjects
>>(i.e. proxies) as part of the confirmation method sepcification of an
>>assertion.
>>    
>>
>
>This point is actually a bit more relevant to the work item on SSO proxying
>(proxies are really just an optional implementation detail of the LECP work
>item).
>
Scott,

I see. It looks like I was reading more into the proxying functionality 
defined by LECP.

>But note that this model of incoporating existing SAML tokens by reference
>as subject confirmation is fundamentally unusable in deployments with
>privacy-preserving identifiers. You can't expose the principal's identifier
>to the new relying party in the chain, and you can't encrypt it without
>breaking the signature.
>  
>
I understand. The mechanism I described could be used by the intermediate to
proxy for the invocation subject presented to the ultimate relying party.

The principal identifier of the invocation subject seen by some other 
SSO related
relying party (including the intermediate) need not be exposed as a 
result of
authorizing the intermediate as proxy for the identifier presented to the
downstream relying party.

If the assertion presented to the intermediate identifies a principal that
must not be shown/known to the downstream relying party, then the 
intermediate will
have to acquire or issue a new assertion with an appropriate invocation 
subject
identity.

I know I am not following the subtleties of this thread. I just wanted 
to point out that
SAML-authority authorized proxying is a feature that the SAML token 
profile of
WS-security accommodates (in addition to the basic sender-vouches 
mechanism).

Ron

>-- Scott
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.
>
>  
>