Whether consent has been issued not specified

Comment

One of the issues with the third party query mode, is how does the AA know that the user has issued consent for his attributes to be retrieved by the grid PEP.

I propose that we insert the Consent parameter (see Section 3.2.1 and 8.4 of SAML Core) into the third party query with a value of Implicit. The fact that the user has initiated the grid job request, causing the PEP to pull his attributes, implies that he wants his attributes to be retrieved so that his job can run otherwise he would get an authorisation failure message response). It therefore seems perfectly reasonable for the PEP to insert the Implicit Consent parameter into the request to the AA.

Answer

The Consent attribute MUST be present in the request, since the attribute value defaults to "unspecified", which is not what we want. Note that SAML2Core requires the request to be signed (lines 1511--1512) (if a Consent attribute is included and the value indicates that some form of principal consent has been obtained, then the request SHOULD be signed.)

Cannot bound assertion to proxy certificates

Comment

The SAML assertion listed in Appendix B cannot be bound to an X.509 proxy certificate since the subject of the assertion can not be confirmed. The value of ds:X509Certificate in SubjectConfirmation element above is the user's X.509 end-entity certificate (EEC) but since the user authenticates with a proxy certificate, the user proves possession of the wrong private key. Thus the subject is not confirmed and the relying party SHOULD discard the enclosing assertion. So that the assertion may be bound to an X.509 proxy certificate, the identity provider should bind the DN of the EEC to the <saml:SubjectConfirmation> element.

Answer

As suggested in the comment, we have changed the assertion in the appendix which now binds the DN of the EEC to the SubjectConfirmation element. This suggested to change the AttributeQuery. accordingly, which need to request the binding of the DN to the element. The profile should specify the content of the <saml:SubjectConfirmation> element by referring normatively to SAMLHoK..

Allow for other mean of authentication than X.509 Credentials

Comment

The profile SAMLX509SelfQry assumes that the user authenticates to the SAML Attribute Authority (AA) with an X.509 credential, which is too restrictive. The user should be able to authenticate with any type of credential, even a username/password, as long as the requirement for a holder-of-key assertion is satisfied. To permit flexibility in the authentication token used to authenticate to the AA, the specification needs to separate the authentication step from the proof of possession. The following requirements achieve the required separation:

• The user MUST authenticate to the AA, but the means by which this authentication takes place are unspecified
• The user MUST present an X.509 certificate to the AA
• The user MUST prove possession of the private key corresponding to the public key bound to the certificate

Answer

The proposed changes have been accepted. This implies that SAMLX509SelfQry is not sufficient. As an alternative, refer normatively to the SAML V2.0 Holder-of-Key Assertion Request Profiles.

Issuing and processing of holder-of-key SAML assertions is not well defined

Comment

The issuing and processing of holder-of-key SAML assertions is not well defined in SAMLX509. Moreover, such requirements are not specified in SAML Core, so there is nothing to rely on. (The OASIS SSTC is considering this issue SAMLHoK at this time.)

Answer

Do not cite section 4 of SAMLX509 in the OGSA Attribute Exchange profile but cite the SAML V2.0 Holder-of-Key Assertion Request Profiles instead.

User presence is not proven

Comment

Since the profile SAMLX509 specifies that the name identifier in the query is a DN, there is no way to prove user presence at the Grid SP. Without proof of user presence, an SP could phish for attributes using the globally unique, persistent DN. Note that this issue does not exist for the self-query (of which traditional VOMS is an example), rather the problem involves a query where the requester is acting on behalf of the subject. In that case, the subject must pass some piece of information to the Grid SP that the SP can forward to the AA. I'm convinced we've specified the name identifier in the query (DN) incorrectly. The requester has to prove user presence and it seems clear that more than a DN is needed. Since the user is authenticating to the Grid SP with an X.509 certificate, the obvious conclusion is that 1) there is some piece of info in the certificate that proves user presence, and 2) the SP passes the complete cert (not just the DN) to the AA.

Answer

The SP using the certificate in the Subject does not prove user presence at the SP, as the certificate is not any more private than the DN.

We believe that proving user presence is out of the scope of this protocol, but instead will be part of the authorization mechanism an AA will take to decide whether to authorize or not an SP to query for a principal attributes.

Figure not clear

Comment

In Fig 2 of OGFSAML, it is assumed that the requester is the SAML subject (i.e., the end user). What if the requester is not the subject, but rather an entity acting on behalf of the subject? How does the Grid SP know if the requester is the subject or an entity acting on behalf of the subject?

Answer

The value of the <saml:Issuer> element in the request MUST be the subject distinguished name (DN) of the presented certificate (see the Holder-of-Key Assertion Request Profiles). The value of the Consent attribute SHOULD be "urn:oasis:names:tc:SAML:2.0:consent:self" (where the latter will be specified in draft-02 of the Holder-of-Key Assertion Request Profiles).