[OGSA-AUTHZ] holder-of-key or sender-vouches SAML token?

[wz qiang]

hi,

On 5/8/08, Tom Scavo <trscavo at gmail.com> wrote:
>
> There's a problem with the Attribute Exchange Profile it seems.  If
> you bind a VOMS-SAML token to a SOAP message and authenticate via
> WS-Security SAML Token Profile, everything is fine because the key
> bound to the SAML token is the same key presented to the RP.


"the key bound to the SAML token is the same key presented to the RP", here
you meant the the key bound to SAML Token is the same key which signs the
VOMS-SAML token? If so, I can not see any real scenario for this. The
VOMS-SAML token (or any other attribute token) should be signed by some AA,
but the "hold-of key" situation in SAML Token (WS-Security) should present
the principle of the identity (which means should be the identity
certificate which signed by some CA).

 However,
> if you bind a VOMS-SAML token to a proxy certificate, there are
> problems since the key presented to the RP is different than the key
> bound to the SAML token, and so the holder-of-key subject confirmation
> on the assertion is not satisfied.


Why is it a problem here? Why can't we just put VOMS-SAML token into proxy
certificate, and look it the same way as traditional VOMS AC (attribute
certificate)?

An RP is obliged to reject the
> SAML token in that case.
>
> Here's an example of a SAML token with holder-of-key subject confirmation:
>
> http://www.globus.org/mail_archive/gridshib-user/2008/05/msg00011.html
>
> Now a VOMS AC is essentially a security token with sender-vouches
> subject confirmation, so I wonder if the VOMS-SAML assertion should
> have sender-vouches subject confirmation as well.


I agree.

Alternatively, the
> proxy certificate could be constructed such that its key is the same
> key bound to the EEC.


The same as above, the AA and CA should not be mixed, I guess.

In that case, the SAML holder-of-key subject
> confirmation requirement would be met since all the bound keys (EEC,
> proxy, SAML) are the same.


Regards,
Weizhong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-authz-wg/attachments/20080509/d4eac833/attachment.html