Hi Yuri answers to your questions below Yuri Demchenko wrote:

Hi David,

I fully support the idea to define credentials validation service as complimentary to XACML based AuthZ service.

thanks

It's known that XACML TC keeps strictly from adding attributes validation functionality to the specification.

This service/functionality is needed and we will support its specification.

I read both your drafts and have few general and specific questions.

Most of general questions are related to the terminology and definition of some basic components. Below are some of them.

1) I don't know whether it is necessary to introduce in this particular specification, that deals with credentials validation, push and pull models (for attribute I guess?).

this is credential push and pull, not attribute push and pull

If you want to request attributes based on the authenticated Subject creds/ID, this is actually Attribute Authority (AA) function. So, why we should embed it into CVS?

I am not doing this. The AA function still exists, as a separate remote function. All the CVS is doing is asking the AA to give it the user's credentials, which it will then validate according to the local policy, and if they are acceptable will return then to the PEP along with the other validated attributes.

Keeping CVS to perform its major function to validate presented credentials/attributes would be more logical.

this is exactly what it is doing. But the credentials may be pushed to it (as in VOMS) or pulled by it (as in GridShib)

2) in WST/SAML document you have sections "4/5. Request Protocol, Push/Push model" and "6. Response Protocol"

Is it what you mean that there will be separate request and response protocols respectively? However currently you describe only request and response messages.

The idea is that there is only one response protocol, regardless of whether the credentials were pushed or pulled or both. In the most complex scenario you could have 1. PEP pushes some credentials to the CVS 2. CVS pulls some more credentials from remote AAs 3. CVS responds to PEP with the complete set of validated credentials. An example of when this is needed is when the user has been delegated a credential and only gives this to the PEP. The CVS sees that the credential is delegated and then goes to the AA of the delegator to get the credential of the delegator. The CVS may then have a complete chain of credentials from the user to the trusted root. (The CVS may need to go to several AAs if the delegation chain is a long one)

3) Can you clarify what is meant by "WS-Trust request protocol message" in section 4?

In section 4.2 it is specifying how the SAML attribute assertions (specified in 4.1) are wrapped inside a WS-Trust message to tell the CVS what it has to do with them, which is to validate the SAML assertions and return a single assertion in XACML format.

WST specification specifies mechanisms that can be added to other protocols and messages especially WS related and SOAP based.

4) I can guess that in section 7 you define a new element <SubjectAttributeReferenceAdvice> but it is not clear if there is no currently available solutions to do intended attributes request based on authenticated Subject ID, e.g. in GridShib to which you refer in Request pull model in section 3.1.

SubjectAttributeReferenceAdvice is actually copied from the existing OGSA SAML profile. But if you have an alternative way to do this then I am happy to use it. The GridShib interface is actually a Java method call so they dont have an equivalent XML protocol for this (but Von and Frank can correct me on this if I am wrong)

5) In regard to security considerations it should be explained somewhere how you protect CVS response message from possible tampering.

Good point. This should be added to Section 8.

Should it be signed by CVS or the WST security mechanisms should be used?

We should debate this. I dont have any strong opinions either way (except that for performance reasons I prefer SSL :-)

Other minor and document specific questions and comments I will better provide in a form of revision of your documents.

Many thanks David

Regards,

Yuri

David Chadwick wrote:

...

Dear All

please find attached my first strawman proposal for a profile for accessing a credential validation service/security token service/PIP.

This document is the first of two. The second will be a profile for XACML for accessing a PDP. As you will read from the attached document, the input to the CVS is a set of credentials, and the output is a set of validated XACML attributes ready for input to the PDP. I look forward to your comments on the above either before or during the next GGF meeting

regards

David

I have uploaded the attached to gridforge but it does not appear to be visible to the public yet.

-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************